Problem/Motivation

ThemeSettingsForm uses theme_get_setting() to get form values - this uses configuration with overrides (as it has to since it is primarily used at runtime). But this means that if any theme setting is overridden using config overrides then they can end up stored in configuration without the user intending that.

Steps to Reproduce

  1. Install standard
  2. Override a theme setting in settings.php for example $config['system.theme.global']['favicon']['use_default'] = FALSE;
  3. Go to /admin/appearance/settings - the override will change the form value - which it should not.
  4. Press save and the override will now be saved to the stored configuration - which it should not.

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Comments

catch’s picture

Is this still valid?

alexpott’s picture

yes

joelpittet’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +CMI

What is the proposed solution here?

joelpittet’s picture

Issue summary: View changes
Issue tags: +Needs steps to reproduce

This needs an example or steps to reproduce.

alexpott’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Needs work
Issue tags: -Needs steps to reproduce

Added steps to reproduce.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

catch’s picture

Issue tags: +Triaged D8 major

We discussed this on a call with core committers and theme system maintainers and agreed it's definitely a major bug since it's completely inconsistent with how other configuration forms work and could result in development settings being deployed to production inadvertently.

Depending on the fix this could end up only happening in 8.2.x but leaving at 8.1.x for now.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.