bugfolder's picture

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.

Some variables data goes into state, though. This change record describes the rationale for state items:

  • 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 variables data that is set once and then rarely changes again;
  • state is preferred for variables data that changes regularly.

Would folks here agree that that is an appropriate distinction and rationale for state usage?

If so, I’d like to suggest that in our documentation where state_* is discussed (e.g., here and here) that we note these criteria and rationales.

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 state_settings_form_submit()).

If this seems reasonable, I’d be happy to work on the changes (both to docs and the new functions in a PR).


klonos's picture

I personally think that having a criterion based on frequency of the variable(s) being changed is subjective (what constitutes "rarely" and "frequently" may vary from use case to use case and perspective/context).

On the other hand, I see the reason behind the following existing criteria:

  • never set via the UI or custom code.
  • expensive to build and don’t necessarily need to be wiped on a cache flush.
  • requested on more or less every request
  • never transferred between sites.

But that's my personal opinion - I'd like to see what others think.

bugfolder's picture

I quite agree that "rarely" vs "frequently" is subjective, and that would be difficult to quantify (thereby leaving it to the judgment of the implementer). Maybe another way of putting the question is "should use of state be restricted to things that satisfy those four criteria and use config for everything else, or are there circumstances other than those where it would be better for the variables data to go in state?"

N.B. Two examples cited by state_get are "the last time cron was run or the current query string appended to CSS/JS files."

Drupal takes a similar approach to State https://www.drupal.org/docs/8/api/state-api/overview. It mentions that it's not meant to be editable by humans. I don't we should encourage coders to use it that way by making it easier.

There will always be edge cases which is fine. I've struggled to decide sometimes whether a variable should be one or the other. Usually the deciding factor for me is whether it's a ok to store it in version control.

bugfolder's picture

@herb, I'm missing why "not meant to be editable by humans" means we shouldn't make it easy for coders to use it. Could you explain further your thinking there?

It seems like if there's a use case for it (and there seems to be one), then we should try to make it easy to use for that use case, and should try to be clear about when it is and isn't appropriate.

A use case that isn't explicitly mentioned on the Drupal 8 API page but that seems appropriate for state, versus config, is something like an on/off switch for a feature that's regularly turned on and off—like, for example, a switch that enables/disables a seasonal block, when you want to allow a low-permission user to turn on and off the content of a block without giving them access to block configuration.

I just figure that this is an edge case and that it is still possible to create a custom submit handler to handle saving the state. I don't see a strong need for making a version of system_settings_form() for state