Our goal is to make things as simple and clear as possible and to put things where they belong. In the end, provided some documentation of course, it should make searching for files easier.
The number of templates is supposed to grow because more hardcoded things get templatized. And, yes, we should shorten the names in this case. Anyways, we'll try making it even more simple than it is now.
Alright, I have spent quite a while thinking the modularization concepts over and here is what I have come to.
. Originally it was supposed that we are going to separate Modules and Plugins, then put big things to Modules and small things to Plugins. It would require separate APIs for them, etc. But what I have come to is that in fact everything should be a Module. In this way we would have a universal way to handle them all, no reason to duplicate APIs, have separate folders, etc.
So, a Module is just some part of engine that may have standalone parts (including root-level scripts) as well as parts that hook into other Modules. All the core modules (pages, list, forums, poll) will become Modules. All the plugins will be upgraded to Modules too. Changes listed in Plugin API changes
will be applied on hookable parts of modules.
. A Module may require some other Modules to be installed or at least present. For example, RecentPagesByPath would require Pages and Index. So Pages/Index would be installed before it (automatically if possible) and if one of them is removed, RecentPagesByPath is removed as well. The dependencies concept ensures system consistency and might be enhanced with on-line module repository later.
3. Directories and file names
. The rule is: the easier the better. Let's get rid of annoying prefixes and postfixes, e.g.:
admin/admin.plug.inc.php => admin/plug.php
twitter/lang/twitter.nl.lang.php => twitter/lang/nl.php
Now, putting modularization and simplification together, let me show an example file tree:
datas (no changes)
js (no changes so far)
lang (core langfiles required by all modules)
js (some JS files if required)
tpl (default tpl files that come with a module)
(etc., for modules with 1 template)
sql (no changes)
Alternative proposal would be for putting all lang files in lang directory, e.g.:
(same as en)
(same as en)
Which is better for langs - I hope translators answer this question for me.
Please post your comments below. We need to decide about this before we start changing structure.
4. Admin part
. As Modules concept is unified, so that there is no more core/plugins, it means that admin part needs to be rewritten. I suppose there will be a tree, so that there are root-level modules (formerly known as core), on the second level modules that expand/depend on them, etc. In the UI it could be done as a context menu or desktop-like icons.
Each module will have its own configuration, its own permissions (with more than 1 area) and if admin.php is supplied, it will be run in Admin => Module_name too.