Problem/Motivation
It is not necessary to storage information about disabled filters in the config system, because they describe state of system where the config is saved and pollute the config system.
It is also impossible to release a dependency on a module or plugin by disabling it from the filter.
Steps to reproduce
- Install Standard.
- Navigate to
/admin/config/development/configuration/single/exportand export the Full HTML text format - Observe that
filter_htmlis present (but hasstatus: false) even though it is not enabled
Proposed resolution
Filter disabled filters before config save.
Remaining tasks
Tests?
User interface changes
API changes
| Comment | File | Size | Author |
|---|---|---|---|
| #26 | 2385047-26.patch | 7.61 KB | wim leers |
| #24 | interdiff_23-24.txt | 2.74 KB | codebymikey |
| #24 | drupal-filter-remove-disabled-filters-2385047-24.patch | 3.35 KB | codebymikey |
| #24 | interdiff_23-24-9.2.x.txt | 1.22 KB | codebymikey |
| #24 | drupal-filter-9.2.x-remove-disabled-filters-2385047-24.patch | 3.26 KB | codebymikey |
Issue fork drupal-2385047
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #1
webflo commentedComment #5
karlsheaReroll on 8.2.x, the array_filter needed to happen after parent::preSave().
Comment #6
karlsheaComment #16
catchI just checked a couple of config exports, and I couldn't find a text format with a disabled filter, the exports only had the filters that were explicitly enabled - how do you end up with a disabled filter in configuration?
I did notice that each filter has status: true, which isn't in the config schema. So if we still save disabled filters in some situations, we should also remove this key as part of removing them from the exports since it'll no longer be necessary.
Comment #17
catchComment #18
quietone commentedAdding steps to reproduce and a related issue.
In the related issue the filter will not be removed, it can be re-enabled. That seems far better to me than deleting it.
What is the reasoning for deleting the filter?
Comment #19
quietone commentedI was completely wrong on this, ignore my previous comment. I am removing changes to the IS and restoring tag.
Comment #20
catchAgreed with trying to clean this up, but it's a task rather than a functional bug.
Comment #23
codebymikey commentedComment #24
codebymikey commentedEnsure that the filters are also sorted by weight so they're consistently stored.
Comment #26
wim leersTests are present already.
Added steps to reproduce.
I'd RTBC the MR, but it needs to be rebased on top of
9.5.x… but then again we'll also need this to get committed to10.0.x. So I just converted @codebymikey's MR to a patch that applies to both9.5.xand10.0.x👍Comment #27
alexpottThis will need an update function to process existing configuration to remove disabled filters.
Plus sorting of configuration should ideally by done by schema and sorting by the key is better than by weight as sorting by weight produces impossible to read diffs when only weight is changing.
Comment #30
eric_a commentedThis now needs a small cleanup after #3017054: Consistently sort filter formats to simplify config exports.
As for the needed update function:
filter_post_update_sort_filters()from that issue must be perfect example code.Comment #31
wim leersThis will help make #3421946: [PP-2] Make FilterFormat config entities fully validatable simpler.
Comment #32
wim leersAFAICT this should also change
to:
… because all entries in
filter.format.*:filterswill havestatus: true.Comment #33
wim leersAlso:
\Drupal\ckeditor5\Plugin\CKEditor5PluginManager::isPluginDisabled()can be simplified thanks to this change:Comment #34
wim leersComment #38
bbralaThis issue confuses me, there was a patch, but looking at the current MR i see quite a few things from there missing. This issue needs some investigating to see if we are not missing loads.
Not unexpeceted since its so old :)