Use display_plugin name to identify allowed displays for custom breadcrumbs

Thanks for the report. custom breadcrumbs 6.x-2.x hasn't been tested with Views 3 yet, but i think I understand the problem.

Custom breadcrumbs should only set the breadcrumb for an allowed display. So far this has been done by checking to see if the $view->display->id variable starts with 'page' . In views 2, renaming the display doesn't change the value of this variable, so custom_breadcrumbs_views works fine whatever the name of the display.

According to this report, it seems that renaming the display renames (or modifies) the $view->display->id variable in Views 3? Is this supposed to happen in Views 3, or is it a bug? Is there another way to determine the views display type?

I am (temporarily) moving this to the views issue queue with the hope that one of the developers can provide some information on this. It is difficult to know from my perspective since views 3 is in alpha.

You probably don't want to check for the name of the display in any case. Views actually has a mechanism with which you can feed it the breadcrumb, assuming your custom breadcrumb happens during the process of rendering the view. You can find out a lot by peering at $view->build_info -- in particular, there's a 'breadcrumb' area. Custom breadcrumb can put whatever it likes there and Views will happily use it, if it's appropriate for Views to place a breadcrumb. If it is not, Views will not do so.

Would that fix your problem?

 Is there another way to determine the views display type?

There is a much better way: $display->display_plugin

Thanks for your feedback.

Ok, so am I correct to assume from your answers that in views 3 $display->id is supposed to change with the display name?

I'll look into trying to feed the breadcrumb in through $view->build_info . Is the breadcrumb info consistent between views 2 and 3, or do you think it will require a separate solution for each version?

I'll also have a look at $display->display_plugin to see if its easy to determine the display type from that. Again, would I be correct in assuming it hasn't changed from views 2 to 3?

Thanks!

yes the display_plugin shouldn't change.

build_info could change later. Now query and count_query is a string, but perhaps, or for example in drupal7, its a object.

Here is a patch based on dereine's suggestion to use the name of the display plugin to determine the allowed display types for custom breadcrumbs. If it works for views 3, its an easy fix to make. I've tested it with views 2 and haven't found any problems. @karlos007, can you test this and see if it solves your problem? Thanks.

Update status

The displaz_plugin key is there always

The same fix was also suggested in #739600: Integration with Image Gallery module and other minor remarks.

committed a fix to 6.x-2.x-dev in CVS.

you can find out a lot by peering at $view->build_info -- in particular, there's a 'breadcrumb' area. Custom breadcrumb can put whatever it likes there and Views will happily use it, if it's appropriate for Views to place a breadcrumb. If it is not, Views will not do so.

I am still struggling with this. It looks like $view->build_info is present in the view during hook_views_pre_execute. And if I add the breadcrumb at this step it works. The problem is that I need the results of the query, which happens later. It would be great if I could add the breadcrumb to the view using the pre_render hook, but I don't see $view->build_info in the view object passed into hook_views_pre_render (using views 2), and creating $view->build_info['breadcrumb'] at this step doesn't work. Is there another hook I should be using? I would appreciate any suggestions!

EDIT: Scratch that! build_info is present, I just wasn't finding $view->build_info['breadcrumb'].

EDIT 2: Further retractions. Adding the breadcrumb view $view->build_info at the pre_execute stage does not work. I can call drupal_set_breadcrumb at this stage to modify the breadcrumb, but that's it.