Consider moving non-constant configuration values for specific sitemap instances out of config.

Yep, the state API was design for this. For our workflow, these will be reverted every time we deploy.

This should defininetely be saved in the state API as it breaks config deployment workflows because you'd deploy wrong config data. Unfortunately this is baked into the xmlsitemap config entity. Are there any reasons for this?

Here is what we currently have in the XmlSitemap entity:

Here are a few questions:

• Which properties should we move to State API?
• How would we relate a set of properties with an XmlSitemap entity?
• Shall we totally replace the XmlSitemap entity by State API?

I think it should remain a config object, I'm guessing a lot of other parts of the module rely on it and semantically it makes sense, it's an item of configuration created by admins. The only things which should move to states API are the things which change when the sitemap is regenerated on each environment. The ones I can spot are:

-chunks: 1
-links: 168
-max_filesize: 24782
-updated: 1472185784

As far as how they are related? Each sitemap has an ID, why not store them in states API keyed by a combination of the module name and the ID of the sitemap.

Hello

We are having this issue in our current project and proposing here a fix for this. Here is a brief description:

• Remove environment dependent properties from the XmlSitemap entity definition (chunks, links, max_filesize, updated)
• Create a XmlSitemapStorage service to manage the XmlSitemap entity operations
• Create a state variable per XmlSitemap entity to store the environment-dependent data
• Use the custom XmlSitemapStorage class to update the state data when performing CRUD operation on the XmlSitemap entity

Now, the environment-dependetn data is not being exported, but it is being loaded and stored transparently to end users.

Regards

I just found some time to have a quick look at the provided patch (just checking the patch contents - did not apply it yet), and I guess this is in there by accident, right?

diff --git a/src/Form/XmlSitemapRebuildForm.php b/src/Form/XmlSitemapRebuildForm.php
index 773da0e..f8c9c9f 100644
--- a/src/Form/XmlSitemapRebuildForm.php
+++ b/src/Form/XmlSitemapRebuildForm.php
@@ -100,7 +100,7 @@ class XmlSitemapRebuildForm extends ConfigFormBase {
    */
   public function submitForm(array &$form, FormStateInterface $form_state) {
     // Save any changes to the frontpage link.
-    $entity_type_ids = $form_state->getValue('entity_type_ids');
+    $entity_type_ids = ['node' => 'node'];//$form_state->getValue('entity_type_ids');
     $save_custom = $form_state->getValue('save_custom');
     $batch = xmlsitemap_rebuild_batch($entity_type_ids, $save_custom);
     batch_set($batch);

Thanks @hctom

I completely forgot to remove that line of debugging code.

Attaching now the updated patch and the related interdiff

Was just hitting this issue -- We check the config of all production sites nightly, and XMLSitemap is triggering a change every night...

I was thinking of suggesting exactly what you're proposing with this patch -- move the frequently changed things into the State API.

Will apply and see if it works correctly and addresses our needs...

Confirmed working for me, too!

Committed. Thanks everyone!

FWIW, this issue still exists if you try to use
https://www.drupal.org/project/config_readonly
But we can't quite figure out which config variable is still being written to.

Our workaround was to add the configuration name xmlsitemap.xmlsitemap.* into the config readonly whitelist in the settings.php.