Control panel module system

General discussion of development ideas and the approaches taken in the 3.x branch of phpBB. The next feature release of phpBB 3 will be 3.3/Proteus.
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.2.x. If you need support for phpBB 3.2.x please visit the 3.2.x Support Forum on phpbb.com.

If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
User avatar
posey
Registered User
Posts: 29
Joined: Fri Dec 18, 2015 9:41 pm

Control panel module system

Post by posey » Tue Feb 19, 2019 3:44 pm

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.
  1. 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
  2. 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
  3. 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.
  4. 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?
  1. Should categories be allowed to be endlessly nested? Or should there be a limitation to "Category > Subcategory > Mode".
  2. Should modes without subcategory be properly listed, or should they be "attached" to the actual category in the first place?
  3. 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.
  4. 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.
  1. 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.
  2. 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.
  3. 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.
  4. 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.
Better known as mrgoldy.

User avatar
hanakin
Front-End Dev Team Lead
Front-End Dev Team Lead
Posts: 905
Joined: Sat Dec 25, 2010 9:02 pm
Contact:

Re: Control panel module system

Post by hanakin » Tue Feb 19, 2019 9:23 pm

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
Donations welcome via Paypal Image

User avatar
david63
Registered User
Posts: 274
Joined: Mon Feb 07, 2005 7:23 am
Location: Lancashire, UK

Re: Control panel module system

Post by david63 » Wed Feb 20, 2019 7:58 am

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.
David
Remember: You only know what you know -
and you do not know what you do not know!

CHItA
Development Team
Development Team
Posts: 160
Joined: Thu Mar 12, 2015 1:43 pm
Location: Budapest, Hungary

Re: Control panel module system

Post by CHItA » Wed Feb 20, 2019 2:24 pm

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.

User avatar
posey
Registered User
Posts: 29
Joined: Fri Dec 18, 2015 9:41 pm

Re: Control panel module system

Post by posey » Fri Feb 22, 2019 10:39 am

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).
  • Dashboard admin & admin/index
  • Management
    • Forums
      Forums                admin/forums/manage
      Prune forums admin/forums/prune
    • Users
      Users                    admin/users/manage
      Prune users     admin/users/prune
      Inactive users admin/users/inactive
    • Groups
      Groups                     admin/groups/manage
      Group positions admin/groups/position
    • Attachments
      Attachments                                       admin/attachments/manage
      Attachment extensions               admin/attachments/extensions
      Attachment extension groups admin/attachments/groups
      Oprhaned attachments                admin/attachments/orphan
    • Banning
      IP bans          admin/bans/ip
      User bans    admin/bans/user
      Email bansadmin/bans/email
  • Configuration
    • General configuration
      Board settings                         admin/settings/board
      Board features                        admin/settings/features
      Post settings                             admin/settings/post
      Private message settings admin/settings/pm
      Attachment settings            admin/settings/attachment & admin/attachments/settings
      Avatar settings                        admin/settings/avatar
      Signature settings                 admin/settings/signature
      Registration settings           admin/settings/registration
      CAPTCHA settings                 admin/settings/captcha
      Contact settings                     admin/settings/contact
      Feed settings                            admin/settings/feed
    • Server configuration
      Server settings     admin/settings/server
      Cookie settings    admin/settings/cookie
      Security settings admin/settings/security
      Load settings         admin/settings/load
      Search settings     admin/settings/search
    • Client communication
      Authentication   admin/settings/auth
      Email settings     admin/settings/email
      Jabber settingsadmin/settings/jabber This is going to be removed?
  • Permissions
    • Overviewadmin/permissions
    • Global
      User permissions      admin/permissions/global/user
      Group permissionsadmin/permissions/global/group
      Global moderatorsadmin/permissions/global/mod
      Administrators           admin/permissions/global/admin
    • Forum-based
      Forum permissions                admin/permissions/forum
      Copy forum permissions    admin/permissions/forum/copy
      User forum permissions     admin/permissions/forum/user
      Group forum permissionsadmin/permissions/forum/group
      Forum moderators                 admin/permissions/forum/mod
    • Roles
      Forum roles          admin/permissions/roles/forum
      User roles              admin/permissions/roles/user
      Moderator roles admin/permissions/roles/mod
      Admin roles          admin/permissions/roles/admin
    • Masks
      Forum-based              admin/permissions/masks/forum
      Forum moderation admin/permissions/masks/forum-mod
      User-based                  admin/permissions/masks/user
      Global moderation admin/permissions/masks/mod
      Administrative          admin/permissions/masks/admin
  • Posting
    • BBCodes                                 admin/bbcodes
      Smilies                                    admin/smilies
      Topic icons                           admin/icons
      Ranks                                       admin/ranks
      Custom profile fields    admin/cpf
      Report/denial reasons admin/reasons
      Disallowed usernames admin/disallow/username
      Disallowed words            admin/disallow/words
  • Customise
    • Extensions
      Manage extensionsadmin/extensions
    • Languages
      Manage language packsadmin/languages
    • Styles
      Manage stylesadmin/styles/manage
      Install styles     admin/styles/install
  • System
    • Logs
      Admin log          admin/logs/admin
      Moderator log admin/logs/mod
      User logs            admin/logs/user
      Error log             admin/logs/error
    • phpBB
      Check for updates      admin/phpbb/update
      Help support phpBBadmin/phpbb/help
    • Database Use /db/ or /database/ ?
      Backup              admin/db/backup
      Restore             admin/db/restore
      Search index admin/db/search
    • General tasks Should be named something else?
      Spiders/Robots    admin/robots
      PHP information admin/php
  • Extensions
Better known as mrgoldy.

User avatar
DavidIQ
Customisations Team Leader
Customisations Team Leader
Posts: 1828
Joined: Thu Mar 02, 2006 4:29 pm
Location: Earth
Contact:

Re: Control panel module system

Post by DavidIQ » Fri Feb 22, 2019 1:36 pm

This topic now looks like a duplicate of this other one... plus there's already a design that Marc did some time ago that we'll probably go with.
Image

User avatar
posey
Registered User
Posts: 29
Joined: Fri Dec 18, 2015 9:41 pm

Re: Control panel module system

Post by posey » Fri Feb 22, 2019 1:41 pm

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.
Better known as mrgoldy.

User avatar
david63
Registered User
Posts: 274
Joined: Mon Feb 07, 2005 7:23 am
Location: Lancashire, UK

Re: Control panel module system

Post by david63 » Fri Feb 22, 2019 4:12 pm

In any redesign of modules (ACP, MCP, UCP) is any consideration being given to how extensions currently use modules or are virtually all extensions going to have to be re-written?
David
Remember: You only know what you know -
and you do not know what you do not know!

User avatar
hanakin
Front-End Dev Team Lead
Front-End Dev Team Lead
Posts: 905
Joined: Sat Dec 25, 2010 9:02 pm
Contact:

Re: Control panel module system

Post by hanakin » Fri Feb 22, 2019 5:47 pm

just exspect all to be re-written for 4.0
Donations welcome via Paypal Image

User avatar
david63
Registered User
Posts: 274
Joined: Mon Feb 07, 2005 7:23 am
Location: Lancashire, UK

Re: Control panel module system

Post by david63 » Fri Feb 22, 2019 10:12 pm

hanakin wrote:
Fri Feb 22, 2019 5:47 pm
just exspect all to be re-written for 4.0
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.
David
Remember: You only know what you know -
and you do not know what you do not know!

Post Reply