History: TikiInstallFeatureDev

For the moment this module is not yet planned, but here are few musings on the whole idea

Reasons to have this module/feature

(I still do not know the difference in tiki-speak when you are used in your dayjob to call it a module, but ... whatever 😉)

Tiki is growing with every release. More and more features and modules are being added and so the codebase keeps on growing as well.

The profiles that are currently under development are a great way to aleviate the admin's job from setting all the options for the features he/she wants to have on his/her site(s).

However, this is not enough for all ...

Not everybody needs 500+ avatar images (since they do not use the forums), "N" languages or "M" different styles.

And then I am not speaking of the amount of code that remains unused in your htdocs or public_html or similar directories and just sits there, taking up (precious hosting space).

There are quite a few users out there that have a tiki site on a free hosting site and/or a small budget hosting. I'm speaking of the <= 100 MB hosting sites. Apart from the fact that they have a MB quota, they often have a file quota as well. For them, current incarnations of tiki are becoming unviable, since a release from the 1.7.3 tarball is taking up a lot of space (3000+ files and 24MB). Add to that session files and cached templates and you have little room left for anything else on their site.

Apart from the fact that not everyone is as happy with opening up directories in their public web space for file uploads, some things just do not belong in the public section of the webspace (most notably: db, lib, templates_c, etc ...).

It is also sometimes needed to place these directories in a mutual place for a multisite tiki running from the same code.

Current way to fix

So, most ppl I know that use tiki move those sensitive directories around, remove the files they do not need, place some .htaccess files to restrict other sensitive dirs (for instance the templates_c and lib, which cannot be moved around) and maintain their site(s) like this.

As you clearly can see, with the current rate of releases this is a bitch to maintain.

Proposed solution

A little refactoring is required (or much), and it needs to made clear what files are used by all modules and which features/modules are inherent in the core functionality of tiki. All the other features/modules need to be divided to their respective files and it needs to become documented what files they use, and on which features (other than 'tikicore') they depend upon.

Feature preferences pages

An install module takes over from the Admin feature-preferences pages. The page to enable/disable specific tiki-features that were already installed is pulled from the database (and placed appropriately under the section they belong to in no specific order, or alphabetically).

During the install process maybe a new page is installed to manage specific settings as well.

naming conventions could prove golden here.

Functionality