I've built a view with a date contextual filter (an "argument" in Views 2 parlance) that has a default value of "return date('Y-m');". Simple stuff. I can edit the view to see that the default value is still there and it works correctly. However, when I export it the default value is not retained, I just end up with the following:

  /* Contextual filter: Date: Date (node) */
  $handler->display->display_options['arguments']['date_argument']['id'] = 'date_argument';
  $handler->display->display_options['arguments']['date_argument']['table'] = 'node';
  $handler->display->display_options['arguments']['date_argument']['field'] = 'date_argument';
  $handler->display->display_options['arguments']['date_argument']['default_action'] = 'default';
  $handler->display->display_options['arguments']['date_argument']['default_argument_type'] = 'php';
  $handler->display->display_options['arguments']['date_argument']['default_argument_skip_url'] = 0;
  $handler->display->display_options['arguments']['date_argument']['summary']['format'] = 'default_summary';
  $handler->display->display_options['arguments']['date_argument']['summary_options']['grouping'] = 'field_event_date';
  $handler->display->display_options['arguments']['date_argument']['year_range'] = '-3:+3';
  $handler->display->display_options['arguments']['date_argument']['granularity'] = 'day';
  $handler->display->display_options['arguments']['date_argument']['date_fields'] = array(
    'field_data_field_event_date.field_event_date_value' => 'field_data_field_event_date.field_event_date_value',
    'field_data_field_event_date.field_event_date_value2' => 'field_data_field_event_date.field_event_date_value2',
  );
  $handler->display->display_options['arguments']['date_argument']['date_method'] = 'OR';
  $handler->display->display_options['arguments']['date_argument']['date_group'] = 'date';

You'll notice that 'default_argument_options' is missing.

I was looking through the code and at a guess it looks like either the option_definitions() for 'default_argument_type' should have a custom implementation to automatically include the 'default_argument_options' value, or 'default_argument_options' should have an export setting assigned. I.e., I think it should be either something like this:

  function option_definition() {
    $options = parent::option_definition();
[...]
    $options['default_argument_type'] = array('default' => 'fixed', 'export' => 'export_argument');
    $options['default_argument_options'] = array('default' => array(), 'export' => FALSE);

or

  function option_definition() {
    $options = parent::option_definition();
[...]
    $options['default_argument_type'] = array('default' => 'fixed', 'export' => 'export_plugin');
    $options['default_argument_options'] = array('default' => array(), 'export' => 'export_plugin');
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

DamienMcKenna’s picture

FYI when I changed line 170 of views_handler_argument.inc to:

    $options['default_argument_options'] = array('default' => array(), 'export' => 'export_plugin');

it outputs the following:

  $handler->display->display_options['arguments']['date_argument']['default_argument_options'] = 'Array';

Clearly a custom exporter is needed.

dawehner’s picture

FileSize
4.6 KB

And there is a custom exporter, it's in handlers/views_handler_argument.inc::export_plugin

Sadly it works for me at the moment, see attachment.
Additional the option definition looks perfect as it is.

Can you give some introductions how to reproduce the problem?
If there is a bug the bug is probably in export_plugin.

DamienMcKenna’s picture

@dereine: Thanks for testing it. The specific argument field I was working with used the Date module (latest 7.x-2.x-dev codebase) and it does not export the 'default_argument_options' setting.

dawehner’s picture

Project: Views (for Drupal 7) » Date
Version: 7.x-3.x-dev » 7.x-2.x-dev
Component: Views Data » Views Argument
Status: Active » Fixed

That's a bug in date



  /**
   * Make sure our custom options get exported.
   * Handle the options we know about, pass the rest to the parent plugin.
   */
  function export_plugin($indent, $prefix, $storage, $option, $definition, $parents) {
    $output = '';
    if (in_array($option, array('year_range', 'granularity', 'default_argument_type'))) {
      $name = $this->options[$option];
      $output .= $indent . $prefix . "['$option'] = '$name';\n";
      return $output;
    }
    return parent::export_plugin($indent, $prefix, $storage, $option, $definition, $parents);
  }

It should do

      // Pass off to the plugin to export itself.
      $output .= $plugin->export_options($indent, $prefix . "['$option_name']");

all the time.

KarenS’s picture

Status: Fixed » Active

Hey @dereine, *where* exactly should this go? I was totally confused about how Views is handling exports.

muriqui’s picture

subscribe

dawehner’s picture

Status: Active » Fixed

This is fixed already, because 'default_argument_type' was removed.

KarenS’s picture

Status: Fixed » Postponed (maintainer needs more info)

Dereine, I still have no idea what you are trying to tell me to do.

dawehner’s picture

Status: Postponed (maintainer needs more info) » Fixed
  /**
   * Make sure our custom options get exported.
   * Handle the options we know about, pass the rest to the parent plugin.
   */
  function export_plugin($indent, $prefix, $storage, $option, $definition, $parents) {
    $output = '';
    if (in_array($option, array('year_range', 'granularity', 'default_argument_type'))) {
      $name = $this->options[$option];
      $output .= $indent . $prefix . "['$option'] = '$name';\n";
      return $output;
    }
    return parent::export_plugin($indent, $prefix, $storage, $option, $definition, $parents);
  }

Sorry for all this confusion.

This was the old code, afaik.

Based on this it didn't exported default arguments right, but it's fixed already in the current date code. So this issue is fixed.

KarenS’s picture

I ended up removing all my manual attempts to get export items to display right because Views now seems to pick them up correctly.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Simon Georges’s picture

Status: Closed (fixed) » Active

Hi. I'm currently using Calendar, and have modified the Views arguments to use a PHP-based default value (which works perfectly), but the PHP code isn't exported with the View (there is indeed no 'default_argument_options' line in the export).
I currently have Views-3.0-rc3 (released November 16, 2011) and Date-7.x-2.0-alpha5 (released November 29, 2011), both released after this thread was closed, but it seems the bug is still happening...

May I help you investigate in any way ? (I'm willing to provide exports, tests Views modification / code modification if needed).

tim.plunkett’s picture

Status: Active » Closed (fixed)

That should have been fixed in September 2011. #1273806: Non-plugin default argument types are not exported

If it persists, please open a Views issue with a paste of your views export.

grendzy’s picture

I can still reproduce it with a fresh install of the latest dev releases. As requested a new issue is here: #1515764: Exported view missing default_argument_options with date argument and PHP code

james.williams’s picture

Status: Closed (fixed) » Needs review
FileSize
2.54 KB

I believe the problem has arisen because date overrides the 'default_argument_type' option definition, which is not yet fixed. The attached patch fixes this, making 'date' the default, but keeping the 'export' => 'export_plugin' part. This makes the plugin then do the exporting of the default_argument_type (in views_handler_argument_date::export_plugin()), which itself exports the default_argument_options.

james.williams’s picture

shoot, sorry that patch was against an old version -- here's a rerolled one.

awolfey’s picture

Status: Needs review » Reviewed & tested by the community

The patch in #16 fixed my issue. Thanks James!

In my case the the default argument type (raw) had been exporting, but not the url index. With this patch it now exports correctly.

kbasarab’s picture

#16 works for me as well.

pdcarto’s picture

#16 works. This patch should be committed and this ticket closed.

grendzy’s picture

#16 worked for me also.

michielnugter’s picture

I can also confirm the posted patch in #16 works. I had a problem with some options not being exported for a date argument and after applying the patch they are exported as they should be.

mikehues’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
884 bytes

EDIT: Nevermind. patch #16 works

I'm seeing this issue with current dev versions date-7.x-2.x-dev and views-7.x-3.x-dev on a clean install of Drupal 7.21.

Reproduce issue:
Install date, views and ctools and enable date, views and views_ui. Do not enable date_views yet. Add a date field to the Page content type, create a view and add the date field as a contextual filter. At this point if you save and export your view, the export will contain the following:

$handler->display->display_options['arguments']['field_date_value']['default_argument_type'] = 'php';
$handler->display->display_options['arguments']['field_date_value']['default_argument_options']['code'] = 'return date();';

Now enable date_views and re-export your view. You will see that the 'default_argument_options' are missing from the export. The same issue occurs if you remove your "Content" argument and replace it with the newly available "Date" argument for your field in contextual filters.

Proposed solution:
Taking a closer look at the code I noticed that when the date_views module is disabled, the option definition array contains the following on line 193 of views_handler_argument.inc:

$options['default_argument_type'] = array('default' => 'fixed', 'export' => 'export_plugin');

And when date_views is enabled, the default_argument_options value is overridden with:

options['default_argument_type'] = array('default' => 'date');

Updating line 88 of date_views_argument_handler_simple.inc to the following resolves the issue for me:

options['default_argument_type'] = array('default' => 'date', 'export' => 'export_plugin');

EDIT: Nevermind. patch #16 works

dawehner’s picture

Status: Reviewed & tested by the community » Needs review

I still think #16 is a bit cleaner.

mikehues’s picture

Status: Needs review » Reviewed & tested by the community

@dawehner you are absolutely right. Not sure what I did the first time around, but I must have missed something. I started fresh again and re-applied patch #16. It did in fact solve the issue. Changing the status back to 'reviewed & tested by the community'. Sorry about that :\

heddn’s picture

Status: Needs review » Reviewed & tested by the community

+1 on #16. Fixes the problem for me as well.

corbacho’s picture

This bug bit me too. It wasn't easy to debug.
#16 works well. It's just 1 line diff, please commit it

caktux’s picture

I concur, please commit and close this issue

awolfey’s picture

Hoping for a commit. Thanks!

cafuego’s picture

Status: Reviewed & tested by the community » Fixed

Patch from #16 applied to 7.x-2.x.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.