Quote:
but as i always advise keep the number of basic pack as minimum as possible one module for each category/job.
eg: one gallery is enough like extgallery or one partner module like xoops partner.
Yes, this will be our approach!
Right now I am focusing on converting the modules to Admin GUI, so they work with no errors on PHP 5.4.8
As next step, I would like to consolidate modules and their features, so as you've suggested, there would be only one calendar, one gallery, one partner module, etc. Hopefully, we'll have a good discussion in the community to which modules should stay as the "official" modules of the "Basic Module Pack".
These modules would then have import function to import the data (if possible at all), from other similar modules.
And at the same time, I would like to extract the coolest features from individual modules and implement them across the whole "Basic Module Pack", but this might happen in XOOPS 2.6.0.
My goal is to keep all modules as consistent as possible, i.e. if I go to module ABC it will have the same files names and folder structure, and the same code as module XYZ, so if we need to change something, it will be a very straight forward process, of copying files (or parts of the code) to all modules, and we are done.
For example, right now we have "update" script under different names, and located in different folders. Some of them are in the main directory, some are in /include, and I've also seen in the /sql folder.
If everybody does the coding in a different way, then we are back to the same mess as we are right now, i.e. we have to spend tons of time trying to figure out what the developer wanted to do and why, before we finally can make some changes to it without breaking anything in the process.
Now, if somebody thinks that there is a better way to implement certain feature, then please let us know the reasons, and we'll do it.
Because the most important thing for me is that we have a consistent source code across all modules, as it will make maintenance easier in the future.
The current release of Basic Module Pack is focused mainly on making all the modules using more or less the same XOOPS 2.5.5 Admin GUI.
But in the next release, I would like us to share and reuse as much code between all the modules as possible, so moving to XOOPS 2.6.0 will result in a very consistent source code base, making maintenance in the future much easier.
And the way the Core Team is refactoring the Core, XOOPS 2.6.0 will give us the foundation to reuse a lot of code between modules. From what I've seen so far, XOOPS 2.6.0 will be a very exciting platform to quickly build modules and applications!
This will be the same as with our current switch to ModuleAdmin class. If all modules are using it, then we need to make changes only this class, and all modules using it will benefit from that change
