Table of Contents
Content Error or Suggest an Edit
This article was generated due to a Facebook post about Gravity Forms Stripe integration not functioning due to Nginx/OLS Cache.
I’ve found that for Gravity Forms + Stripe credit card processing forms to work right I need to exclude that page from Redis caching following these instructions: https://gridpane.com/kb/exclude-a-page-from-server-caching/
But I sometimes forget! And then the form often spins and spins on submission and clients and customers are unhappy.
Does anyone have any suggestions for how to streamline this process? Some kind of code that says, IF there a GF form on this page with Stripe fields THEN automatically block from caching would be amazing.
Nginx and OLS offer full-page caching, Nginx has FastCGI and SRC Redis while Openlitespeed/Litespeed has it’s own built-in server cache. All of these options are great for static content that never changes, but when you change content, or there is dynamic content, then you will have issues, hence why Nginx Helper and LSCache WordPress plugins exist.
These helper plugins assist the cache to work properly with WordPress and any associated plugins by clearing the cache on specific actions or not caching specific pages that are dynamic or even parts of a specific page using ESI (Litespeed Paid Only).
The only problem is that Nginx Helper doesn’t cover a wide variety of WordPress core or common plugin situations. Litespeed’s LSCache covers more, but not all as there are new plugins every day, and the Litespeed team is slow to update the LSCache plugin. So in both situations, you need to add excludes manually through each plugin, or write specific code to exclude pages based on a specific scenario.
I am biased and suggest using Openlitespeed or Litespeed (Paid) and the LSCache plugin since it already has a good foundation for many scenarios covered already. Versus Nginx with the Nginx Helper, which has the basic WordPress core functionality covered.
But that’s only half of the solution. As you still need custom code to address Gravity Forms and it’s Stripe Integration for example.
GravityWiz has created code that uses Ajax requests for forms; there are two ways to enable it, and both are detailed in this article.
One solution for this is to simply exclude those pages from the cache, but you lose the benefits of page caching. A better solution is to only bypass the cache for the form itself, and we cooked up a Cache Buster plugin to do just that.
It loads the form via AJAX (not to be confused with submitting the form via AJAX), bypassing the WordPress cache for the form only. This allows the page cache, and the performance boost that goes with it, to remain intact.
First, you must add the following code to a mu-plugin within your WordPress plugin.
There are two implementation options to deploy the cache bustercode.
[gravityforms id="123" cachebuster="1"]
The following hook/filter will enable the cache buster on all forms on the specific WordPress site.
add_filter( 'gfcb_enable_cache_buster', '__return_true' );
The only issue with the above is that single upload forms don’t function since they don’t use Ajax, but multiple upload forms will function as they will use Ajax.
The following is an example of how you can use the Server Headers in Nginx (also possible with OLS/LS) to bypass the cache where there are specific shortcodes. Download the code into mu-plugins and then all your forms that use the Gravity Forms or Stripe shortcode will be excluded from the cache.
Note: This specific code will use the headers for Nginx not OLS. For OLS you have to use the following header which I haven’t tested but it’s documented for Litespeed.