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

**URL:** <https://community.gravityforms.com/t/fix-for-save-and-continue-links-not-working-after-the-first-save/20264>\
**Category:** Get Help\
**Tags:** caching, nocache\_headers, save-and-continue, has-ticket\
**Created:** [May 13, 2026, 7:52pm UTC](https://community.gravityforms.com/t/fix-for-save-and-continue-links-not-working-after-the-first-save/20264 "2026-05-13T19:52:23Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![user5b13b577995466.6](https://avatars.discourse-cdn.com/v4/letter/u/c77e96/32.png) [@user5b13b577995466.6](https://community.gravityforms.com/u/user5b13b577995466.6)\
**Post date:** [May 13, 2026, 7:52pm UTC](https://community.gravityforms.com/t/fix-for-save-and-continue-links-not-working-after-the-first-save/20264/1 "2026-05-13T19:52:23Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jimtrue](https://sea2.discourse-cdn.com/flex020/user_avatar/community.gravityforms.com/jimtrue/32/1405_2.png) [@jimtrue](https://community.gravityforms.com/u/jimtrue)\
**Post date:** [May 14, 2026, 5:01pm UTC](https://community.gravityforms.com/t/fix-for-save-and-continue-links-not-working-after-the-first-save/20264/2 "2026-05-14T17:01:25Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![user5b13b577995466.6](https://avatars.discourse-cdn.com/v4/letter/u/c77e96/32.png) [@user5b13b577995466.6](https://community.gravityforms.com/u/user5b13b577995466.6)\
**Post date:** [May 14, 2026, 9:24pm UTC](https://community.gravityforms.com/t/fix-for-save-and-continue-links-not-working-after-the-first-save/20264/3 "2026-05-14T21:24:47Z")

</div>

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.

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

```

---

<div class="post-metadata">

**Author:** ![david](https://sea2.discourse-cdn.com/flex020/user_avatar/community.gravityforms.com/david/32/2517_2.png) [@david](https://community.gravityforms.com/u/david)\
**Post date:** [May 15, 2026, 10:21am UTC](https://community.gravityforms.com/t/fix-for-save-and-continue-links-not-working-after-the-first-save/20264/4 "2026-05-15T10:21:02Z")

</div>

Great stuff, Adnaan!

Our [GF Cache Buster](https://gravitywiz.com/cache-busting-with-gravity-forms/) 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!

---

<div class="post-metadata">

**Author:** ![user5b13b577995466.6](https://avatars.discourse-cdn.com/v4/letter/u/c77e96/32.png) [@user5b13b577995466.6](https://community.gravityforms.com/u/user5b13b577995466.6)\
**Post date:** [May 15, 2026, 4:11pm UTC](https://community.gravityforms.com/t/fix-for-save-and-continue-links-not-working-after-the-first-save/20264/6 "2026-05-15T16:11:08Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex020/uploads/gravityforms1/original/2X/f/fef63f0599c45e0218c30d9f5d7ca8bff9b00189.png) [@system](https://community.gravityforms.com/u/system)\
**Post date:** [June 14, 2026, 4:12pm UTC](https://community.gravityforms.com/t/fix-for-save-and-continue-links-not-working-after-the-first-save/20264/7 "2026-06-14T16:12:02Z")

</div>

Closed on June 14, 2026, 4:12pm UTC

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.