Using the URL alias UI to change aliases doesn't do necessary invalidations: path aliases don't have cache tags

Let's continue the discussion from #2336597: Convert path aliases to full featured entities here..

Right, but aliases being entities means that we don't have to retrofit aliases with cache tags in some hacky way; they'll be able to use cache tags in exactly the same way as others can today.

I disagree :)

having a cache tag is one line of code. But you can't actually have a cache tag on the *alias*, we somehow need a cache tag for the source path or something like that. How else can you invalidate something when you *add* a new alias for something that didn't have one before?

And just using a list cache tag or so would invalidate most of the render cache every time you add an alias, not fun.

This is a pretty hard one...

Is this something where we would want to use a system similar to the expire module where it does a search for things that need to be expired like a URL alias given a path?

The original idea behind the expire module is when a node changes find all the related paths where that node can show up and output a list of URLs to clear from something like varnish. So if the node is tagged with front, be sure to include that in the list, or if it has the alias of about-us include that.

What made me think about this aliases can be used in reverse. I'm assuming we know the machine name but we need to find the aliases associated with it. Just do a reverse lookup of the alias. Or did I completely misread the issue summary?

My guess on the current issue:
node 1 (contact us) contains a link to node 2 (about us). Some one goes to /admin/config/search/path and decides to change the about-us alias to team-awesome. None 1 needs to be invalidated because it now is using the old alias. My current assumption is that linking node 1 to node 2 is kept somewhere besides a raw a href so we can use that to do a reverse lookup.

Is the url_alias table viable?

Here's a query that joins the url_alias table to the node table in D7

SELECT 
  COUNT(*) as counter, 
  url_alias.*,
  node.*
FROM url_alias AS url_alias 
INNER JOIN node AS node 
  ON node.nid = CAST(substring(url_alias.source, 6) AS UNSIGNED) 
  AND node.status = 1
GROUP BY node.nid
ORDER BY counter DESC

Takes about 10 seconds with 1.7M aliases. This just to show that one can use the url_alias to find the nodes associated with them. Maybe we add some fields to the url_alias table make this a lot faster and less brittle.

I really haven't taken a look at this issue in D8; just throwing some ideas out :)

In terms of cache tags I haven't looked at the D8 implementation of it yet but I will say that GROUP_CONCAT in MySQL is powerful. Using it you can take what would have taken 2+ queries and make it only take one query. An example of this is the role retrieval of the user on a session load; in D7 this is always 2 queries but by using GROUP_CONCAT, CONCAT & GROUP BY one can use just one query if you do some minimal processing after the fact. Would something like this help with the issue of having 100 aliases grouped together? Use SHA1() to hash the GROUP_CONCAT field to make the output smaller (see advagg bundler for an example of this).

the substring query is a known issue, fixed in D8 with a D7 patch: #1209226: Avoid slow query for path alias whitelists. And not related to this issue I think.

I also just noticed that the 4xx-response cache tag introduced in #2472281: 404/403 responses for non-existing nodes are cached in Page Cache/reverse proxy, are not invalidated when the node is created doesn't get invalidated when a URL alias is updated via /admin/config/search/path. It only gets cleared when an entity is saved.

Sure that this is the correct issue reference?

What you need is first #2539634: PathItem::delete() never runs because the path field type is a computed field in disguise and a follow-up of that to actually compute/load the alias when accessed. which is the better approach than what that other issue is doing, I don't want to always load them, only when necessary.

This issue is blocking #2835528: Path module is missing a REST plugin from being cacheable. :(

Just curious, does this issue cover this problem statement.

Actual:
When we change the URL alias of an already created node, then refreshing the old URL returns a 404

Expected:
The new URL and page content should be returned and not a 404 error.

Approach:
See if it is possible to seamlessly remap the URL.

Use Case: Content author created a new page of content and then the SEO team asks for the URL to be changed. Based on SEO recommendations, the content author changes the node title and URL alias. When the author refreshes the old URL, automagically the new URL and page content is returned and not a 404 error.

FYI - WordPress seems to have resolved this.

Isn't what #33 describes perfectly handled by the Redirect module setting to Automatically create redirects when URL aliases are changed.

On /admin/config/search/path/settings

On /admin/config/search/redirect/settings

If I understand correctly (possibly I'm wrong) the scope of this issue seems that if you have a manually entered link to a URL alias page in the body content of node A that points to the url alias of node B, and node B's url alias gets updated, then they want a way to somehow invalidate the cache of node A and dynamically update that link in the body to point to the right alias.

I can potentially see this happening, particularly when using the Linkit module, which gives you a fancy pants way to link to nodes in the wysiwyg of the body field. But with the URL Alias + Redirect settings dialed in, the old alias becomes a 301 redirect (which results in an expected behavior of taking you to the page you intended).

Many thanks jwilson3 - my understanding for the scope of this issue is that for a given node, your comment should be default(core) functionality without having to download,install and configure a contributed module - also wondering if this is related to https://www.drupal.org/project/drupal/issues/133552 - if there is a clear consensus by the community on these issues, maybe update the status of the issues?

jwilson3 is being polite, but spot on. The difference between what you are describing and what this issue is about, is whether the URL is embedded in actual content on the site (what this issue is about; if it is, it needs to be updated when the alias changes) or whether visiting the URL directly, e.g. because another site is linking to it, or because a user has bookmarked it or just typed it into the address bar (what you are describing).

With redirect module in place, this issue would hurt less, because the redirect would handle the problem (but it would still be something to fix; it is not very tidy to have your own site rely on redirects; those are for *other* parties that can not reasonably know you changed a URL; your own site can know that and should just give you the right URL in the first place).