Problem/Motivation

When configurable plugins are exported, they output their current configuration. If that matches exactly to a plugin's default configuration, it's not necessary to store it.

Proposed resolution

Move the Condition plugin code to the parent class.
This is also needed by #2295129: Filter formats should not save plugin data when the plugin configuration matches defaults.

Remaining tasks

If #2295129: Filter formats should not save plugin data when the plugin configuration matches defaults goes in first, reroll to remove that bit.

User interface changes

API changes

CommentFileSizeAuthor
#1 plugin-2310023-1.patch2.46 KBtim.plunkett

Comments

tim.plunkett’s picture

Status: Active » Needs review
StatusFileSize
new2.46 KB

Because we move this up, we don't have to bother with a second loop and unset, we can just not assign it in the first place.

tim.plunkett’s picture

Status: Needs review » Closed (works as designed)

Once you deployed a config with default values these defaut values won't be part of the active config.
If you as a filter plugin developer want to change default values, this would automatically change the behavior of all these default values
based input formats.
In practice this means that you as a core/contrib developer cannot change default values anymore.
As catch pointed out in IRC this is especially critical in the land of input formats as it could lead to potential security issues.

If you store all configs all the time, changing the default values would have no impact on active behaviour.
If you want on the other hand change the behavior of all the things, you could write an update script
or for custom world simply change all those configurations manually.

Note: This is the normal behavior of CMI.

Storing everything gives you the flexibility to change the default values later, which was always problematic
in contrib world (views for example).

- dawehner, in #2295129-29: Filter formats should not save plugin data when the plugin configuration matches defaults