Use key_value.expirable for the development settings page

Created on 18 April 2025, 3 months ago

Problem/Motivation

The development settings page uses key_value for storing the current state of the toggles. This is good in the sense that it allows a UI without requiring config to change, since usually config gets deployed upwards from development from development to production, while database themselves don't.

However, when taking a site from development to live for the first time, this will usually be done by making an existing environment public, or syncing a database from a staging to production environment.

If development mode is on when the site is moved to production, then it will be on until someone with access to switch it off logs into production and submits the form (or resets it via drush etc.).

I think we could mitigate this by using key_value.expirable instead. If we toggle development mode for some number of days, then even if it makes its way to production, or is toggled on production against the advice on the form to debug something, then even if it's forgotten about, it will eventually get switched off again.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

📌 Task
Status

Active

Version

11.0 🔥

Component

base system

Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @catch
  • 🇨🇭Switzerland berdir Switzerland

    This honestly seems a bit confusing.

    What about adding a requirements check that warns about this? We also have sensor for this in the monitoring project, because sometimes people change the setting in sites/default/services.yml and accidentally commit it. A requirements check would help with both.

  • 🇬🇧United Kingdom catch

    A requirements check could work with Add a Production/Development Toggle To Core Needs work , it will be harder for the current implementation because it would need to check multiple different key/value keys and that list could potentially keep expanding - not impossible just a bit messy.

  • 🇨🇭Switzerland berdir Switzerland

    It doesn't need to check key value at all, it just needs to check the container parameters. It doesn't matter if they are set through key value or a customized services file.

    See https://git.drupalcode.org/project/monitoring/-/blob/8.x-1.x/src/Plugin/...

  • 🇬🇧United Kingdom catch

    Hmm OK but we'd need to check each parameter then, however I guess we kind of have to because we might want individual messages for each.

    I guess what development mode would allow then is to suppress all of those individual messages for things toggled by dev mode, but replace them with a general development mode warning instead or something.

    Retitling based on that.

Production build 0.71.5 2024