AliasPathProcessor doesn't add cacheability for the path alias entity

Created on 27 January 2025, 27 days ago

Problem/Motivation

Drupal\path_alias\PathProcessor\AliasPathProcessor::processOutbound() is responsible for replacing a system path in a rendered link with an alias, if one exists.

This replacement does not add cacheability for the path alias entity to the cacheability metadata. This means that if the path alias is changed, render arrays that contain the link may not be correctly invalidated.

Steps to reproduce

1. Create a node, and give it a path alias, e.g. /foo.
2. Create a second node, and note its system path
3. Go to admin/config/search/path, and find the alias entity for path /foo.
4. Edit the alias entity, and set its system path to point to the 2nd node instead of the first node.
5. Load the page for first node (for example, from the admin/content page). The URL for this node is now the system path, /node/NID. However, in the tabs block for this node, the 'View' link has the alias. Clicking this will lead to the 2nd node.

Proposed resolution

AliasPathProcessor::processOutbound() needs to add the cacheability for the path alias entity.

However,

      $path = $this->aliasManager->getAliasByPath($path, $langcode);

gets a string, and not an entity.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

🐛 Bug report
Status

Active

Version

11.0 🔥

Component

path.module

Created by

🇬🇧United Kingdom joachim

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @joachim
  • 🇬🇧United Kingdom catch

    This code intentionally doesn't load path entities (e.g. it never has done, entity loading was avoided as part of the original conversion of path aliases to entities) because there are potentially dozens or hundreds of URLs rendered on a page - think node listings showing a tags field etc.

    Does this also break if a node previously didn't have an alias and now does?

    If so, maybe we could use the list cache tag here, although that will result in a lot of invalidation.

    We might want to pass the cacheability metadata into the method as an extra parameter instead of changing the return value, that would allow for more flexibly adding metadata for the 'new alias' situation. Maybe we can also include the entity ID in the current queries and add the cache tag for that manually instead of loading the entire entity.

  • 🇬🇧United Kingdom joachim

    > Does this also break if a node previously didn't have an alias and now does?

    Do you mean these steps?

    1. Create a new node, with no alias
    2. At admin/config/search/path, create a new alias and point it at the node's system path

    That works ok - reloading the node shows the new path alias.

  • 🇬🇧United Kingdom catch

    @joachim - yes that's what I mean, but I don't think we use cache tags for that situation either, so a bit surprised it works?

  • 🇬🇧United Kingdom joachim

    Discussed this on Slack.

    This should probably be closed in favour of 🐛 Using the URL alias UI to change aliases doesn't do necessary invalidations: path aliases don't have cache tags Active , though before doing that we might want to redirect this issue to documenting in AliasPathProcessor why the cache tag isn't added.

Production build 0.71.5 2024