2. When duplicating displays, what ViewEditForm::submitDuplicateDisplayAsType() does is it removes the display_title and display_plugin but otherwise clones ALL the settings of the display. That is ending up with all kinds of cruft in the new display setting, such as in the test a path for a block. Not good. So what I thought we can do there is to ask the display for their options and then filter the options from the old display with the possible options of the new. That is not possible because defineOptions() is protected on PluginBase and not intended as a public method. I previously also thought display extenders would be a problem here, but getting their stuff integrated is part of defineOptions() on DisplayPluginBase. The $view->options array is actually public, but sounds like it would be a major sin to use that directly, haha... #evilgabor
Filter the options using the defined options, so we don't end up with crap entries in the configuration.
User interface changes
Add a new API function to filter out invalide items.
Beta phase evaluation
|Issue category||Bug because it makes it impossible for configs to validate the schema.|
|Disruption||Not disruptive at all, because it doesn't change anything beside internal details.|
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,067 pass(es). View
|#23||interdiff.txt||586 bytes||Gábor Hojtsy|
|#23||2387157-22.patch||12.12 KB||Gábor Hojtsy|
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,120 pass(es). View