[PP1] Move the Edit buttonoutside the more actions drop down

Getting started on this one locally.
Note: #3484564 is the dependency and this issue's MR can only be raised once the parent is done.

Changing the version to 11.x-dev so that the Issue fork gets created from 11.x branch.

Removing the postponed title prefix as 📌 Define the 3 areas the Top Bar will provide Active is merged to 11.x.

Adding the "Drupal CMS release target" to see if we could hopefully get to it.

Also adding Navigation stable blocker

I have been working on this issue and have so far completed rendering the edit button and adding partial styles. Some more styling work is pending and then will be raising the MR for this.

Looks like the MR has conflicts due to changes in Plugins, Hooks & Test files. I will have to look into this and update the MR accordingly.

I have resolved most of the pipeline issues except the PerformanceTest that's failing. Below are the different messages that I have been getting:

Line 75: Failed asserting that 59 is identical to 61.
Line 78: Failed asserting that 1 is identical to 2.
Line 79: Failed asserting that 27 is identical to 29.
Line 83: Failed asserting that 90360 is less than 90000.

Question: I noticed that core/tests/Drupal/Tests/PerformanceTestTrait.php calculates these values, but I'm unclear whether these numbers are updated based on specific criteria or the incoming test data. Could someone provide clarification?

Hello,
Tested and verified on Drupal 11,
MR applied successfully.
Attaching before and after screenshots

Left a review about the edit link idenfication.

> Question: I noticed that core/tests/Drupal/Tests/PerformanceTestTrait.php calculates these values, but I'm unclear whether these numbers are updated based on specific criteria or the incoming test data. Could someone provide clarification?

It's no so much calculated, it's just what's the current expectation. If we add more CSS, then we have to increase the expectation. What's interesting is that this *lowers* the amount of cache gets/sets. That is generally good and we can just lower the values. It would be good to understand and write down which cache operations aren't happening anymore.

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

Does it make sense to postpone this on the title issue? If I understand this correctly, that one introduces an API method to fetch the current entity for which to display the title and the same logic could be applied as to when the edit button should be displayed. I think it makes sense if those two things are in sync. We should only have an Edit button if there is a title that displays for what that button?

Gonna work on it

At the moment, the module is still experimental.
We are still waiting for the final design.
We are still waiting for the icon system.

The task description says

This issue is to ONLY move the Edit button outside of the drop-down, not applying any of the other visual changes to the image above is providing.

So there is no need to make it fully consistent with the image. It is enough to just add the markup and roughly understand how it will work afterwards.

And even more so, there is no need to add deeply nested CSS that will be impossible to clean up later without significant effort

Also, there is no need to add new icons. In particular, the Pencil was already there. Let it be different, but there will not be many icons with the same meaning when we switch to the icon API. (I hope soon)
I also took the icon of three dots from https://phosphoricons.com/ where all the other icons came from.

I also think that there is no point in adding backend tests based on visual styles, for example, the icon type, but this is not my area and I did not change it.

@plopesc could you please review backend after rebase?

Does it make sense to postpone this on the title issue? If I understand this correctly, that one introduces an API method to fetch the current entity for which to display the title and the same logic could be applied as to when the edit button should be displayed. I think it makes sense if those two things are in sync. We should only have an Edit button if there is a title that displays for what that button?

Both issues are related but not essentially depends one on the other, I think. Here we make use of $this->navigationRenderer->hasLocalTasks() and that method has been moved to a new service in 📌 [PP1] Show entity information on the Top Bar Postponed . If we merge that one first, we will need to make some adjustments here and vice-versa. Agree that things would be simpler here if we merge that one first, though.

We could postpone this one to have a better separation of concerns.

📌 [PP1] Show entity information on the Top Bar Postponed has landed so I think we're good to proceed here 🚀

I think this is looking good. I made minor tweaks to the design to make it match the original design a bit more.

Few follow-ups that we need to open:

1. Removing the current active local task from the more actions
2. Showing the Edit button as the primary action when viewing a forward revision

🐛 Navigation Top Bar Page Actions dropdown shoud not include link to the current page Active Was already created.

> Showing the Edit button as the primary action when viewing a forward revision

FWIW, that should be pretty trivial, just need extend the route match to allow canonical or latest_version: (canonical|latest_version). If we also want to cover it with tests then it might get more complicated.

nod_ → closed merge request !10667

the dots are way too small for me, but that's subjective, no need to hold this up longer

Committed b8ed481 and pushed to 11.x. Thanks!

Thought I commented about this yesterday, follow-up issue then: 🐛 navigation top bar edit button has strange active (?) colors Active

Created follow-up 🐛 Navigation Top Bar should Edit button as the primary action when viewing a forward revision Active to address the Latest version page behavior.

Automatically closed - issue fixed for 2 weeks with no activity.