Problem/Motivation
When you disable a text format it is not possible to re-enable it. This seems counter to the behavior in other situations, such as Views, which allows disabling than re-enabling a display. Furthermore, it can lead to major problems on a site if a text format was mistakenly disabled.
Steps to reproduce
Disable a text format and experience the disappointment upon realizing it can't be re-enabled. You'd need to create a new text format (yet can't create one with the same machine name), then change all items previously using the old one to use the new one.
Work around
\
From #60
- go to /admin/config/development/configuration/single/export
- choose Text format as the Configuration type
- choose the disabled text format as Configuration Name
- copy the configuration
- go to /admin/config/development/configuration/single/import
- choose Text format as the Configuration type
- paste the configuration
- change "status" from false to true
- click on import
Proposed resolution
Add an "Enable" operation for disabled text formats, which can be used to re-enable the disabled text format.
Add a 'Status' column to disable the status of the format. This is similar to the search pages, /admin/config/search/pages.
Remaining tasks
Code review
If needed add a followup to explore and implement an effective solution for ensuring cache reflects changes when a text format is re-enabled. This may involve adjusting or entirely rethinking the approach to cache tag management within preRenderText method of core /modules/filter/src/Element/ProcessedText.php#142 and #144
User interface changes
Both screenshots taken after disabling the Basic filter
Before
After
API changes
Data model changes
Release notes snippet
Beta phase evaluation
Issue category | Bug because of unexpected behaviour. Upon disabling the text format it disappears from the form which makes it seem deleted, but it isn't actually deleted because you can't add a new text format with the same machine name. |
---|---|
Issue priority | Major because as cilefen states in #19:
|
Prioritized changes | The main goal of this issue is two-fold, fixing a DrupalWTF bug and improving usability. |
Disruption | Non-disruptive because only the filter format admin interface is changed. No API changes |