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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dawehner’s picture

Maybe 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.

andjules’s picture

Sorry, 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.

dawehner’s picture

It's really a wonder that this code works!

Please use just views_embed_view('view_name', 'block_1');

andjules’s picture

switched to views_embed_view (thanks), but still facing intermittent views::$dom_id issues

andjules’s picture

Title: unserialize and $dom_id issues with upgrade » $dom_id issues with upgrade
andjules’s picture

added this before line 114 of /theme/theme.inc:
if (!isset($view->dom_id)) $view->dom_id = md5($view->name.REQUEST_TIME.rand());

tseven’s picture

Here is a patch which includes andjules suggest fix from #6.

This stops the Undefined property: view::$dom_id in template_preprocess_views_view() error.

John Pitcairn’s picture

@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):

$view = views_get_view('view_name');
$view->set_display('display_id');
$view->set_arguments(array($arg1, $arg2));
$view->pre_execute();
$view->execute();

if (count($view->result) > 5) {
  $output = $view->render();
}
spacereactor’s picture

i 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

dawehner’s picture

@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.

dawehner’s picture

marvil07’s picture

I 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.

loze’s picture

I 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.

StephanieFuda’s picture

Status: Closed (duplicate) » Active

Hello 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.

mmtahir’s picture

Just 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.

dawehner’s picture

Well, you simply can't fix stuff right, as people don't use API the right way :(

PeteS’s picture

If 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.

vaza18’s picture

John Pitcairn , try this:

$view = views_get_view('view_name');
if (!$view || !$view->access($display_id)) {
    return;
}
$view->set_arguments(array($arg1, $arg2));
$view->pre_execute();
$view->execute();

if (count($view->result) > 5) {
  $output = $view->preview($display_id, array($arg1, $arg2));
}

Use $view->preview instead of view->render

dawehner’s picture

If 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.

A) 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.

Programming 101 validations like this, it would cut down on 50% of the Views issue queue.

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.

dvdroest’s picture

I think that PeteS his response is more a reaction on your comment:

Well, you simply can't fix stuff right, as people don't use API the right way :(

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.

acbramley’s picture

Confirming that using the following approach gets rid of the errors:

  $view = views_get_view('lp_promoted_content');
  $display_id = 'promoted_content';

  // Set the display and arguments based on the pane's context.
  $view->set_display($display_id);
  $args = $view->args;
  $args[0] = $node->nid;
  $view->set_arguments($args);

  // ADD THESE 2 LINES IN TO REMOVE ERRORS
  $view->pre_execute();
  $view->execute();

  $output = $view->render();
Reg’s picture

When 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:

  $view = views_get_view('my_view');
  $display_id = 'my_display';
  if ($view && $view->access($display_id)) {
    $view->set_display($display_id);
    // Do stuff like the following two lines
    $options = array(...) ;
    $id = $view->add_item($display_id, 'xxxxxx', 'xxxxxx', 'xxxxx', $options);
    // Show the view
    print $view->preview($display_id);
  }

Note the use of preview instead of render.

And if I don't need to do stuff I just use views_embed_view().

StephanieFuda’s picture

Post #21 from acbramley help me, thank you very much!

marvil07’s picture

About 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?

fromtheindia’s picture

gr8!!! Thanks it works for me.

khiminrm’s picture

#21 works for me too

DamienMcKenna’s picture

Component: Miscellaneous » Code
Issue summary: View changes
Status: Active » Needs review
FileSize
598 bytes

The code in #7 matches the logic used elsewhere in the module. This patch simply updates it to fit the Drupal coding standards.

hkirsman’s picture

#21 works!

dongtian’s picture

Thank you for your patch.
It works for me great.

moonray’s picture

Status: Needs review » Reviewed & tested by the community

This patch fixes the issue for me as well. Marking as RTBC

moonray’s picture

Still an issue on the latest views.

njbarrett’s picture

#21 fixed it for me. Thanks.

colan’s picture

We'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.

moonray’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
598 bytes

Re-uploading the patch by DamienMcKenna in #27.

moonray’s picture

Status: Needs review » Reviewed & tested by the community
dawehner’s picture

The 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?

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 34: views-n1556174-27.patch, failed testing. View results

sam.spinoy@gmail.com’s picture

Rerolled

sam.spinoy@gmail.com’s picture

FileSize
600 bytes

Sorry too much in the patch, here's the correct one

Reg’s picture

I'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:

if ($view && $view->access($display_id)) {

Admittedly that post 6 years old so the relevant code should be checked again but it's probably fundamentally the same.

arsn’s picture

FileSize
598 bytes

Hello,

Here is the views-n1556174-27.patch adapted to v. 7.x-3.23 of views.

Hope this will help.