Score:3

All routes resolve to entity.user.edit_form for authenticated users

nr flag

This is a new one for me:

All routes, for an authenticated user, resolve to entity.user.edit_form.

Anonymous users are able to browse all public-facing pages of the site without any problems.

This is the route:

$ ddev drush core:route --name=entity.user.edit_form
name: entity.user.edit_form
path: '/user/{user}/edit'
defaults:
  _entity_form: user.default
  _title_callback: 'Drupal\user\Controller\UserController::userTitle'
requirements:
  user: \d+
  _entity_access: user.update
options:
  _admin_route: true
  parameters:
    user:
      type: 'entity:user'
      converter: paramconverter.entity
  _access_checks:
    - access_check.entity

There doesn't seem to be anything wrong with this particular route -- it's all the other ones that don't behave as expected.

For what it's worth:

Drupal version   : 9.4.5
PHP version      : 7.4.30

The problem surfaced on a remote production site running on Microsoft Azure (Kudu / IIS); I have imported its database, for testing purposes, into a DDEV-Local environment (Docker / Linux).

In the remote environment, the following route-related errors appeared in the dblog:

$ ddev drush ws
 --------- -------------- ------------------ ---------- --------------------------------------------- 
  ID        Date           Type               Severity   Message                                          
 --------- -------------- ------------------ ---------- ---------------------------------------------                                         
  5692475   04/Oct 20:10   php                Error      Symfony\Component\Routing\Exception\RouteNotFou  
                                                         ndException: Route "devel.configs_list" does     
                                                         not exist. in                                    
                                                         Drupal\Core\Routing\RouteProvider->getRouteByNa  
                                                         me() (line 206 of D:\home\site\wwwr              
  5692474   04/Oct 20:10   php                Error      Symfony\Component\Routing\Exception\RouteNotFou  
                                                         ndException: Route "devel.configs_list" does     
                                                         not exist. in                                    
                                                         Drupal\Core\Routing\RouteProvider->getRouteByNa  
                                                         me() (line 206 of D:\home\site\wwwr              
  5692473   04/Oct 20:10   php                Error      Symfony\Component\Routing\Exception\RouteNotFou  
                                                         ndException: Route "devel.configs_list" does     
                                                         not exist. in                                    
                                                         Drupal\Core\Routing\RouteProvider->getRouteByNa  
                                                         me() (line 206 of D:\home\site\wwwr              
  5692472   04/Oct 20:10   php                Error      Symfony\Component\Routing\Exception\RouteNotFou  
                                                         ndException: Route "devel.configs_list" does     
                                                         not exist. in                                    
                                                         Drupal\Core\Routing\RouteProvider->getRouteByNa  
                                                         me() (line 206 of D:\home\site\wwwr              
 --------- -------------- ------------------ ---------- --------------------------------------------- 

In the DDEV-Local environment, I executed the following commands:

$ ddev drush eval '\Drupal::service("router.builder")->rebuild();'             
$ ddev drush cr
 [success] Cache rebuild complete.

After rebuilding the routes, the error no longer appears in the logs; however, all routes now arrive at the logged-in user's profile edit form.

In comments, @jaypan said:

Disable the devel module and any devel related modules, and see if that resolves it.

This is a good suggestion. Those modules are already disabled:

$ ddev drush pml |grep devel                        
  Development                          Devel (devel)                           Disabled   4.1.3           
  Development                          Devel Generate (devel_generate)         Disabled   4.1.3           
  Webform                              Webform Devel (webform_devel)           Disabled   6.1.2

They are present in the composer.json:

$ grep devel composer.json                    
        "drupal/devel": "^4.1",
        "drupal/devel_generate": "^4.1",

I am able to enable them without error:

$ ddev drush en devel devel_generate
 [success] Successfully enabled: devel, devel_generate

This does not fix the routes.

I am able to disable them without error:

$ ddev drush pmu devel devel_generate
 [success] Successfully uninstalled: devel, devel_generate

This also does not fix the routes.

The previous developer was unable to use Drush in this environment and appears to have been using raw SQL queries to clear caches (truncate all the cache tables) and disable modules. The errors are quite likely related to that approach.

Update (2022-10-07)

In comments, @cilefen asked:

Did any known platform or codebase change precipitate this? Are any custom modules installed? Is there a version control log? Have you restored from backups to identify when or how this changed?

I still do not have access to the client's VPN, so I can't access their version control repositories directly. We have restored the database from backups that predate the problem, so I now think the problem may be caused by Azure DevOps being configured to deploy the built artifact on top of the previously-installed files.

Troubleshooting from another angle, I have used curl to capture an authentication cookie:

$ curl --cookie cookie.txt --cookie-jar cookie.txt $(ddev drush uli)

Now, when I use curl to request a page as an authenticated user, I receive this:

$ curl --cookie cookie.txt https://clientsite.ddev.site
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   414    0   414    0     0   3568      0 --:--:-- --:--:-- --:--:--  3568
<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8" />
        <meta http-equiv="refresh" content="0;url='https://clientsite.ddev.site/user/1/edit'" />

        <title>Redirecting to https://clientsite.ddev.site/user/1/edit</title>
    </head>
    <body>
        Redirecting to <a href="https://clientsite.ddev.site/user/1/edit">https://clientsite.ddev.site/user/1/edit</a>.
    </body>
</html>%

This appears to show that the redirect is caused by <meta http-equiv="refresh" content="0;url='https://clientsite.ddev.site/user/1/edit'" /> rather than by corruption in the routing table.

I hope I'm getting close to resolving this. (If not, I might add a bounty to the question in 10 hours!)

Jaypan avatar
de flag
Disable the devel module and any devel related modules, and see if that resolves it.
hotwebmatter avatar
nr flag
Good idea @Jaypan! See my edited answer above for my full response.
id flag
Did any known platform or codebase change precipitate this? Are any custom modules installed? Is there a version control log?
miststudent2011 avatar
fr flag
IIRC I ran into this issue with custom entity which has wrong parameters in routing.yml parameters: user: type: 'entity:user' This might be causing it.
4uk4 avatar
cn flag
It makes sense that the previous developer got into trouble with routes when only truncating the cache tables because routes are stored in a different database table. A cache clear, either in UI or via Drush, includes rebuilding the router table, so you don't need the extra step.
4uk4 avatar
cn flag
Now that you have removed Devel properly, can you provide some details about the second problem? Is Drupal redirecting to the user edit form when you check the responses in the F12-tools of your browser?
id flag
Have you restored from backups to identify when or how this changed?
hotwebmatter avatar
nr flag
Thanks for all the great responses. @cliefen I've restored a database backup from just before the remote site crashed, and I may try to restore an earlier one next. As for the codebase, I'm still waiting for VPN access to the client's GitHub Enterprise repositories; meanwhile, I have a tarball of the Production build artifact (not including git metadata) from the Azure DevOps folks. Another possible angle: some contrib modules are duplicated under `./modules/` and `./modules/contrib/` (they are not using `drupal/recommended-project`). So I've got many options for fixing things. :)
Score:0
nr flag

I figured out what was causing the redirect, and it was something perfectly normal and obvious: the Password Policy module.

I had been using drush uli to log in as User 1, but the site had a password expiry policy, and User 1 had not logged in for a long time ... so its password was expired.

I'm just so used to ignoring the message that says "change your password" that I didn't read it :)

Resetting the User 1 password made the redirect go away.

I might open an Issue Queue for Password Policy to suggest that the module should implement a different route to reset the password, rather than re-using the default profile edit page.

I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.