Route "sitemap.page" does not exist error after upgrading to 8.x-2.0-beta7

This happened to me after I updated the module, but I hadn't run the database updates. Did you?

Yes, I run updates as part of the deployment. I have cleared the cache as well.

By any chance, are you running database updates and then importing config right afterwards (e.g.: like drush deploy)?

The sitemap.page route used to be defined in sitemap.routing.yml, but in ✨ Customize the sitemap path Fixed we changed it to be defined by \Drupal\sitemap\EventSubscriber\RouteSubscriber::alterRoutes() so the path can be stored in a new configuration key (see commit ea3e82fa).

(3348769 was merged back in April, but apparently didn't get released until now — apologies!)

The sitemap_update_8201() update hook sets the new configuration key to be sitemap (i.e.: /sitemap), but if you import the old configuration right after running database updates, it is possible that the newly-added configuration gets deleted by the config-import that gets run right afterwards.

(note, we also set the default to sitemap in config/install/sitemap.settings.yml, but that is only used when the module is installed)

As a work-around you might want to...

1. Update sitemap locally
2. Run drush updatedb or update.php
3. Run drush config:export or export config from the UI
4. Commit the change to sitemap.settings.yml

... I will add this work-around to the module release notes right away.

In the mean time, does anyone know of a more-permanent way to solve this, or could point me to what another project (e.g.: core, contrib) has done?

The only thing I can think of right now is exporting configuration in the update hook, but I don't think that is a recommended practice, especially for sites that have their production filesystem set to read-only (e.g.: Pantheon).

I do a lot of manual testing, but I don't think that I ran into this locally, because I had previously run into this problem back in 2019 on other modules, so I had gotten into the habit of...

1. updating modules locally,
2. running database updates,
3. exporting config,
4. committing the changes, and
5. pushing that to my shared environments, which then run drush deploy (i.e.: on the updated, newly-exported config)

... but I'll bet that not everyone does this.

Those are the steps I ran locally when I updated them module. There was no new config exported after I ran the updates and config exports for sitemap. Since it has already been updated, and updated locally and the admin config page to set a path is inaccessible, I'm not sure what the local steps to fix are.

@shelane, if you have drush, could you try running drush config:set sitemap.settings path 'sitemap', and let me know if that fixes the problem? If so, I will add that to the release notes as well.

I ran that step which did add path: sitemap to the sitemap config. However, that did not fix the error trying to go to the admin configuration page.

I apologize for the delay replying... I appear to be the only active maintainer of this module, and it took me a while to wrap my head around the chicken-and-egg nature of the problem.

As mentioned earlier, if you update the module, run database updates, export config, and commit that, then everything works fine going forward. But if it didn't happen exactly that way after upgrading, then your site gets into a state where it can't build the new route because it can't find the config, so clearing caches doesn't help.

I have some code that appears to make it work on my test environment, and I'll add an update hook to rebuild the router cache as well.

I will post a merge request and patch shortly, if you could test it and tell me if it works, then I can create a new release.

Thank you again for your patience.

@shelane, may I trouble you to try the attached patch → and let me know if it fixes the problem?

How to apply the patch with composer:

1. Add the URL of the patch file to the composer.json file in the extra -> patches section:
   

       {
           ...
           "extra": {
               ...
               "patches": {
                 ...
                 "drupal/sitemap": {
                     "3466939-9: ": "https://www.drupal.org/files/issues/2024-08-12/3466939-9--route-does-not-exist-error-after-beta7.patch"
                 }
                 ...
               },
               ...
           }
           ...
       }
     

2. Run composer update drupal/sitemap to update the lock file.
3. Verify that line 39 in .../modules/.../sitemap/src/EventSubscriber/RouteSubscriber.php looks like $path = $this->config->get('path') ?? 'sitemap';
4. Run database updates
5. Log in if you aren't already
6. Visit /admin/config/search/sitemap: the config page should load without errors. Please let me know what happens by adding a comment in this issue.
7. If this works, then:
   1. Click the Save configuration button at the bottom of the page.
   2. Export configuration. You should see a change to sitemap.settings.yml that adds the line path: sitemap.
   3. Commit the change to sitemap.settings.yml.
   4. At this point, the un-patched code should work again, so in preparation for upgrading to beta9:
      1. Undo the change to composer.json in the extra -> patches section that you made in step 1
      2. Run composer update drupal/sitemap to update the lock file.
      3. Double-check that the config page loads without errors by going to /admin/config/search/sitemap.

I will update the issue summary shortly.

Updating issue title to better summarize the problem.

Moving to "Major" priority as per Issue Priority field documentation for Major Bugs → ("Trigger[s] a PHP error through the user interface, but only under rare circumstances or affecting only a small percentage of all users, even if there is a workaround.")

Updated issue summary, part 1.

Updated issue summary, part 2: added steps to reproduce.

After some work, I'm not really sure that there is a way for me to make a patch to test that (a) doesn't contain unrelated changes, and (b) that running database updates from won't break the module in the future (due to the very important config changes made in an update hook in the previous patch).

However, I've tested this several different ways on several different sites at this point, so I feel like it is ready to merge and make a new release, so I'm going to do that shortly.

(although this time I'm going to make clear that there are database hooks which modify configuration — and what to do about that)

I am crediting @dcam on this issue, for their excellent update hook test, which I've made use of here.

This has been merged, and I'm getting ready to make a release.

This fix has been released in sitemap-8.x-2.0-beta9 → .

Automatically closed - issue fixed for 2 weeks with no activity.