Allow admin users to be reminded when forms in /admin are likely to alter configuration

Adding link to Config Override Warn as inspiration

Adding an option for the warning to include a custom message.

Playing around with this a little and the following working “pseudo code” (i.e. please don’t actually use this as is - it is just to test ideas) gives the idea of what I’m thinking:

function xx_form_alter(&$form, FormStateInterface $form_state, $form_id) :void {

  // Get out of here if it is not an admin form.
  if (!\Drupal::service('router.admin_context')->isAdminRoute()) {
    return;
  }

  // We need an actual object rather than just a jumble of array items.
  $form_object = $form_state->getFormObject();

  // Assume forms have no config to begin with.
  $has_config = FALSE;

  // Does the getEditableConfigNames method exist on the form?
  if (method_exists($form_object, 'getEditableConfigNames')) {
    $has_config = TRUE;
  }

  // Are we editing an entity that has config form for it's setup?
  if ($form_object instanceof EntityForm) {
    $entity = $form_object->getEntity();
    if ($entity instanceof ConfigEntityInterface && !$entity->isNew()) {
      $has_config = TRUE;
    }
  }

  // Permisions being permissions.
  if ($form_object instanceof UserPermissionsForm) {
    $has_config = TRUE;
  }

  // Blocks being blocks.
  if ($form_object instanceof BlockListBuilder) {
    $has_config = TRUE;
  }
  // Okay, warn people.
  if ($has_config) {
    \Drupal::service('messenger')->addWarning(t("This form is likely to alter the running configuration of the site and, therefore, changes should probably go through the development quality processes."));
  }

}

Note: BlockListBuilder extends ConfigEntityListBuilder and that ’s probably worth looking out for, rather than the special case of blocks.

Isn't this the same as 🐛 Display status message on configuration forms when there are overridden values Fixed ?

Actually, reading again, it's not the same, sorry!

This is an excellent idea, it's something we're currently coming up against where site editors used to have access to config pages in D7 that we can't give them access to anymore as they're controlled in config.

It would be very useful to have a clear indication for them of what pages they can't change as they won't know. We can of course take their permissions away, but there are also cases where the support team may use a privileged account to help fix issues the site editors are experiencing. Having this message for them would speed up support and ensure issues don't get introduced when config reverts on import.

Overall this would be great functionality we would make use of on our sites.

Don't mind me, just fixing the version.

I like the idea. Hopefully we don't have too many forms where content and configs is mixed up.

Might need UX folks for how this should look like and behave

I also quite like that idea, because there are some legitimate cases where configuration is changed on a production site. Just some additional thinking aloud.

• There are messages displayed if config is overriden in the settings.php file (so that site builders don't get confused why the config change in the GUI doesn't have an effect). That should work together somehow, and look consistent.
• If something is in config ignore, then it also shouldn't show up - or show up with a different message?
• This shouldn't show up on a development site because it would drive site builder crazy. May a toggle to turn it off, that can be overridden in a local settings.php file?
• The wording of the message: This is also relevant for projects that don't have a dev team - as long as there is a separate copy of the site for development and exporting config. Something like "This configuration should better be changed in the development environment and then exported. Otherwise they will be reverted back during the next config import."
• And maybe... and option for an extra field for whom to contact if this really needs changing on prod to ensure it doesn't get lost?

This is a nice idea. Developers should not be editing config live on production either, really so they should also see a warning. The simple environment indicator module already warns of the environment. Perhaps this could be used in combination with that.

I should probably not only see this warning on forms but as soon as I land on the config, views, block layout or metatag area.

It feels as though a check of every form could be expensive.

How about a block with a customisable message that is placed by checking against a list of pre-defined, customisable routes? It may (or may not be) as straightforward as /admin/structure, /admin/config and so on.

The code above actually works, Tony. It inspects what base classes the form is implementing and can make a prediction of whether it will affect running config from that. This means it even works on contrib modules!

• There are messages displayed if config is overriden in the settings.php file (so that site builders don't get confused why the config change in the GUI doesn't have an effect). That should work together somehow, and look consistent.
  -- yes, I would suggest the code sits alongside that, too.
• If something is in config ignore, then it also shouldn't show up - or show up with a different message?
  -- very good point! Should be a reasonably easy check to make, I expect
• This shouldn't show up on a development site because it would drive site builder crazy. May a toggle to turn it off, that can be overridden in a local settings.php file?
  -- yeah, I was thinking we could have a option in the development section of admin that is turned off by default - a site owner only turns it on for prod sites, if they want.
• The wording of the message: This is also relevant for projects that don't have a dev team - as long as there is a separate copy of the site for development and exporting config. Something like "This configuration should better be changed in the development environment and then exported. Otherwise they will be reverted back during the next config import."
• And maybe... and option for an extra field for whom to contact if this really needs changing on prod to ensure it doesn't get lost?
  -- yeah - another option in the development area, I would suggest, though I guess the whole text could be overidden just like any text can be overridden in the site.