Redirects/URL aliases not working as expected

Created on 12 May 2025, about 2 months ago

Problem/Motivation

I’m not sure if this is a bug or a feature request. We expect to be able to track redirected URLs because the content is still being used. If you create two nodes: 1A and 2A, and you link 1A in 2A, then the usage for 1A will show it is used in 2A. If you run eu-r to recreate the usage, then you will see 1A is used in 2A. If you then change the alias for 1A to 1B, creating a redirect, then 1A still appears as used in 2A. There’s a link to 1A that takes you to 1B. However, if you run eu-r again because you updated your settings and now want to track media as well as content, then the 1A/1B usage disappears from 2A. This seems unexpected. The content is still being used and referenced, so the connection should remain.

Steps to reproduce

Drupal 10.4.6
entity_usage 2.0.0-beta24 (default settings)
drupal/redirect 1.11.0

Proposed resolution

Recreating the entity usage would not remove redirects/aliases from the usage tables.

πŸ’¬ Support request
Status

Active

Component

User interface

Created by

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

Comments & Activities

  • Issue created by @hannakras
  • πŸ‡ͺπŸ‡ΈSpain marcoscano Barcelona, Spain

    Do you have redirects enabled as souce/target in the settings page?
    As soon as you have a redirect in the middle it starts becoming one extra entity in the chain, so that needs to be tracked as a separate entity.

  • Yes, redirect and URL alias are enabled as both source and target. One thing I forgot to mention in my post (I'll update it) is that these links are not properly linked using Linkit or some other tool, they are hardcoded in the source in a/href tags. <a href="/title-1A">cool page</a> They work as expected and appear in usage, but if you recreate usage settings after switching the page to /title-1B, those hardcoded links to /title-1A disappear from the usage tab.

    Side note: Needing to have redirect enabled to track redirects isn't ideal UX for our authors. They see "- Restricted access -" "Redirect: redirect," which can be confusing. Admins already can see redirects from inside the node edit screen. It would be nice to be able to granularly exclude the actual redirect entity from appearing in the usage table but still be able to view the actual links that happen to be redirected. If you think this request has legs, I can open a separate ticket.

  • To clarify further, the Type: Redirect does display. This is not overly helpful though. Our assumption is that a page that has been redirected will still appear in the Usage tab under Type: Content as well as having the Type: Redirect display.

    If you link Page A to Cool Page, then you run "Recreate all entity usage statistics," you will see Cool Page is linking to Page A in the Page A Usage tab. If you then change Page A to Page B, you still see Cool Page is linking to Page A/B in the Page B Usage tab. You also now see a redirect called page-a in the Usage tab of Page B. However, if you rerun "Recreate all entity usage statistics," then Cool Page will no longer display in Page B's Usage tab. You will only see page-a redirect display. It seems like this is unintended behavior. I wouldn't expect Cool Page to disappear from the Usage because it is still referencing Page B via the Page A redirect.

  • πŸ‡ͺπŸ‡ΈSpain marcoscano Barcelona, Spain

    Support for redirects has been implemented recently in πŸ’¬ Entity Usage when a URL Redirect Exists Active and the UI displaying usages was improved in πŸ“Œ Consider updating usage when path aliases change Active . Note that changing a path alias / creating a redirect outside of the affected entity's form makes it challenging to update all places in the system that could be using the old URL. Due to this, when there is a need to re-calculate tracking based on a URL that changed, we use a queue to update the corresponding usage information. This means that the system won't be really "up-to-date" until the next time you run cron and all queued items have been processed. (This may explain why you see differences in behavior after you create the redirect and after you run drush to re-generate statistics... the second action would be equivalent of running cron (or waiting a bit if you have cron scheduled to execute in background)).

    Does this clarify things a little bit?

Production build 0.71.5 2024