Use with Menu Block causes PHP notice and active trail problems

That's interesting. I'll investigate. Thanks for reporting this!

Have the same issue with 7.x-1.1 and Drupal 7.0.

Things fail after search_by_page_page_content invokes block_page_build on line 493. I can email you a stacktrace if you like. But due to time constraints of my own, I patched my install to not bother rendering blocks.

I am unable to reproduce this error, although I have PHP set to display even "Notice" messages. I tested using Drupal 7.2 and Search by Page 7.x-1.x-dev. It is not giving me any PHP notices on the search results page (I am seeing notices from another contrib module I have enabled, so I know that notices are in general visible).

I see that two people are reporting this same problem, so I know it exists, but unless I can make it happen, it's difficult for me to fix it.

Hmmm... So I'mjust trying to think through what might be happening... The error is coming when node_page_title() calls
$node->title
so apparently it's getting $node not being an object. That $node object is likely coming from menu_get_item()... I'm wondering if this patch would fix this problem -- can either of you try it out?

Other than that, I'm not sure what else to try, since I cannot see the problem. Maybe you both have a particular block enabled in your theme that is triggering the error? Search by Page renders the page to make a search excerpt on the Results page, so anything happening during page rendering could trigger something like this. It's hard to track down.

I've committed the change above to the DEV release of 7.x-1.x-dev (should be available for download within 24 hours if you want to try it out). It shouldn't break anything.

Upper case?!? that sounds a bit odd, to say the least.

OK, anyway, knowing that Menu Block is the problem helps. I can at least investigate that, and see if it can be fixed.

This doesn't sound good. It's a consequence of the way Search by Page compiles the search results page -- it renders each result as a page, and then gets an excerpt from the rendered page (to highlight the keywords). I thought I had gotten around most of the side effects of this by resetting some static variables, but obviously it's not completely working.

So I'll have to get Menu Block, take a look at what it is doing, and see if I can fool it into ignoring all but the real page (the search results page).

OK... I installed the Menu Block module, and added a menu block to the page.

However, when I do a search, I am still not seeing
(a) the error message originally reported (I have my PHP error level set to the highest level of warnings)
(b) the menu block items getting set to active when the page they refer to is in the search results.

For instance, node/1 is in the menu block, and when I go to node/1, it is definitely marked "active" in the menu block, but when I search for a word that is on that page, its entry is not marked active in the menu block.

So, I'm still not sure what to do to debug this. Any ideas on how I can get this to show up on my test setup?

One thing I remembered is that there was a suggested fix on a somewhat related issue here:
http://drupal.org/node/1040002#comment-4462812
I haven't put that fix into Search by Page 6.x or 7.x yet, but it looks like it might help with the active trail part of your problem anyway? That person was using Menu Trails (which doesn't exist in 7.x).

+1 I got this error thrice when I send an email using Print

Getting this error when sending an email isn't likely to be related to Search by Page... is it?

I may be mistaken but this error can have other core origin rather than in Print Module
Suggestions?

babbar.ankit: This issue is in the Search by Page project. If you are having a similar error that is unrelated to the Search by Page project, then you need to file an issue in another project (perhaps Print or Drupal Core?).

RE #17/#18 - that is very helpful and detailed information - thanks! I will try later today (hopefully) and see if I can reproduce your issue(s).

Hi. I'm getting this same problem. I too have Menu Block installed. Unfortunately, the fix in #21 is unsuitable for my situation. Additionally, on my search results page, my embedded menu gets pretty broken too. I print my main menu using menu_tree() and on this particular page, the actual link text of all the top level links is removed, however the HTML (as in <ul>) structure and classes are preserved!

For info, following on from #17:
- "Perhaps the order of rendering the Menu Block matters..." my custom menu block (show siblings only of second level) is rendered after the main content (i'm using it as a side bar navigation)
- "...these notices only appear when the content I am finding in the search does not have a menu item associated with it" - This sounds about right too, as when the search result only includes pages that do have an associated menu item, the notices dissappear.
- "When you perform a search that returns the menu'd item you should see the additional "active-trail" classes added to the menu item." Bingo. Hadn't noticed this myself, but i'm getting exactly the same here.

Unfortunately, my knowledge doesn't extend far enough to be any help coding a fix for this, but good investigating @jasondecamp and thanks for looking into it @jhodgdon.

I think that the fix to #1040002: Active trail being set incorrectly that I added to the 7.x development version of Search by Page a few days ago should fix the active trail issues that have been seen with Menu Block. If someone that has seen this problem can test, that would probably be useful.

I am still not sure about the property of non-object PHP notice that was originally reported, so I am leaving this issue open until that is resolved. If someone who was seeing this notice could verify that it is still happening with the latest Drupal 7.x and latest Search by Page, with Menu Block enabled, that could be helpful.

I do still get this error:

Notice: Trying to get property of non-object in node_page_title() (line 2075 of /var/www/html/modules/node/node.module).

I am running the dev version of Search by Page released on 9/23/2011, Drupal 7.8 and the dev version of Menu Block from 8/17/2011. I observe this behavior:

1. When not logged in to site, visit www.example.com/search_pages/test which returns four pages of results.
2. Dblog reports many "Trying to get property of non-object" errors.
3. Remove menu block from search results page
4. When not logged in to site, visit www.example.com/search_pages/test which returns four pages of results.
5. Dblog reports no errors
6. Add menu block back to search results page
7. When not logged in to site, visit www.example.com/search_pages/test which returns four pages of results.
8. Dblog reports many "Trying to get property of non-object" errors.
9. When logged in to site, visit www.example.com/search_pages/test which returns four pages of results.
10. Dblog reports *one* "Trying to get property of non-object" error.

I thought the last item was interesting -- logged in users only get one error when visiting the search results pages, where as anonymous users get a ton.

Thanks for the specifics! I'll look into this as soon as I can.

I have reproduced the behavior you are seeing, but I'm not sure why it's happening yet.

I've tracked it down to a function in menu.inc -- _menu_link_translate() is not getting $item['to_arg_functions'], which would normally auto-load the $node object. So it is not loading the node, and so it is not having an object to get the title from when it calls node_page_title(), which is generating that error.

But I don't yet know why this is the case... will investigate further, but unless I figure it out in the next few minutes, it may not be for a couple of weeks.

No wait, that's not right. It's not the to_arg_functions, it's the load_functions that should be used... anyway I think the problem is in that function, just don't know where.

I am jumping on this thread in regards to the following error shown above, and how I was able to circumvent it

Notice: Trying to get property of non-object in node_page_title() (line 2075 of /var/www/html/modules/node/node.module).

On the site that I am working on, the menu is in the range of 500+ items, added based off of a migration from another CMS server. I have noticed this error popping up on pages that are added via hook_menu(), which have subsequent child pages. For instance, the example in question has content displayed here...

news-events-announcements/tw-news-views/mytw-weekly

with arguments of 2012, and 2011

news-events-announcements/tw-news-views/mytw-weekly/2012
news-events-announcements/tw-news-views/mytw-weekly/2011

to display more detailed information.

When visiting the child pages, and then accessing the original landing page of...

news-events-announcements/tw-news-views/mytw-weekly

I received 7 errors which correlated to all of the nodes drilling up to the root menu path, with them calling node_page_title with just the nid as the argument.

I was able to circumvent the issue, but adding a menu path to the arguments as well. While this might not be helpful in all situations, it leads me to believe that the issue stems from this menu item, while not being a node, preventing all of the other node items from being loaded as well.

For instance, if we had a hierarchy of...
node-1
--node-2
----node-3
----custom
------custom/arg

i believe the node's 1-3 will throw the page title error if you access custom/arg, and then custom.

A more permanent fix would be to edit line 586 of menu.inc, and perform a check to see if the item is a node_page_title, and to check to see if the argument is an object or not. If not, it would be the nid, and the nid can be loaded.

I get this error, as previously described, and decided to formulate a patch against 7.x .
I simply add a check in node_page_title, and load the object if I infer the argument is a nid:

function node_page_title($node) {
  if (is_numeric($node)) {
    $node = node_load($node);
  }
  return $node->title;
}

I find this solution to work better then patching in menu.inc, since I need no string compare check against a fixed value.

RE #29 - Yes, you could hack core to fix this problem.

But the real root of the problem is that node_page_title() is always supposed to be receiving a fully-loaded $node object as its argument, because _menu_link_translate() is supposed to be making sure the $node object gets loaded. And it's not doing this, for some reason, when Search by Page is rendering pages internally to format search results, when the Menu Block module is being used.

What I'm not sure is why the malfunction is happening in _menu_link_translate under these circumstances.

I took another look into this issue, and found some interesting things:
a) The Menu Blocks module does some additional caching of menu trails in its function
custom_menu_active_trail.inc :: __menu_block_set_menu_trail()
So if this module is going to work with Menu Blocks (not mess up its blocks), we'll probably need to do some more drupal_static_reset() stuff in Search by Page to get around it.

b) The PHP notices about node title are being generated when the function
menu_block.module :: menu_trail_build()
calls the core function
menu_tree_page_data()

  else {
    // Get the tree pruned for just the active trail.
    $tree = menu_tree_page_data($config['menu_name']);
  }

[This is called (somewhat indirectly) during the search execution, when it renders the page in search_by_page_page_content(), in these lines:

  foreach (module_implements('page_build') as $module) {
    $function = $module . '_page_build';
    $function($page);
  }

That, in turn, ends up calling menu_block_block_view() to render the menu block, and that calls that menu block function.]

More investigation still needed...

I just committed a fix for this issue to the 7.x development version of this module. Basically, Search by Page is now only rendering the content region blocks, so it should avoid all the problems in Menu Block when the menus in other regions are attempted to be rendered during processing of search results, which confuses Menu Block about which page it is on. On my test box, it definitely makes all the active trail and PHP notices problems go away with Menu Block. Hopefully it will work for everyone else too! :)