Problem/Motivation

If a module provides a default filter format implementation in config/install it is possible to end up in a situation where the module can not be re-installed. Discovered in #2639336: filter.format.php_code already exists in active configuration.

Also it is possible that a disabled filter format will be deleted on uninstall. Filter format deletions are prevented in the UI because of security risks. Disabling filter formats was added in #1826602: Allow all configuration entities to be enabled/disabled

One thing that makes the problem even more funky is #2502637: Disabled text formats can't be seen in the GUI

Proposed resolution

No idea. yet.

Remaining tasks

Come up with a way to fix this.

User interface changes

tbd

API changes

tbd

Data model changes

tbd

Comments

alexpott created an issue. See original summary.

alexpott’s picture

My current thoughts are:

  • If a filter format is in use we should not allow it to be deleted
  • If a module provides a filter plugin that is in use it should not be able to be uninstalled
  • Filter formats should not be disable-able - this makes less sense now we have config dependencies
  • If they are not used they should be deletable through the UI
catch’s picture

If a module provides a filter plugin that is in use it should not be able to be uninstalled

This should already be the case after #2348925: Uninstalling a filter plugin removes text formats.

But looks like the same wasn't applied to formats as a whole.

There's a couple of old issues around this that never got resolved: #562694: Text formats should throw an error and refuse to process if a plugin goes missing and #161354: Disabling a module which provides a text format leaves the text format behind. Looks to me like we fixed it for filter plugins and just forgot about formats.

alexpott’s picture

#2348925: Uninstalling a filter plugin removes text formats made so that only enabled filter formats are checked not disabled - hence the weird bug reports because the behaviour seems really odd.

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.

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.