Primary tabs order when editing a taxonomy term are reversed

In Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies. Thanks

Thanks for pointing that out! You're right — without an explicit weight on the View tab, it was relying on the default which could shift ordering. I've added weight: 0 to entity.taxonomy_term.canonical so all the tabs under that base route now have explicit weights. The taxonomy_vocabulary.* ones are under a different base_route, so I left them as-is to avoid altering their order unnecessarily.

Kindly re review

### Reproduction
* Confirmed the original tab order bug (View › Delete › Edit › Revisions) on 11.x-dev, clean install.

### Patch / MR tested
* Applied MR !12697 locally (`core/modules/taxonomy/taxonomy.links.task.yml` changes).

### Results
* Tabs now appear in the expected order: **View › Edit › Delete › Revisions**.
* Checked term add / edit / delete pages – no regressions.
* Ran `phpunit` functional tests – all green.

### Environment
Drupal 11.2.x, PHP 8.3, MySQL 8.0, DDEV 1.25 (Docker + WSL2).

Adjusted the empty lines to group together the related tabs/ routes (in this case there are 2x groups): this 'technique' is used in other core *.links.task.yml files in core modules including system and block. This should make the file a bit more comprehensible (why weight config is used for some but not all).

I appreciate this grouping is more important in eg system.links.task.yml there being tons of tabs, but there are two different groups here and this makes them immediately identifiable .

Thanks to all for your work on this issue.

Since this issue is a bug report, it should have an automated test to make sure that, once we fix it, it does not return. I am setting the status back to NW for that, and adding the issue tag.

@sagarsingh24:

Thanks for testing the changes, and for providing screenshots. I am adding them to the issue summary (under "User interface changes") and marking your account as Approved. Welcome to the Drupal community!

Perhaps you expected issue comments to support markdown formatting. They do not, but "soon" we will use GitLab issues, which do. (I hope this happens before the end of 2025.)

The "R" and "T" in RTBC stand for Reviewed and Tested. From your comment, it looks as though you tested, but you did not say anything about reviewing the code changes.

@oily:

If you make changes to a merge request (MR) after it has been reviewed and tested, please set the status back to NR. In this case, you could have taken the reviewer role instead of making changes yourself: ask for the updates, set the status to NW, and then review the new version after someone else had updated the MR.

All:

Before agreeing to these changes, I would like to know what changed between 11.1.8 and 11.2.2 to cause this problem. Without that investigation, we might be fixing a symptom of a problem instead of the underlying problem, or we might be fixing only part of a larger problem.

RE: #14 @benjifisher Yes I could have tried that. But not sure how that would have worked when there is no doc standard? enforcing the line spacing change I made. But there seems a de facto 'standard'. I suppose i self-RTBTC'd which does happen. Interesting to hear your points. But deleting a few blank lines which has no PHPCS/STAN implications, but does seem a slight enhancement seems okay to self-RTBTC..

Using git bisect, I found the issue that caused this problem: #2219393: Menu Local Tasks should be sorted by alphabet if there is no weight set. Having found that issue, it seems clear that it caused the problem in this issue. I am adding it as a related issue.

As I said in my previous comment, the taxonomy-term pages might be only part of the problem. Looking through the *.links.task.yml files, I notice that the config module defines tabs (local tasks) on /admin/config/development/configuration: Import, Export in Drupal 11.1 and Export, Import in Drupal 11.2. Is one choice better than the other? Should we add weights to restore the order in earlier versions of Drupal or should we sort them alphabetically?

Instead of fixing just the taxonomy-term page, I think it would be better to expand the scope of this issue to review all the *.links.task.yml files, and add weights on a case-by-case basis.

But I think there is an even better solution: revert the changes from #2219393.

On that issue, there is no discussion of translation and how it affects the order of the tabs (local tasks).

The current behavior (in 11.2, after #2219393) is to sort alphabetically before translating. For the taxonomy-term page, that means the order is

• English: View, Delete, Edit, Revisions, Translate
• Spanish: Ver, Eliminar, Editar, Revisiones, Translate

The effect for Spanish users is that the the tabs have been sorted alphabetically based on the English translations, which is not helpful.

Yes, we can fix this page (as the current MR on this issue does). But the same fix would be required in many places: core, contrib, and custom modules.

Another option is to fix #2219393 so that it sorts after translation. But that is also bad. It would mean that people looking at the site in different languages would see the tabs in different orders.

Neither option seems good to me. I vote to revert #2219393.

RE: #16: @benjifisher Thank you for getting to the heart of this.

@AbhijithS:

Thanks for adding the test. It is a very nice test! Just to be sure, I hacked the test in a few ways:

• Search for "Foo Edit" instead of "Edit". The test fails as expected.
• Change assertNotFalse() to assertTrue(). The test fails because it is comparing an int to a bool.

I have just two suggestions:

1. Remember to update the issue status (from NW to NR) when appropriate.
2. I suggest making the positive assertion assertIsInt() instead of the negative assertion assertNotFAalse().

As I said in Comment #16, I think a better solution is to revert the commit from #2219393: Menu Local Tasks should be sorted by alphabet if there is no weight set:

1. That issue changed the order of primary tabs on at least one other admin page besides the term-edit page. We should fix all of them at once.
2. That issue did not consider translations. Neither choice (sort before translating or sort after translating) really works.

That decision may be controversial, so instead of updating the existing MR, I added a new one. I kept the test from MR 12697 (with the change I suggested earlier). Instead of adding weights to the YAML files, I reverted the commit from #2219393.

I updated the issue summary, explaining the different approaches in the two merge requests. I am also running the test-only job on MR 1297.

@camhoward brought this up during DrupalEasy office hours and we looked into it a bit and based on our conversation, I have a couple of questions that might help inform the best path forward:

1. Personally, I'm not sure what the goal/point of #2219393: Menu Local Tasks should be sorted by alphabet if there is no weight set was. What problem was it solving? I'm not saying that I don't think it makes sense, but it would be good to know what prompted it in the first place.
2. I would really like to know how many *.links.task.yml files in core would need to be updated to include weights. I think this would be a valid data point. A quick search shows 27 or so. As each are updated, would a test be needed for each (or would that be overkill?)

We also discussed what effect of this issue's MR !12697 would have on contrib and custom modules, and we came to the consensus that it doesn't really affect contrib and custom modules. If anything, a blurb about #2219393: Menu Local Tasks should be sorted by alphabet if there is no weight set would have probably been helpful in the 11.2.0 release notes.

-mike

1. It is pretty easy to review the comments on #2219393: Menu Local Tasks should be sorted by alphabet if there is no weight set.

• 2014-03-17: The issue was created, saying that it restored the behavior in Drupal 7. (I have not checked that claim.)
• After Comment #6 (6 weeks later) and one patch (which failed automated tests) there was no activity until ...
• 2025-01-18: Comments #20 (Should we do this?) and #21: (It makes sense to me.)

There is no further discussion of whether it is a good idea and (as I said in #16 here) no discussion of translation.

2. Using my MR !12792, we do not have to edit any of the YAML files.

I count 32 YAML files:

$ ls core/modules/*/*.links.task.yml | wc -l
32

If we decide to keep the alphabetical sort, then we have to review all of these and decide whether to add weights. For example:

• config.links.task.yml: Keep the order Import, Export or switch to alphabetical?
• taxonomy.links.task.yml: Keep the order Edit, Delete or switch to alphabetical?

I do not think we need a test for each of these. The test added in #2219393 is enough.

@camhoward:

I guess we agree on most things, but not all.

Instead of adding weights everywhere, we get the same result if we simply revert the change from #2219393. We go back to the order of the primary tabs before Drupal 11.2, and primary tabs are listed by weight and then the order in which they are defined. That is what I did in MR !12792.

I do not see the advantage of sorting alphabetically and then adding weights to everything so that the alphabetical sort never applies.

Clarification: sorting by weight is always primary, before and after #2219393. The only question is whether the secondary sort should be alphabetical or order in which they are defined.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

There is a merge conflict because #3534248: Convert test annotations to attributes in core’s Unit tests using Rector rule changed the @dataProvider annotation to an attribute. I resolved the conflict by removing both the test and the data provider, as in the earlier version of the MR.

Is there any advantage to reverting the change from #2219393 and then adding weights to the 32 YAML files?

My opinion is that reverting #2219393 is the correct fix for this issue. After that, if we want to add weights to some YAML files, then we can do that in separate issues: it seems out of scope for this one.

I had to re-read the comments to see that your "32 YAML files" refers to the second part of my Comment #22. I should have been clearer there: I was describing what we would have to do if we kept the alphabetical sort. My main point is that we should remove the alphabetical sort, and then we do not have to edit any YAML files.

@camhoward:

I am happy to discuss at length. It is unusual to revert an issue that has been committed and added to a full release, so we should be sure we know why we are doing it.

I have updated the issue summary, indicating the preferred approach. Are you willing to mark the issue RTBC? If you are not comfortable giving a code review, then maybe you can bring this issue up in DrupalEasy office hours (Comment #21) again and find someone who can do that.

I think we should focus on getting this issue to RTBC.

The core committers talk to each other. If any one of them decides to review this issue, and they want to ask @nod_ about it, then they will.

Looking at the MR, it looks like it isn't exactly a revert of https://git.drupalcode.org/project/drupal/-/commit/f3e92d3, but it does look okay to me (including the new test.)

Marking as RTBC.

-mike

@ultimike:

Thanks for the review!

Looking at the MR, it looks like it isn't exactly a revert ...

I had forgotten that I kept the test that @abhijith s (or @AbhijithS ... one is d.o, one is GitLab) wrote. As I said in #20, it is a very nice test.

The third commit in MR !12792 is a clean revert (git revert ...).

See my Comment #26 for why the later commit was needed.

Thanks for finding the history on this one

Committed cff1082 and pushed to 11.x. Thanks!

We need a 11.2.x version of the MR since it doesn't cherry pick cleanly

There were only 5 commits on MR !12792. (See Comment #35.) I cherry-picked the first three to the 11.2.x branch and added https://git.drupalcode.org/project/drupal/-/merge_requests/13561.

I have not done any testing.

The failing test is because of #3546740: Initial workspace-published revisions are marked as new too late. It also fails on the 11.2.x branch.

Looks like #3546740: Initial workspace-published revisions are marked as new too late is now fixed. Going to attempt a rebase.

Tests passing after rebase. Hopefully this can be merged into 11.2.x.

Committed c0255e8 and pushed to 11.2.x. Thanks!