WordPress.org

Ready to get started?Download WordPress

Forums

[resolved] W3 Total Cache and WordPress Mobile Pack? (32 posts)

  1. RavanH
    Member
    Posted 4 years ago #

    Hi Frederick and others,

    Since W3 Total Cache and MobilePress are reported to be incompatible, and Wapple Architect is just too difficult for my limited synaptic firing abilities, I am trying to get WordPress Mobile Pack working with W3TC. The results are confusing...

    I am using http://ready.mobi and http://www.opera.com/mini/demo/ to see the results:

    1. Mobile Pack off, W3TC on - web theme, large images (as expected)
    2. Mobile Pack on (default config), W3TC off - mobile theme, small images (fast, good visual result)
    3. Mobile Pack on, W3TC on (all Mobile User Agents copied to the Rejected User Agents field)- web theme (?), small images (fast but weird visual result)

    EDIT: When both on, there seems to be some kind of combination of mobile and web theme being served: Partly adapted to small screen width and no theme background images but still (so it seems) the basic web theme layout. Looks like the mobile stylesheet is used in combination with the web theme source...

    Is there anyone with experience with these two plugins running together?

    Thanks for any tips :)

  2. Frederick Townes
    Member
    Posted 4 years ago #

    Make sure to use the same rejected user agents list in the minify settings tab if enabled.

  3. RavanH
    Member
    Posted 4 years ago #

    Make sure to use the same rejected user agents list in the minify settings tab if enabled.

    Thanks Frederick, that solved it! :)

  4. Frederick Townes
    Member
    Posted 4 years ago #

    You're welcome.

  5. jamesgpearce
    Member
    Posted 4 years ago #

    I'm glad it's solved... I will update the docs accordingly.

    (I am also working on a pro-active solution for SuperCache, and I'll try and make sure this works in the general case too)

    Thanks, all
    James

  6. Frederick Townes
    Member
    Posted 4 years ago #

    Ok.

  7. RavanH
    Member
    Posted 4 years ago #

    @ jamesgpearce

    did you succeed in making mobile pack compatible with super cache yet? if so, in which cache mode (half-on or on) can the two be used together ?

    thanks!

    EDIT:
    Oh, as I read mobile pack needs to be in /plugins/ when running on WPMU: can mobile pack be activated site-wide or is it better to do it per blog ?

  8. darelparker
    Member
    Posted 4 years ago #

    I'm also anxious to see mobile pack work with wp super cache. This would be a killer combination.

  9. Frederick Townes
    Member
    Posted 4 years ago #

    Darelparker, I'm not aware of the solution for WP Super Cache, I added that tag to this topic.

  10. Donncha O Caoimh
    Member
    Posted 4 years ago #

    fredericktownes - thanks, wp-super-cache supports wp-mobile-edition out of the box but not other mobile plugins.

    I'm thinking of adding a filter on the list of mobile user agents so mobile plugins can modify the list to suit the mobile devices the plugin supports. I haven't got around to that yet but it's a simple mod. Then it'll be up to mobile plugin authors to support wp-super-cache.

    I'd like to work with Frederick so w3-total-cache uses the same filter. Make it easier for mobile plugin authors to support our plugins!

  11. AndreaTrasatti
    Member
    Posted 4 years ago #

    I have just finished and committed to SVN an implementation of the new actions of WP Super Cache that make the mobile pack work nicely with it. Unfortunately it's still "just" the partial cache as Super Cache does not let me control how the local files are stored.

    See here the changes if interested: http://plugins.trac.wordpress.org/changeset/234095

    Next thing is make the Mobile Pack work with W3 Total Cache.

    For both WP Super Cache and W3 Total Cache, I think you can safely move to our detection approach as implemented in lite_detection.php as it is more up-to-date than Alex King's and we want to keep it updated.

  12. Donncha O Caoimh
    Member
    Posted 4 years ago #

    AndreaTrasatti - looks good but I think you'd have to make supercache use the "late init" feature where the cache is served and initialised on "init".

    I'm going to add a filter on the mobile user agents list today and I'll update this thread when I do. Users will only have to visit the Supercache admin page to be alerted about new mod_rewrite rules. I've held back on allowing the plugin auto update those rules because of the risk of overwriting local mods but I bet 99% of users use the stock rules.

  13. Donncha O Caoimh
    Member
    Posted 4 years ago #

    Just added a filter, "cached_mobile_browsers" so you can filter the list of mobile user agents. Unfortunately the user has to visit the Super Cache admin page for that filter to fire.

    I also added the function "update_cached_mobile_ua_list()" to do the same thing but it won't update the mod_rewrite rules (yet). You can call that from within your own plugin, of course after checking that it exists first!

    When W3-Total-Cache supports mobile users if it uses that filter and function too it should make it easier for mobile plugin authors!

  14. AndreaTrasatti
    Member
    Posted 4 years ago #

    Hi Donncha,
    these are very good changes, thank you. I will look into the code as soon as possible and start playing with them. When are you planning the next official release that will include these?

    Speaking of the function "update_cached_mobile_ua_list()", if you look at our lite_detection.php you will notice that we use a few methods to detect if a visitor is a mobile browser. Your approach, which is very valid and will catch most browsers, is still not as complete. I wonder if we can bring any consolidation here and make sure all plugins that want to do mobile can use the same code-base.

    I started a separate thread for W3 Total Cache and mobile integration and I will recommend some changes. Bringing the two caching plugins in line would make it easier for developers, of course.

    WRT "late init", I see a mention in your changelog, I'll have to look at it. My idea would be to make the cache store the mobile pages in a separate direcory (say hostname/mobile/path/pagename/index.html) and then add new rewrite rules to pick up the appropriate path. Of course as you say, changing those rewrite rules can be dangerous although 99% of users will likely use the stock rules. On the other hand, if you now allow plugins to modify the list of user-agents for mobile, then the rewrite rules should be modified accordingly.

    EDIT: Fixed a couple of typos

  15. Donncha O Caoimh
    Member
    Posted 4 years ago #

    Thanks Andrea, that lite_detection function looks comprehensive! I'll update my mobile detection script to follow those guidelines.

    Currently Supercache bypasses the supercached pages if it find a mobile user agent and uses the PHP powered caching instead as you've probably guessed. For 99% of sites this will be perfectly fine as there's hardly any difference in speed between both modes.

    I'm planning a new release soon, probably this week, especially as the preloading stuff is working well on my server.

  16. Donncha O Caoimh
    Member
    Posted 4 years ago #

    Andrea - is it worth having a separate cache key for each mobile useragent? That's what I do now so that an iPhone visitor gets shown a different cache file to a Nokia visitor.

    I'm going to add support and a filter on your UA prefix list too.

  17. Donncha O Caoimh
    Member
    Posted 4 years ago #

    I think I can check for the UA prefixes in the .htaccess too. I'll need to do some testing though.

  18. Donncha O Caoimh
    Member
    Posted 4 years ago #

    Just checked in support for mobile prefixes. I added a new filter, "cached_mobile_prefixes" and added a second parameter to the update_cached_mobile_ua_list() function for the prefixes. It's an optional parameter.

    It will display a "Rewrite rules must be updated" message on the admin page currently. I'll get around to doing an auto update later.

  19. AndreaTrasatti
    Member
    Posted 4 years ago #

    In general, if the mobile plugin is powerful enough and does per-device adaptation, you would need to use a cache key per device. My experience is that most plugins produce only 1 output. The most advanced like the Mobile Pack and Mobilepress have 2 or 3 presentations and all devices fall in one of those groups based on the features. My suggestion is that you do the same, i.e. define some groups for devices and use a key for those. This will reduce the cache replication and the produced pages will still be good enough.

    At this stage we have a separate file to manage device group detection, see group_detection.php, but we are thinking of bringing together these functions in the lite_detection and make it an integral part of the plugin (rather than the themes as it is now).

    The way I've done it now in the mobile pack I am completely overriding your detection (i.e. the admin will NOT turn on the mobile checkbox in the admin and the mobile pack plugins in automatically using your add_cacheaction()), so I am not sure if I need all these filters that you are adding. From my perspective, unless these filters let the other plugin affect how you cache the files, I do not need them, as I am happy to use my own detection. My view is that the detection should be in the mobile plugin and your cache plugin should offer a way to plugin (as you already do with add_cacheaction); anything that you do beyond that is a nice-to-have for plugins and themes that do not want to deal with detection (although IMHO they should!).

    Finally, about modifying the .htaccess, adding checks such as the presence of the UAProf header is very simple and yet will catch most mobile devices that respect the WAP 2 requirements (not iPhones and Androids, I'm afraid) and that is still the vast majority of the devices on the markets worldwide.

  20. AndreaTrasatti
    Member
    Posted 4 years ago #

    donncha - if you think you will add a function that would allow a plugin like WPMP to update the user-agents and prefixes (as you already do) and then force an update of the rewrite rules, I think that will be interesting for us to use.

    Either way, we would appreciate if you would refer to our plugin for the improvements you brought into Super Cache. We want to release a new version of out plugin to use the actions around the weekend as well, so your mention would be very welcome.

  21. Donncha O Caoimh
    Member
    Posted 4 years ago #

    Would you mind giving me example mod_rewrite code to check for the UAProf? This is the first I've heard of it.

    I'll add a group variable to the plugin, but leave it filterable so plugin authors can modify it. By default I'll put everything in the one group. I'd rather the plugin authors decide on the capabilities of their plugins rather than the caching plugin.

    Sure, I'll definitely be referring to your plugin in the next release. I appreciate all the help.

  22. AndreaTrasatti
    Member
    Posted 4 years ago #

    donncha the idea of one group and then letting plugin authors to manage them sounds great. Allowing them to "push up" the rules to Super Cache and then Super Cache to suggest the update in the rewrite would be the best.

    Here is an example of rewrite rules, I just tested it on my Apache 2 server:

    RewriteEngine On
        RewriteCond %{HTTP:X-Wap-Profile} ^[a-z0-9\"]+ [NC,OR]
        RewriteCond %{HTTP:Profile} ^[a-z0-9\"]+ [NC]
        RewriteRule .* http://example.com/mobile_user_see_here [R,L]

    I am sure you understand everything, but for the sake of clarity the two conditions check that the header "X-Wap-Profile" OR "Profile" are set. To be honest all you need to check is if the header is set, but since I could not find a better way I used what are meant the be the very first characters (from experience the most common is a proper URL, sometimes starts with a " other times just with the hostname).
    I am also setting the NC (nocase) in case of wacky starting HTTP strings. I've seen a few rare ones.

    For Apache 2.2 you might also add the NV flag, although I do not think it will ever make any difference.

  23. Donncha O Caoimh
    Member
    Posted 4 years ago #

    Thanks, those rules look easy to implement!

    Here's the groups changeset. I added the groups as a param to the update_cached_mobile_ua_list() function as well as adding an appropriate filter to modify them.

  24. Donncha O Caoimh
    Member
    Posted 4 years ago #

    And here's what you've been looking for.

    This changeset adds the function wpsc_update_htaccess() which will update the rewrite rules after you've called update_cached_mobile_ua_list() with the new browser, prefix and group list.

    It needs testing but works on ocaoimh.ie

  25. AndreaTrasatti
    Member
    Posted 4 years ago #

    I'll try and look at it tomorrow or Friday. Thank you.

  26. Donncha O Caoimh
    Member
    Posted 4 years ago #

    Just added the rewrite rules for the WAP and Profile checks.

    The plugin won't complain if they're not there but they'll be added as soon as someone clicks the "Update mod_rewrite rules" button. That'll be everyone who upgrades ...

  27. Duane Storey
    Member
    Posted 4 years ago #

    Hey guys,

    So what would be the requirements for someone trying to make this work. Would it be the following?

    1) Intercept cached_mobile_browsers & update_cached_mobile_ua_list and modify based on the user agents the plugin supports? Do these have to be complete UA strings, or will partial strings work as well?
    2) Call wpsc_update_htaccess() whenever these change in the admin panel?

    Is that basically it? Any gotchas to watch out for? Thanks, I'll try and update WPtouch today.

  28. Donncha O Caoimh
    Member
    Posted 4 years ago #

    1. The mobile_browsers are mostly complete strings, but it's not a requirement as the check is for .*string.* - it can be partial strings but be careful about matching desktop clients!
    2. Yup, that's basically it. You have to obviously check those functions exist first. Also, I just realised the wpsc_update_htaccess() function doesn't check if .htaccess is writeable. I'll have to add that.

    I also added support for UA prefixes. It'll match a 4 char prefix at the start of the user agent. Look for $wp_cache_mobile_prefixes in wp-cache.php

  29. Duane Storey
    Member
    Posted 4 years ago #

    1. Ok. We mostly check for partial, i.e. "iPhone" instead of the huge user agent string with mobile safari in it, that way it doesn't stop working when the mobile safari version number changes.

    2. Any chance calling wpsc_update_htaccess is going to bork anything, or are you pretty confident with it? If we don't call it, is there some kind of notification in WP Super Cache that the rewrite rules need to changed so they can do it there?

    Thanks.

  30. Donncha O Caoimh
    Member
    Posted 4 years ago #

    1. Yeah, I use "iphone" too. but the prefixes are even shorter and I presume match a lot more mobile mobile browsers. I'm just working off Andrea's code.

    2. It could break things. I only wrote it yesterday and it works on 2 blogs I tried it on but that's why I need people to test it and hammer on it!

    If you don't update the .htaccess there will be a warning in the Supercache admin page so the user will at least see that!

Topic Closed

This topic has been closed to new replies.

About this Topic