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

@quietone -- Ah, thanks. I used 11.2.x-dev because the issue is present in 11.2.x and not in 11.1.x and I thought I should be specific. Thanks for the clarification and update.

@annmarysruthy -- Thanks for your work on this!

I manually applied the changes in your merge request !12697 to core/modules/taxonomy/taxonomy.links.task.yml and that resulted in the tabs displaying in this order:
Delete, View, Edit, Revisions.

That's not quite what I was looking for. The order should be:
View, Edit, Delete, Revisions.

I'm guessing that means weights should be added to all of the items in core/modules/taxonomy/taxonomy.links.task.yml.

Feeling a bit brave, since you pointed me to making changes in core/modules/taxonomy/taxonomy.links.task.yml, I tried the following:

entity.taxonomy_term.canonical:
  title: 'View'
  route_name: entity.taxonomy_term.canonical
  base_route: entity.taxonomy_term.canonical
  weight: 0

entity.taxonomy_term.edit_form:
  title: 'Edit'
  route_name: entity.taxonomy_term.edit_form
  base_route: entity.taxonomy_term.canonical
  weight: 10

entity.taxonomy_term.delete_form:
  title: 'Delete'
  route_name: entity.taxonomy_term.delete_form
  base_route: entity.taxonomy_term.canonical
  weight: 20

entity.taxonomy_vocabulary.overview_form:
  title: 'List'
  route_name: entity.taxonomy_vocabulary.overview_form
  base_route: entity.taxonomy_vocabulary.overview_form
  weight: 30

entity.taxonomy_vocabulary.edit_form:
  title: 'Edit'
  route_name: entity.taxonomy_vocabulary.edit_form
  base_route: entity.taxonomy_vocabulary.overview_form
  weight: 40

This puts the tabs in the right order.

Writing this kind of code is not my area of expertise, however, so I don't know if this is the correct way to resolve this issue.

Thanks again for your help. I set the status back to "Needs work" since the solution in the merge request did not solve the issue. I hope that's the right thing to do. I'm learning as I go.

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).

**Marking Status → RTBC.**

@annmarysruthy -- Thanks again for your work on this and for your explanation; that's very helpful.

I manually applied the changes in your revised MR !12697 to my Drupal 11.2.2 site and the tabs now display in the correct order.

I agree with @sagarsingh24 that the status should now be RTBC. I updated the issue summary and changed the status.

Thank you both!

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.

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: 📌 Menu Local Tasks should be sorted by alphabet if there is no weight set Needs review . 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.

abhijith s → made their first commit to this issue’s fork.

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 📌 Menu Local Tasks should be sorted by alphabet if there is no weight set Needs review :

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 📌 Menu Local Tasks should be sorted by alphabet if there is no weight set Needs review 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 📌 Menu Local Tasks should be sorted by alphabet if there is no weight set Needs review would have probably been helpful in the 11.2.0 release notes.

-mike

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

• 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.

@benjifisher -- Thanks for all your work on this and for finding the issue that caused the problem and summarizing the main events in that issue.

I think your summary supports what @ultimike said -- the goal/point of that change is not clear. Someone suggested it in 2014 and 11 years later, in 2025, @smustgrave said it makes sense and it was implemented. There was no discussion about the rationale for, or consequences of, making this change.

And, as you noted in #16, translation is an issue when tabs/local tasks are sorted alphabetically, resulting in even more inconsistency when the alphabetization is based on English regardless of the user's language.

I vote for updating the .yml files with weights so the order of the tabs/local tasks will be consistent across Drupal. Using weights will standardize the order when translated, make teaching/learning Drupal easier, and make it easier for content editors on sites upgrading to 11.2.2, 11.2.3, and versions going forward.

I think the weights should be added based on the order the items appear in the .yml files. I expect some thought has already gone into that order and it would make Drupal 11.2.2 and later consistent with previous versions.

@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.