Block cache problem (Not showing for anonymous or authenticated users)

Turn off block cache - unfortunately Quick Tabs doesn't work with block caching on.

I do not know how to turn this off- can you help?

the block cache can be turned off on the admin/settings/performance page.

Hi,

This can be solved by changing line 610 of quicktabs.module, here is the line that adds the javascript file.
To fix it you just need to change this line for this:

By doing this the file will be added independent from other javascript files and will avoid caching its content.

I tested for me and worked, please test it and confirm if this works for you and then they will be able to include this fix for next version.

Best regards,
Nestor Mata

OH never mind I found it- DUH! you were right- works great now- Thank you so much

@nestor.mata: what do you think about this patch #279773-2: I am Unable to Get Quick Tabs for Authenticated User??? I think it serves the same purpose. So I don't know now which one is better..

Yes, it's still a problem with the latest dev release.
Here is a patch, based on the solution on #4 (The line #was changed).

quick thought:
if quicktabs do not work with block caching then:

http://drupal.org/cvs?commit=166220
Ok, I have committed the change in #8 (and cleaned up the code around it)

Please test the next dev release (or cvs), and report if it is still a problem..

Recently I've found that block cache is really very important for high traffic websites, and it's really not OK if they're disabled. There should be a way to use blockcache with QT. Or maybe this belongs in its own issue?

For me, it now works.

@Miraploy: if you search for "BLOCK_NO_CACHE" in the Drupal source code, you will find that many blocks have the cache disabled.
If QT does not work properly with enabled block cache then I have no other option than to disable it. It is better to disable cache in QT blocks only than in all blocks.
I don't know much about caching. If someone makes the necessary tests and provide all the situations when the QT block breaks with enabled block cache (or explain why it breaks), than we can push this issue further, if we find a solution for those problems..

#279773: I am Unable to Get Quick Tabs for Authenticated User??
#272352: Problems with Block Cache
issues marked as duplicate

QT still not works with enabled block cache

You are running drupal_add_js inside quicktabs_render which is called from theme_quicktabs in turn called from quicktabs_block op view and that's not called when caching is on. That's your problem.

The users need to update the caching to -1 for now by hand in blocks table.

This bug report update is sponsored by ifvnews.com.

Also see #235673: Changes to block caching mode not caught

Thanks Károly and ifvnews.com :)
so we need an update function to update the existing blocks, and then we should be fine?

I'm still ambivalent about this issue. It would seem that the patch in #19 would work in that it would ensure that all QT blocks get their cache setting set to -1, it only needs to update those that were created before the BLOCK_NO_CACHE setting was introduced in the hook_block code.
However, when I discussed this briefly with chx on irc he seemed to be saying that the best solution would really be not to use drupal_add_js in hook_block at all and output script tags directly to pull in quicktabs.js. This would mean we could still allow the QT blocks to get cached, which i guess is what people want when they turn on block caching.
On the other hand, the idea of not using drupal_add_js has other drawbacks - we have no way of being sure that drupal.js is on the page so would need to make a call to drupal_add_js at least in hook_init() or something. And then there are the js settings that need to get added (the new Drupal.settings.quicktabs and the ajax views settings). So I don't really like this approach either.

I'd like to hear from others who have opinions on this block caching issue but it has dragged on a long time at this stage, it would be good to just commit the patch and put the whole issue to bed. Let's see if anyone else has anything to say in the next few days...

Firstly, I'd like to say quicktabs is a magic project, it is very interesting and practical, just like the one tailored for my website.

However when I test this module by using of authenticated account, I found quicktabs block will be cached in the {cache_block}.

Since I am unable to resist convenience of block cache and my primary menu style is the same as quicktabs style, I hack the quicktabs module as following for the time being.

Backup the files before doing！

1. Copy the following function to the file quicktabs.module

2 Then find the function quicktabs_render in the quicktabs.module and comment 3 lines of script

3. Copy css script of your website applied style from quicktabs/tabstyles/***.css to your theme folder like: site/all/themes/****/style.css
4. Copy images of your website applied style from quicktabs/tabstyles/***/images to your theme images folder like: site/all/themes/****/images/
5. Clean your website cache

I know this method is a little complicated, but it realy help and I also wait for the perfect solution from the next release of quicktabs:)

sorry i change the title that i think is comment title

One thing I do not understand is, why is it cached when it should not be..

@cityreader: when you run this SQL select

Pasqualle see #17

Ok, so I think the correct solution would be to fix and backport issue #235673: Changes to block caching mode not caught.
Then we do not have to deal with it on the module level..

@chx: Is that where you are trying to guide me.

Is this issue the primary reason for the stalled progress in quicktabs...? Haven't run into a dead end I hope. <_<

@highvoltage: in current situation, there is nothing to fix in this issue, so I don't understand your point..
You just need to be sure that your QT blocks are not cached.. Any new QT block what you create is not cached, for old QT blocks you should check the status column in the {blocks} table.

I've noticed that progress has slowed significantly in quicktab releases, and this issue continued to grow, and the maintainer said she was ambivelant as to how to proceed. I was curious if her difficulty in choosing a course of action here was related to the delays.

I see you've just barely released another -dev, however.

the dev is created automatically (twice a day) when there is something changed in the code, but if there are no bugs then we do not have to change anything.. all features will go to the 3.x version..

hook_init seems to be the right way to do this. Disabling block cache, either globally or for this module is overkill.

I cleaned up the code in #21 and fixed it to apply the user's chosen style. Attached is a patch.

After further testing, that won't work. Looks like the content of some tabs won't load with caching turned on.

subscribing

the block cache is disabled already for every new QT block. I do not see that as an overkill..

I have a similar issue:
When not logged in, the QT display the message "You are not authorized to access this content."

When logged in as an admin, they display just fine.

I've disabled block caching.

That means you have not set the permissions on your site to allow anonymous users access to the content you are putting in your QT blocks. QT adheres to the access control specifications of the individual items placed in each tab.

That was the problem.

Thanks for the fast response, Kat, and being gentle to a rookie.

Did this work around work for anyone else, I have the same problem with block cache on,
Quicktabs works if you log in, but if you are anonymous, it won't wrap correctly.

Antonio

Is it still a problem?

It is weird that quicktabs is working on one page, but not on one particular page as anonymous user.. but it was working okay for some time, now it is consistently not working. all caching enabled, CSS, Javascript optimization enabled.

This is not working.
http://216.38.53.212/~fortune1/social-initiatives

This is working
http://216.38.53.212/~fortune1/social-initiatives/inclusive-development

with login as admin, it is working for all pages.

Edit:
After I added the following, it seems to be working for all pages:

@priceline: check your {blocks} table. Make sure cache is set to -1 for every row where module = 'quictabs'.

I updated my post, that solution also seemed to work.. i will keep an eye on it. Thanks,

sorry priceline, that solution do not work (for every situation).. you should check the blocks table..

I tried the two fixes and it dont work. I get -1 in my tables, and if i use the fix by priceline dont work either.

@Ptx_Soccer: are you talking about the front page of the site on your d.o user page? That page loaded the quicktabs.js and all the required QT files. So the problem there is something else. My first guess would be an incorrect views argument setting..

You are right, i think that the problems is with views, but i dont see anything there either.

Thx

@Ptx_Soccer: please create a new issue, with screenshots of the quicktab edition and the view (argument) edition screens. And I will probably be able to help you with the issue.

I will create a new issue in the views forum, because there is no one view that i can see anonymous, even the views pages. Thx for the help :)

Yes, i noticed it is still not working consistently. I will use your solution also. Hope it is consistent.

sorry priceline, that solution do not work (for every situation).. you should check the blocks table..

I ran into this with quicktabs mapping a heavy view. The block is not cached, and hence is heavy for the site.

So, it is the opposite problem in a way.

Will Quicktabs support block caching at some point?

@kbahey: views version 3.x will support caching, so quicktabs probably does not have to..

you guys know if there is any resolution to this? just got up to D6 on a fairly heavy load site and the server will get crushed if we can't use block cache or cache the views in the QT blocks.

Thanks,
Patrick
http://www.wallstreetoasis.com

Yes, the views module supports caching already (from views-6.x-2.6).
#468824: Add caching system to Views

Views block cache does not work in certain situation.

To avoid this, I implemented caching right in quicktabs when it is using views.

The attached patch adds that feature.

This needs some refining, such as making the time for cache configurable or getting it from the global cache_lifetime variable.

But it makes a heck of a difference with the patch compared to without, even if views blocks are configured for caching.

As I see this patch removed the views access check.

This is a revised patch that checks the view permission. The penalty of doing this is around 10 to 15 ms, so not a huge hit.

From what I can tell the patch doesn't account for paging in views. I've updated this so it also appends the current page on the cache key (cid). It will also work where the paging is set only on the default display and the other display inherit these settings.

Would appreciate Khalid casting his eye over it.

A note on this patch (and the previous quicktabs-views-cache.patch) - you should specify the arg parameter in quicktabs e.g. %1 if you need a nid don't rely on the default arg in view (i.e. if no arg available then the use a nid from the url). As the key is built up from the args supplied through the quicktabs UI (hope this makes sense).

Including the pager is a good idea.

However, the code can be simplified further. Here is a revised patch that does just that.

It is untested though. If you can test it, please report back.

Hi Khalid, the problem with removing the default display paging check is that a display that doesn't override the default will not have paging properties set, so you would need to pick these up from the default display object to see if paging is on. I had implemented it similar to your patch originally but one of my displays was just inheriting its paging from the default display and wasn't working and this was the reason why.