So, let's talk modules.
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 the ACP_CAT_DOT_MODS category. 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

Okay, so that are a few issues which can all be solved, but what is the desired?

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_basename and module_mode combination. 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.

So, let's talk a bit about routes as the entire thought is to turn it into controllers, which will need routes.
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 of admin/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.

Now a little bit about entities.
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.

posey wrote:
Should there be a pagination route provided?
While this might look cleaner for the front-end (eg: admin/index/page-2/ instead of admin/index?page=2), it will make the back-end a bit harder and only a very few modules even use pagination.

This should be handled by a global standard something like /panel/{slug}/page/2 which just maps to "admin/index?page=2" similar /panel/{slug}/:id so maybe something like /panel/{slug}/:page

Whilst I would not discount any of the above as being potential problems, and I would agree that there are some areas that need blocking, I would ask is this actually a problem in the real world. By that I mean is there any data on users actually having these problems as I cannot recall any support topics relating to this.

How many users actually move "categories" around? All I can ever recall doing is moving items up/down within a category - I have enough trouble trying to remember where things are without moving them somewhere else!

Another point to bear in mind is that of modules added by extensions as, from memory, if you move an extension's module from where it is intended to be then it causes errors if that extension is removed.

DavidRemember: You only know what you know -
and you do not know what you do not know!

I would just get rid of the whole concept of an admin can move modules around. It is fairly pointless, and for example, in case of the ACP it might make handling support requests harder (e.g. the admin moved some module to some place else, and now they cannot find it).

My idea implementationwise is to remove the modules table, and move modules into service collections. So you would have a service collection for the ACP, MCP, UCP with the top level modules, then a service collection for each top level module, and so on. In this architecture you could still have unlimited levels in theory, but in practice we shouldn't really try to render everything (but we still keep the backend flexible enough to be able to do so).

I think that with this approach we would need a new topologically sortable service collection provider, so each module in a collection can specify two parameters: (exactly_after|after: other_module_name and exactly_before|before: other_module_name - the | means or here, so only use one of these per module/service definition). Then you just do a topological sort in the collection, cache it, and extension authors can just simply specify those two parameters (or which ever they care about), and their module will pop up at the right place (or at least close to it).

Also let's not use slugs in routes if there is a way to avoid it. Each module should have their own controllers. So the service collection stuff is only needed for the *CP menus, as the modules should live in their own controllers.

Okay, that sounds great and ideal for back end coding.
Will drop the customisation options for an Administrator but as far as I can tell, that is never used.

Perhaps it's now also a good time to talk about "reorganising" the menu a bit? As there are a lot of duplicate entries in the ACP and I think they could more sensibly ordered. Have a look here for a quick overview: https://codepen.io/mrgoldy/full/BMEzqa (don't mind the rest, just the menu order).

No it does not, nothing concrete is being discussed in that topic on how it should function.
Also, as mentioned, do not look at the style in the codepen, that was me just playing around, just at the categories, subcategories and actual modes.
Which I have also listed above, with their respective routes.

If the service collection approach is going to be taken, these have to be set up and implemented. So they have to be known beforehand. Otherwise it will be double (if not triple) work later on, apart from the fact that it's being postponed while it can easily (and imo should) be included from the "get-go" in this PR.

Just great - let's upset all extension developers and all style developers just because somebody want to change something.

The whole point of extensions was supposed to be that they would be backwards compatible with all future versions until the point where some aspect was dropped several versions ahead giving time for extensions to be updated.

To say that all extensions are going to have to be re-written for 4.0 (after they will have to be re-written for 3.3 due to the style changes) is the best way to loose support for phpBB. Bear in mind that this will not only affect extension developers but will impact on users who have become used to having extensions on their board and many of those extensions will not be available.

It is time that the development team started to realise that firstly phpBB is aimed at the the end user who could not care less what goes on in the background. The next in line is the board owner who does not want, nor need, the hassle of having to change everything and making all current extension unavailable in 4.0 will drive many away to another platform.

Unless some serious consideration is given to how phpBB is to progress and not responded to with glib one line dismissal answers I for one will be out of here before long.

DavidRemember: You only know what you know -
and you do not know what you do not know!