I had a troublesome issue concerning handlers not being properly initialized and causing WSOD. It took a lot of time to figure the problem was in my implementation of this hook. The options were set, but when the views were loaded by views_block() in the main page, the error appeared (when the cache was not built).

I just added some lines to the example, so one make sure the display handler is properly initialized before setting the options.

Before someone asks, this hook is very useful when dealing with views exported by features, so that some options can be set dynamically (like vocabulary IDs and role IDs)

Comments

franz’s picture

Status: Active » Needs review

Ops... This needs review only.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Looks fine

franz’s picture

Component: Documentation » Code
Category: feature » bug
Status: Reviewed & tested by the community » Active

I found my error still goes on. Cleaning up my code, I found the steps to reproduce the bug:

1. On hook_views_default_views_alter(), call $views[$vname]->set_display($dname) (with valid view name and display id)
2. go to admin/build/views/tools and clear views cache
3. go to admin/build/views and get:

Fatal error: view::get_path() [<a href='view.get-path'>view.get-path</a>]: The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition &quot;views_plugin_display_attachment&quot; of the object you are trying to operate on was loaded _before_ unserialize() gets called or provide a __autoload() function to load the class definition in /dados/chuva/svn/alb/trunk/src/sites/all/modules/contrib/views/includes/view.inc on line 1181

franz’s picture

Also, just using $views[$vname]->set_item_option() is enough to cause the bug.

I think the right way of doing, which worked fine for me to change options in this hook is:

$views[$vname]->display[$dname]->display_options['fields']['tid']['vids'] = array($vid => $vid);

Is that right?

dawehner’s picture

$views[$vname]->display[$dname]->display_options['fields']['tid']['vids'] = array($vid => $vid);

If you export a view nowadays, something like this comes out;


$handler->display->display_options['query']['type'] = 'views_query';
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'full';
$handler->display->display_options['style_plugin'] = 'default';
$handler->display->display_options['row_plugin'] = 'fields';

So it's fine to alter the values there. So this part of the documentation should be updated.

iamjon’s picture

So can we switch this back to reviewed and tested?

dawehner’s picture

Status: Active » Reviewed & tested by the community

Oh sorry, sure

merlinofchaos’s picture

Component: Code » Documentation

Recategorizing.

franz’s picture

Status: Needs review » Needs work

Didn't see that, the patch on the top is not good, as it causes the same error (see #3). The right solution is not on the patch (see #4) yet.

franz’s picture

Status: Reviewed & tested by the community » Needs review
StatusFileSize
new506 bytes

Now there is a proper patch applying #4's concept with the old example.

The same patch applies to both 6.x-3.x and 7.x-3.x so it could be a combo commit =)

tim.plunkett’s picture

Version: 6.x-2.11 » 6.x-3.x-dev
Assigned: Unassigned » esmerel
Status: Needs work » Reviewed & tested by the community

Applies cleanly to both 6.x-3.x and 7.x-3.x.

merlinofchaos’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Sadly it doesn't apply cleanly to 7.x-3.x because the docs file was renamed a couple days ago. Committed to 3.x, tho.

tim.plunkett’s picture

Status: Patch (to be ported) » Reviewed & tested by the community
StatusFileSize
new526 bytes

I somehow forgot that checking out a local branch doesn't get changes the way checking out a remote branch does.
Putting back to RTBC since its just a file rename.
I didn't use git format-patch since I shouldn't get credit, but it's -p1 so it should still work with `git apply`.

dawehner’s picture

Status: Reviewed & tested by the community » Fixed

Earl seems to have commited this already.

@tim.plunkett
Thanks for the patch nonetheless

merlinofchaos’s picture

OH yeah, forgot to fix the issue. Doh!

Status: Fixed » Closed (fixed)

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