No internet connection
  1. Home
  2. Support

Querystring cachebusting being stripped for all resources.

By David Meagor @dmeagor2019-11-25 16:25:59.419Z

We just tried to go live with a new version of our site and it was a dogs breakfast. When I investigated it seems that the ?v=123.456 cachebusting querystring values are being stripped from all wordpress/elementor resources completely breaking everything.

We have tried version 6.6.5 and the may alpha version with the same stripping.

Please advise, this is urgent for us.

  • 8 replies
  1. D
    David Meagor @dmeagor2019-11-26 18:34:46.097Z

    No worries.

    Remember that invalidating the GitHub/cloudflare/CDN cache does nothing for the end users who will just be using the old version until the expiry date. That's a lot of broken contact/registration forms for existing visitors!

    1. In reply todmeagor:
      Leon Stafford @leonstafford2019-11-25 19:56:46.566Z

      Hi David,

      Sorry to hear that, hope you were able to roll back easily!

      Looking to allow query strings to stay in for v7, but no quick fix for v6, sorry.

      Curious why this is causing an issue in your case, though, so happy to help debug.

      Cheers,

      Leon

      1. DDavid Meagor @dmeagor2019-11-26 14:43:17.737Z

        Hi, thanks for the quick response.

        Curious why this is causing an issue in your case, though, so happy to help debug.

        Surely this issue makes the plugin incompatible with most wordpress plugins, certainly Elementor and extensions?

        The only workaround I can see are:

        • set no-cache for all static resources. Huge seo no no and totally defeats the purpose of this plugin as a performance.
        • Remap the wp-content/wp-includes to versioned folders. Unfortunately this seems broken for us. The HTML links are correct but the folders simply do not exist in the zip.

        How come V6 cannot be fixed to keep the querystring?

        1. Leon Stafford @leonstafford2019-11-26 15:55:25.681Z

          Usually no issue with Elementor, so really need to have a look at what exactly is breaking for you.... Will need to see a site backup or access a dev server, then we can see what's up.

          1. DDavid Meagor @dmeagor2019-11-26 16:23:40.948Z

            This is not unique to our site, it's every site using ANY plugin, Elementor or otherwise that uses a ?v=xxx style cachebust rather than a filename one (which is a LOT.)

            Without this existing users with cached files will use the previous script or css versions with whatever bugs, security issues, display problems that causes.

            If you are seeing not seeing this or having this reported then it's because

            • The script/css file change is so minimal that it is unnoticeable.
            • You have developer tools enabled and have enabled the disable cache option.
            • Your static site does not have a proper expiry set for the static resources (i.e. its set to no-cache or 30 minutes or something.)
            • You hit hard refresh out rather then just visit the site (I've noticed devs to this often do this but users don't.)

            We didn't notice this ourselves until we changed the menu plugin used as elementor seems to handle the user css in some other way. Minor changes are generally hidden as they are small bug fixes etc. and the cached old version of the script will usually run the site ok.

            If you look at the elementor homepage and scroll to the bottom of their source you will see lots of ?v=1234 scripts.

            1. Leon Stafford @leonstafford2019-11-26 16:41:17.919Z

              Good point!

              There are various cache invalidations others must be using for this not to be such a reported issue (ie, CloudFront, CloudFlare, Netlify).

              We will be bringing back the option to preserve query strings (and likely ability to append own cachebuster ones during post-processing).

              Where are you hosting your static site now?

              May be some quick band-aid solutions to get you out of trouble...

              Cheers,

              Leon

      2. Progress
      3. D
        David Meagor @dmeagor2019-11-26 18:03:31.274Z

        Cloudflare etc don't take over cache busting, they only override your servers expiry headers, usually extending them. The default for cloudflare is to cache query string busted files in the same way as a browser.

        Cloudflare adds a second problem in that they have their own cache which will keep the stale files for the above specified time (unless you run the cache purge). When a user does a hard refresh they still get the old files!

        I think GitHub has a 1 month cache for static and HTML files. In that case the visitor would at least get the matching html and script versions so probably wouldn't notice but would not get the new content, bug/security fixes and any changes to backend form or json end points would break.

        I've set wp2static to rename the wpcontent and includes folders to include a v-123 path segment. A server rewrite rule then strips it out again so that it maps to the real folder in the zip.

        This sort of works as it invalidates the entire site on every change but it's obviously inefficient and prone to human error.

        1. Leon Stafford @leonstafford2019-11-26 18:07:15.277Zreplies todmeagor:

          Clever workaround!

          We don't have any CloudFlare API triggering manual cache invalidations. GitHub, I personally used the special empty commit message workaround to force GH Pages to invalidate. CloudFront is easy with their API call in the S3 add-on.

          I agree that query string cachebuster is the ideal and most simple. Thanks for bringing attention to this!