3

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!)

8
  • 1
    Disable the devel module and any devel related modules, and see if that resolves it.
    – Jaypan
    Oct 6, 2022 at 1:12
  • 1
    Did any known platform or codebase change precipitate this? Are any custom modules installed? Is there a version control log?
    – cilefen
    Oct 6, 2022 at 3:20
  • 1
    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. Oct 6, 2022 at 3:25
  • 1
    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
    Oct 6, 2022 at 6:54
  • 1
    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?
    – 4uk4
    Oct 6, 2022 at 6:59

1 Answer 1

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.