An FAQ to address questions regarding the Contact Form 7 – Dynamic Text Extension plugin.
DTX provides the following built-in shortcodes for general access of post and user data:
CF7_get_custom_field to allow access to any meta data for any post or page.
CF7_get_current_var to access any post variable or metadata for the current post or page.
CF7_get_current_user to access to any user data for the current user.
This means that any logged-in user with the ability to edit contact forms (e.g., contributor+ access) had the potential to access or reveal sensitive data. If there are untrusted users with access, this can pose a security risk.
Chris Mavricos of Seven Spark and myself, Tessa Watkins of AuRise Creative, worked together to address this potential security risk and decided that disallowing access by default and giving site administrators the ability to allowlist keys was the best option.
Instructions for adding post meta keys to the allowlist are available here. You can also use the filter to programmatically allow specific keys.
Instructions for adding user data keys to the allowlist are available here. You can also use the filter to programmatically allow specific keys.
When you update, DTX will run a quick scan of your forms and determine if user intervention is required (that is, if you’ve used either the post meta or user data shortcodes).
If your intervention is required, a notice will be displayed to admins when logged into their admin panel:
If you do not see this alert after updating, you should be good to go. But if you want to double check, you can run the Form Scanner any time from the DTX settings page.
If you see this alert, it’s important to resolve the issue promptly as the built-in shortcodes will not function properly until you complete this process.
You’ll have 3 options:
Edit Settings will bring you to the DTX Settings Page. From here, you can add any keys you wish to allow access to manually, or you can allow all keys.
Scan & Resolve will bring you straight to the Form Scanner, which will detect any keys that are in use which need to be allow-listed, so you can review them, select those you want to allow access to, and easily add them to the allow list. This is recommended for most users.
More Information will bring you to our documentation page with detailed information about how to use the allowlists.
Correct! Version 4.0.0 still registers those form tags and handles them the same as dynamic_text and dynamic_hidden, so nothing should break. If it does break, please let me know as I’m not intending on breaking them anytime soon.
That should do the trick. My go-to tool for that kind of thing is the free WordPress plugin Better Search Replace. I would recommend making a backup of the database first. If you’re using any storage plugins like Flamingo, it would also be affected. If it breaks, then restore the backup.
Probably not for a very long time. I made the decision to change the form tag standards more out of my own preference for readability, especially when introducing the new tags bringing our total from just 2 to 13. The current active version statistics show that most websites are still using version 2.0 of this plugin, so I wouldn’t even consider removing them until at least 80-90% are using version 4+ to avoid breaking them.
Anything is possible, it’s more about whether it should. I would not make automatic updates that modifies content without affirmative consent and steps to ensure the user knows exactly what is going to happen. There are plugins that can do search-and-replace modifications already, like the free WordPress plugin Better Search Replace. If you do choose to do it manually, you don’t have to rush or do it all at once. Perhaps just start with using the new ones going forward when creating new forms and slowly update any older forms you have.
Yes! You can enable a cache compatibility mode for individual form tags. Check out the cache compatible documentation for more information like how to enable it, see examples, and read about it’s impact on performance.
As of version 4.0.0, the dynamic email and dynamic hidden form tags are compatible with the Contact Form 7 validator.
In earlier versions, if you’re using a mail tag for a dynamic text or hidden input in the “To:” field, you will get warnings from Contact Form 7. If you click the link provided by CF7 beside the error notice, it explains why: Invalid mailbox syntax is used. It’s just a warning, nothing is actually broken and you can safely ignore it so long as long as you are sure the tag you’ve created will always return a valid email address.
You can check out other configuration errors here.
You need a self-closing shortcode that returns that value. You can use one of the included shortcodes, a shortcode from a third party component like a plugin or theme, or write your own custom shortcode. As long as your shortcode is written properly and it returns a value that can be displayed in a text input or hidden input, you can use it. Remember that CF7 DTX is just the conduit for putting the value returned from your shortcode into the form field.
If you’ve written a custom shortcode or I gave you a code snippet to solve your unique support ticket, you do not want to edit the plugin files on your website. Whenever the plugin gets updated, it will overwrite any custom edits you made. There are a few locations I would recommend for placing your code snippets for DTX customizations.
Method 1: use a plugin
If you’re not super code-savvy, you can check out this free Code Snippets plugin. In that plugin, create a PHP snippet and set it’s location to only run on the site front-end (or everywhere, it won’t hurt). Copy and paste the snippet where it says “Snippet Content” and give it a descriptive title and optional description.
Method 1: use your theme
If you’re using a custom or child theme, you can certainly add your custom code there and it won’t get overwritten when this plugin is updated.
Method 3: create the dtx.php file
In version 4.1.0 of DTX, I introduced a feature that looks for a dtx.php file in three (3) locations:
1. the wp-content directory (e.g. file path C:\path\to\website\wp-content/dtx.php or URL example.com/wp-content/dtx.php)
2. the directory of your currently active theme (e.g. file path C:\path\to\website\wp-content/themes/my-theme/dtx.php or URL example.com/wp-content/themes/my-theme/dtx.php)
3. the parent directory of your current active theme (e.g. file path C:\path\to\website\wp-content/themes/parent-theme/dtx.php or URL example.com/wp-content/themes/parent-theme/dtx.php)
And calls them using include_once should they exist. Does nothing if they don’t. So you can create that file, modify it however you see fit, and upload it via FTP to be executed.
To speed up your custom shortcode creation, you’re welcome to call any of the functions defined in DTX’s shortcodes.php and utilities.php directly such as wpcf7dtx_post, wpcf7dtx_get_post_var, or wpcf7dtx_format_atts, that way you don’t have to always define functions for getting variables from things, you can just call the appropriate function and get right to it, outputting what you need your custom shortcode to output.
Please report bugs found in the source code of the Contact Form 7 – Dynamic Text Extension plugin through the Wordfence Intelligence Bug Bounty Program. This plugin is registered in that platform and I’ll receive those notifications.
Please report security bugs found in the source code of the Contact Form 7 – Dynamic Text Extension plugin through the Wordfence Intelligence Vulnerability Submission Form. This plugin is registered in that platform and I’ll receive those notifications.
Hi,
i have acf block with field location wich is in repeater and i want add this location to my contact form 7, How? Please help. Thanks!
igor
Hi Igor,
I’m just looping back since we solved this via Messenger chat, but posting the code here in case anyone else has the same question 🙂
—
You could also update the shortcode to take a taxonomy parameter so a single shortcode/function can handle any custom taxonomies you make
function au_get_custom_taxonomy_names($atts = array()) { // Get Post ID extract(shortcode_atts(array('post_id' => '', 'taxonomy' => 'locations'), array_change_key_case((array)$atts, CASE_LOWER))); $post_id = $post_id ? intval(sanitize_text_field(strval($post_id))) : ''; if (!$post_id || !is_numeric($post_id)) { global $post; if (isset($post)) { $post_id = $post->ID; // If the global $post object is set, get its ID } else { $post_id = get_the_ID(); // Otherwise get it from "the loop" } } if ($post_id) { $term_names = wp_get_object_terms( $post_id, // Get only the ones assigned to this post $taxonomy, // Or a custom taxonomy array('fields' => 'names') // Return an array of term names ); if (is_array($term_names) && count($term_names)) { // Return a string value for the text field input return esc_attr(implode(', ', $term_names)); } } return ''; } add_shortcode('au_get_custom_taxonomy_names', 'au_get_custom_taxonomy_names', 10, 1);And then for your locations taxonomy, the form tag is simply:
And the form tag for employment type is:
We’re experiencing conflicts with this extension and our caching plugin (WP Rocket). Is your plugin compatible with caching?
Thanks!
Hi Brent,
It depends on where the data is stored. If you’re using the `CF7_get_post_var` shortcode to get post or page variables, the value would be the same every time a user loads the page, so it’d be fine to cache. However, if you’re using the `CF7_GET` shortcode to pull values from the query string, a value you’d expect to be different every time a user loads the page, the users may experience conflicts with caching from possibly seeing other users’ values if caching is captured on page views to not working at all. Adding a frontend component to prevent caching conflicts has been something I’ve been considering in a future version of the plugin.
Hi Brent, I just wanted to let you know that cache compatibility was added in version 3.5!