Problem/Motivation
The issue occurs in a special scenario, we need to have enabled the following contrib modules: redirect, subpathauto.
The method processInbound(...) located in PathProcessor.php file is not resolving correctly the alias when it has a redirect. That makes it fail when a redirect is created automatically, I mean, the expected behavior of redirect from old to new url doesn't happen and instead throws 404 page. This is because the processor treats the old url as a valid case when it should be replaced by the new url instead. I'm leaving a tested steps below.
Steps to reproduce
First prepare a clean Drupal 8 installation:
$ composer create-project --prefer-dist drupal/recommended-project d88
$ cd d88
$ composer remove drupal/core-project-message
$ chmod u+w web/sites/default
$ drush site-install standard --db-url='mysql://[db_user]:[db_pass]@localhost/[db_name]' --site-name=Example
$ composer require drupal/redirect
# For the most recent release
$ composer require drupal/subpathauto
# Or for the dev version
# composer require 'drupal/subpathauto:1.x-dev'
$ drush en redirect
Now, follow these steps to create content, aliaspath and redirects.
- Create a page view that lists content and has a path alias
- /admin/structure/views/add
- For "View name" enter anything like "Article list"
- Under "View Settings", set Show: "Content", of type "Article"
- Under "Page Settings" check the box for "Create a page"
- Leave the defaults.
- Note using that example text, the Path defaults to "article-list"
- Click "Save and edit"
- Add a Contextual Filter for "Tags (field_tags)"
- (depending on the view path will vary, could be admin/structure/views/view/article_list )
- expand the "Advanced" section
- Next to "Contextual filters" click "Add"
- In "Search" enter "tags"
- Click the checkbox next to "Tags (field_tags)"
- Click the button "Add and configure contextual filters"
- Under " WHEN THE FILTER VALUE IS NOT IN THE URL" keep the default "Display all results for the specified field" option
- Under "WHEN THE FILTER VALUE IS IN THE URL OR A DEFAULT IS PROVIDED" section check "Specify validation criteria"
- For "Validator" select "Taxonomy term name"
- For "Vocabulary" click the checkbox "Tags"
- For "Action to take if filter value does not validate" keep the default: Show “Page not found”
- Click the "Apply" button
- Click the "Save" button
- Create an alias /articles to the system path /article-list
- admin/config/search/path/add
- In "System path" enter "/article-list"
- In "URL alias" enter "/articles"
- Click "Save"
- Create an article at the path /articles/foo
- /node/add/article
- In "Title" enter "foo"
- Expand the URL Alias field set
- In "URL alias" enter "/articles/foo"
- Leave other defaults
- Click "Save"
- Change the path of the article to somewhere else, eg /foo
- edit the node (eg /articles/foo/edit)
- Expand the URL Alias field set
- In "URL alias" enter "/foo"
- Leave other defaults
- Click "Save"
- At /admin/config/search/redirect, confirm there is a redirect from /articles/foo to /foo
- Go to /articles/foo and observe the expected redirect.
- end up viewing the node, just the node
- at /foo
- Install and enable subpathauto
- Go to /articles/foo and observe a 404 error.
After a quick review I detected that in the mentioned method processInbound(...) is processing the old url instead of the new url and when a part of this url matches with some existing pathalias it replaces the url generating a wrong (non-existing) path.
Proposed resolution
(Not verified yet, but an idea is to) add a condition to verify the current url (is new/old) and if a part of this url is not matching with an alias.
Remaining tasks
- (done) simplify the steps
- (done) make steps to reproduce detailed
- (done) verify problem is in the latest dev code too
- (done) check if could be same as
https://www.drupal.org/project/subpathauto/issues/2856303
🐛
Aliases don't get resolved
Fixed
- (done) implemented an initial patch.
- continuing with usual back and forth. no specific next actions or blockers identified yet.
User interface changes
N/A
API changes
N/A
Data model changes
N/A