Problem/Motivation
In order to allow custom views argument handler settings to be exportable, an extra setting should simply be able to specify 'export' => 'export_plugin' and get automatic export of a simple key => value setting. It seems that this is what is intended, but the views_handler_argument code effectively excludes anything but 'default_argument_type' from using this method.
For example, if I wanted to specify an alternative to the '=' operator for a numeric handler (attached issue), I should be able to export that setting simply by including the following in method "option_definition()":
function option_definition() {
$options = parent::option_definition();
...
$options['comparator'] = array(
'default' => 'eq',
'export' => 'export_plugin',
);
The export_plugin() method, while annotated as "* Generic plugin export handler. " prevents this by setting "type" to NULL unless the plugin is "default_argument_type". Because, in the following code, in class views_handler_argument, the variable $type is NULL unless $option is 'default_argument_type', and this overrides the default views_handler_argument::get_plugin($type = 'argument default', $name = NULL).
function export_plugin($indent, $prefix, $storage, $option, $definition, $parents) {
$output = '';
if ($option == 'default_argument_type') {
$type = 'argument default';
$option_name = 'default_argument_options';
}
$plugin = $this->get_plugin($type);
Proposed resolution
Write the default export key = value option for any option that specifies "export_plugin" and has a non-array value for $option:
Change From:
if ($plugin) {
// Write which plugin to use.
$output .= $indent . $prefix . "['$option'] = '$name';\n";
// Pass off to the plugin to export itself.
$output .= $plugin->export_options($indent, $prefix . "['$option_name']");
}
to
// Write default export_plugin info
if(!is_array($name)) {
$output .= $indent . $prefix . "['$option'] = '$name';\n";
}
if ($plugin) {
// Pass off to the plugin to export itself.
$output .= $plugin->export_options($indent, $prefix . "['$option_name']");
}
Remaining tasks
- (done)Write patch
- Develop tests
- Update patch if necessary
User interface changes
n/a
API changes
n/a
Data model changes
n/a
Comment | File | Size | Author |
---|---|---|---|
#6 | views-support-export_plugin-generically-2838749_05.patch | 1.88 KB | kingandy |
#4 | views-support-export_plugin-generically-2838749_03.patch | 1.93 KB | kingandy |
#2 | views-support-export_plugin-generically-2838749_02.patch | 720 bytes | robertwb |
|
Comments
Comment #2
robertwb CreditAttribution: robertwb commentedComment #3
robertwb CreditAttribution: robertwb commentedComment #4
kingandy CreditAttribution: kingandy commented$type doesn't actually get initialised to NULL, it's implicitly NULL because it's not set - this can lead to a slew of "Undefined variable" warnings whenever the export_plugin method is called (e.g. when Features is rebuilding its cache and reviewing its exported features status), depending on your error settings. This also applies to get_plugin() which does the same (does not legislate for a $type outside its fixed list of three and therefore does not initialise $plugin_name/$options_name).
Here's a patch which does .... something like that. Hopefully. I'm afraid I've had to manually edit some of the lines because I already applied some other patches - let's see if I've lined it up right.
Comment #6
kingandy CreditAttribution: kingandy commentedTrying again with UNIX linebreaks
Comment #7
robertwb CreditAttribution: robertwb commented@kingandy I think you'll need to apply this patch on a clean install, then make the mods you require, then create the patch. Manually editing the patch is a perilous route :)