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
Comment #1
franzOps... This needs review only.
Comment #2
dawehnerLooks fine
Comment #3
franzI 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 "views_plugin_display_attachment" 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 1181Comment #4
franzAlso, 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?
Comment #5
dawehnerIf you export a view nowadays, something like this comes out;
So it's fine to alter the values there. So this part of the documentation should be updated.
Comment #6
iamjon commentedSo can we switch this back to reviewed and tested?
Comment #7
dawehnerOh sorry, sure
Comment #8
merlinofchaos commentedRecategorizing.
Comment #9
franzDidn'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.
Comment #10
franzNow 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 =)
Comment #11
tim.plunkettApplies cleanly to both 6.x-3.x and 7.x-3.x.
Comment #12
merlinofchaos commentedSadly 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.
Comment #13
tim.plunkettI 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`.
Comment #14
dawehnerEarl seems to have commited this already.
@tim.plunkett
Thanks for the patch nonetheless
Comment #15
merlinofchaos commentedOH yeah, forgot to fix the issue. Doh!