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

I followed the steps in the IS but was unable to reproduce this error.

Feel free to reopen if you still think this is a bug.

@JeroenT, thanks for looking into this issue. I got different results.

I tested this on Drupal 10.0.x, standard install and using the steps in the Issue Summary I was able to reproduce the problem.

Clearing the cache fixes the problem. This now needs to be updated to 10.0.x, adding reroll tag and setting to NW.

Added reroll of patch #4 on Drupal 10.0.x.

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, showed that the cache tags of the entity were not linked to the local task block, where the cache tag for the entity was correctly linked 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, if 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.

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 uses $this->clickLink('Add'); the second time also to check the added translation which is wrong. If a translation is already added, then the link text should 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.

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, Thank you for the review. There was an error incore/modules/config_translation/tests/src/Functional/ConfigTranslationUiModulesTest.php which caused the test to fail. I've explained it in the merge request and also in this comment . Please review.

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.

Test failures issue needs to fix

Moved to NR

Rebase seems fine

Test failures resolved & pipeline passed successfully.

Please review

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!