Updates to an entity's URL alias do not reflect on the corresponding local tasks.

I have the same problem with node and Sub-pathauto (Sub-path URL Aliases) : when the node's path is changed, the subpaths are always with the previous path and not the new one. For exemple, the local tasks links are wrong now. So, it's not very easily to edit or delete the node in that condition. Only a clear cache resolve that.

I updated the patch #4 to be compatible with Drupal 9.5.x (I didn't yet test it on Drupal 10).

I tested this issue in Drupal 11 and it is still reproducible. Unlike #2, this issue was reproducible for nodes as well.

• Install with standard profile
• create an aricle, Give URL alias and save.
• Edit the created article, Change the URL alias and save.
• No click on 'View' link from the local tasks.
• 'View' link leads to 404 as it is still using old alias.
• Clear Drupal cache and try again.
• 'View' link points to the new alias.

However, this issue was not reproducible for any of the entities in the demo_umami profile. While debugging the cache tags in the standard profile, it was found that the cache tags of the entity were not added to the local task block where the cache tag for the entity was correctly added to the local task in the umami profile.

As @geertvd pointed out in #2, cache tags are added to the local tasks block through access checks. Currently, EntityAccessControlHandler::access() does not add any cache tags associated with the entity to the access results. Therefore, the local task block won’t receive any cache tags related to the entity.
In demo_umami profile, since content_moderation module is enabled, local task access checks eventually invoke content_moderation_entity_access and it adds the entity as a cachable dependency to the access result.

function content_moderation_entity_access(EntityInterface $entity, $operation, AccountInterface $account) {
  /** @var \Drupal\content_moderation\ModerationInformationInterface $moderation_info */
  $moderation_info = Drupal::service('content_moderation.moderation_information');

  $access_result = NULL;
  if ($operation === 'view') {
    $access_result = (($entity instanceof EntityPublishedInterface) && !$entity->isPublished())
      ? AccessResult::allowedIfHasPermission($account, 'view any unpublished content')
      : AccessResult::neutral();

    $access_result->addCacheableDependency($entity);
  }
//

Patch #19 attempted to add a cachable dependency from the EntityAccessControlHandler. But it resulted in numerous test failures.

Link to the failed pipeline: https://git.drupalcode.org/issue/drupal-2927141/-/pipelines/82261

Exploring another option, we could integrate cache tags directly from the local tasks block, iff the current route is related to an entity.

The new change caused only one test failure .

Drupal\Tests\config_translation\Functional\ConfigTranslationUiModulesTest::testNodeFieldTranslation
Behat\Mink\Exception\ExpectationException: The string "FR label" was not found anywhere in the HTML response of the current page.

These are the lines that failed. The test makes a field translatable and tries to add 'French' translation to it's label and help text.

    $this->drupalGet("/entity_test/structure/article/fields/node.article.$field_name/translate");
    $this->clickLink('Add');

    $form_values = [
      'translation[config_names][field.field.node.article.translatable_field][description]' => 'FR Help text.',
      'translation[config_names][field.field.node.article.translatable_field][label]' => 'FR label',
    ];
    $this->submitForm($form_values, 'Save translation');
    $this->assertSession()->pageTextContains('Successfully saved French translation.');

Then it checks if the translation is saved or not.

    // Check that the translations are saved.
    $this->clickLink('Add');
    $this->assertSession()->responseContains('FR label');

The code suses $this->clickLink('Add'); to check the added translation which is wrong. If a translation is already added, then the link text will be 'Edit' instead of 'Add'.

Without the fix in MR 6315, the link text would remain as 'Add,' which is a bug that was somehow overlooked. Correcting the test.

This needs tests. But temporarly moving to needs review for core maintainers to check the proposed solution and provide further guidance.

Akhil Babu → changed the visibility of the branch 2927141-taxonomy-local-tasks to hidden.

Akhil Babu → changed the visibility of the branch 2927141-taxonomy-local-tasks to active.

Appears to have a test failure.

Have not retested.

When a node/taxonomy term is created with an alias like this

$this->drupalCreateNode([
        'type' => 'article',
        'path' => [
          'alias' => '/original-node-alias',
        ],
])

The ‘view’ link in its local task will have the link ‘/subdirectory/original-node-alias’ when the test is executed. This lead to the test failure.

   Failed asserting that two strings are identical.
    --- Expected
    +++ Actual
    @@ @@
    -'/original-node-alias'
    +'/subdirectory/original-node-alias'

I believe this issue arises because SIMPLETEST_BASE_URL is set as http://localhost/subdirectory in pipeline.yml
So, to confirm that the link has been updated, I replaced assertSame() with assertStringContainsString() in the test. Pipeline is up now.

Left a comment but why are we changing a translation button, and does changing it mean we are losing coverage for when the link is "Add"

smustgrave → credited catch → .

Crediting @catch for taking a look at the change I had a question on.

Removing tests tag as they appear to be added.

Clearing patches for clarity as fix is in MR 6315

Tested out following the steps appears fixed to me.

Thanks!

Fixing component and updating issue credits

Left some comments on the MR

For the open thread in the MR.

Looks good to me, thanks!

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.

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.

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

Test failures issue needs to fix

Rebase seems fine

Test failures resolved after implemented suggestion & pipeline passed successfully.

I think this is a major bug as you end up with a broken link immediately after saving an entity. Therefore backporting to 10.3.x to be included in 10.3.0 when it is released.

Committed and pushed 8448f2d14f to 11.x and e664ed0182 to 11.0.x and 4792a5ccf4 to 10.4.x and 66531e2783 to 10.3.x. Thanks!

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