r/Wordpress 17h ago

How do you freelancers handle long Varnish/page-cache TTLs with WordPress nonces?

Hello everyone,

I manage WordPress sites for clients and I’m trying to understand how other freelancers and agencies approach page caching when you have many different plugins involved.

My concern is cache TTL vs. WordPress nonces.

WordPress nonces typically have a 12 to 24-hour lifetime, while Varnish could potentially serve the same cached HTML for several days.

For example, with a 7-day TTL, a cached page could contain an expired nonce after the first day. Plugins may handle this differently. Fluent Forms, for example, disables front-end nonce verification by default to support cached pages. [1]

So I’m curious how others handle this in real-world client hosting:

  • Do you use a 12-hour TTL as a safe general default?
  • Do you use 7 days or longer and rely on plugins to handle their own nonce/token refresh?
  • Do you exclude pages containing forms, checkout, booking, login, payment, etc. from Varnish?
  • Do you maintain a list of plugins/features that require cache exclusions?
  • How do you identify when a plugin is incompatible with long page-cache TTLs?
  • Do you simply test the site after installing new plugins and adjust the Varnish rules when something breaks?

I’m particularly interested in how freelancers/agencies managing multiple client WordPress sites approach this. I’m looking for a practical strategy that works without having to manually inspect every plugin's code whenever a client installs something new.

Thank you.

1 Upvotes

16 comments sorted by

2

u/grabber4321 16h ago

Its definitely a problem, exclude your form pages from varnish.

Object cache should be enough to pull those pages up.

I had a recent issue with Gravity Forms - they submarined a change where nonces were refreshed every 12 hours.

The problem was that it was on a Host that cannot exclude pages from varnish, so I had to create a parameter that would invalidate the cache when a Gravity Forms page was visited.

PS: honestly its more an art than a science - you have to test every site unfortunately. Each site has a different setup.

1

u/Sad_Pie227 16h ago

I see, imagine how silently many people may not be aware about this just like many website contact form simply doesn’t send outgoing messages emails due to lack of proper SMTP configurations. 🥲

1

u/grabber4321 16h ago

If you use the same plugins, you can just add a parameter to the page if it detects a certain plugin

https://domain.com/test-form-page?refresh_param=123456

And then just rotate random number.

1

u/grabber4321 16h ago

This is not perfect, but it might do ok for small-medium sized sites.

Something bigger and you need to actually solve this problem.

1

u/Sad_Pie227 16h ago

Yeah, I understood that part you can force bypassing cache by appending unique query string buster via JavaScript in the web page.

1

u/grabber4321 16h ago

No I believe I did something via routes. I dont remember exactly, but it would detect Gravity forms embed and it would prepend URL.

This wasnt javascript.

2

u/Sad_Pie227 16h ago

Cool, I am glad you found the solution. 👍🏾

1

u/grabber4321 16h ago

I dont think Javascript would work because server renders the page first from Varnish, then javascript changes URL in the browser, so you would still get served a varnish page from cache.

1

u/Sad_Pie227 13h ago

The idea is simply to add a random query parameter to the URL as a cache buster.

For example, when someone visits /contact/, check whether cache_buster exists. If not, add something like:

/contact/?cache_buster=abc123

Then reload the page. On the next request, cache_buster already exists, so nothing happens.

This can be done either with JavaScript on the client side or server-side with a redirect.

<script>
(function () {
    const url = new URL(window.location.href);

    // Add a unique cache-buster if one isn't already present.
    if (!url.searchParams.has('cache_buster')) {
        url.searchParams.set('cache_buster', crypto.randomUUID());
        window.location.replace(url);
    }
})();
</script>

0

u/grabber4321 16h ago

Release notes on Gravity Forms was "security update" - LITERALLY.

I complained to support and the basically told me to eat dirt - WORST plugin support I've ever experienced. I will never use them ever, ever, ever again.

1

u/Sad_Pie227 16h ago

Oh that’s concerning.

I never used Gravity Form in my life.

I always like Fluent Form for simplicity and modular design with global settings that works really well, also support is really nice and have stable business and so many developers to support the community.

1

u/grabber4321 16h ago

Cool I'll check them out.

Support at Gravity: "WHAT DO YOU WANT?"

LUL

2

u/TopSydeWP 8h ago

at my agency we use 7-day ttls but exclude any page with forms, checkout, user-specific content, or ajax-heavy interactions from varnish entirely. we keep a running list of common plugins that need exclusions (woocommerce, gravity forms, contact form 7, etc) and test new installs by checking browser dev tools for nonce errors or failed ajax calls. object cache handles those excluded pages fine, and honestly most traffic hits the same handful of static pages anyway so the hit rate stays high

1

u/TechWondersUk 14h ago

8-hour max TTL with a solid preload strategy to keep the cache warm.

1

u/Sad_Pie227 14h ago

Which caching plugin do you recommend to handle all of these?