Local task name expectation in getFeaturedPageActions is fragile

Adjusted the summary to include "Top Bar" for easy reference.

Changed Category to Bug report.

Added steps to reproduce.

Code in question is this:

   if (preg_match($canonical_pattern, $current_route_name, $matches)) {
      $entity_type = $matches[1];
      $edit_route = "entity.$entity_type.edit_form";
      // For core entities, the local task name matches the route name. If
      // needed, we could iterate over the items and check the actual route.
      if (isset($page_actions['page_actions'][$edit_route]) && $page_actions['page_actions'][$edit_route]['#access']?->isAllowed()) {
        $featured_page_actions[$edit_route] = [
          'page_action' => $page_actions['page_actions'][$edit_route],
          'icon' => 'pencil',
        ];
      }

So is the fix to resolve the 'if needed' comment and iterate over the items?

the route name is just as much convention as the local task, it's probably more reliable than the local task as route names are typically generated while local tasks aren't yet.

Could go a step further and look for __entity_form in the route definition, but that's also an extra lookup.

Either way, doesn't really seem like a stable blocker to me? extending this to support more cases won't require API/structure changes or anything like that?

Either way, doesn't really seem like a stable blocker to me? extending this to support more cases won't require API/structure changes or anything like that?

Yeah I was also wondering this - if it's a 'normal' bug and the fix is self-contained (e.g. doesn't require adding some kind of declarative API) then it doesn't feel like a blocker.

Yeah I was also wondering this - if it's a 'normal' bug and the fix is self-contained (e.g. doesn't require adding some kind of declarative API) then it doesn't feel like a blocker.

I was wondering about that.

We can have a self-contained improvement to cover more cases, but it's probably not perfect. I've seen some discussions about what and if there should be a primary action on views pages for example, specifically admin pages such as admin/content and admin/people and whether the action there should be add user or edit view. Neither will be covered by this. But add user would be possible through the local action system that we already have.

Even if we need a declarative API eventually, we could still add that post-stable I think, just would take longer for contrib to be able to rely on it.

Discussed in Slack as well. Conversation there couldn't recall a concrete reason for making this issue blocking.

Removing the Navigation stable blocker label.

I'm not sure if this is the right place for this feature request, but I would propose to add an alter hook to the getFeaturedPageActions() method.
In my case, I want a custom entity to have another "featured action", rather than the edit form.
Currently I don't see a way to achieve this.
IMHO core should provide sane defaults, but allow the option for contrib / custom module to change the default behaviour.

I early adopted the navigation module so I could get rid of admin_menu (so: everything forthcoming is "my fault"), and 11.2's forced top bar and this is a blocker for me, usability-wise (forcing me to retrain dozens of people and rewrite documentation on where tab links went). Force removing the "Tabs" block is one thing, but force-adding an extra click is quite another. The current code seems to assume that only one local task is "important", and that importance is determined in one specific way ("name same as route", which this issue hopes to fix).

Overall:

• For an ecommerce site, all of Commerce's local tasks are hidden (per this issue). Clicking "Edit" and "Variations", the two more important parts of editing a product, now requires two extra clicks, and is hidden in one of the most hard-to-see three-dot menus I've ever seen (compare the boldness of our three-dots to, say, Chrome's three-dots, and imagine the difficulty of supporting someone into clicking the right one, given their proximity to each other).
• Usability-wise, admins now have an entirely different UI than normal users. With the sidebar only (11.1.x), an admin would click the user/# "Orders" tab the same way an end-user would. With the top nav hiding the tabs block, the admin now sees a non-equal UI to do the same thing. It is entirely possible that an admin will try to support a user by saying "click the three little dots in the upper right and then the Orders link", when a normal user would not see the three dots at all.
• "Only one local task is the most important" is a bad idea even in core. We ship with the Layout Builder enabled and configured for all types, and our site builders fiddle with how things look and are arranged just as often is the content is edited (usually by a different team). This change adds an extra hunt-and-click for the "Layout" tab for no apparent reason.