Posted by paucku on Thu, Nov 13, 2025 - 2:29am

I am experiencing an issue caused by a configuration corruption that breaks my website.

The file system.core.json located in /files/config_[random-string]/active ends like this:

    "user_login_appearance": "tabs",
    "login_admin_theme": 1
}
e": "tabs",
    "login_admin_theme": 1
}

The bold lines should not be there. When I remove them, the website starts working again.

The exact invalid fragment may vary, but the result is always the same: the system.core.json file becomes invalid JSON because of an extra closing brace and duplicate or incomplete configuration entries.

After manually removing the invalid section, the site works again — but only temporarily. After some time, the file becomes corrupted again.

As far as I know, files in the active configuration directory should not be edited directly. However, I cannot import configuration from the staging directory because when the corruption occurs, the site becomes unusable and I cannot access the admin UI.

I suspect that the issue may be related to the Domain Access module, although I do not have solid proof. It is possible that I misconfigured it, since the module is quite complex and I do not fully understand how it works. Still, the problem could be coming from somewhere else.

To resolve this, I need to understand how Backdrop's configuration system ("active" vs. "staging") works internally. Where is the canonical version of the configuration stored — in the active directory, or in the database? I suspect the database is involved, because otherwise the system should not be rewriting the active configuration files.

Is there a way to make Backdrop recognize a manually cleaned-up system.core.json file in the active directory, even without using the admin interface? I tried to pull it from staging but after I repair it both files in staging and active are identical and the configuration management system does not allow me to apply the configuration.

Comments

Thu, Nov 13, 2025 - 2:48am by yorkshirepudding

Hi paucku. Whether 'active' config is stored in the database or files is determined in settings.php here: 

/**
 * Configuration storage
 *
 * By default configuration will be stored in the filesystem, using the
 * directories specified in the $config_directories setting. Optionally,
 * configuration can be store in the database instead of the filesystem.
 * Switching this option on a live site is not currently supported without some
 * manual work.
 *
 * Example using the database for live and file storage for staging:
 * @code
 * $settings['config_active_class'] = 'ConfigDatabaseStorage';
 * $settings['config_staging_class'] = 'ConfigFileStorage';
 * @endcode
 */
// $settings['config_active_class'] = 'ConfigFileStorage';
// $settings['config_staging_class'] = 'ConfigFileStorage';

By default it uses files, but if you have changed config_active_class to ConfigDatabaseStorage then it will be database.

To force it to sync the system.core.json you could make a minor inconsequential change to the maintenance_mode_message setting and that should force the sync of the file.

If you suspect Domain Access, see if you can narrow it down to a particular form. I can't think of anything that would cause that as any config setting is done via the standard config functions.  I've checked my dev version of Domain access and the config is fine, so if it is that module and we can narrow down where it is caused, it may be that additional validation is needed to prevent incorrect entries.