Root URL not excluded

  • Resolved 4g3ntg00dsp33d

    (@4g3ntg00dsp33d)


    2 weeks, 3 days ago

    We are currently on the free version of Super Page Cache, 5.3.2, running on WordPress 7.0.3.

    The website is multi-lingual and uses the Polylang plugin. The plugin is configured as following:

    • Detect browser language setting is enabled
    • The language is set from the directory name in pretty permalinks setting is enabled
    • The front page URL contains the language code instead of the page name or page ID setting is enabled
    • Hide URL language information for default language setting is disabled

    So if the the website’s root URL (domain.com) is requested, Polylang detects the browser language and redirects to a matching language (e.g. domain.com/fr) or the default language (e.g. domain.com/en) if no match is found. This setup is working perfectly.

    We set up Super Page Cache with default settings when the website went live. So far, so great.

    However, a few weeks in, we noticed that the root URL suddenly returned a 404. error page for anonymous visitors.
    We then added “/” in the Prevent the following URIs from being cached setting in the Super Page Cache plugin and purged the cache. Problem solved.

    However, today the root URL again returned a 404. We disabled Super Page Cache and the problem was solved. We then re-enabled the plugin and it is working again as intended.

    Current state:

    But of course we are very interested to see if we are overlooking anything, we stumbled onto a bug and / or if we can safely rely on Super Page cache in the future. Any insights or pointers are highly appreciated. Many thanks in advance!

Viewing 2 replies - 1 through 2 (of 2 total)
  • malexandric

    (@malexandric)

    2 weeks, 1 day ago

    Hi @4g3ntg00dsp33d,

    Thanks for the detailed report, this was genuinely useful.

    You did the right things. On your Polylang setup the root URL is always a redirect to a language folder, so it should never be cached, and excluding “/” was a sensible workaround.

    Version 5.3.2 had a group of related bugs that match what you saw, and all of them are fixed in 5.3.5. So upgrading to 5.3.5 was exactly the right move, and these specific paths are closed there and covered by regression tests. A few recommendations going forward:

    • Keep the “/” exclusion in place. It is harmless and adds an extra layer of safety for your language redirect.
    • Your uptime monitor is a good idea. One suggestion: also alert when the root URL returns a 200 status. The healthy response for your root URL is a redirect (301 or 302), so a 200 there means a cached page is being served instead of the language redirect, even if nothing looks broken at first glance.
    • In the unlikely case it happens again on 5.3.5, please capture the exact URL and the response headers (especially x-wp-spc-disk-cache, x-wp-cf-super-cache-disabled-reason, and cf-cache-status if you use Cloudflare) and let us know whether your site is connected to Cloudflare or using the disk cache only. That would let us pinpoint the layer immediately.

    Thanks again for the thorough write-up, and sorry for the trouble this caused.

    Thread Starter 4g3ntg00dsp33d

    (@4g3ntg00dsp33d)

    1 week, 5 days ago

    Many thanks for the swift return, confirmation and extra pointers. The support is much appreciated!

Viewing 2 replies - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.