Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
The links under "Reports" in the Administration menu are mostly alphabetical, but a few have been moved to the top: with the Standard profile, "Available updates" and "Recent log messages".
The "Status report" link should also be moved near the top of the list. It had weight -60 before #1987824: Convert system_php() to a new style controller. There is no discussion of rearranging the menu on that issue, so it seems to be unintentional.
Steps to reproduce
Install Drupal with the Standard profile. There are several places to view the Reports section of the Administration menu:
/admin/structure/menu/manage/admin/admin/reports- In the admin toolbar, vertical mode.
- In the admin toolbar, with the contrib Admin Toolbar module.
A site administrator can change the order of the menu items using (1), so this issue is about the default order.
Proposed resolution
Change the weight of the "Status report" menu item. Either -60 (as it was before #1987824, above the "Available updates") or -10 (below "Available updates" and above the rest).
Remaining tasks
User interface changes
TODO: before and after screenshots. See the "Steps to reproduce" section above.
API changes
None
Data model changes
None
Release notes snippet
N/A
| Comment | File | Size | Author |
|---|---|---|---|
| #26 | 3259953-25.patch | 1.64 KB | paulocs |
| #20 | 3259953-20_minus_sixty.patch | 410 bytes | andregp |
Comments
Comment #10
benjifisherThis issue comes out of the discussion of #3114813: Admin Reports (/admin/reports) menu items are not sorted . I am closing that issue: works as designed. I am transferring credit from that issue to this one.
Thanks to @hmendes for tracking down #1987824: Convert system_php() to a new style controller, where the Status report lost its priority (Comment #29 on #3114813).
Comment #18
benjifisherComment #19
andregp CreditAttribution: andregp at CI&T commentedI'll fix this
Comment #20
andregp CreditAttribution: andregp at CI&T commentedI did a patch for each case.
Before:
Weight -10:
Weight -60:
Comment #21
andregp CreditAttribution: andregp at CI&T commentedComment #22
andregp CreditAttribution: andregp at CI&T commentedComment #23
benjifisher@andregp:
Thanks for working on this!
It looks as though you added screenshots to the issue description and then removed them again. Was that an accident?
What weight did you choose, and why? Are you putting the status report above or below the available updates?
Comment #24
AaronMcHaleGiven that the goal of the issue is to put status report at the top (based on agreement at the last UX meeting), I think the "minus_sixty" patch is the one to go for. Looking at the updates module, it sets the Available Updates report to -50, so -60 seems like a natural next step.
It would be good to also add a test that checks to make sure status report is always at the top, as it could be quite easy for this to be accidentally overridden by another issue in the future.
Good work so far though, thanks!
Comment #25
andregp CreditAttribution: andregp at CI&T commented@benjifisher. Yes it was by accident. I don't know why (if this is a bug or a normal drupal.org behavior) but when I created my comment the issue's summary was also changed and the pictures were added automatically to the end of the summary, after the "Release notes snippet" topic.
Placing the status report first should be better, but I post patches/images on both solution so people could better see and chose by the visuals the best solution.
Comment #26
paulocsI added tests to the patch. I don't think its the best approach because if any other module adds a link to the menu, the tests will not cover it.
How should I be able to write a test and cover it? Do you have any example?
Comment #27
AaronMcHaleIn theory that should work though, because if another link was added above Status report, or Status report was moved, then the test should fail.
I guess the other way I can think to do it would be to use the menu API to test to ensure Status report is at the top of the list. But that might be more complex in terms of checking weights, and actually, since we're testing for how the list ends up being rendered in the UI, this is probably the most reliable way.
I'll RTBC this to get it in front of core committers, if they are happy with it as is then fine, otherwise it can go back to NW.
Comment #29
AaronMcHaleLooks like an unrelated test faliure.
Comment #31
Kristen PolThis keeps getting bumped so retesting #26 to see if the spurious failure goes away. Moving back to RTBC based on #29.
Comment #32
benjifisherThe test failures for this issue are caused by a known, intermittent bug: #3262505: [random test failure] Random error in layout_builder FunctionalJavascript tests.
Comment #33
alexpottCommitted and pushed 1b89f43b7d3 to 10.0.x and d901d684da0 to 9.4.x. Thanks!
Not backporting to 9.3.x because while this is tagged as a bug - there is a workaround and it seems the sort of thing we'd change in a minor and not a patch.