Does your WordPress website use a caching plugin that caches the HTML of a contact form created with Contact Form 7? This feature in Contact Form 7 – Dynamic Text Extension (DTX) makes your dynamic fields cache friendly!
You can set a field to be calculated after the page loads by setting the dtx_pageload attribute to any DTX form tag.
Many websites use caching plugins to optimize for performance. If your website caches the HTML of the form, then any dynamic form fields you have get their first calculated value cached alongside it. This becomes an issue if you’re using DTX to pull values that typically change depending on who is viewing the page or how they got there, like from a cookie or the current URL’s query string.
This is best for dynamic form fields that:
- gets the current URL (or a part)
- getting a value from the query string
- getting the referring URL (if set)
- gets a value from a cookie
- gets the current user’s info or meta data
- generates a unique identifier (GUID)
For dynamic fields that are site, theme, or page-specific, it’s perfectly safe to cache those values, so this feature is unnecessary for dynamic form fields that:
- getting the current page’s ID, title, slug, or featured image
- getting a page or post’s ID, title, slug, or featured image
- getting post meta for the current page
- getting the post’s assigned categories, tags, or other custom taxonomy
- getting site info
- getting theme modification values
Note: Enabling a dynamic field to be calculated after the page loads will add frontend JavaScript. Depending on the shortcode used as the dynamic value, an AJAX call to the server may be sent to be processed. The script is minified and loaded in the footer and is deferred, minimizing impact on site performance and the AJAX calls are called asynchronously to avoid being a render-blocking resource and minimizing main-thread work. The script itself can be safely cached too.
How to Use (with example)
If using the form tag generator, it’s as simple as checking the box!
Otherwise, you can simply add dtx_pageload to the form tag in the form editor. Check out the examples below.
Example
Let’s say you have a landing page for a product and you’re running a campaign where the URL sends UTM parameters. If you want a field to capture the value for the source, you might be using the built-in CF7_GET shortcode like this:
[dynamictext usource "CF7_GET key='utm_source'"]But perhaps your site is also using WP Rocket to boost performance by caching your web pages. Because it does not use fragment caching (neither does the free version of W3 Total Cache), it looks like DTX isn’t working because the field is always empty! While you could bypass the cached version by using nowprocket in the URL, that’s not a viable solution because you want the page to be cached.
So what we did with DTX is added an option to run on the frontend via JavaScript/AJAX. When the option is enabled for a single form field, you’ll see the dtx_pageload attribute in the form tag like this:
[dynamictext usource dtx_pageload "CF7_GET key='utm_source'"]What happens is that the cached page will continue to show a blank value (or whatever value that got cached), but then after the JavaScript file has run, it will then update the input field to show the correct value.
Best part? This is still compatible with any custom shortcode you use!
Note: obfuscated values inserted via JavaScript don’t appear to the user as intended. The functionality works and saves obfuscated in the database so emails, storage, and hidden fields are not affected. Only visible form fields that are intended to be read by humans are affected in that they show the obfuscated mumbo jumbo instead of the human-readable format.
Impact on Performance
Many website owners care about their website’s performance, whether it is to serve an optimized user experience or to rank highly in the search results or both. AuRise Creative cares about performance too, which is why this feature was added with performance in mind.
Previously, the workarounds included not using a caching plugin or excluding the page from being cached by your server or plugin (unless you had fragment caching). The only real solution is the one we’ve added—use JavaScript after the page has loaded.
Resource Request
For forms that have fields with cache compatibility enabled, a minified JavaScript file will be loaded in the footer. For those using WordPress 6.3 or higher, you’ll see it uses the defer strategy. Because of these choices, it will not impact your webpage’s Core Web Vitals. The script is considered non-critical and shouldn’t be render-blocking.
It’s also only loaded on pages that have a form field with caching compatibility enabled, so it won’t be loaded on every single page or for every single form.
About the AJAX Request
The AJAX request is only made when using custom shortcodes and some built-in shortcodes. Some built-in shortcodes can be determined client-side, so to avoid an unnecessary request to the server, it is completed in JavaScript.
Only a single AJAX request is sent from our script per page load, so even if you have multiple form fields with caching compatibility enabled, it will not send multiple requests. They are collected and then sent together in a single AJAX request. When an AJAX request is sent, it is sent asynchronously to avoid clogging up the main-thread tasks and affecting the Total Blocking Time (TBT) score.
Client-Side Shortcodes
See below for a list of the included shortcodes with DTX that do not send an AJAX request and are retrieved via JavaScript instead.
- CF7_GET for getting values from the URL query string
- CF7_referrer for getting the referring URL
- CF7_URL for getting the current URL or a part of it
- CF7_get_cookie for getting the value of a cookie
- CF7_guid for generating a globally unique identifier (GUID)
- CF7_get_current_var for getting the value from the current page or post
- CF7_get_post_var for getting the value from the current post object
File Size
The script itself is minified, small in size, and safe to cache! You can see it here.
