I have a Drupal 8 site on 8.4.2. When I upgrade it to 8.5.1, after running the database updates, the paths /user/register, /user/login, and /user/logout return a 404.

  • I can log in with Drush (drush uli myuser), so it is possible to actually log in, but the log in page is not displayed.
  • I tried uninstalling my custom modules, but the problem persists.
  • I looked at /admin/reports/dblog, but it just says "page not found" as the error for /user/login.

This question about a similar problem was closed as off topic because it was too specific; my question is about "how can I debug this?" not "what is the cause of my problem?"

  • 1
    I have exactly the same problem going from 8.6.4 to 8.5.1... I'm in the process of making a module to check the routes that exist. – Andrew Killen Mar 29 '18 at 18:49
  • 1
    I checked the routeProvider and the settings match the expected values and exist properly. Also tried adding some debug stuff into the form that is called and the controller that manages it all. Nothing shows. It feels like the symphony router is not getting as far as loading the login process before it gives a 404... more investigations tomorrow. – Andrew Killen Mar 29 '18 at 20:42
  • 2
    drupal.org/forum/support/upgrading-drupal/2018-03-30/… added this on the drupal support forum and also put the problem on the Drupal Support group in Facebook. – Andrew Killen Mar 30 '18 at 8:26
  • Checked with Devel and it says "Unable to load route for url '/user/login'" when checking the user.login route. – Andrew Killen Apr 3 '18 at 4:51


Checked with Devel and it says "Unable to load route for url '/user/login'" when checking the user.login route.

How this could be debugged (on an working example, because I don't have a broken site):

Enable Xdebug and go to the url: /devel/routes/item?path=/user/login


  public function routeDetail(Request $request, RouteMatchInterface $route_match) {
    $route = NULL;

    // Get the route object from the path query string if available.
    if ($path = $request->query->get('path')) {
      try {
        $route = $this->router->match($path);

Set a breakpoint for the last line and step into match($path). Then after a new request with the path info is created you get to:


  public function matchRequest(Request $request) {
    $collection = $this->getInitialRouteCollection($request);
    if ($collection->count() === 0) {
      throw new ResourceNotFoundException(sprintf('No routes found for "%s".', $this->currentPath->getPath()));
    $collection = $this->applyRouteFilters($collection, $request);

    if ($ret = $this->matchCollection(rawurldecode($this->currentPath->getPath($request)), $collection)) {
      return $this->applyRouteEnhancers($ret, $request);

getInitialRouteCollection() results in three possible matches:

  • user.login
  • user.login.http
  • entity.user.canonical

The second one is filtered in applyRouteFilters() because this is POST only and for JSON. The entity route is removed after the compiled routes are matched in matchCollection() because "login" is not a valid user.

And so the route user.login is the last one remaining and returned. If not you have to check where on this way the route is not collected or filtered out.

  • 1
    the problem (thanks to luis below) is that we had a view that is on /user/% that normally showed the Author stories as a list when clicking on the authors name on an article, and also re-direct from /user/UID to /author/author-name. Removing that view allows for the login/logout/register to be visible. – Andrew Killen Apr 3 '18 at 14:01
  • OK, in this case you would have seen this view route while debugging the route match. – 4k4 Apr 3 '18 at 14:03
  • @4x4 I'm still going to go through the debug process to see that things are truely fixed and we are dealing with these overview pages properly along with the login/logout pages. Many thanks indeed for your time and help – Andrew Killen Apr 3 '18 at 14:08
  • Thanks Andrew - that was it for me as well. Commenting just in case anyone else hits this snag - I had a view set to /user/content and even that was messing with the default routing of /user. Changed from /user/content to /content/all and voila, it works again. – W0LF Aug 12 '19 at 3:33

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