Going from a working views 3.1 to 3.3 (which mostly worked but broke one view) to 3.3_dev (117) I'm getting two errors (but, thankfully, my views are rendering, though not consistently).
1) Notice: unserialize() [function.unserialize]: Error at offset 7272 of 7350 bytes in views_db_object->load_row() (line 2148 of /home/myaccount/public_html/d7b/sites/all/modules/views/includes/view.inc).
same as this issue: http://drupal.org/node/1185806 - I haven't exported/deleted/imported my views yet, so we'll see how that goes. And like him, I have migrated the site from one server to another.
2) Notice: Undefined property: view::$dom_id in template_preprocess_views_view() (line 114 of /home/scarfeca/public_html/d7b/sites/all/modules/views/theme/theme.inc)
not sure how this view::$dom_id can be unset, it's called in pre-execute, around line 1300 of includes/views.inc. I tried adding an if(!isset) and then set it again right before it's called in views/theme/theme.inc, but it seemed to cause more problems.
I suspect these are related to some embedded code-based views with custom .tpl files... but they were working pre-migration and pre-updates... but are causing problems now.
Comment | File | Size | Author |
---|---|---|---|
#41 | v-7-x-3-23-dom-id-fix-update-for-views-1556174-41.patch | 598 bytes | arsn |
Comments
Comment #1
dawehnerMaybe the patch in #1408312: fatal error, call to undefined function db_decode_blob - function calls need to be removed. cause that issue for you?
Regarding the second error; how do you embed views via .tpl files? I guess you do it wrong, so please use views_embed_view here.
Comment #2
andjules CreditAttribution: andjules commentedSorry, I was unclear.
I'm embedding the view in a node, using:
$view = views_get_view('view_name'); print $view->render('block_1');
The view displays fields, and a number of the fields have complex tpl files. It also has a field of type "global: view", so it's a nested view.
Anyhow, with the unserialize problem (1), exporting and re-importing the views seems to have solved that issue.
Still facing the view::$dom_id problem.
Comment #3
dawehnerIt's really a wonder that this code works!
Please use just views_embed_view('view_name', 'block_1');
Comment #4
andjules CreditAttribution: andjules commentedswitched to views_embed_view (thanks), but still facing intermittent views::$dom_id issues
Comment #5
andjules CreditAttribution: andjules commentedComment #6
andjules CreditAttribution: andjules commentedadded this before line 114 of /theme/theme.inc:
if (!isset($view->dom_id)) $view->dom_id = md5($view->name.REQUEST_TIME.rand());
Comment #7
tseven CreditAttribution: tseven commentedHere is a patch which includes andjules suggest fix from #6.
This stops the Undefined property: view::$dom_id in template_preprocess_views_view() error.
Comment #8
John Pitcairn CreditAttribution: John Pitcairn commented@dawehner: if I need to take some action based on the view result (count results, say) before rendering, then views_embed_view() doesn't help me. What would be the preferred method in this case? I'm using (working):
Comment #9
spacereactor CreditAttribution: spacereactor commentedi using Entity Reference View Widget module and it too give me error message
Notice :Undefined property: view::$dom_id in template_preprocess_views_view() (line 116 of [path]/sites/all/modules/views/theme/theme.inc
There is post about the error at Entity Reference View Widget
Comment #10
dawehner@spacereactor
This can only happen if entity reference view widget fails to execute $view->pre_execute, so basically
it is not a bug of views.
Comment #11
dawehnerSee #1667296: Undefined dom_id because $view->pre_execute didn't runned
Comment #12
marvil07 CreditAttribution: marvil07 commentedI am not using Entity Reference View Widget, and have the same problem in a module that also manually render the view. In the related patch mentioned, view preview method is used to solve it(instead of build/execute/render), but I am using preview and still getting the same problem.
Inside preview(), there is a call to pre_execute(), so it is called. Is there another reason why this could be happening?
PS: I am happy to open a support request if needed, but I feel it seems to be related with this.
Comment #13
loze CreditAttribution: loze commentedI also get this error without using Entity Reference View Widget.
Patch in #7 fixes it. But if that is not the correct way to fix it, what is?
Edit: My bad. I was calling $view->render() without $view->pre_execute() in a custom mod. Added pre_execute and that fixed it. No need for the patch.
Comment #14
StephanieFuda CreditAttribution: StephanieFuda commentedHello all,
Sorry to reopen this, but I'm getting the error - "Notice: Undefined property: view::$dom_id in template_preprocess_views_view() (line 116 of /home/susanh8/public_html/sites/all/modules/views/theme/theme.inc)."
I'm not using entity reference, and when I attempted the patch in comment #7 I got this error - "error: sites/all/modules/views/theme/theme.inc: No such file or directory". When I checked the directory using the same path, I see the file is there, any suggestions are welcome.
Thanks!
Stephanie
EDIT: (9/8/12) I just reverted back to 7.X-3.2 since I can't find an answer to the error, though I'm still hopeful.
Comment #15
mmtahir CreditAttribution: mmtahir commentedJust Installed Views Contents DS, and get the same error.
I had been using Entity Reference, but it hadn't caused this error. However, after Installing Views Content DS, I get this error message.
If so many modules are having same error which can be handled in 'theme.inc', then it would be good, IMHO, to fix it here.
Comment #16
dawehnerWell, you simply can't fix stuff right, as people don't use API the right way :(
Comment #17
PeteS CreditAttribution: PeteS commentedIf the function shouldn't be used as part of the API, why is it in the API? If people shouldn't use those methods in question, they should be private class functions.
This is obviously just another case where a simple sanity check would save a ton of people the trouble of having to understand every nuance of how the API works and what it expects at each step. If DOM ID is required at this step, it should be checked. If it's presumed to exist, and some other function or set of events is supposed to ensure its creation, then someone should explain what those steps are. Saying "all of a sudden don't use half of the APIl" is a ridiculous contribution to this thread.
In this case, I'm assuming the correct answer is to run pre_execute. That's all that was needed. And frankly, if pre_execute is a required step in generating a view without an error, then there should be a state flag that tracks whether it was run, and halts the View with a useful error message. If we had basic, Programming 101 validations like this, it would cut down on 50% of the Views issue queue.
Comment #18
vaza18 CreditAttribution: vaza18 commentedJohn Pitcairn , try this:
Use $view->preview instead of view->render
Comment #19
dawehnerA) There might be use-cases and if you know what you are doing, it's valid. B) Views has been developed for PHP4, so there hasn't been protected methods. In general we can't change that now.
I welcome you to help in the views issue queue, and you will see, why there are so many issues in the issue queue.
Drupal contributions are a do-crazy, so feel free to post a patch, help in the queue etc. but just complaining is not a useful contribution, sorry.
Comment #20
dvdroest CreditAttribution: dvdroest commentedI think that PeteS his response is more a reaction on your comment:
This comment is not constructive and provokes reactions like the one from PeteS.
As response to your comment, using an API the right way can only happen when you know what the right way is. A way of enforcing this would be to use private methods (the views module requires php 5.2, so private methods can be used), or by properly documenting the method in question. I have added a comment on http://api.drupal.org/api/views/views.module/function/views_get_view/7 to try and help out others who need to use this method.
Please note that this method might very well be required to stay public since there certainly are usecases where more control is needed. The views_embed_view method currently is not configurable enough.
Comment #21
acbramley CreditAttribution: acbramley commentedConfirming that using the following approach gets rid of the errors:
Comment #22
Reg CreditAttribution: Reg commentedWhen I looked at how calls were made internally I copied over how it was done and came up with the following structure. Using it I've never had an error:
Note the use of preview instead of render.
And if I don't need to do stuff I just use views_embed_view().
Comment #23
StephanieFuda CreditAttribution: StephanieFuda commentedPost #21 from acbramley help me, thank you very much!
Comment #24
marvil07 CreditAttribution: marvil07 commentedAbout my comment on 12, the real problem was not on my manual rendering of the view (at versioncontrol), but instead seems to be a bug on a dependency, views_field_view, which also renders a view manually on the view I was rendering :-)
For people using views_field_view, please take a look to the patches at #1791304-4: Some mistakes when query aggregation is used.
So, in general I would agree with maintainers comments that this is a bug on API use instead of a bug in the API itself.
Maybe it's time to close this?
Comment #25
fromtheindia CreditAttribution: fromtheindia commentedgr8!!! Thanks it works for me.
Comment #26
khiminrm CreditAttribution: khiminrm commented#21 works for me too
Comment #27
DamienMcKennaThe code in #7 matches the logic used elsewhere in the module. This patch simply updates it to fit the Drupal coding standards.
Comment #28
hkirsman CreditAttribution: hkirsman commented#21 works!
Comment #29
dongtian CreditAttribution: dongtian commentedThank you for your patch.
It works for me great.
Comment #30
moonray CreditAttribution: moonray commentedThis patch fixes the issue for me as well. Marking as RTBC
Comment #31
moonray CreditAttribution: moonray commentedStill an issue on the latest views.
Comment #32
njbarrett CreditAttribution: njbarrett as a volunteer commented#21 fixed it for me. Thanks.
Comment #33
colanWe've recently switched our testing from the old qa.drupal.org to DrupalCI. Because of a bug in the new system, #2623840: Views (D7) patches not being tested, older patches must be re-uploaded. On re-uploading the patch, please set the status to "Needs Review" so that the test bot will add it to its queue.
If all tests pass, change the Status back to "Reviewed & tested by the community". We'll most likely commit the patch immediately without having to go through another round of peer review.
We apologize for the trouble, and appreciate your patience.
Comment #34
moonray CreditAttribution: moonray commentedRe-uploading the patch by DamienMcKenna in #27.
Comment #35
moonray CreditAttribution: moonray commentedComment #36
dawehnerThe main problem I have with this patch that it sort of hides some errors on views which, for some reason, don't had
pre_execute
executed. Hiding problem is often causing more harm, than not doing anything.Does someone actually understands how things happen?
Comment #38
sam.spinoy@gmail.com CreditAttribution: sam.spinoy@gmail.com at Adapt commentedRerolled
Comment #39
sam.spinoy@gmail.com CreditAttribution: sam.spinoy@gmail.com at Adapt commentedSorry too much in the patch, here's the correct one
Comment #40
Reg CreditAttribution: Reg as a volunteer and commentedI'm trying to understand why you would need a patch when if you just follow the usage as views does it, i.e., the code I pasted in #22 from views itself, you won't get a problem. Note the check for the views object being set before checking any properties and checking the security access so you don't show it when access should be denied:
Admittedly that post 6 years old so the relevant code should be checked again but it's probably fundamentally the same.
Comment #41
arsn CreditAttribution: arsn commentedHello,
Here is the views-n1556174-27.patch adapted to v. 7.x-3.23 of views.
Hope this will help.