I've been messing with this project off and on for about six months. So for it's been a real problem solver, and I'm very thankful to be using it. But, there is one giant elephant in the room kind of issue that has not yet been addressed, the page cache.

I have a separate issue created that contains a fork of the project able to disable the page cache and serve the right version of the site to visitors. But, that isn't the same as working with page cache.

I'd like to start a dialog, and invite the cache developers, to discuss ways potentially new ways to cache pages. In this module's use case, we eventually will need a cached version of the default theme, and the mobile theme. Other modules may eventually need to cache even more versions of the page for other use cases.

Gentleman, let's make some magic happen.

Comments

lance.gliser’s picture

lance.gliser commented

Created a new issue in the drupal core to hopefully open us a way to have flexible page caching... someday. #1302982: Mobile Theme and Page Cache

robloach’s picture

robloach
he/him
commented

He'd have to either have a little JavaScript to trigger the switch, or have a Mobile|Desktop switch, or both.

SandraL’s picture

SandraL commented

I don't want to create a new issue for this, but it would be very helpful to have a mention of this on the main project page. You know, something nice and subtle, like "WARNING: This module does not work with caching turned on!" ;)

As most people develop sites with caching mostly turned off, then turn it on closer to release time, a bit of warning could save a lot of trouble later.

Lance, I'm going to give your code fork a try. Thanks.

nielsvm’s picture

nielsvm commented

Hi guys,

I think that the recent post of Crell regarding the WSCCI activities in core
might solve this problem in the future: http://groups.drupal.org/node/198538.

When Drupal would be running on Symfony's HttpKernel we could easily
declare a dispatcher that does the mobile detection and map a special
request controller to it. The cool thing here is that every controller could
implement the caching differently and therefore we could easily make a
distinction between mobile/notmobile and process the request based on that.

Niels