Problem
The current AccountHeaderBlock uses a very specific and large twig file to render the various cases that occur in the account header block. A single extension hook has been made to allow adding some menu items but it's otherwise not very flexible.
Solution
Rewrite all the components in the block in such a way that they use standard Drupal render arrays. For the icons on desktop with their submenu's we create an AccountHeaderElement render element that provides some shortcuts to the developer and keeps code DRY.
Two info hooks and alter hooks are then implemented that gather up all the AccountHeaderElements as well as all the links for the profile AccountHeaderElement. We deprecate the previously created alter hook as its format is ill-defined for the new structure.
We also allow both sets of items to be sorted using weights so that the order in which hooks are called doesn't matter and sites can easily re-order them if they so choose.
Possible follow-ups
It's pretty easy to figure out which menu items exist now so it is possible in theory to create a UI for Site Managers that allows them to rearrange the order of all the items. The ordering could then be applied in an alter hook that reads the configuration.
Target version
This should land in a MAJOR Open Social update as it removes some template files.
Release Notes
The AccountHeaderBlock has been rewritten to provide more flexibility. Various hooks to alter it's behaviour have been introduced and documented in social_user.api.php. The previous hook to extend the user menu has been deprecated and will be removed in a future version.
Comments
Comment #2
kingdutchUpdated the issue summary. All links have been moved to the correct modules. A glue function has been written.
A question I encountered:
The "Create Book Page" in the "Create" (+) menu uses the following access check:
'#access' => $context['user']->hasPermission('create new books')However, if I revoke that permission from a content manager then they're not actually stopped from creating new book pages (they can still do that through the Admin menu), it's just slightly less convenient. The access check was added in the following commit: https://github.com/goalgorilla/open_social/commit/63d101a41e17fb02694461...
My proposal would be to remove this access check because the access check of the URL itself works well enough to see if a user is allowed to create a Book Page (even if they can only add to existing books).
What are your thoughts?
Comment #3
kingdutchI've actually found the answer to my previous question in the commit I mentioned.
The access check can be removed as the link is simply not rendered if the user does not have access to the URL. Previously an inaccessible link would be rendered which is why the access method was added in the first place.
Relevant lines here: https://github.com/goalgorilla/open_social/commit/63d101a41e17fb02694461...
This was also happening for the "Edit profile" link in the user menu.
Comment #4
kingdutchA Pull Request against 8.x-3.x has been created here: https://github.com/goalgorilla/open_social/pull/967
The patch has been omitted from this issue because it's huge.
Comment #5
kingdutchA follow-up should be created to convert the hook in the social_gdpr module to the new format.
Comment #6
ronaldtebrake commentedComment #7
ronaldtebrake commentedWill be in 4.0, thanks! :)
Comment #10
kingdutchComment #11
jaapjan commentedFor future reference.
Change request can be found here:
https://www.drupal.org/node/3019929