I know it's listed as a GSoC idea. This is just to talk about how it should look / what approach to take, regardless of whom the developer might be.
I've been looking into the module system lately and there are quite a few problems, of which most are already known but let's list a few. As this will also help determine what the desired outcome should be.
- Currently categories can be endlessly nested, but are not properly displayed.
For example, you can move the entire "General" category to be a child of the "Forums" category.
This will result in the actual modes not showing up: http://prntscr.com/mn50mg
- Currently there are two "modes" (only checked the ACP) that are not listed under a "Subcategory".
This being the actual ACP Index and a Permissions Index mode. They are currently accessed by clicking on the "General" or "Permissions" category, cause they are per default the first active mode under that category and therefore displayed. However, as soon as they are moved within that category, they are no longer accessible. http://prntscr.com/mn508k
- Currently it's possible to actually delete the "Administrion Control Panel" under "Module management", meaning once you do that, you can no longer even manage the modules nor re-add it. Only through a direct SQL query in your database.
- Currently modules are added to a parent category defined with their
module_langname, for example extensions add a module with theACP_CAT_DOT_MODScategory. However, currently it's allowed to change the language name of the module and if done, this will result in errors: http://prntscr.com/mn3vx0
- Should categories be allowed to be endlessly nested? Or should there be a limitation to "Category > Subcategory > Mode".
- Should modes without subcategory be properly listed, or should they be "attached" to the actual category in the first place?
- Probably stating the obvious, but of all modules that arguably should not be deletable, the actual Module Management should be the first on the list. But this raises an interesting question as in what should be adjustable for a module and what not? I think we can keep the same adjustable options as there currently are but perhaps with a few limitations for the "most important" modules, such as module management and perhaps Control panel index pages.
- The problem with this system is, is that are is nothing "fixed" for a module apart from the
module_basenameandmodule_modecombination. However, changing this to controllers will probably change this as it will require some sort of "slugs" to be present for the route, which can then be used to link to modules and adding modules to it.
Just to clearify, I am assuming there will be a
path: /admin/{slug}. Where the slug will determine which module is desired.
- Should slugs be adjustable by the admin in the module management?
This will allow users to further customise (and localise) their board. However, when adjusted it will 'break' a user's bookmarked links to control panel modules.
- Should there be a routing collection?
This will allow 'easier' linking, for example:->route('phpbb_acp_index')instead of->route('phpbb_acp_controller', array('slug' => 'index')). Something that should be determined beforehand, before links are implemented all over the place. If the slugs should be adjustable by Admin, this has to happen anyway.
- Should there be a pagination route provided?
While this might look cleaner for the front-end (eg:admin/index/page-2/instead ofadmin/index?page=2), it will make the back-end a bit harder and only a very few modules even use pagination.
- Should the "*CP Index" be the actual index of the *CP (and mcp/ucp for that matter) or keep the current system where the first mode in the first category is displayed upon opening the *CP. This will limit the 'custimisation possibilities' of an administrator. Meaning he can no longer determine what the 'front page' of a control panel is. On top of that the index module should not be deletable and under an "unauthorised" category.
I don't see much (any ?) entities through out phpBB's core code and I was wondering if there is a specific reason why it's not used. As the more I look into modules, the more it seems as an ideal candidate to use an entity for with operator(s).
And some about the "tree".
As currently a lot of the heavy lifting is done by the
\phpbb\module\module_manager, while there is already existing code in \phpbb\tree\nestedset which can be easily extended. Is there any particular reason this is not being used?I think this is enough to begin with. Actual slug names is perhaps something for later.
I might have used a few instances of the ACP as examples, but most of them are also applicable to the MCP and UCP.
