Plugins and Subsites

Plugins that do not generate their own data (for example TableSort) work fine even in subsites and their second languages.

In normal multilingual installations (without subsites), also data generating plugins work fine.

The problem in subsites

In subsites may be problems with data generating plugins, when they store their data in the plugin folder of the main installation, and support multilingualism by data files names like:

etc.

Because the language files ​​are used multiple in the subsites and their second languages​​, this type of distinction is not suitable anymore.

The Solution

This problem can only be solved by the plugin developers reliable. The plugins should be programmed to store the data in the content folder of the respective subsite or second language.

If the data path is configurable, it should not be configurable from the CMSimpleRoot, but from the root of the respective subsite or second language.

Only in this way ensures, that different subsites and second languages not uses the same data files, and can change it.

Access protected plugin data

Access protection for folders via .htaccess is only effective on Apache Web servers. On different Web servers, the Administrator himself has to take care of the access rights of its folders.

The plugin data should be stored in a sub-folder of the "content" folder of each subsite or second language. This folder is protected by .htaccess from prying eyes, and that's also inherited to the subfolders.

But: this protection can also cause problems, for example in galleries. Suddenly the images or thumbnails are not visible, the reason is the access protection by htaccess.

Therefore, there is a folder

./content/plugins/

in which this protection is canceled by .htaccess. Also this is inherited for the subfolders.

If there are no sensitive or non-public data in the plugin, the data path can be a sub-folder of

./content/plugins/