views caching hides breadcrumb

So far I haven't been able to reproduce this problem with the current code.

Can you provide some details/instructions on how to make this happen? What version of views are you using? any important details about the view itself, or does it happen for all views? Does the breadcrumb work for one user, but then not another, or are you talking about multiple hits by the same user? Does it depend on the user role at all?

Thanks

No response in 3 weeks. Is this still an issue?

Closing this issue since its been a long time without response. If this is still an issue, please test with the latest version of custom breadcrumbs. Then, if you still have this problem, reopen and answer the questions in #1.

Hi MGN, reopening as I've recently observed this issue. I'll try to answer the questions you put forth in comment #1!

I was able to reproduce the issue in a Drupal installation with only Views, CCK and Custom Breadcrumbs by doing the following:

1. Create a view with a page display and a path
2. Assign the view a custom breadcrumb
3. Edit the view and enable time-based views caching
4. On first page load, the custom breadcrumb appears. On refresh (and subsequent refreshes) the breadcrumb disappears.

The views version is 6.x-2.8, and it's not particular to any one view, it occurs on all views in the same way. It doesn't matter whether the user is anonymous, user 1 or another authenticated user and it doesn't matter what role the user holds, the behavior is still the same.

When the view is hit for the first time, the breadcrumb appears, but in subsequent hits it disappears. It looks like views is doing the caching per-user, but the breadcrumb behavior is the same for all users. If a user logs out and logs in again, the breadcrumb will still be gone as Views loads the cached version of the results unless the time limit for caching has expired in which case the breadcrumb does appear one time, then when the page is hit after that the breadcrumb is absent.

Thanks liquid06. I have confirmed this problem now. I am working on a solution.

I think this because the breadcrumb information wasn't being added to the view - it was being set before the view was rendered. When the view is cached, hook_views_pre_render() isn't called so the breadcrumb wasn't being set.

I think this can be fixed by implementing hook_views_pre_execute() (instead of hook_views_pre_render() ). In this hook, adding the breadcrumb information to $view->build_info['breadcrumb'] lets the breadcrumb information get cached along with the view. The attached patch is against the current 6.x-2.x-dev version.

I've done a little testing of this and it seems to fix the caching problem. I have not yet checked to see if there are unintended side effects. In particular, I want to check to make sure arguments are still handled correctly.

Thank you so much for creating this patch and for your prompt response! From the tests I've done, the patch fixes the caching problem and arguments don't appear to be problematic.

I just ran a test and found problems with this approach. the view results are not available in hook_views_pre_execute(), so tokens relying on objects obtained from the view results will not work.

I am afraid this is going to be an issue I can't fix without changes in views. I've created an issue #769498: How do I modify the views breadcrumb using one of the views hooks? on the views issue queue better describing the problem. Marking this as postponed until then.

My suggestion for now is not to cache views that custom breadcrumbs is providing the breadcrumb for.

subscribing

Suffering the same problem for some time; thought I was going crazy. Glad others see this happening as well.

I think this is important enough to increase the priority to major (views without caching on production would be irresponsible, esp. for authenticated users).

A little update for this, for anyone using 7.x-2.0 – according to this comment by merlin on the other thread, simply using hook_views_post_render instead of pre_render should solve the issue.

I had this problem on D6 as well, but altering the function call as per #6 above fixed it. I then forgot all about it, until I encountered it again upgrading to D7.

Using post_render as suggested by merlin more than two years ago works fine, as far as I can tell..
Is there any reason this hasn't been changed for both 6.x-2.0 and 7.x-2.0 ?

This patch convert pre_render to post_render as #12 says

Patch provided in #13 is for Drupal 7, and works very well for us.

Thank you very much

It has completely a lot of sense :)