When a URL alias entity is updated to point to a new entity, pulling the new entity causes two URL aliases with the same alias on the client site.
The use case for this is a content editor wanting to make a completely new section of the site on a staging server, with different nodes but preserving the URLs of the original. For example, a basic page node at /foo might be getting replaced with a larger content section made up of multiple nodes, with a landing page node now at the path /foo.
Set up an import configuration with the Path alias processor, so that URL aliases are imported with nodes. Set up a server and client to pull a particular node type.
1. On the server, create a node and give it a path alias such as '/foo'
2. On the client, pull this node. The node on the client has the alias.
3. On the server, create a new node.
4. On the server, go to /admin/config/search/path and edit the /foo alias so its system path is the new node.
5. On the client, pull the new node.
The result is that there are now *two* path aliases on the client site, with the same alias. This can be seen
- in the path_alias table
- in the links at /admin/content, although those will also be affected by this core caching bug:
🐛
AliasPathProcessor doesn't add cacheability for the path alias entity
Active
Active
3.0
Code
This changes the path alias processor to handle path aliases as entities.
The fact that the core path alias field sort of and sort of isn't a reference field makes it a bit more complicated than the entity reference processor.
I've added a base class for kernel tests too.