Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.This is a follow-up to #2513626: [Regression] Module permission links missing from module list page.
Problem/Motivation
The main Permissions page (/admin/people/permissions) has anchors that are intended to take you to the section of the page with the given module's permissions. For example, with the comment module, the link is /admin/people/permissions#module-comment. When you open that link, you see this:
Where is the comment module header? You have to scroll up to find it.
The variants of the Permissions page added in #3216341: Provide a module-specific permissions form and #2934995: Add a "Manage permissions" tab for each bundle that has associated permissions have the same problem.
Steps to reproduce
Go to /admin/people/permissions#module-comment. Observe that the module name 'Comment' is not visible.
Proposed resolution
Add proper named anchors above the given sections. For example, add <a id="module-comment"></a> before the section for the Comment module.
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | 1129578-1-D9.patch | 695 bytes | tr |
| #3 | Screen Shot 2015-07-03 at 11.38.39 pm.png | 153.29 KB | naveenvalecha |
| Screen Shot 2015-07-02 at 9.37.15 AM.png | 63.92 KB | cilefen | |
| Screen Shot 2015-07-02 at 9.37.30 AM.png | 156.24 KB | cilefen |
Comments
Comment #1
cilefen commentedComment #2
naveenvalechapicking this up
Comment #3
naveenvalechaI have tested the same on the bartik and seven theme and it is due to the overlaying the table header on the table rows.
Sceenshot attached.
Its seems CSS bug.Not found really exactly it needs changes.So unassigning from myself.
Comment #12
quietone commentedI tested this on 9.3.x and was able to reproduce this error.
Comment #13
tr commentedI raised the EXACT SAME ISSUE more than 10 years ago. And my solution (with patch) was the same as in the above issue summary, "Consider putting proper named anchors above the given sections."
My trivial patch went nowhere, and the issue was derailed by people blaming overlay etc. But I've been using this patch successfully on my old D7 sites for over 10 years.
See #1129578: Overlay doesn't respect internal anchor links
Funny, but the tiny patch I provided there still works 10 years later when massaged to apply to D9. Here it is again. This patch moves the CSS id from the tr element, where it clearly has never worked in D7 D8 or D9, into an anchor tag where it works properly.
Comment #14
tr commentedI missed a space, so the coding standards failed. Here's the correct patch.
Comment #15
quietone commented@TR, thanks for the history of the issue and the patch.
intended to make new screenshots so I tested this with Drupal 9.3.x, standard install and was pleasantly surprised that this has been fixed, although in a different way. When clicking a permissions link on the extend a new page with permissions just for that module is displayed. It is rather nice to have just the subset of permissions that the long list.
This was fixed in #3216341: Provide a module-specific permissions form, committed Sep 21 2021.
Therefore, closing as cannot reproduce.
Comment #16
tr commented"This was fixed ..."
Not really. That issue *added* separate module-specific pages for module permissions, but did not remove the original page that has the problem raised in this issue. And we still need the original page in core and will always need it - that's the only page where all the permissions are shown and if you don't happen to know which module provides the permissions that is where you will have to go to find the information.
Core tests still have references to the original page, see for example
core/modules/system/tests/src/Functional/System/AdminTest.phpLikewise, many contributed modules have help files or README.txt files containing links to the original page, and those aren't likely to change anytime soon.
All these links to that original permissions page, whether in core or contrib or in documentation, are still valid and are still broken as described in the original post. The only thing that is "fixed" are the permissions links on the
/admin/modulespage, and these are not so much "fixed" as "avoided" by linking to entirely new pages with currently-unknown new problems.Also these new module-specific pages happen to have the exact same issue, when listing permissions from multiple modules. They have the same issue because the markup was copied from the original page. A module that provides fields and content types, for example, will have to link to a module-specific page with multiple sections of permissions: one section for the module, one for "Node", one for "Field UI" etc. And once again the anchor to the section for that module will fail, even on this new page, in the manner described above. A simple example would be the taxonomy module, which provides field permissions as well as taxonomy permissions. A proper link to this new page would be /
admin/people/permissions/module/taxonomy,field_uiand that doesn't scroll to the taxonomy section - it links to the top of the page instead. You could try/admin/people/permissions/module/taxonomy,field_ui#module-taxonomyor/admin/people/permissions/module/taxonomy,field_ui#module-field_uibut guess what, those anchors have the same problem we've been trying to fix for 10 years now. So brand new pages can get committed after only a few months of consideration and minimal testing, replicating known issues, but a 1-line fix to the anchors is ignored through three major versions of Drupal and 10 years of issues?Is it really too much to ask to stop bikeshedding this and just fix the anchors?
Comment #17
quietone commented@TR, I followed the steps to reproduce the problem that are given in the Issue Summary and based my review on that. If the comment about bikeshedding is any way directed at me, then it is not warranted. There have been 3 people who commented on this issue in the 6 years of it existence. One person updated the IS, one person tried to fix it, and then I did a review.
So, to move this along, I've added steps to reproduce to the IS to make sure the the URL is entered by hand.
Tagging for Issue Summary update because the proposed resolution is to consider an option, not actually do something, and this needs remaining tasks as well. Eventually it will need updated before and after screenshots. And, of course, this will need a test as well, adding tag.
Comment #18
quietone commentedAdding related issue.
Comment #19
benjifisher+1 for needing an issue summary update. It talks about the links on
/admin/modulesand even has a screenshot from that page. That much really has been fixed by #3216341: Provide a module-specific permissions form.OK, I will go ahead and update it, and remove the issue tag. Maybe someone else can add a screenshot, with the patch applied, to the "User interface changes" section.
I am also updating the title of this issue. I hope this makes it clearer that the anchors on the Permissions page, not the links on the Extend page, are the problem.
I agree that the main Permissions page is not going away, and that we should fix the anchors.
Yes, the pages like
/admin/people/permissions/module/taxonomy,field_uihave the same problem. The good news is that fixing the main Permissions page will fix those pages as well. (Side note: as far as I know, the only way to get a link like that, other than typing it yourself, is in the confirmation message when enabling more than one module.)If I have my way, then #2934995: Add a "Manage permissions" tab for each bundle that has associated permissions will add even more variants of the Permissions page, and the fix here will apply to those pages, too.
@TR, I understand your frustration. I have felt it, too. But try to appreciate @quietone, who spends a lot of effort working on the Bug smash initiative (among other things). One of the goals of that initiative is to identify issues like this, where a bug fix is just waiting to be committed.