In Drupal, the
variables table was a handy catch-all repository for bits of information that needed persistent storage. In Backdrop, this table goes away, and much of what was stored there should be migrated to config, as described in Configuration Management.
variables data goes into
state, though. This change record describes the rationale for
- They are never set via the UI or custom code.
- Some of them are not really cache items - more for tracking state between requests (and different sessions).
- Some that look like cache items (path alias whitelist, css/js) are expensive to build and don’t necessarily need to be wiped on a cache flush.
- Some of them are requested on more or less every request to Backdrop.
- They are never transferred between sites.
There is one more category of data that gets stored in the
variables table that doesn’t fit neatly into either config or the above criteria: that is frequently changed configuration data. An example would be switches on a “control panel” that turns on and off temporary or seasonal effects. For example, on our site, we have site-wide banners that we put up just when an event is going on, a warning banner if the site is going to have scheduled maintenance, and the like, whose behaviors are under control of checkboxes and select options on a custom control panel page (to provide a friendly interface for admins). These get switched on and off all the time by various admin users.
These sorts of data are certainly configuration-like, and so would be candidates for config. But when configuration management is stored under version control (like the versioned staging approach), having the active config directory changing often is awkward, due to the need to ensure sync with the version-controlled staging directory. Stuff that gets changed often is typically stored in the db (like
state data), and so this version control approach pushes one toward another rationale for config versus state:
- config should be used for
variablesdata that is set once and then rarely changes again;
- state is preferred for
variablesdata that changes regularly.
Would folks here agree that that is an appropriate distinction and rationale for
For forms that set a bunch of settings/configuration variables, we have the new and improved
system_settings_form() that automatically stores its variables in config. For “control panel”-type pages that would store their variables in
state, it would be nice to have a function that behaved like the old D7
system_settings_form(), but storing things in
state, rather than config. So I’d like to also suggest that we create a new function,
state_settings_form() (and associated
If this seems reasonable, I’d be happy to work on the changes (both to docs and the new functions in a PR).