- 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 pathThat 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.