96
First let me say that this is a copy paste of an email I've sent to Nicolas and Mage. Since I forgot to include all the core team and because I think this deserves the attention of module developers and the whole community, it follows:
1 - I would like to convert 'mymenus' module into 'menus' and use it as an official menus module. It will hold the actual system mainmenu and it will use the plugin system to get dynamic menus from modules. One less item in xoops_version.php. The idea of xoops_version is not to execute logic. Sometimes modules don't respect this condition and we get hits on performance by having code executed that is not required,
2 - I would like to remove onUninstall, onUpdate, onInstall hooks from xoops_version. They should be implemented as plugins of the system module, just like search, notifications, comments and menus
3 - We should consider dropping extensions and find an effective way to navigate on the admin side. For performance reasons, I would like to remove drop down menus. I would prefer a single entry page with all modules icons. Then, after clicking on the module, we should get access to preferences and other options. A drop down just for listing modules is acceptable. We could use a separation line for modules that have no main, this way the modules(that are now extensions) will be displayed in the bottom, they are usually the less accessible modules.
/************/
Well, regarding extensions:
I find it very confusing. Some times I want to change preferences on some module(example search) and I don't know if it is a module or an extension. How can we distinguish modules from extensions? At this moment I assume extensions are modules that have no main content. Search and tag sound to me like extensions, but they are modules just because they have front pages.If we were going to create separate folders, we should also have to create separate db tables, separate methods of getting configs, of loading handlers, of getting forms etc. For me, it does not make any sense doing that because there is just one difference in the way we code both of them, a single line saying extension = 1;
The idea of using extensions was to simplify the navigation on admin side. I think the goal was not accomplished. For me it is revealing to be more confusing.
I would like to propose to list the modules as it was done before but with one difference. Modules with main on top, Modules with no main on bottom. The sorting of the weight of modules should be done as before, with drag and drop. Weight of modules is important, it is not just for menus, it affects the order of the execution of preloads, the order how they are displayed on a sitemap, and perhaps the order they will display in the front page of the admin side.
/*************/
4 - Add back the module sorting(weight) with drag and drop. We need to sort modules not just for menus, but also for priority on preload, sitemaps, etc.
5 -Remove the system waiting block, we can/should make a module for that (that uses the plugin system)
6 - Making mail module(extension) not uninstallable. We need this as core module because webmaster may need to retrieve their passwords. We don't want to support users asking how to enable the mail module when they can't even login!
7 - Refactor preload to use simple names like beforeCacheCheck, afterUserLogin, etc. The actual method of naming preloads following the module/file is not good. We are moving files around and getting preload names that are not coherent anymore.
8 - Look for preloads in module/class/preloads.php. I guess there is no need to support preloads on several files like core.php, sytem.php, etc. Modules will not be using preloads to hook with each other, they will use the plugin system now.
9 - At the moment xoops_lib path is asked during installation for users that may want to put it on private folder. Problem is that we are using classes that are located on this folder for the install process. If the folder is moved, the install will fail to load the required classes. On the future perhaps all classes will be moved to xoops_lib, so it is not a solution to copy/paste the missing class to the install folder.
We have 2 options:
- Don't ask for the path of xoops_lib, assume it is on public folder, If users wants to relocate it, they can do it after installation.
- Don't make use of core classes until the users have inputed the correct xoops_lib location.
I would like to say that xoops_lib is totally ok to be on public folder, security is not an issue. Users could move it if they want to share a unique location for different xoops installations. Only xoops_data is essential to be private/htaccess protected.
10 - It would be nice to have the install completed in the less steps possible. It would be great for promotion if xoops could be installed in 1 step. After step one we could have a "go to site button" or a "configure your site" which would lead to extra steps(install modules/themes/etc). 1st page would do the requirements checking and if positive ask all the data needed (db, username, etc). It would have also have a language select box that if changed, would refresh the all page. It would be simple, effective, amazing and again(kick wordpress on the but)
11 - Translations. Should we go for ini files? My choice is ini files. There are some drawbacks from dropping defines, we loose smarty.constant for templates (although we can make a smarty plugin to get language) . We loose editor autocompletion, we will never notice a typo until we see it on the rendered page. The advantages are great, we can override items that are not yet translated. If missing from french file, just get the english version of it.
12 - Compatibility with 2.5.5
Although compatibility is planned for 2.6, there are things that will mostly like break modules:
- code is ready for php 5.3 using proper type checking on methods, CriteriaCompo does not accept strings anymore. This was enough to stop publisher from working-
- Re factoring of XoopsForm introducing interfaces. Modules that use custom forms that extend the core ones will fail because they do not implement some of the methods. Again, this was enough to break publisher.
- Search, Notification and Comments . This will not work without changing modules.
- Translations. We should use en-Us, pt-pt, etc for language folders. Should we support inclusions for legacy folders?
It seems that compatibility will not work for the big modules but it should work for simple modules.
My issue is, should we consider dropping compatibly completely? By completely I mean dropping support for GLOBALS, TEMPLATEOPTION, language files.
If we do drop compatibility we should assure the upgrading of old modules by the core team, when requested.
