After updating to 7.x-3.0-beta3, hook_views_default_views() does not work anymore like it did before:
I am no longer able to customize default views provided by my module. The config form can be accessed, but trying to change a value results in
Ein AJAX-HTTP-Fehler ist aufgetreten
HTTP-Rückgabe-Code: 500
Im Folgenden finden Sie Debugging-Informationen.
Pfad: http://localhost:3141/d7test4/admin/structure/views/ajax/display/bz_categories/default/pager
Statustext: Service unavailable (with message)
Antworttext: PDOException: in ctools_object_cache_set() (Zeile 75 von C:\XAMPP\xampp\htdocs\d7test4\sites\all\modules\ctools\includes\object-cache.inc).
The views was exported using alpha1.
But when I import the view anew ( to a new name, of course) I am able to edit the properties again (but of course, I want to make use of default views).
Is this going to be an issues with views or with ctools?
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | slidefront.views_default.inc | 25.9 KB | -osiris- |
Comments
Comment #1
merlinofchaos commentedThat's highly unusual. The error message says PDOException, but there's no actual exception listed? I don't even know what that error condition fully means.
It suggests that ctools_object_cache_set() query failed, meaning it was somehow unable to write the Views' temporary cache object used when editing. But the error message isn't telling us why.
Can you attach an export of the view this is failing on? Maybe we can reproduce this on another system.
Comment #2
-osiris- commentedIt is actually two different views, one is based on an field of type image, the other one purely on taxonomy.
Here's my hook_views_default_views():
I have to mention though, that before upgrading to the latest views beta (beta3), these views worked well using beta2.
Thanks for your interest.
Comment #3
dawehnerAs you can see on #784144: Sort by taxonomy term name throws PDO exception, table not found what you posted is probably not the full error message.
Perhaps you should disable javascript for a moment and do the same stuff.
Then you get a better error message.
Comment #4
-osiris- commentedNope.
This is the error message I get with JS disabled:
There is nothing more. Strange, huh?
Comment #5
merlinofchaos commentedMaybe you should use devel.module to reinstall CTools -- maybe the table definition is somehow wrong?
Comment #6
dawehnerCan't you enable a better error displaying?
PDO throws exceptions which often explains the problems... But i have no idea where to enable helpful error messages on xampp.
Comment #7
-osiris- commented@#5: I will try that, as soon as I get near that testing environment again.
@#6: If anyone else could enligten me on ho to enable advanced error messages on xampp, i wolud be ever so grateful.
Comment #8
-osiris- commented@#5: Reinstalling ctools, views and views_ui using devel.module has no effect.
Can anyone confirm this hook works with views 3.0-beta3 and ctools 1.0-alpha4?
Comment #9
merlinofchaos commentedViews itself implements this hook, and provides several default views. Yes, I can confirm the hook works.
Comment #10
dawehnerSo a proper error message is still missing.
Comment #11
-osiris- commentedTo simply put it: I can't get a more precise error description, I don't know where to look for, but would be grateful for any advice how to isolate this error.
But I can provide some more information:
1. When I enable one of the default views (Archive, e.g), all filters, fields, etc can be changed. Clicking on one of the properties, the according form is shown, I do the changes, press apply and am returned to the view, where saving is no problem.
2. When I take the exact code of this default view from the node.views_default.inc in views/modules and copy it into my own hook_views_default_views() (of course I change the $view->name and $view->human_name) the view is broken.
Clicking on any property in the Views-Form, the Pop-Up is shown, but the apply button produces the aforementioned error.
I tried this also with a clean install, the result is the same.
Btw, to exclude other sources of fail, here's my hook_views_api(). Just to make sure nothing is wrong with that:
The slidefront_views_default_views() resides in
sites/all/modules/bz/slidefront/slidefront.views_default.inc
I'm really stuck here.
Comment #12
merlinofchaos commentedCan you attach your views_default.inc file? Maybe there's something subtle wrong there that's causing this.
Comment #13
-osiris- commentedThanks for your interest, here's the file.
Of course, I had to append the extension .txt to upload it here, otherwise it's unchanged.
And, btw, what is the correct syntax for a new view:
Is it (like the export code) $view = new view; or is it $view = views_new_view(); ?
Don't get my previous statement about default views wrong, I know that view's default views do indeed work properly, but I can not implement any in my module.
Concerning the unexplained error message: I moved the environment for testing to a hosted site (some *nix driven server) but the error and the message stay the same.
Greetings, o.
Comment #14
dawehnerCan you pastebin your hook_views_api as well?
Comment #15
-osiris- commented@14:dereine : Just look at #11 !?
Comment #16
merlinofchaos commentedI have an idea what may be wrong.
As a test, can you go through this file and edit any word that has non-ASCII characters in it to have only ascii characters? Yes it will ruin the words, but we're mostly doing this to see if maybe it's UTF-8 characters causing PDO to panic trying to write to the object cache.
For example:
$handler->display->display_options['exposed_form']['options']['reset_button_label'] = 'Zur�cksetzen';That word contains a character that doesn't print properly for me. Change that word to something else.
Another one is this:
$handler->display->display_options['use_more_text'] = '�';Comment #17
-osiris- commentedThat definitely fixed it.
You were right, it was just the
$handler->display->display_options['use_more_text'] = '...';Maybe there's the need to raise a ctools-issue to request a proper error handling?
Thank you.