Doesn't work with caching enabled

I, for one, am not experiencing the same problem. Caching is on and the selected blocks are hidden on mobile devices.

AdaptiveTheme.

Confirmed that, at least with Omega, browscap_block will not work for setting block visibility if page caching is enabled.

Well this uses pretty standard Drupal method to unset blocks, the same a Node module for example.

I can reproduce this and I doubt very much its theme related, more probably the actual block, although I am not a cache expert and can't see any difference between Node module implementation of hook_block_list_alter() and this module.

Can you guys tell me what blocks you are trying to hide - are these core blocks, module blocks, views blocks etc - I need some more info to narrow down the debugging process.

I can't see how this module would ever work correctly as written. Any web accelerator (think varnish, but many ISP's also layer them between the customer and the web) is not going to know to cache multiple versions and in which case to serve them. To work correctly, this module would either need to send headers indicating that the content should never be cached (bad solution) or modify the url. I'm thinking about how to solve this via url query modification - if I do I'll post a patch or link.

Correct, there are certainly limitations, and I am not a cache expert, just someone who is trying to solve a problem.

One other idea I have seen is to use AJAX to load the blocks, that might be a different module, maybe something along the lines of combining http://drupal.org/project/ajaxblocks and browsecap.

Certainly help, patches and so fourth are very welcome, as are co-maintainers ;)

Jeff, we're thinking in the same directions.

Something I'm playing with is using the block query module I created (which will soon be updated to support contexts) and then redirecting appending a uri argument (for example, mobile=true). Then blocks can be enabled/disabled based on the uri argument (which is caching compliant), and a browscap submodule just takes care of the redirection. However, this has quite a bit of overlap with the mobile_tools module (D7 version still in development).

The reason I don't like the ajax solution (believe me, I've thought about it many times) is that Drupal has to spin up for each request, and each request is another hit on the server. This makes it a non starter for me from a performance perspective.

Hi, it doesn't seem to work with Bartik 7.15 theme either.
Do you have news regarding this issue, or maybe a solution soon with the block query module ?

To fix this problem use the cache exclude module.

Yes it does

We'll soon be back tackling this problem for our solution, but http://drupal.org/project/esi along with uri modification may be the magic.

I see that the Mobile Switch Module has added a nice solution: #1854198: problem with caching enabled for anonymous users

Perhaps this module should follow the same route or integrate with Mobile Switch.

I dont think we should integrate, they are substantially different modules, however the cache ideas are pretty good, I looked, the only concern would be no conflicting with cache for that module if both are being used. Worth looking at certainly, would love to get a patch :) My biggest enemy for this stuff is time to write and test patches.

I just don't like the idea of integrating a similar solution into every module that has a problem with caching and mobile devices. Would it be better to add something like this to the Browscap module instead?

Not really, browsecap module is just a wrapper for the detection library, so to speak, there are several of these around such as Mobile Detect and others.

AFAICT what we really need is something like a "Mobile Cache" module that we can all leverage.

i took what they were doing here: #1854198: problem with caching enabled for anonymous users and made a patch for this module to do the same thing.

to use it you need to add this to your settings.php:

  $conf['cache_backends'][] = 'sites/all/modules/browscap_block/browscap_block_cache.inc';
  $conf['cache_class_cache_page'] = 'BrowscapDatabaseCache';

it then extends Drupal's page cache index by adding :standard or :mobile to the index for each cache entry.

so basically, if you enable page caching; then add those 2 lines to your settings.php.

Above patch works. Just wish I didn't have to add variables to settings.php.

I tried @#19. Then I get a WSOD, my logs explains, that there is no browscap_block_cache.inc what I can confirm.
So could anybody please explain where this file comes from?

THX in advance,

maen

!! Now I'm ashamed! Works like a charme. I patched th module file instead creating an inc file.

My fault, my mistake...

Cleaned up the paths in patch #19. Moved instructions to README.txt.

I'm new to Drupal and don't know where to apply this patch. I'd love to get this module working. Where do I need to paste this code?

See: https://www.drupal.org/node/1203936 which is part of https://www.drupal.org/patch/apply

Does this patch work with installed varnish?