WordPress.org

Ready to get started?Download WordPress

Forums

WPtouch Mobile Plugin
WPTouch + W3 Total Cache - must disable browser caching? (31 posts)

  1. MegaZone
    Member
    Posted 3 years ago #

    OK, I feel like I must be missing something obvious, but I've reached my frustration point. I'm bringing my blog back from a long hiatus, and to prepare for that I'm updating it with the latest and greatest. That includes upgrading to WP3.1.3, changing themes, replacing WP Super Cache with W3 Total Cache and installing WPTouch.

    It has been going fairly smoothly, except I'm having an issue with WPTouch which I think is tied to W3 Total Cache, but I'm not positive. I've searched for threads on working with these two and I found http://nimopress.com/pressed/blog-building-how-to-configure-w3-total-cache-to-work-with-wptouch-for-wordpress/ as well.

    I started off with a stock install of both, and things seemed to be OK. Testing from a Motorola Droid I'd see the WPTouch version of the site, and my desktop got the 'normal' version. But if I tried to use the On/Off toggle on the WPTouch page it'd just reload the page in the same version - and the toggle was the same. But if I follow a link the next page loads the 'correct' theme. So say I load the home page and get the WPTouch version, I hit the toggle and still see that. But then I follow a link to a post and see the 'desktop' version and the toggle is now 'Off'.

    So it looks like the request is making it to the server and being registered, but the browser is reloading the same page and only new pages are getting the change. But then those pages are 'stuck' on that theme. This does seem like a caching issue.

    Based on what I found in past threads I added this list to the Rejected User Agents on the three W3 Total Cache pages:
    acer\ s100
    android
    archos5
    bada
    blackberry9500
    blackberry9530
    blackberry9550
    blackberry\ 9800
    cupcake
    docomo\ ht\-03a
    dream
    googlebot-mobile
    htc\ hero
    htc\ magic
    htc_dream
    htc_magic
    incognito
    ipad
    iphone
    ipod
    kindle
    lg\-gw620
    liquid\ build
    maemo
    mot\-mb200
    mot\-mb300
    nexus\ one
    opera\ mini
    samsung\-s8000
    series60.*webkit
    series60/5\.0
    sonyericssone10
    sonyericssonu20
    sonyericssonx10
    t\-mobile\ mytouch\ 3g
    t\-mobile\ opal
    tattoo
    webmate
    webos
    240x320
    2\.0\ mmp
    \bppc\b
    alcatel
    amoi
    asus
    au\-mic
    audiovox
    avantgo
    benq
    bird
    blackberry
    blazer
    cdm
    cellphone
    danger
    ddipocket
    docomo
    dopod
    elaine/3\.0
    ericsson
    eudoraweb
    fly
    haier
    hiptop
    hp\.ipaq
    htc
    huawei
    i\-mobile
    iemobile
    j\-phone
    kddi
    konka
    kwc
    kyocera/wx310k
    lenovo
    lg
    lg/u990
    lge\ vx
    midp
    midp\-2\.0
    mmef20
    mmp
    mobilephone
    mot\-v
    motorola
    netfront
    newgen
    newt
    nintendo\ ds
    nintendo\ wii
    nitro
    nokia
    novarra
    o2
    openweb
    opera\ mobi
    opera\.mobi
    palm
    panasonic
    pantech
    pdxgw
    pg
    philips
    phone
    playstation\ portable
    portalmmm
    proxinet
    psp
    qtek
    sagem
    samsung
    sanyo
    sch
    sec
    sendo
    sgh
    sharp
    sharp\-tq\-gx10
    small
    smartphone
    softbank
    sonyericsson
    sph
    symbian
    symbian\ os
    symbianos
    toshiba
    treo
    ts21i\-10
    up\.browser
    up\.link
    uts
    vertu
    vodafone
    wap
    willcome
    windows\ ce
    windows\.ce
    winwap
    xda
    zte

    I deployed and cleared all of the cache, but it doesn't seem to have made any difference. If I deactivate W3 Total Cache, WPTouch seems to behave correctly. Doing more debugging I determined that the issue is browser caching. If I disable browser caching in W3 Total Cache then, even with it enabled in general, it seems that WPTouch works as expected.

    Before I spent too much time possibly re-inventing the wheel, I wanted to see if anyone else has W3 Total Cache working with WPTouch *with* browser caching enabled. If so, did you have to do anything special?

    The site is http://www.gizmolovers.com/ Ignore the style, I'm still working on re-customizing the theme since I just switched from an ancient custom template I'd been using. So it is pretty much stock 'twentyten' right now.

    Right now it is running *with* the Rejected User Agents list and with browser caching disabled. (I plan to test it without the list too, but I need a break.)

    Thanks.

  2. MegaZone
    Member
    Posted 3 years ago #

    I did a little more troubleshooting. I reset W3 Total Cache to defaults and tried testing with just browser caching disabled, without the Rejected User Agent list, but that seems to have the same problem. Restoring the Rejected User Agent list (as above) re-enabled the correct WPTouch behavior on my Droid.

    That's how I'm running right now - browser cache is off and the Rejected User Agent list is in place - but I'd really like to use browser caching if anyone has a working setup to share.

    I'm thinking about buying WPTouch Pro, but I'd rather know I can make it work well with W3 Total Cache before doing so.

    Thanks.

  3. MegaZone
    Member
    Posted 3 years ago #

    This still seems to be the situation in 0.9.2.2. I'd love to get browser caching enabled if anyone has any tips.

  4. derickschaefer
    Member
    Posted 3 years ago #

    Megazone,

    We just went through this with a customer's blog and finally got resolved by adding the following long list under Page Cache, Minify and CDN. There is hope on this one as we were a bit frustrated too. We are using Pro version of WPTouch. Good luck with it.

    iphone
    ipod
    ipad
    aspen
    incognito
    webmate
    android
    dream
    cupcake
    froyo
    blackberry9500
    blackberry9520
    blackberry9530
    blackberry9550
    blackberry 9800
    blackberry 9780
    webos
    s8000
    bada
    2.0 MMP
    240×320
    ASUS
    AU-MIC
    Alcatel
    Amoi
    Audiovox
    AvantGo
    BenQ
    Bird
    Blazer
    CDM
    Cellphone
    DDIPOCKET
    Danger
    DoCoMo
    Elaine/3.0
    Ericsson
    EudoraWeb
    Fly
    HP.iPAQ
    Haier
    Huawei
    IEMobile
    J-PHONE
    KDDI
    KONKA
    KWC
    KYOCERA/WX310K
    LG
    LG/U990
    Lenovo
    MIDP-2.0
    MMEF20
    MOT-V
    MobilePhone
    Motorola
    NEWGEN
    NetFront
    Newt
    Nintendo Wii
    Nitro
    Nokia
    Novarra
    O2
    Opera Mini
    Opera.Mobi
    PANTECH
    PDXGW
    PG
    PPC
    PT
    Palm
    Panasonic
    Philips
    Playstation Portable
    ProxiNet
    Proxinet
    Qtek
    SCH
    SEC
    SGH
    SHARP-TQ-GX10
    SPH
    Sagem
    Samsung
    Sanyo
    Sendo
    Sharp
    Small
    Smartphone
    SoftBank
    SonyEricsson
    Symbian
    Symbian OS
    SymbianOS
    TS21i-10
    Toshiba
    Treo
    UP.Browser
    UP.Link
    UTS
    Vertu
    WILLCOME
    WinWAP
    Windows CE
    Windows.CE
    Xda
    ZTE
    dopod
    hiptop
    htc
    i-mobile
    nokia
    portalmmm
    vodafone
    BlackBerry7100i
    Nokia6650d
    SAMSUNG-SGH-A737
    HTC_P3650
    HTC_HD2_T8585
    HTC-ST7377
    htc_touch_pro2_t7373
    HTC_Dream
    HTC-P4600
    HTC_Touch_Pro_T7272
    HTCP3300
    LG-CT810
    LGE-MX380
    BlackBerry9650
    BlackBerry9700
    BlackBerry9630
    BlackBerry9000
    BlackBerry8330
    BlackBerry8703e
    BlackBerry8820
    BlackBerry7100i
    BlackBerry7130e
    BlackBerry7250
    BlackBerry7230
    BlackBerry7730
    Cricket-A200
    MOT-COOL0
    MOT-V9mm
    MOT-L6
    MOT-V3r
    MOT-V3i
    MOT-A-1C
    MOT-V620
    MOT-V600
    MOT-E398
    mot-V3
    Samsung-SPHM800
    SAMSUNG-SGH-A867
    SonyEricssonW595
    SonyEricssonK800i
    POLARIS

  5. MegaZone
    Member
    Posted 3 years ago #

    I added a similar list (see my first post) to all three of those as well, but it seems like I still need to also disable browser caching to get rid of the page 'sticking' problem on mobile browsers. I need more time to play with this, but I suspect it is tied to the .htaccess rules added by enabling Browser Caching, and the headers they insert.

    I think a solution would be if WPTouch did something to alter the URL when toggling the theme (mobile/desktop) so that the browser would refetch the page instead of pulling it from cache. For example, adding '?wpt=mobile' when using the mobile theme, or something similar.

  6. derickschaefer
    Member
    Posted 3 years ago #

    Hmmmm. . .browser cache is a big part of the bennefit. Sucks to have to do that. Our re-writes are in NGINX so sharing ours with you wouldn't do you a lot of good.

    Ask WPTouch guys as I too agree that the solution likely is over there.

  7. MegaZone
    Member
    Posted 3 years ago #

    Yeah, if I find some time I may dive into the WPTouch code to see if I can add a query string when in mobile and see if that does work. But I'd love for the Brave New Code guys who chime in here. I'm probably going to buy WPTouch Pro, but I'd like to get this working first to know it can be solved.

  8. MegaZone
    Member
    Posted 3 years ago #

    The lack of responses makes me think there isn't a good existing resolution to this. Maybe I'll find some time to dive into WPTouch and see if I can fix it.

  9. MegaZone
    Member
    Posted 3 years ago #

    OK, I whipped something up *very* quickly as a proof-of-concept. It is quick & dirty. A small modification to wptouch.php in the bnc_filter_iphone function:

    if ( isset( $_GET['wptouch_redirect'] ) ) {
                                    $protocol = ($_SERVER['HTTPS'] == 'on') ? 'http\
    s://' : 'http://';
                                    $redirect_location = $protocol . $_SERVER['SERV\
    ER_NAME'] . $_GET['wptouch_redirect'];
                            }
    /* START NEW CODE */
                            if (strstr($redirect_location, "wptview")) {
                              $redirect_location = str_replace("&wptview=normal", "\
    ", $redirect_location);
                              $redirect_location = str_replace("?wptview=normal", "\
    ", $redirect_location);
                              $redirect_location = str_replace("&wptview=mobile", "\
    ", $redirect_location);
                              $redirect_location = str_replace("?wptview=mobile", "\
    ", $redirect_location);
                            }
                            if ($_GET['wptouch_view'] == 'normal') {
                              if (strstr($redirect_location, "?")) {
                                $redirect_location .= "&wptview=normal";
                              } else {
                                $redirect_location .= "?wptview=normal";
                              }
                            }
                            if ($_GET['wptouch_view'] == 'mobile') {
                              if (strstr($redirect_location, "?")) {
                                $redirect_location .= "&wptview=mobile";
                              } else {
                                $redirect_location .= "?wptview=mobile";
                              }
                            }
    /* END NEW CODE */
                            header( 'Location: ' . $redirect_location );
                            die;

    What it does is probably fairly obvious - it sticks a query string on the redirect when changing modes, with minimal checks for an existing query string. (It doesn't check for a fragment anchor, like I said, quick & dirty.) For simplicity's sake before setting the query value I strip out any existing ones, the most direct approach.

    As a proof-of-concept, this works. I can turn on all the browser caching bells & whistles - expires header, cache control, eTag, etc. - and toggle back and forth between themes without getting 'stuck'.

    There are obvious flaws - it is only concerned with changing that one page and the query strings are only on that first reload. When you first load the page, say it is mobile, it'll be the bare URL. Then you toggle to normal, it reloads with ?wptview=normal in the query string and looks fine. Then you follow a link to another page, that page will load with no query string and in normal mode. Now follow a link back to the first page, which will load with the bare URL - and you'll see the mobile version. Why? Because that's what the browser cached on that very first load.

    A possible solution to this would be to have WPTouch tag a query string on *every* link as the pages are served. Or at least when serving pages in the non-default mode. (If you default to 'mobile' then only add query strings when in 'normal' mode, and vice-versa.) Then bare URLs are default and query tagged URLs are the alternate.

    If not in the free version, perhaps in WPTouch Pro? Having WPTouch working fulling with caching would be a nice feature. I did this mainly to make sure my theory worked in practice. I'm not sure I'll have time soon to try to make extensive changes to WPTouch Pro. Frankly I'd rather just pay for a version with this working than do the work. ;-)

  10. Mr. Cui Bap
    Member
    Posted 3 years ago #

    I have to finished confog it... But speed download page only 56% ... When I use W3TC 0.9.1.3 , it speed 85% ..

    So boring.. Because it can work when check Auto : Minify mode ...

    Can you check here... I have creat Subdomain: Start.CuiBap.Org and Config CDN move CSS, Img, J.... ec

    http://www.cuibap.org/anh-dep/gallery-allbum/

    It link of Img changed to subdomain

  11. Frederick Townes
    Member
    Posted 3 years ago #

    Thanks everyone, so what's the consensus here on the recommended user agent groups and any feature conflicts in W3TC?

  12. MegaZone
    Member
    Posted 3 years ago #

    I'm currently using the UA group that I posed above, and the conflict with WPTouch seems to be Browser Caching. I haven't had any time to do more hacking since what I posted above, just been a busy week (business trip and then my folks were visiting). I did the hacks on WPTouch, but if there is a way to do URL re-writing in W3TC to force browsers to reload the pages when different themes are used (mobile vs. normal), or another way to solve the caching problem, that'd be great.

    For now I decided having mobile users sometimes get 'stuck' on one version of the page is the lesser of two evils, so I've turned on browser caching and I still have my quick & dirty WPT hack in place.

  13. Tropa
    Member
    Posted 3 years ago #

    Hello,

    megazone i have wptouch pro and i try to find the bnc_filter_iphone function in wptouch-pro.php but i can't find.

    You have already the pro version? Can you please check if is on the same file in pro version?

    Thank you

  14. MegaZone
    Member
    Posted 3 years ago #

    Tropa - Sorry, I'm still using the free version so the function may be different in the Pro version.

    I've actually upgraded WPTouch and I haven't reapplied my hacks to the update yet. I just haven't had time to work on it and I'm willing to live with the issue for now.

  15. Frederick Townes
    Member
    Posted 3 years ago #

    Can anyone help with the final word?

  16. MegaZone
    Member
    Posted 3 years ago #

    Frederick,

    I'd be happy to send you my current configuration for both W3 Total Cache and WPTouch. But even with that configuration there is still the issue of the browser caching causing the 'sticking' on mobile clients when toggling between the mobile and desktop themes in WPTouch. Adding some kind of query string to the URL seems to help, as in my proof of concept.

  17. Frederick Townes
    Member
    Posted 3 years ago #

    Giving it some thought.

  18. Frederick Townes
    Member
    Posted 3 years ago #

    You'll have to switch to anything other than disk enhanced mode and add some query string pattern in the reject URIs field on the page cache settings tab.

  19. two7s_clash
    Member
    Posted 2 years ago #

    @Frederick - can you say more? I don't see that screen. Plus, perhaps an example if you have a moment?

  20. wexler
    Member
    Posted 2 years ago #

    derickschaefer - thanks for the list of Rejected User Agents. I have applied to all three areas. Even with browser caching enabled, it seems to be working at least on desktop and mobile without swapping pages between the two. However, in order for all to work without hanging up, I've had to disable minify caching.

    Looking forward to added feedback by the community on these two plugins and compatibility. I realize that this is fairly complex.

  21. rasolis
    Member
    Posted 2 years ago #

    This issue is still happening Frederick. When going to view the site on my Android or Safari Dev User AGent iPhone; it renders the previous page. Once I refresh/reload the page, it renders the correct mobile format.

    It does the same thing the other way. When viewing on my Google Chrome and if I viewed it on my mobile on WPTouch PRO, it renders the WPTouch PRO page on my desktop browser. A simple reload fixes it to render the right page.

    Please advise. I can give you complete access.

    Email me at rasolis <at> readipress dot.com (formerly Webshoo.com).

    Thanks,
    Anthony

  22. funkster
    Member
    Posted 2 years ago #

    I noticed that the version of jQuery in WordPress is not up to date. You can try updating it by replacing /wp-includes/js/jquery/jquery.js with the updated version which you can download from here http://blog.jquery.com/2011/09/12/jquery-1-6-4-released/.

    This, coupled with the list of Rejected User Agents, seems to have cleared the issue for me.

  23. pythonskynet
    Member
    Posted 2 years ago #

    should we delete the lists on User Agents Group on W3 Total Cache settings page? I mean, there are 2 groups, High and Low, which contains the list of user agents group..

  24. BraveNewCode Inc.
    Member
    Plugin Author

    Posted 2 years ago #

    pythonskynet,

    You shouldn't need to remove those. You only need to add WPtouch's default mobile user agent list to the 'Rejected User Agents' area for the types of caching you have enabled - Page Cache/Minify/CDN.

  25. Graham Stoney
    Member
    Posted 2 years ago #

    I've noticed this problem too. It's particularly annoying for those of us without a plethora of mobile devices to test on, and it's way too complex for novices to get right first go. It would be great if this could be made to work correctly out of the box when W3 Total Cache and WP Touch are used together.

    Cheers,
    Graham

  26. Frederick Townes
    Member
    Posted 2 years ago #

    You can always disable the user agent groups completely.

  27. ndjworldnews
    Member
    Posted 2 years ago #

    Boy, a long post on a very irritating problem.

    Well MegaZone, I had the same issues you did and for a while had no mobile plugin. Then I reinstall WPTouch only to have the same strange problem again.

    Like you already did I too discovered that WPTouch and W3T aren't fully compatible, even though no errors exist.

    I did discover something else though.

    When I entered my list of Rejects (copied here, if that's ok?) and inserted them in only the page cache and the minify, my WPTouch works time and again without the need for hacks and with browser caching active.

    However, and this is a big one, I have CDN DISABLED!.

    When I enable that feature I am back to square one.

    So... since I seem to be having good speed thus far I've decided to forsake CDN for now and thus far WPTouch is working like a charm with browser cache enabled and the rejection agents list filled out.

    Hope that helps a bit?

    Lode

  28. Frederick Townes
    Member
    Posted 2 years ago #

    @ndjworldnews, can you submit a bug submission form from the support tab of the plugin?

  29. ndjworldnews
    Member
    Posted 2 years ago #

    Hello Frederick;

    Would love to but can't find a 'support' tab.

    Where should I be looking for that?

    Lode

  30. Frederick Townes
    Member
    Posted 2 years ago #

    In the performance menu.

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic