In mobile_tools.module there's a hook_exit function (which runs on every single page of the site, both cached and uncached) which is clearing all cache. As suggested by the 'fix me' comment, this has a massive performance hit.

What would it take to get this cleaned up? Why's it necessary? While this is here I'm not comfortable pushing this module to a production site. I'd love to help patch this, but don't understand enough to know where to begin.

/**
 * Implementation of hook_exit();
 */ 
function mobile_tools_exit() {
  // FIX ME: check what cases don't need this. Bad for performance
  cache_clear_all(NULL, 'cache_page', TRUE);
}

Comments

softrusher’s picture

softrusher commented

The cleanest way would be to redirect to a different subdomain for mobile pages. Since cache_page has the full domain and path as cid, mobile cache entries should then not conflict with non mobile entries.

Drawbacks: Cookie is not valid for subdomain, so user is logged out?, Subdomain has to be mapped to document-root, which is not possible for all users.

Changing the current get request and adding something like "mobile=true" could break other modules request handling and should not be done.

twom’s picture

twom commented

Hi,

I'll add soon the option to disable the removal of the cache, so people can start using subdomains.

I think it is possible for cookies to be shared accross subdomains (cookie domain = *.domain.com)

What kind of problems can occur with redirecting the request to '?mobile=true'

softrusher’s picture

softrusher commented

Perhaps some other module uses 'mobile' as one of its get parameters. Or what about modules that try to catch every possible parameter and try to do something sensible with the data? (I have written a module that makes use of both, keys and values, from the get parameters. So the words 'mobile' and 'true' would get used in a taxonomy search query...)

The session cookie set by drupal is not valid for subdomains. Mostly the user has to login anyway because if he is accessing the mobile site, he is using a diffent device and not his 'main' computer where the cookie is stored.

tom_o_t’s picture

tom_o_t commented

Hi Tom,

Check out how the themeswitcher module handles theme switching: http://drupal.org/project/switchtheme

It just makes use of the global $custom_theme - http://api.drupal.org/api/global/custom_theme/6 - Drupal's core way of overriding a theme.

Cheers!

Thomas

twom’s picture

twom commented

But I still see that happening in the hook_init(). What they do is setting a query parameter for each theme (theme)

By setting a query parameter when a new theme is selected, the hook_init() is being called again, so that's their solution. But then again, I don't see immediately how they maintain the themeswitch accross different pages

twom’s picture

twom commented

very funny discussion here: http://drupal.org/node/365266 about the problems that the theme switching module has
See comment 48

I don't see actually a solution there (except changing cache settings, removing cache...)

tom_o_t’s picture

tom_o_t commented

Re #5 the theme is maintained by storing it in the session, and then using the theme in the setting to set the global $custom_theme.

Re #6 I've not tested the dev release, but we have this module working fine on a couple of Sony sites, so I know that this theme switching module works. I think there's some other issues going on for the people that are having problems. Clearing/disabling cache is definitely not necessary.

I'm not going to have time to work on this anytime in January, but if you're interested then I could try and spend some time in February.

twom’s picture

twom commented

I've removed the clearing of the cache. Only where you have 1 url and want to switch theme based on device, the module clears cache.

If you have a mobile and desktop url, the clearing of the cache is not needed...

twom’s picture

twom commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.