Hello Martin,
thanks for the extensive reply.
However, for web designers the templates and modules are as important as the core itself, so we agreed that there should also be a modules development team. (actually, the idea is not new. I believe Manuela has announced such a plan mentioning you as one of the coordinators already some time ago).
I don't remember being announced as coordinator for module development or a team dedicated to such a task. And I never anticipated such a role for myself.
I am interested in building my own modules and have done so in the past with several developers but stopped development until the 2.8.4. will be finished and released.
Another task which came up for the module development was that there should some kind of API or functions which the modules can call, some set of default variables and some kind of guidelines how modules should be written so that it fits well together with any template.
Once, there is such an API, or however you would call it, we can take old modules and simplify them.
I see.
That's a good idea for sure.
It's not an easy task to create a "one size fits all" semantik for the frontend layouts of modules (so the layout output of modules fits in all templates), but it should be possible to make it better as it is now. And moving away from the table structure in modules like News or Form (and in this way providing an example for community developped modules) is a good idea.
One example is that many modules come with their own upload mechanism - and if there was a framework which provides ready-to use dialogs for such standard tasks, one can replace the module's own mechanism by this framework, which is then maintained (e.g. receives security patches in a central place).
Understand, however, mechanisms like this should be part of the core.
The core has a (ACP-) Module "Media" which needs a handler for data (images and txt files at least) upload.
Creating a clean upload handler that can also be used in modules should be considered as core- component. (And of course, the community should contribute to the core - as one person alone won't make it all by herself.)
Another example is the inclusion from the edit-area (or code-mirror or such). Some Community Developped Modules need it and the core should provide it- as it may need it for example for the upcoming, Twig based, Search Loop Template (in Frontend).
Yet another example may be the upload of zipped folders. The core needs it, and, if well adjusted, the same class could be used for core-needs and module-needs as well.
(Just like the access pages class is used in core and can be used in modules as well.)
So I wonder why a module-based-api is being approached, instead of creating a team which works on solutions that can be used in core AND modules as well.
As for the building of a team which updates existing Addons: great. That's allways welcome.
As far as I know, Ruud has a list of modules that should be updated. I even updated one or two but have seen that such a task really makes sense at leeast after the release of 2.8.4. (inclusion of Twig) and even better, after a rework of the ACP (Admin Control Panel / Backend). The latter because in the course of reworking the ACP a whole new Backend-Style-Guide can be defined, and thus creating the base for uniformity of modules (look and feel) independently of what "Backend-Theme" is installed.
(If you have any questions in this regard, drop me some lines.)
This is not to say that reworking modules should be suspended until a point in the future. I am only pointing out that what can be done now can only be a phase one of the entire process of modernization.
But for sure, with the release of the 2.8.4. many things in the modules may be reworked (and because you can coordinate with the core-developer, the work can be started immediately).
Scanning through the modules and deciding what is really needed and doable in
phase one is a reasonable starting point.
Kind regards,
Stefek
Support WebsiteBaker
