Invalid argument supplied for foreach() ===> views_plugin_display.inc on line 679.

This happened to me, too. After I cloned a view and removed some of its displays. Not sure what's going on.

Sadly i cannot reproduce the problem

Agentrickard: Are you using views plugins, or is this a problem for views, too?

I also have same problem.
I only tried to clone Calendar view... then same warning appear.

same issue as op and #1, not sure what the question in #2 refers to. The Views Plugins module has no releases.

header, footer, empty text, relationships: no
fields, arguments, sort criteria, filters: yes

EDIT:
the original view had a block display. When I deleted the block display from the cloned view, the Invalid Argument messages went away.

Could you please provide an export where this error appears?

When its reproducible this should be fixable

this is the cloned view, still containing the Block Display:

$view = new view;
$view->name = 'practice_test';
$view->description = 'TS ONLY';
$view->tag = '';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 3.0-alpha1;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */

/* Display: Defaults */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->display->display_options['items_per_page'] = 0;
$handler->display->display_options['access']['type'] = 'none';
$handler->display->display_options['cache']['type'] = 'none';
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'none';
$handler->display->display_options['pager']['options']['offset'] = '0';
$handler->display->display_options['style_plugin'] = 'list';
$handler->display->display_options['style_options']['grouping'] = 'field_ref_practice_nid';
$handler->display->display_options['row_plugin'] = 'fields';
/* Field: Node: Title */
$handler->display->display_options['fields']['title']['id'] = 'title';
$handler->display->display_options['fields']['title']['table'] = 'node';
$handler->display->display_options['fields']['title']['field'] = 'title';
$handler->display->display_options['fields']['title']['label'] = '';
$handler->display->display_options['fields']['title']['link_to_node'] = 1;
/* Sort criterion: Node: Title */
$handler->display->display_options['sorts']['title']['id'] = 'title';
$handler->display->display_options['sorts']['title']['table'] = 'node';
$handler->display->display_options['sorts']['title']['field'] = 'title';
/* Argument: Node Hierarchy: Parent Node */
$handler->display->display_options['arguments']['parent']['id'] = 'parent';
$handler->display->display_options['arguments']['parent']['table'] = 'nodehierarchy';
$handler->display->display_options['arguments']['parent']['field'] = 'parent';
$handler->display->display_options['arguments']['parent']['default_action'] = 'not found';
$handler->display->display_options['arguments']['parent']['style_plugin'] = 'default_summary';
$handler->display->display_options['arguments']['parent']['default_argument_type'] = 'fixed';
/* Filter: Node: Published */
$handler->display->display_options['filters']['status']['id'] = 'status';
$handler->display->display_options['filters']['status']['table'] = 'node';
$handler->display->display_options['filters']['status']['field'] = 'status';
$handler->display->display_options['filters']['status']['value'] = 1;
$handler->display->display_options['filters']['status']['expose']['operator'] = FALSE;

/* Display: Block */
$handler = $view->new_display('block', 'Block', 'block_1');
$handler->display->display_options['defaults']['style_plugin'] = FALSE;
$handler->display->display_options['style_plugin'] = 'default';
$handler->display->display_options['defaults']['style_options'] = FALSE;
$handler->display->display_options['defaults']['row_plugin'] = FALSE;
$handler->display->display_options['row_plugin'] = 'fields';
$handler->display->display_options['defaults']['row_options'] = FALSE;
$handler->display->display_options['defaults']['arguments'] = FALSE;
$handler->display->display_options['defaults']['filters'] = FALSE;
/* Filter: Node: Published */
$handler->display->display_options['filters']['status']['id'] = 'status';
$handler->display->display_options['filters']['status']['table'] = 'node';
$handler->display->display_options['filters']['status']['field'] = 'status';
$handler->display->display_options['filters']['status']['value'] = 1;
$handler->display->display_options['filters']['status']['group'] = 0;
$handler->display->display_options['filters']['status']['expose']['operator'] = FALSE;
/* Filter: Node: Type */
$handler->display->display_options['filters']['type']['id'] = 'type';
$handler->display->display_options['filters']['type']['table'] = 'node';
$handler->display->display_options['filters']['type']['field'] = 'type';
$handler->display->display_options['filters']['type']['value'] = array(
  'practice' => 'practice',
);
$handler->display->display_options['filters']['type']['expose']['operator'] = FALSE;
$handler->display->display_options['block_description'] = 'Practice Area for general sidebar';

update status

Bit us again when exporting Views to code. Investigating.

Still not sure of the cause, but this makes the errors go away:

  function get_handlers($type) {
    if (!isset($this->handlers[$type])) {
      $this->handlers[$type] = array();
      $types = views_object_types();
      $plural = $types[$type]['plural'];
      // Make sure the plural option has loaded correctly.
      $test = $this->get_option($plural);
      if (empty($test)) {
        unset($this->handlers[$type]); // This will force a reload next time through.
        return array();
      }
      foreach ($this->get_option($plural) as $id => $info) {

This is happening primarily when using a style plugin that overrides the default display. Which I see is also the case in #6.

$handler->display->display_options['defaults']['style_plugin'] = FALSE;

Another patch attempt. Unfortunately, our test server is down, so I can't roll a proper patch.

Line 588 of views_plugin_display.inc:

  /**
   * Intelligently get an option either from this display or from the
   * default display, if directed to do so.
   */
  function get_option($option) {
    if ($this->is_defaulted($option)) {
      return $this->default_display->get_option($option);
    }

    if (array_key_exists($option, $this->options)) {
      return $this->options[$option];
    }
    // Make sure an array gets returned.
    return array();
  }

In the tests I was running on @keva's view, the display element for the block handler was returning NULL for the 'arguments' option of the display_handler. Returning an empty array here eliminates the error and allows the display to return correctly.

Doing that can expose other errors, as arrays get passed to t(), so that's not right either.

It looks like some elements of the option definition are not getting exported correctly. In my case, we're using Mapstraction plugin, and it breaks whenever cloned or exported.

On export, several of the field definitions are simply dropped by Views.

Picture 1, below, shows the plugin options as defined by the View when it is stored in the database.

The attachment shows how that data is exported by Views.

I wonder if this is an API change that hasn't filtered down yet, but I suspect it is also happening in other cases of this issue.

@keva

Are any settings definitions missing from your exported View?

Took a quick peek at mapstraction's style.

16 	 function option_definition() {
17 	$options['api'] = array();
18 	$options['width'] = array('default' => 'auto');
19 	$options['height'] = array('default' => '400px');
20 	
21 	$options['initial_point'] = array(
22 	'auto' => TRUE,
23 	'latitude' => '',
24 	'longitude' => '',
25 	'zoom' => 10,
26 	);
27 	$options['controls'] = array();
28 	$options['behaviours'] = array();
29 	$options['zoon_control'] = array();
30 	$options['default_maptype'] = array();
31 	$options['fields'] = array();
32 	
33 	return $options;
34 	}

That option_definition() code is invalid.

Compare to the one from Views' on table style:

14 	 function option_definition() {
15 	$options = parent::option_definition();
16 	
17 	$options['columns'] = array('default' => array());
18 	$options['default'] = array('default' => '');
19 	$options['info'] = array('default' => array());
20 	$options['override'] = array('default' => TRUE);
21 	$options['sticky'] = array('default' => FALSE);
22 	$options['order'] = array('default' => 'asc');
23 	
24 	return $options;
25 	}

There's a couple of items in mapstraction that are properly using the 'default' keyword. The rest are not. Also, the 'initial_point' should be using the 'contains' keyword so that Views will properly drilldown.

Views 3.x will be much more sensitive to these incorrect definitions than 2.x was.

And I notice that @keva is using node_hierarchy, so I wonder if that module has the same API problem.

@merlinofchaos

So you mean something like:

    $options['initial_point']['contains'] = array(
      'auto' => array('default' => TRUE),
      'latitude' => array('default' => ''),
      'longitude' => array('default' => ''),
      'zoom' => array('default' => 10),
    );

/me is looking for good sample code or API docs. views_plugin_display_page seems to be a good example.

Moving to support request, unless the maintainers want to allow for V2 => V3 exception handling. mapstraction issue moved #810240: Views3 API changes

agentrickard, what are "settings definitions"? (#14)

these are the steps:
- cloned the original view
- edited $view->name and $view->description
- removed a field from the default display only (broken/missing handler)
- even with above field removed, both error messages are still generated

The forms you use to set display options, particularly for the display style itself. Make sure each option in the UI form is present in the exported View.

In my case, 5 or 6 settings were getting dropped because they were not using the API correctly.

I would look here, in particular:

/* Display: Block */
$handler = $view->new_display('block', 'Block', 'block_1');
$handler->display->display_options['defaults']['style_plugin'] = FALSE;
$handler->display->display_options['style_plugin'] = 'default';
$handler->display->display_options['defaults']['style_options'] = FALSE;
$handler->display->display_options['defaults']['row_plugin'] = FALSE;
$handler->display->display_options['row_plugin'] = 'fields';
$handler->display->display_options['defaults']['row_options'] = FALSE;
$handler->display->display_options['defaults']['arguments'] = FALSE;
$handler->display->display_options['defaults']['filters'] = FALSE;

the only thing missing is the entire broken/missing handler field that I deleted.

otherwise, the code for both views are identical. It only had one block display.

I'm seeing this behavior with block displays as well.

The problem is that the options are not defaulted, but also not set, so the call to get_options() method fails.

Patch fixes the symptoms, but not the cause of the issue. In my case, the following calls to get_options() fail:

items_per_page
offset
use_pager
header
footer
path

This is for a block display, using default values.

This patch, of course, ends up passing an empty array to check_plain(), for some %$#@! reason, throwing a different error.

Here's a view that is erroring out for me.

items_per_page
offset
use_pager
header
footer
path

None of these items are valid for a block display in Views 3.x:

Pager options have moved to the pager plugin. You should probably retrieve those options via the plugin: $pager = $display->get_plugin('pager'); $pager->get_items_per_page();

header and footer are now pluggable handlers. I think they're now $display->get_option('headers')

Block displays have no 'path'.

Right, but why is the block display handler asking for these items?

We're seeing this problem for an exported view that has no arguments in the default display. When $this->get_option($plural) is called is get_handlers(), where $plural == "arguments", get_option() does not return anything, so the foreach() in get_handlers() errors out.

The items above are a red herring. The problem seems to be:

1) Create a view with multiple displays.
2) Create default arguments, filters, or empty text (a handler) and add some values.
3) Override the defaults in a display.
4) Remove all default elements (so that, say, the block display has no filter, but the default does).

5) Watch error appear.

/me goes to test.

Still cannot replicate on a newly created view. May be related to import/export definitions. I just don't know.

Actually, I found the issue. Took a fair amount of digging.

It turns out the problem is the fact that _set_option_defaults() is overridden for views_plugin_display. This method attempts to intelligently control whether the default option is applied based on the defaults set in the option_definition(). This, however, is completely unnecessary, and the default options should still be applied to avoid issues later (like this one). Since get_option() *first* checks to see if the option is defaulted or not, it will apply the default_display option if the option is defaulted, so having _set_option_defaults() try to selectively apply the option defaults is unnecessary. In addition, as I said, it causes problems later (which is what this issue is about), because _set_option_defaults() doesn't apply the option default. If the option is *not* defaulted, but it's set to the default *for* that option (such as an empty array for arguments, etc), then the default is not applied, which causes it to become an undefined option which then causes problems that expect at least the default to be available (such as get_handlers() does).

As it turns out, because get_option() is intelligent enough to use the default_display option when the option is defaulted, the default _set_option_defaults() from the views_object defined in base.inc is exactly what should be used. So all that's needed is to remove the _set_option_defaults() override for views_plugin_display. Patch to do so is attached.

the original view had a block display. When I deleted the block display from the cloned view, the Invalid Argument messages went away.

Confirmed. I also started getting errors after cloning a view that had a block module. Deleted the block on the cloned view nd recreated it manually made the errors dissapear.

The patch in #29 fixed it for me.

The patch in #29 fixed it for me.

The patch in #29 fixed it for me.

Enough to mark this as RTBC?

subscribing

The patch in #29 worked for me on the Aug 1st dev snapshot. Thanks for the patch mgriego.

This needs to get patched ASAP. Are we happy this is RTBC?

Same problem here, it seems the patch in #29 fixed it.

That's quite a few tests saying this works, and there's no actual code to review. Committing, let's see if this comes back to bite us.

I'm using Views 6.x-3.0-alpha3, the code that needs to be removed as per patch #29 is still there. Was this patch committed for Views 3?

I think this patch needs to be committed for the 3.0-alpha3 version.

It's commited against the dev version of views3, so it's not part of 6.x-3.0-alpha3

bookmarking, waiting for alpha4 in production site.
greetings, Martijn

subscribing

Subscribing

this append after upgrade from views 2..the error appear after that..
suscribe for a patch

Invalid argument supplied for foreach() dans /sites/all/modules/views/plugins/views_plugin_display.inc à la ligne 824.