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.