Needs review
Project:
Context Mobile Detect
Version:
7.x-1.x-dev
Component:
Documentation
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
1 Sep 2012 at 19:02 UTC
Updated:
21 Dec 2015 at 22:13 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
fabianx commented*FIXED* in http://drupal.org/node/1594692/commits.
Comment #2
kevinquillen commentedDoes this work with Varnish and Nginx?
I've had issues with those using PHP to detect user agent and had to resort to Javascript to do it.
Comment #3
fabianx commentedIt does, but you need to tweak the settings in Varnish / NGINX to do a vary based on Cookie and not strip the device cookie and to never deliver a cached version, if the cookie is not set.
The README has a little more explanation on that.
Comment #4
kevinquillen commentedAh, yeah. On hosted setups like Acquia, you can't touch that stuff.
I can share some of my JS code with you if you like, and offer to swap between PHP or JS detection for the redirect from config.
Comment #5
fabianx commentedThat sounds like a good plan! :-)
Comment #6
kevinquillen commentedI am utilizing jQuery cookie plugin to achieve this. As you may or may not know, this plugin is not loaded for an anonymous user. To make that happen, first it needs to load it. In a custom module (or Context Mobile Detect patch??) I add this to hook_init:
The Drupal behavior, mobileDetection. This fires on every page and sets a JS cookie, and swaps back and forth (if the user clicked View Full Site or vice versa). You could easily replace the SITE_DOMAIN etc with values supplied by drupal_add_js settings array (taken from an admin setting UI?):
One note though, I am using a subdomain, and that subdomain has its own theme. I found (the hard way) that this stuff does not work very well on a single domain with two themes.
Leveraging JS was the only way to sidestep Drupal caching and server based caching. We are using this on a Acquia hosted Drupal 7 site with Varnish and works quite well.
Comment #8
RAFA3L commentedI found a problem...
When some page is viewed from a desktop browser the cache file is generated fine, for example "_.html", but if I open the same page from a mobile device this load the same cached "_.html" file and not generate the mobile version.
But if I open for the first time some page from a mobile device this generate the correct cache file, for example "_device=1&device_type=blackberry.html"
The problem is when the page is opened first from a desktop browser.
I'm using the Boost module.
Comment #9
fabianx commentedFor this to work with boost, you'll need to add some special rules to boost to not cache the first request if the "device" cookie is not set - similar to how we do it with varnish.
Comment #10
norhusz commentedRAFA3L!
At me the same problem. Did you manage to untie it?
What kind of rules is it necessary to write into the .htaccess file?
Thank you!
Comment #11
RAFA3L commentedI'm using this
http://drupal.org/node/629520#comment-3941580
Comment #12
norhusz commentedWorks great. Thanks a lot!
Regards,
norhusz
Comment #13
nerdcore commentedFabianx has suggested in #3 that Varnish can be modified to deal with this Device cookie thing properly, and indicated that there is additional information in the README...
What am I supposed to do with this?
I'm sure a couple lines of VCL is all this is required for this, but can we get some actual VCL down here on this issue for those of us trying to set up context_mobile_detect behind Varnish?
Will this be sufficient?
Any advice greatly appreciated.
Comment #14
kevinquillen commented#6 is how I bypassed Varnish without having to touch VCL, if you are using a subdomain for mobile.
Comment #15
fabianx commented#13: Yes, I think this VCL is sufficient as long as you make sure that your code does additionally:
* Get value of device cookie via regexp
* Strip all cookies like normally (assuming lullabot config)
* If req.http.Cookie == '' {
** Add device cookie back to req.htto.Cookie
** return (cache); // the difference of pass ...
* }
I will also need to implement this next week, so I'll report back then :-).
Comment #16
nerdcore commentedI'm seeing these HTTP headers coming from my web server and unsure how to mitigate their use with an external cache such as Varnish. It seems to me that one or all of these are causing pages not to cache. I'm unsure how to proceed and would appreciate some feedback (personal data removed):
Set-Cookie: device=3; expires=Thu, 04-Apr-2013 20:31:44 GMT; path=/; domain=.EXAMPLE.COM; httponly
Set-Cookie: device_type=0; expires=Thu, 04-Apr-2013 20:31:44 GMT; path=/; domain=.EXAMPLE.COM; httponly
Set-Cookie: pagestyle=standard; expires=Fri, 04-Apr-2014 18:31:45 GMT; path=/
Set-Cookie: SESSKEY=VALUE; expires=Sat, 27-Apr-2013 22:05:05 GMT; path=/; domain=.EXAMPLE.COM;
Comment #17
mgiffordThe README.txt really needs some work. From the sounds of it in #3, this is supposed to be described in the readme, but it's just not..
We really need to get down to the specifics. Saying "add some special rules" isn't as useful as a snippit of config to paste in. I'll compare it to what's in Lullabot's guide http://www.lullabot.com/articles/varnish-multiple-web-servers-drupal
@kevinquillen thanks for the extra JS, but we should be able to do this within Boost or Varnish.
@Fabianx what did you do with your install?
Comment #18
mgifforddevice & device_type are definitely set as part of this module, but the other two probably aren't related:
setcookie("device", $data['device'], REQUEST_TIME+7200, $params['path'], $params['domain'], $params['secure'], $params['httponly']);setcookie("device_type", $data['device_type'], REQUEST_TIME+7200, $params['path'], $params['domain'], $params['secure'], $params['httponly']);Mostly looking at setting this issue to active.
Getting more specifics for Varnish 3 would be great.
EDIT: Useful reference https://www.varnish-cache.org/docs/3.0/tutorial/devicedetection.html
Comment #19
fabianx commentedYes, docs really need work.
I was assigned to other work in the mean time so I did not yet get to update the docs for CMD with Varnish.
Comment #20
klausiSo here are 2 Varnish config files I'm currently experimenting with.
* Device detection is done in Varnish with https://github.com/varnish/varnish-devicedetect/
* The X-UA-Device header created by that is normalized down to mobile, tablet or pc.
* Varnish uses the Vary header internally to cache 3 versions for each device category per page.
* Before delivering the page the Vary header is changed to User-Agent, so that the X-UA-Device variation is not visible to any other external caches.
* The request to the backend (to the web server like Apache) is updated with a device cookie. Which means that the mobile detection library is never invoked in PHP, if the site is accessed solely through Varnish.
Feedback welcome!
Comment #21
fabianx commentedWow, looks great!
Comment #22
fabianx commentedSome more work is needed here for #0:
Currently we do:
But we should do:
That gives support for all webservers automatically :-D.
Comment #23
fadgadget commentedSorry Fabianx would you, or anyone else, know what rules i should be adding to boost module to use this module?
thanks
Comment #24
ckngHere are the config we are using, showing the related config only, the rest are generally based on Lullabot version.
Please test this out, feedback/improvement are welcomed.
Comment #25
shaneod commentedUsing standard Drupal Caching. I've included the line from the read me but it is still throwing off the contexts off on different devices depending when i have caching for anon users enabled.
As soon as i switch caching off it works perfectly. Any ideas?
*** Edit - my mistake - My Settings.php file had not uploaded - now working with caching place.
Comment #26
paolomainardi commentedAttached a patch, which does the following things:
1) Parse request headers if available:
VCL Example: https://www.drupal.org/node/2638156#comment-10684950
2) Use cookies when req headers not available, as already does with a bit of refactoring.
3) Make _context_mobile_detect_detect() and _context_mobile_detect_devices_types() drupal_static powered.
Comment #27
mgifford