This is an overview of all the file permissions that may need to be set to enable certain features in your iWiccle.

Understanding the logic behind iWiccle folder permissions is simple:

• /uploads and all folders in it (namely /modulename/thumbs), whatever they may be with your module selection, need to be writable (CHMOD 0777) as they contain files uploaded by your users using your modules.
• /tmp and the /export and /import subfolders need to be writable (CHMOD 0777), as they contain temporary files that are processed and transferred for download or to other locations. Whatever files you may find inside these folders are safe to delete, unless you are in the middle of a system operation.
• With system file operations in the Admin CP (such as creating a new skin, cloning a module or importing a new language), whenever new files are imported or cloned to any other directory (such as to /templates, to /modules and to /languages), then those folders need to have write permissions for the duration of the operation.
• The /core and its subfolders should never be given write permissions; they should remain at default permissions. The /installer folder should be left at default permissions; this has been the case since version 1.10, and is something you should not change to 0777 (as told in our ancient installation video for 1.01).
• Whenever a folder is not used for uploading, it's a good idea to reset its permissions to default to minimize the amount of writable folders in your system.
• You should periodically review the contents of your writable folders (/uploads and /tmp) to ensure that no attempts at importing backdoor scripts or other malicious/illegitimate content have taken place.

Upcoming Security Features

The notes above on importing or cloning files to /modules and to /languages is something that will be introduced in a near future release as a part of a more comprehensive extension importing and exporting setup. There will be an FTP class to provide one-click extension imports, upgrades and patches directly through the Admin CP without a need to log in over FTP to upload files or set permissions.

We are currently developing system integrity and security review tools for the Administrator Control Panel that'll give you a centralized security toolbox and lets you ascertain that every area of your filesystem contains only the data that it's intended to, and also lets you scan user input for hacking attempts.

To give you an idea of the level of screening we are talking about, there will be a System Integrity Scanner that will compare each file in your filesystem against an updatable md5 grid containing the original hash imprints of the files you uploaded to your site. This will make it very easy for you to verify the integrity of your system whenever any suspicious activity has taken place.

Explanation of Upload File Names

All uploaded files are renamed and their names standardized into a lowercase string and extension that look something like below:

• s60_news-1-1264550499_myownphoto.jpg

This is an example of a thumbnail name. The original image (if source images have been chosen to be saved) would not have the first prefix of the filename.

s60_ = the automatically scaled image thumbnail size (by default 60/160/250/400/600 pixels), indicating the maximum length of the longer side of the image. The different sizes are used across different content formats to ensure as fast loading times as possible, and to avoid downrescaling by HTML. You can configure the sizes at /core/variables.php under $core['image_sizes'] and override them on a per-module basis by copying the setting to the module's configuration files.

_news = this is the module identifier for the file.

-1- = your member ID in the database. If you spot a suspicious-looking upload attempt, you can get straight from the filename to deleting the member who tried to hack your site. (We get the occasional madshell.php.jpg attempt at our demo!)

1264550499 - This is a unix timestamp corresponding to the exact time of the upload, and helps further connect uploaded files to database content, as well as to locate unused files for deletion (admin tools for upload maintenance will be available for the next release).

i can honestly say

the details here are so specific, i have absolutely no questions about how / why it works the way it does.

Thanks Markus

Glad it's coming in handy and is clear enough.

The idea has been to make the system crystal clear to understand. The more there's confusion as to what does what and what stands for what, the more complex bugs become, and the more slots you have for people to try to haxor your site.

If you ever come across anything in our productions that doesn't make sense, please give a shout and I'll either explain or revise and then explain. There are still some slightly raw areas I haven't had the time to systematize and polish, but they shouldn't concern the average user at all.