Cookie value to hidden field -- local processing to avoid server page cache?

We have several forms on our site and want to pass UTM from page to page. We are using Handl Grabber to store the cookies but it seems the aggressive caching (Kinsta nginx) is not working (we get visitors presenting cookies from our testing, for example). We’ve turned off caching now for any pages with UTM cookies, but that’s not practical.

I see the gform_field_value_parameter_name method to populate a filed with a cookie, but will this work client side and avoid this caching problem?

I can do a simple script to inject the parameters into a query string in all HREFs (this almost serves the analytics team’s needs but falls short of their GA Goals needs) except it won’t work on the Submit button (hence my hope I can get a hidden field to populate on the client side).

Anyone with insights on this scenario?

Thanks much.

Hi Cala

If your need is to save and re-use entered field values from other forms, this new plugin (free) I wrote might help you.

1 Like

Hey, James. Thanks, this is interesting. Since our visitors are not logged in, and this happens in $_SESSION, that’s on the server side, yes? And so subject to page caching? (as you can tell, I’m pretty lost with what’s cached on the server side for anonymous users).

Correct that SESSSION data is stored server-side.

You can defeat page caching with the trick documented in the “About” page, under section “Note to Developers.”

If you don’t use the plugin, but do want to use the time_unix merge tag “trick,” I have an old post here that shows you how - LMK i’ll dig it up.

Cheers

I’ll read the note tomorrow and see if I get it :slight_smile:

Thanks!

Hey, again. It looks like the cache-busting requires the addition of the time param (date={time_unix}) added to the overall string, and that forces $_SESSION to effectively re-run. Is this correct?

Hi Cala,

I want to be careful to accurate, as I could be confused about what you are doing.

The added query string param pair (date=value) on the URL simply causes the web server to NOT return a cached copy of that URL request.

So, for the use case of an URL request, it’s seen as new and unique by the server, and it will perform a full and fresh rendering and not use its cache copy of the URL.

I hope I’m answering your actual question, if not, you can try to restate your case with more details.

Cheers

I think that clarifies it. In your plugin, our inbound links might look like:

https://mysite.com/?utm_source=mailchimp-email&date={time_unix}

and that triggers the fresh render of the hidden field for our cookie value, which we then pass along in the Gravity Form (and possibly also to the Confirmation page URL through GF’s add query string function.

This should be easy for you to mock text by manually constructing the URL.

If you don’t wish to install the MFSFS plugin, the code for adding the merge tag support for unix time into your functions file is very small. (just search for my posts, and you should find it easy).

Cheers and GL !

1 Like

cool, thanks so much for your help.

1 Like

Hi Cala, if everything else is working and you just want to bust the cache for this form, try this plugin:


We (Gravity Wiz) have published an alternate solution to this here that allows you to just exclude the form from the page cache without disabling the entire page cache. With that said, Fresh Forms is still the preferred solution if performance is not an issue.

2 Likes