Browser language detection stops homepage from being cached with W3 Total Cache

[mzwolenik]

Prerequisites

• This is not a usage question (Those should be directed to the community supported forum, unless this is a question about Polylang Pro in which case you should use the helpdesk).
• I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
• The issue still exists against the latest master branch of Polylang and the latest WordPress version.
• This bug happens with only Polylang plugin active
• This bug happens with a default WordPress theme active
• I can reproduce this bug consistently

Steps to reproduce the issue

1. Activate W3 Total Cache page caching
2. Activate Polylang browser language detection
3. Refresh homepage multiple times

Expected behavior and actual behavior

Default homepage never gets cached. All other pages are cached as expected. I've seen similar issue with WP Rocket but it's now closed. Is there any known workaround to keep homepage cached with browser detection activated?

[Chouby]

This is the expected behavior. Detecting the browser preferred language is done in PHP. Thus, this can't be done with a cached page. No workaround.

WP Rocket is explicitely compatible with Polylang and disables itself the cache for the home page for the first visit, allowing the Polylang code to be executed. At next visits, detected by the Polylang cookie, WP Rocket serves the cached page.

I have no idea if W3 Total Cache offers the same feature as WP Rocket. If it has, and this requests some work in Polylang, I am willing to do add the compatibility.

Tell me if you know.

[martin-braun]

Hey, @Chouby.

I think this is the wrong approach. Yes, PHP redirection is better than JS redirection, because it will not load the page twice. However, cache solutions like WPFC can load several pages before WP is able to even return one page without cache, when you have installed more than a couple of plugins.

So I think, detection of the browser language should not affect any caching systems and you should provide an option to use a pure JS version, that can be cached safely.

I made a little script that does that using a localStorage object, because I even defined PPL_COOKIE to be false, since I use language specific perm links.

The script will not support multiple dialects for each language and will only redirect for new users on the homepage. Maybe someone else can profit from this simplified solution. It would be great to get something like this into Polylang, but in respect of all possible situations:

/* Language redirection with cache support */
(function() {
  if(location.pathname === '/') {
    var lang = localStorage.getItem("lang");
    var avaiLangs = ["en", "de"];
    if(!lang) {
      var prefLangs = navigator.languages || [ navigator.language || window.navigator.userLanguage ];
      for(var i = 0; i < prefLangs.length; i++) {
        var prefLang = prefLangs[i].split('-')[0];
        for(var j = 0; j < avaiLangs.length; j++) {
          if(prefLang === avaiLangs[j]) {
            localStorage.setItem("lang", avaiLangs[j]);
            location.href = '/' + j ? avaiLangs[j] + '/' : '';
            return;
          }
        }
      }
      localStorage.setItem("lang", avaiLangs[0]);
    } else if(lang !== avaiLangs[0]) {
      for(var i = 0; i < avaiLangs.length; i++) {
        if(avaiLangs[i] === lang) {
           location.href = '/' + lang + '/';
        }
      }
    }
  }
  jQuery(document).ready(function( $ ) {
    $(".nav .lang-item a").on("click", function() {
      localStorage.setItem("lang", this.getAttribute("hreflang").split('-')[0]);
      return true;
    });
  });
})();

[KZeni]

As a W3 Total Cache user,

I would love to see "Detect browser language" be renamed to "Detect browser language (PHP Based)" which then doesn't cache the homepage in certain circumstances.

Meanwhile, it'd be great to see "Detect browser language (JavaScript Based)" added as an alternative where there's client-side JS that detects the visitor's browser language and then redirects accordingly. That would then never interrupt any server-side caching (while then keeping the server-side option for those that want that greater certainty of the redirect happening with the potential performance drawback from that not being seen as an issue & then having a much more performant option for the homepage's initial page load that is potentially not as reliable [while plenty fine for most.])

Otherwise, is there a way W3TC gets support for Polylang's server-side browser language detection hat doesn't force DONOTCACHE for the homepage? I have a site that went from 3s for content load & 5s full load to <1s content load and 2s full load by turning off that Polylang feature with W3TC & Cloudflare being used.

[chesio]

@KZeni I don't know what your server runs on, but in case it's Apache, you may perform language-based redirect entirely using server configuration, see: #450 (comment)

This is much faster than PHP-based redirects.

[KZeni]

@chesio I appreciate the follow-up & recommendation. I suppose my request still stands since I'm thinking it's ideal that a plugin could/should offer this without requiring a website owner/operator to implement custom code to get that functionality.

As it stands, there's one option that seems to effectively disable caching of the homepage for W3 Total Cache (and possibly others) while then seemingly not offering language detection on any other pages. Meanwhile, there's then a JS and .htaccess solution out there where it's fully server-side caching-friendly, but one has to manually implement the code (with possible need to actually modify that code to have it work properly.)

If work was put in to have a PHP-based solution... why not offer the JS and/or .htaccess solution as an alternative for those that might want caching on a plugin that currently has DONOTCACHE triggered on the homepage when the language detection is enabled? At that point, couldn't it happen on more than just the homepage...? I mean, the language switcher interface element is offered on more than just the homepage on sites so these could match that behavior on all URLs.

I'm wondering if the PHP-based solution was limited to the homepage as to not potentially remove caching from all pages of your website... but at that point, the homepage is commonly the most important page of the site that should ideally load as quickly as possible so that not being cached properly is definitely an issue (which one of these 2 other alternatives would avoid.)

I think this would be best served by being offered similar to the current problematic option (PHP-based & warn about caching, .htaccess-based and warn about potential recovery being needed & server compatibility, and then JS-based as the basic & generally friendly catch-all option) without needing custom code (a-la the current PHP-based option.)

[KZeni]

Btw, the idea that this topic was closed due to there being no workaround for the PHP implementation (per #294 (comment)) isn't ideal. I mean, there is still an active issue with W3TC and Polylang's browser detection implementation as it is now. At that point, the workaround would be to offer .htaccess and/or JS based solutions instead of / in addition to the PHP solution that experiences this problem with caching.

Even with WP Rocket's explicit code update to have the homepage not be cached on the first visit, the homepage should be made available through cache for optimal performance regardless of it being the first visit or not (generally, the first visit would be the time you'd least like it to load slower than ever.) I think the approach of this being PHP-based inherently has this flaw & there are 2 viable solutions out there to be considered that this plugin could offer to address it.