I'm using mobile tools and browsercap. Since we got lots of guest user boost seems to be a very efficient, simple yet fast method of caching. Boost caches static pages and redirects a user directly to the static file. This seems to be though a problem: Let's say a mobile user visits the site. Without cache he will be redirecty to the mobile Version of the site (ending in .mobi). With the cache enabled a user is directly forwarded to the static file, leaving out the possibility to do any PHP requests (checking if it's a browser) and redirecting the user to the mobile version.
Any idea on how to avoid/solve this problem
Comments
Comment #1
mikeytown2 CreditAttribution: mikeytown2 commentedrelated info
#629520: Cache by theme for mobile sites.
Comment #2
twom CreditAttribution: twom commentedHi,
Using BOOST and mobile tools will indeed not work for the redirection. For this you will need some switching that could be more client side (JS) or at apache level (maybe this can help: http://www.idelfuschini.it/apache-mobile-filter.html)
Let us know if you find a solution for this!
Tom
Comment #3
ifuschini CreditAttribution: ifuschini commentedHi Tom,
thank you to have suggested Apache Mobile Filter for solve mobile redirect problem. In this post I add some more info:
1) The correct URL of AMF project is http://www.idelfuschini.it/en/apache-mobile-filter-v2x.html
2) The AMF is an Open Source project.
3) The AMF is a suite of modules for Apache, below a little description:
4) from november 2009 is a module included in "Apache Module Registry" (http://modules.apache.org)
Comment #4
twom CreditAttribution: twom commentedGreat, thanks for this additional documentation!
Regards,
Tom
Comment #6
vikramy CreditAttribution: vikramy commentedHi,
This is also one of the solution.
http://www.projectronin.com/blog/?p=10
Comment #7
udvranto CreditAttribution: udvranto commentedSubscribing.
Comment #8
skolesnyk CreditAttribution: skolesnyk commentedCan you propose a solution for Nginx as a webserver instead of Apache?
Comment #9
thedavidmeister CreditAttribution: thedavidmeister commentedsince this is the first hit on google when you search "drupal boost mobile tools", i thought i'd drop a simple suggestion that you can "avoid" the problem by telling Boost not to statically cache your landing page. Users will be redirected when they hit your front page, but be served cached content everywhere else.
i just tested it, seems to be working sweet.
the solution is not perfect if a lot of your traffic is from referrals, but the alternatives suggested here have nothing to do with the Mobile Tools module or Boost, and they require a lot more tech savvy to implement/maintain. Especially the suggestion that requires maintaining .htaccess rules based on the current list of mobile phones on the market. There's no way that's future-proof.
Comment #10
skolesnyk CreditAttribution: skolesnyk commentedThanks, David, for simple yet effective solution.
Comment #11
DocMartin CreditAttribution: DocMartin commentedThanks to David for this solution
I've noticed that in SIte Information, can specify a home page for the mobile site: so maybe this would be worthwhile thing to do, again helping avoid the Boost issue; and may be able to make a better home page for mobile site users.
Comment #12
liminu CreditAttribution: liminu commentedIf i undestrand i can use mobile tools with the theme switch option based on url and boost only if the redirect is by apache and disabling it in mobile tools option?
Comment #13
thedavidmeister CreditAttribution: thedavidmeister commentedre: #12
short answer - I don't think mobile tool's redirect will work with any module that uses Drupal's "fast cache". The suggestion to use the apache redirect is a workaround as the redirect happens before Drupal is bootstrapped at all.
Comment #14
audster CreditAttribution: audster commentedsubscribing
Comment #15
gundarx CreditAttribution: gundarx commentedA little late but here's a Javascript solution we're using for http://goaskalice.columbia.edu/
This assumes that:
"Cache pages that contain URL Variables" is disabled
The upside is Boost can be active for all pages you'd like it on (necessary for a heavily-trafficked landing page) and the user is redirected to the same page they wanted to see (ex. http://goaskalice.columbia.edu/fun-stuff goes straight to http://mobile.goaskalice.columbia.edu/fun-stuff)
Hope this helps someone out.
Jake
Comment #16
gundarx CreditAttribution: gundarx commentedTo add to the above, I have this included in page.tpl.php right under:
And before other CSS and Javascript files are loaded. This spares the user from loading those resources before they are redirected.
Jake
Comment #17
ifuschini CreditAttribution: ifuschini commentedGood news for use Apache Mobile Filter for mobile redirect, now is possible to use AMF with mod_rewrite so is more easy todo this job.
For more info:
http://wiki.apachemobilefilter.org/index.php/Mod_rewrite_integration
from last my post something change, now AMF got a site:
http://www.apachemobielfilter.org
and a dedicated wiki;
http://wiki.apachemobilefilter.org
Now AMF support several device repository like WURFL, DetectRight and 51Degrees
Comment #18
mrP CreditAttribution: mrP commentedSee #1475420: Document Apache Mobile Filter and Domain Access configuration for more information about Apache Mobile Filter configuration
Comment #19
thedavidmeister CreditAttribution: thedavidmeister commentedIn response to #17, one of my clients has purchased a "managed server" package with a hosting company that won't install Apache Mobile Filter because their staff has no prior experience with the software.
For various reasons (simplifying the question of accountability mostly) we want to run any changes to server software through the hosting provider, so we had to do something simpler in the .htaccess that would work with a more "vanilla" Apache installation.
We're actually using authcache + cacherouter + memcache for this particular setup, but the underlying issue is identical to the Boost problem - the cached pages are served before Mobile Tools has the chance to do any redirects with PHP (which is a good thing overall, really).
Also, the site in question is getting traffic too heavy for us to have the luxury of removing page caching from the front page (as per my earlier suggestion in #9) so we dropped this in our .htaccess for a "quick fix"
This should also work on most shared hosting environments, so I hope this helps somebody as I still see this thread as the top google hit for "boost mobile tools".
Obviously, if another major provider invents a new smart phone, the list of user agents will have to be updated accordingly, which is the main downside of this approach over the 3rd party Apache Mobile Filter solution.
Also, this is a pretty simplified set of conditions, for example it won't redirect desktop users back to the non-mobile site and mobile users will not be able to get away from the mobile domain even if they want to (so you might want to remove ipad from the user agent check, depending on your theme). Luckily these limitations weren't such a problem for us :)
Comment #20
captainpants CreditAttribution: captainpants commentedI did a little bit of a spinoff from the solution above because I currently use a multisite installation with specific redirect rules and this does the trick. This is in D6 by the way.
My requirements were that if a url alias exists in a list, then redirect to its mobile equivalent if you have a mobile device. If a mobile device hits a url alias that is not on this list, then just redirect to the mobile homepage.
Changes to .htaccess. (This chunk of code does at the bottom of the rewrite rules in the section where you decide whether or not to serve a cached page)
Note that this htaccess rule only works if you have a domain naming scheme of m.example.com
Code to put in preprocess_page
Using this method, a mobile device will not be served a cached page when it hits the desktop site which means that it will hit that chunk of code in preprocess_page and be redirected appropriately to mobile.
Comment #21
bitcookie CreditAttribution: bitcookie commentedWe successfully used boost with mobile tools using the m. domain method and javascript device detection/switching. Since you can set cookies at a top level domain the device preference can be saved in a cookie, allowing the mobile user to switch to the desktop site if they need to. This provides a great benefit over the .htaccess method, which would never let a mobile user switch to the desktop site.
Check out all the steps here: http://bitcookie.com/blog/integrating-drupal-7s-boost-and-mobile-tools
Maybe some clever lad will turn our code into an addon module for mobile tools ;)