The function that resets the cookie when switching from desktop to mobile does not have a case to force a mobile cookie. A user willing to see a mobile version should be allowed, at the very least, to see a basic presentation associated with the default group, normally the "mobile" group.

function mobileplugin_switch() {
	global $mobileplugin_group;
	if ($mobileplugin_group != MOBILEPLUGIN_FULL_GROUP) {
		$group = MOBILEPLUGIN_FULL_GROUP;
		$touch = false;
	} else {
		list($group, $touch) = _mobileplugin_detect_group(MOBILEPLUGIN_MOBILE_GROUP);
	}
	setcookie('mobileplugin_group', $group . ',' . ($touch ? '1' : '0'), time() + 8640000, '/');
	drupal_goto(drupal_get_destination());
}

The above code should be changed to have a case where, if the group was originally "full" and I want to switch, if recognised as "full" still forces to "mobile".

There is an inherent fault that if an admin has removed the "mobile" group this fill fail. Maybe should be addressed elsewhere allowing the admin to define a default mobile group.

Comments

teemule’s picture

teemule commented
Status: Active » Closed (fixed)

That code will force from full to mobile. One should not use "full" in the rules, but "no" so that the detection will stop and use the default passed for the _mobileplugin_detect_group as a parameter.

atrasatti’s picture

atrasatti commented
Status: Closed (fixed) » Active

That piece of code is used in the block to switch from desktop to mobile and back. I don't understand what you mean when you refer to the rules.

The point is, in my view, that it is possible that a user that gets the desktop version wants to switch to the mobile one and viceversa. The problem there is that if the browser is recognised as mobile by the rules the site admin has defined, the user will NEVER be able to see the desktop version.

teemule’s picture

teemule commented

As far as I know this has always worked - reading the code or testing it?

Switching from any group not full will end up in full (the first if).

Switching from full will do the detection to detect possibly a real mobile device. But the parameter MOBILEPLUGIN_MOBILE_GROUP is the default group and this will be returned if a rule with 'No detection' is matched or none of the rules match. I suppose any other rules that could match are mobile site versions.

Removing the default 'mobile' group will ruin this but maby something else as well so that could be made immortal.

atrasatti’s picture

atrasatti commented

I think it's OK to keep a generic group called mobile. Yes, we might want to change the name to something like "basic_mobile" or other that makes it clear it's a fallback case for all mobiles that are not in any other group that the admin has defined in the rules. In fact we might have some handbook page or addition to the README.txt that recommends to use "mobile" as the fallback for all mobiles.

I agree with you the first case is correct, i.e. if I am any "non-full" group and want to switch I get the "full" version and that part is OK.
The problem is if I want to FORCE a mobile version and I can see at least 2 cases. First case is a bit extreme, I'm using a browser/device that is considered for "full" presentation (a PC, a Mac, etc), but I REALLY want to see the mobile version for some strange reason (save bandwidth) and then a second case that is more likely, a new device that is not part of the rules or a device that is hybrid (a netbook, or a small tablet). In these cases the admin might have not created a rule for that and the device might fall into the "full" category, but in my view if the user clicks on the "switch" link it should be presented a mobile version no matter what. This means that the user will get, in the worst case, the theme assigned to the group "mobile" or anything else if, for some reason matches some other rules.

teemule’s picture

teemule commented

Like said there is no "full" group. There is just a 'no detection' rule that will stop matching rules and use the DEFAULT group. Also when no rules are matched the DEFAULT group is used. Now here the default group set is the fallback mobile group.

I recommend testing features and not only reading code that seems to lack few comments in that function.

atrasatti’s picture

atrasatti commented

OK, I'll make it simple: "it doesn't work for me". Obviously making the effort of checking the code after testing it wasn't appreciated.

Check it out on http://dtest.dreamhosters.com/ visit with your normal browser, scroll to the bottom of the page and click on "Show mobile version", now my English might not be very good, but I expect, as a user, to click that link and see the mobile version regardless of the browser or device I am using. This does not happen.

teemule’s picture

teemule commented

Test with the mobile_garland theme. Works for example in http://betalabs.nokia.com

I'm not putting down your efforts. I'm just telling the problem is not in that specific code and the logic you look after is there.

atrasatti’s picture

atrasatti commented

I'll close this ticket because on a different dev server, with the latest mobileplugin seems to work fine. I wonder if it is a settings issues on this specific install. mobile_garland does not seem to work properly either, so must be something else conflicting

nrackleff’s picture

nrackleff commented

Wondering if anyone figured out what caused this? I am having a similar problem and can't seem to figure out what is causing it to misbehave. I had the admin theme module installed, but I uninstalled it because some other users noted that it seemed to conflict.

adam_c’s picture

adam_c commented

I too cannot switch to 'mobile mode' in a desktop browser.

Could it be something to do with Pressflow? I know Pressflow does not like cookies too much.

agittins’s picture

agittins commented

Also experiencing the same issue - on both desktop and a Symbian S60 client, I see the normal theme regardless of how many times I click the switch link - I am using nokia_mobile theme. Using neither admin theme nor pressflow here.

I also agree with the sentiment posted by several users that: If a user clicks "show full browser version" or "show mobile version" then the site should do _exactly_that_ - any autodetection or cookie/session-based choice should be ignored at that point. It appears that this is indeed meant to be the case (and that this bug is causing the issue) but some responses have been... confusing.

EDIT: Actually, this seems to be working for me now - somehow (ie, my fault but don't want to admit it) the group theme for "mobile" had changed back to the installation default of garland mobile, which I don't have installed. Definitely worth checking if you run into this issue :-|