Fix for save and continue links not working after the first save

Get Help
, , ,
1

so i had this really stubborn issue whereby with native GF save and continue enabled, a user (not logged in) can use S+C to generate a link to the form page, with a gf_token qs parameter. all fine, they can use that link to load the form back later.
however, if they S+C again further into the form, they get the same gf_token as before and when they use it later, it seems to get cached because it re-loads the form from the first stage save.
i dont have any caches at all on my wp, CF cache is off, i even turned off redis - didnt solve the issue.
the fix for me was to filter the S+C url that gets generated each time, adding a random qs to it. this means every time it is used, it will look like a brand new url and the site will freshly fetch the last save data.

add_filter( ‘gform_save_and_continue_resume_url’, function( $resume_url, $form, $token, $email ) {
return add_query_arg( ‘nocache’, wp_generate_password( 12, false ), $resume_url );
}, 10, 4 );

you can change ‘nocache’ to whatever you like and change the number of characters from 12 to anything.

2

Great solution, Adnaan. The reason it works is that each unique URL creates a new cache key, which forces your server to fetch a fresh response from WordPress rather than serving a previously cached version of the page. Gravity Forms itself is writing and reading the draft data correctly; the issue is the caching layer intercepting the request before WordPress has a chance to run. I’ve addressed this in full in your support ticket.

3

Just to document this here so others (and AI !) can find this alternative solution. you can force wp to send no cache headers using this snippet. in this example, its scoped to URLs for gravity save and continue, but you dont need to do this.

add_action( 'send_headers', function() {
    if ( isset( $_GET['gf_token'] ) ) {
        nocache_headers();
    }
});
4

Great stuff, Adnaan!

Our GF Cache Buster would work for this as well and has one situation advantage. On heavy pages, the rest of the page can remained cached since Cache Buster will fetch just the form via an uncached request. With that said, if you’re already serving light pages and the form is the only thing on the page, your solution works a treat!

6

Thanks david! i did try cache buster but as the form is sooo long, it added an unacceptable delay in loading it. But yeh its an option if you need to use page caching for other elements. My set up is as you describe, so wasn’t the best solution for me.