Follow-up to #2358265: Some views schemas are (still) missing, maybe
While fixing #2358265: Some views schemas are (still) missing, maybe found that while views stores plugin options under the plugins, it does not clear out the [plugin]_options form element and therefore saves extra items in views that are an artefact of the form structure and then not used later on. See:
abstract class DisplayPluginBase extends PluginBase {
public function submitOptionsForm(&$form, FormStateInterface $form_state) {
case 'access_options':
case 'cache_options':
case 'exposed_form_options':
case 'pager_options':
case 'row_options':
case 'style_options':
// Submit plugin options. Every section with "_options" in it, belongs to
// a plugin type, like "style_options".
$plugin_type = str_replace('_options', '', $section);
if ($plugin = $this->getPlugin($plugin_type)) {
$plugin_options = $this->getOption($plugin_type);
$plugin->submitOptionsForm($form[$plugin_type . '_options'], $form_state);
$plugin_options['options'] = $form_state->getValue($section);
$this->setOption($plugin_type, $plugin_options);
}
break;
}
}
Remove the artefacts.
1. Patch, automated tests.
2. Review
3. Commit.
None.
None
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 2385107-no-persist-options-12.patch | 2.17 KB | gábor hojtsy |
| #12 | interdiff.txt | 1.14 KB | gábor hojtsy |
| #9 | 2385107-unset-options-9.patch | 2.12 KB | gábor hojtsy |
| #7 | 2385107-unset-options-7-with-test.patch | 2.11 KB | gábor hojtsy |
| #4 | 2385107-unset-options-2.patch | 717 bytes | gábor hojtsy |
Comments
Comment #1
vijaycs85Comment #2
vijaycs85Initial patch...
Comment #3
gábor hojtsyHere is a very quick test only patch that proves pager_options are still saved. Thanks to the views wizard tests checking for strict config schema.
Comment #4
gábor hojtsyDuh, strange crosspost....
Comment #5
gábor hojtsyCompleted the title :)
Comment #7
gábor hojtsyMerged the two patches.
Comment #9
gábor hojtsySo this just sets it to NULL. Let's use unsetValue() :) Sorry no interdiff because I hand-edited. The change is in the first hunk, only one line.
Comment #11
gábor hojtsyNote that pager_options and exposed_form_options are both in the defaultable list in DisplayPluginBase::defaultableSections():
OTOH exposed_form_options and pager_options are not listed in DisplayPluginBase::defineOptions(). But they are under pager.options and exposed_form.options respectively.
So would it suffice to not list the pager_options and exposed_form_options in defaultableSections() or is that needed for some reason? Other options are not listed.
Comment #12
gábor hojtsyAn attempt at that approach.
Comment #14
olli commented#2331793: Changing pager settings for this display only also changes pager settings for other display looks related.
Comment #15
gábor hojtsyThis looks like a clear duplicate of that one.