Block still shows in mobile browser

I'm using 7.x -1.0 can I make the same change or should I be using the .dev version?

Thanks for such a quick response to this issue.

Thanks, this fix worked for me.

Weird side-effect though, for testing purposes I had several identical views showing, and disabling one of the blocks with that view disable the other blocks too.

deleted

I better test this, are you saying to use string not a bool, thsi sounds like some other weirdness that Browscap can return strings.

Perhaps we need to use something like this:

if ($browser['ismobiledevice'] == TRUE || $browser['ismobiledevice'] == "true" || variable_get('mobile_switch_ismobiledevice', FALSE))

Thanks, folks... this had me scratching my head for a while. #1 works for me, but #6 does not.

Ditto, #1 worked so clearly value is string. Only tested on WAP, Opera, Opera mini, Nokia Symbian.

+1 for monstrfolk's fix in #1. Applied to dev version of module and it now works like a champ again.

Thanks!

Hm...didn't fix it for me. Any other suggestions?

Update: works in every block except main menu, superfish with the fix. Superfish has it's own mobile detection but it doesn't collapse, so could be a problem with superfish.

Try resaving your blocks, emptying all caches under performance, plus emptying your mobile browser caches. Also, if you're using views as a block you might look to temporarily disable caching and then re-enable. Working w/ views block, with caching on that block here. Also, check the code to make sure you made the change correctly.

Bingo! I was trying to use it with the menu region. Ah well, still works manually with php. Thanks for the quick response.

You are using PHP to hide the main menu block with superfish in mobile? Good idea, care to share the code with the rest of the class and help us all out?

#6 worked for me with the latest dev of Browscap Block and AT Core 7.x-3.1+53-dev. No luck with #1.

Edit: I only checked the iphone prior to posting here, and when I checked Firefox it had removed the block there too. Now neither seem to work.

Is yours a Superfish menu or another for main? If it is Superfish, I think we're both in the wrong issue queue space.

http://drupal.org/node/1420930

See the dev in a media query based Superfish. I haven't looked browsercap block code on my main menu/superfish issue but I've just assumed since superfish is jQuery, somehow that is overriding the initial "hide block" directive and this module really isn't designed to deal with responsive/jQuery scripts.

Dunno. For me, the ideal would be to have one Superfish that actually collapses, scales hides select menu children upon mobile detect and this might be in process for her new jQuery script is implementing a mobile detect first.

http://drupal.org/node/1420930

Update: I upgraded to the Supefish 7.x dev. released on 02.08.13 and the "hide block in mobile" for browcap block worked for main menu, Superfish, Opera browser tested, major progress.

@RobertOak

Is yours a Superfish menu or another for main? If it is Superfish, I think we're both in the wrong issue queue space.

No it's a non-superfish menu. I'm thinking it's supposed to work at the block level. Do thank you for info on the updates to superfish which I needed anyway.

@mermentau Looks like a css and main menu having a hidden id issue. The link talks about techniques to grab the main menu id in order to hide/collapse in mobile. I took a scan at this code and it's setting a database field in PHP but the main menu "block" has a hidden higher level ID to it, looks like a weird "Drupal feature" on just this region.

I was wrong, mine wasn't hidden, it was outright PHP/jQuery errors in the latest devs, so I reverted and am going to try the css, rewrite regions route others are sugggesting.

Hey Robert,

I just used a php isMobile with an else statement. I'll copy and paste the code when I'm back in the office, but basically I used menu block module to place a second version of it in a "mobile only region," which was printed in the isMobile with the main menu region being placed in the else statement. Not an ideal fixed but will work until a major theme rewrite builds it in.

Probably in office tomorrow, I'll pass on the whole code.

Start a developer or "how to" something thread in the community and link here to it. We're getting into techniques and coding, which is cool, vs. issues with this module.

Hello

Even applying #1 fix, with Corolla Theme in a Language Switcher Block, does not work.

Is still visible in smartphones.

KiM

with dd(gettype($browser['ismobiledevice'])) return 'string'

I solved in this way

line 85

if ($browser['ismobiledevice'] == 'true'){

Bye

#22 worked for me with the latest dev versions of Browscap, Browscap Block, and AT.

Thanks #22, Seshen, your code works for me on the development version.

If you are having issues make sure you are using the development version. I spent an hour banging my head to only realize I was using the stable version, which exhibits the same issue for me. Make sure to create a backup of the original browcap_block.module just in case!

None of the codes work for me. I am trying to hide browser sized adsense codes using the adsense module. How can this be resolved?

Back to correct title, please don't change issue titles like this (we use titles to keep track of things).

Didn't work for me using latest versions of AT, Browscap, Browscap Block (dev version), and Pixture Reloaded subtheme. I tried carefully editing line 85 both ways -- as suggested in comments #1 and #22 -- and flushed caches on both server and mobile device before each test. But I'm a relative newbie so can't be certain I did it all correctly. I tried on both header and sidebar blocks.

I did not understand this line in comment #22, if it was part of the line 85 edit instruction:
with dd(gettype($browser['ismobiledevice'])) return 'string'

This module would have been handy.

Hello,

I have the same problem. Blocks are still visible in mobile browser (android). I have test #1 & #22 with no success.

Thanks for your help.

Agree w/ #30, does not seem to be working at this time w/ AT, BrowsCap.

#22 works for me on dev version - whoops I take that back, it does 'hide' the block but for both mobile and wide screen use.

#30 the module can only rely on what is sent back to it, and it appears to be pretty dependant on browser afaict, 1300 sites are using this so its not unusable. Could do with some love, but I have been for the most part unable to work on this module the past year or so, doesn't mean people can't get something out of it.

I am using the latest 7x dev version of this module. It works after I save the block but if I go to Performance page and clear all caches the block will show up again.

When I check the block settings the Hide in mobile is still selected. And again, when I save the block and immediately check on iPhone, Android the block will not display until the cache is cleared and it is as if it has been reset to display in mobile.

I don't have anything in my logs.

That has to do with caching a single page as either mobile or desktop. Does it works as expected after clearing the cache, then doesn't on the next device you try?

Depending on your caching solution, you may need to find one that seperates them into two caches, one for mobile one for desktop.

When I resave the block so it hides in mobile and then immediately afterwards clear the cache, the block is hidden on mobile.

If I then clear the cache again, the block reappears on mobile display.

I am using the default Drupal page cache. Is there a recommended cache module that works with browscap block?

Hey Isabug,

You just have to set up two seperate caches, one to generate a mobile page, and another to generate a regular. Give me a couple days, I'll figure it out and post it when I do. (If you don't do it first :-)

That would be a great help @stephen.punwasi as I'm not sure how to do that. Thanks!

Was reviewing my dashboard and thought I'd see if you'd had a chance to sort this out @stephen.punwasi ?

Thanks

Browscap is returning the string "true" on most occasions where I could test.

Patch attached to deal with these situations.

#41 solved my issues with this.

prior to applying the patch, some mobile browsers worked properly (safari and dolphin), but chrome was not. after applying the patch in #1 the reverse was true. after applying the patch in #41 all mobile browsers are rendering mobile content properly.

Tried the patch in #41. Got these messages:

"patching file browscap_block.module
Hunk #1 FAILED at 82.
1 out of 1 hunk FAILED -- saving rejects to file browscap_block.module.rej"

Don't know what happened there. Opened the patch file and copied the appropriate line (line 10) and replaced the line in the browser_block.module file and, finally, it appears to be working correctly!

Thanks!

Just installed the 1.0 module and it doesn't work for me either. Using the Corolla theme and no page caching.

Looked at the patch mentioned in #41 and it doesn't appear to apply. Unless I'm supposed to be using the dev release?

Hey there,
Glad I'm not the only one with this problem. Is the fix mentioned above implemented in the current release?
I'll try to be as specific as possible. If more info helps, I'll be glad to provide. I'm a noob if it comes to code though.

• Problem: the site (http://nkdyp2016.nl/) loads on mobile as if it were a desktop browser.
• Which either could mean the right variable is not set (which would be a Browscap problem) or Browscap Block doesn't react to it like stated above.
• Tested with Views blocks and custom blocks. Both are configured to not be visible in the right sidebar -- and be replaced by other blocks below the main contents instead -- when loaded on mobile.
• Tested on iPhone 3GS and iPhone 5.
• Page caching is turned off. Cleared all the caches I could find several times.
• I'm using Browscap 7.x-2.2, Browscap Block 7.x-1.0. The database is connected (version 6011).
• Theme is based on Stark (i.e. as simple as possible). Working on it right now.
• Yes, it's on a commercial server farm, but that would only a problem for retrieving the db, right? It did that alright.

Can anyone give me a clue as to what I'm doing wrong here?

EDIT: fixed, see below.

#22 works!

For me at least.

In browscap_block.module:
Replace
if ($browser['ismobiledevice'] == 1) {
with
if ($browser['ismobiledevice'] == 'true') {

That's because ismobiledevice doesn't return TRUE or FALSE. It returns a four-letter string called "true" or a five-letter one called "false".

I've been looking with a guy who knows more about php and after more than an hour we finally concluded that the lookup in the array is the problem. Same as #22, but I thought 'if that'd be the solution, it'd be implemented by now'. Naive, I know.

That said, can we include this in the base code, or do we then exclude older/newer php versions?

None of the above worked for me.
Installed https://www.drupal.org/project/mobile_detect
and also turned on "Mobile Detect ctools" within this module.
Then for the visibility options for blocks you'll have: "Mobile Detect: device type" option.
On next screen (Mobile Device Type) choose "Mobile" at the top (and check "Reverse (NOT)" at the bottom if you want to hide for mobile).
This worked on the first try.
My blocks are showing/hiding depending if it's mobile or not.

#'s 22/46 worked for me using the .DEV version - this really should be updated in .DEV and the Stable version.
Still will not work with caching enabled. Since this seems to be a known issue it should at least be put into the release notes/documentation so poor webmasters don't bash their heads against the wall trying to figure out what's wrong.

@ #49 agree, the maintainer is a total slackass, we nee to get on to him about this! Lets add it, but really mobile detect is the actual solution.

This took sometime as well...
Finally solved on this end.

Did two things:
1- admin/config/system/browscap
Press "refresh browscap data"

2- Go to browscap_block.module

line 85 was changed to:
if ($browser['ismobiledevice'] == 1 || $browser['ismobiledevice'] == 'true' || variable_get('mobile_switch_ismobiledevice', FALSE)) {

Bang. Worked. Great module and well thought out.

Only run cron.php