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 ) Prerequisites:
AdminMayhem
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 ... TikiFeatureBloat
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). BudgetHosting
Fixed directories and security
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 | |
As you clearly can see, with the current rate of releases this is a bitch to maintain. |
Proposed solution | |
Tiki Core and all other modules/features
Install module
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 So, how do you go about it then? Installing a feature would involve the next steps
Making Patches Not only would it be possible to make these modules/features be patched in between versions of tiki, it would also allow to make an update patch between tiki (core) versions possible. Removing installations This one is even more trickier then an install or update. It should be possible to deinstall certain features, but with the exception that anything in the database is to be maintained in it. (after all, there could be other features/modules still installed that are in need of that table/data), or when they are still needed by other modules/features, leave the files as well (or abort the whole uninstall or display the dependencies). Making distributions In fact, it could also be noted that you could also do the opposite as well. Select the files that belong to a certain feature/module, name it, package it along with a script and distribute this as well. (for backups for instance when you have customised a feature).
|
Naming conventions | |
in short:
Where:
|
Script | |
It is divided up into sections (example): tiki-myFeature-1.7.3-1.0-install.tar.gz //FEATURE DESCRIPTION
//REQUIRED BEFORE INSTALL
//DB SCRIPT
//INSTALLATION FILES
$feature is a macro that in this case is substituted by myFeature predefined directories
modus operandi
|