One of Elementor’s strong features is dynamic fields, which we can use to create dynamic pages and templates.
By “Dynamic fields” we mean fields that are not stably defined, but whose value changes depending on several variables:
- From the currently displayed article
- From categories
- From the currently logged in user
- From the current time
- From available metadata
- Now…
Each post, in the core of WordPress, contains not only basic data (title, content) but also auxiliary data, which we call “metadata”. These can sometimes be very important and helpful for our purposes. System metadata includes e.g. the author of the contribution, the date and time of creation of the contribution, the type of template used. Hierarchy of contribution. For categories, metadata can be e.g. category description, subordination/superordination relationship of categories to each other. Even users have metadata, which is e.g. the selected language, the user’s email, first and last name and various wordpress settings (such as the selected colour scheme). We can also use this metadata when working with dynamic fields.
In addition to the system metadata, we also have custom fields that we can easily add to posts, even natively. However, their use in practice has somehow not taken off due to their relative complexity. Much more often, metadata is added to posts using external plugins, most often Advanced custom fields, or CMB2. This is a much greater ability to set metadata for individual content types.
How to do it?
When you click on the icon, the available dynamic fields will pop up, sorted by category:
- Articles
- Archives
- Page
- Media
- Author
- Comments
Working with dynamic fields is a bit tricky, especially for someone who is not experienced. After selecting a specific dynamic field, we need to click on it again and make further settings.
By default, we have settings available that vary according to the specific field (e.g. in the case of an excerpt from a post, we can set the number of words to be displayed). The second item is “Advanced”, where we set the Before, After and Backup.
Before: sets the text or html to be displayed before the dynamic value itself.
After: sets the text or html to be displayed after the dynamic value itself.
Backup: sets the text/html to be displayed if the value of the field is not filled in for a given post.
The use in practice is frequent. For example. when selling garden houses we can set the area of the house in square meters. For each house, set the floor area as a number only. Then in the template, where the detail of the house will be displayed, we will use a list with icons. To Before we write <b>Floor area:</b> and to After we write m<sup>2</sup> (square metres). In Backup, type a dash that will be displayed if the floor area for the house is not filled in.
Types of dynamic fields
Article
Use this metadata when working with an article, page, or custom post type. The resulting values always refer to a specific article, regardless of whether we are in the article list (archive) or in the article detail (single). The key ID of the article by which the data is extracted from the database is considered to be the so-called. current query, which really just means that we get exactly what we currently want and don’t have to deal with anything extra
- Post custom field: with this field we can tighten any value attached to a specific article. We only need to know the name of the key under which the value we want is stored in the database. And it’s not so easy to find out. WordPress has several predefined keys, but other plugins and features can add their own keys
- Post date: Displays the date of the post. We can choose whether we are interested in the date of the contribution or the date of the last modification of the contribution. We can also set the format in PHP formatting of time and date. Of note is the “Human readable” value, which returns “44 minutes ago” or “A week ago”, etc., instead of a specific time and date.
- Post excerpt. We can set the number of words to display as well as whether to use the main content of the article or the “Summary” (which few people actually use)
- Post ID: Returns the Post ID of a specific article
- Post terms: returns the taxonomy of the post. That is, either the built-in categories/tags, or our own taxonomy if we use it for some reason. In the settings, we then set the separator (comma by default), and whether we want the individual terms to act as a link to the archive of the taxonomy.
- Post time: As with the date, only here it is the time
- Post title: returns the headline (title) of the article
Archive
We will use this metadata when working on archive templates.
- Archive description: returns the category description as is
- Archive meta: Returns the metadata for the given category. As in the case of articles, we need to know the key
- Archive title: returns the title of the archive. If we wanted to use the Post title from the article category at this point, we would see the title of the last article, even though we are on the archive subpage. Therefore, we must use this Archive title in the archive.
Page
Dynamic fields that arise from the page itself.
- Page Title: the title of the current subpage. Practically returns exactly the same as the Post title articles
- Site tagline: Slogan, can also be set in Settings -> General
- Site Title . What we enter when installing WordPress, or set in Settings -> General
- Current datetime: returns the current (server) time and date. We have the option to set the date and time format as usual
- Request parameter: returns the value of the parameter. *
- Shortcode: we can even add the result from the shortcode to the dynamic field. Very useful feature
- User info: The last dynamic field in this category allows us to add user information. We have a choice of basic data, such as. login name, real name, surname, email, etc. Or we can also call the metadata, but again we need to know the name of the desired key for our field.
* The request parameters issue is a bit more complex and only suitable for more advanced users. But it is very useful. There are 3 types of parameters available, namely GET, POST and QUERY. GET and POST are standard requests that are sent when a web page is loaded, respectively. subpages. The GET parameter is one that is clearly visible in the URL. A question mark, variable name, equals, and value are added to the end of the URL. It looks like this
https://priklad.sk/produkty?orderby=price
orderby in this case is the name of the variable and price is its value. From this particular address, we can determine that the value of the GET parameter orderby is price. These GET requests can also be chained using the & character.
https://priklad.sk/produkty/orderby=price&order=asc
In this example, we can see that the value of the orderby parameter is price and the value of the order parameter is asc. In reality, this occurs e.g. in Woocommerce, when we sort products by price from cheapest to most expensive.
The average user often encounters get parameters when clicking on links on Facebook or Google. FB then adds its advertising parameters there, starting with ?fbclid=xxxxxxxxxxxxxxxx. Google does a similar thing. Ads work based on that (and it’s very annoying when sharing). We can easily work with all these get parameters, we just need to figure out their name.
And what good is that in reality? For example, with booking buttons, we can redirect a person to the booking form so that they already have a pre-selected room for which they clicked the button. Or so that we can redirect bookings from multiple rooms to one form. The user on the page doesn’t need to know anything about it.
The POST parameters work similarly, but are not visible in the URL. Simply put – they are hanging in the air (they are part of the so-called headers when the client communicates with the server). They are sent e.g. when confirming the form (for the login form it would be stupid if our name and password were displayed in the URL after login). We can tell that there is a POST parameter by the fact that when we try to refresh, a warning window pops up asking us if we want to resend the same POST parameter.
Query var is a variable that is used to query the database. It carries all the information needed for WordPress to return exactly the post(s) we want at the moment. Using the Query var parameter, we can “hook into” this process and pull the information we currently need for our purposes. Here is a list of all the parameters we can extract from query var. But we can only use those that are marked as public.
Media
- Featured image data: Returns the illustration data we need. Not the image itself, but e.g. its name, description, URL, etc.
Author
- Author Info: Returns information about the author of the post. Basically, we can call up Bio, Email and Website here.
- Author Meta: We can select the metadata for the author of the article, but again we need to know the name of the key.
- Author name: Returns the name of the author of the post. The name that the user has set in their profile as the so-called. “display name”.
Comments
- Comments number: Returns the number of comments that are on the given article. We can also set the wording of the messages in case the article has no comments.
ACF field
This section will appear if you install the Advanced custom fields plugin. Through it, we select the custom fields that are filled in for the contribution. Elementor will even give us existing keys, from which we just choose what we want.
From practice
Elementor tries to help us and so fields that are not indicative of the Element type are cheekily filtered out, which is sometimes to the detriment. For example, if we add dynamic fields in the Caption element, it will never allow us to add an illustration image because the image in the caption cannot appear. And when we add a dynamic field in the image source, it won’t let us add an ACF field of type “text” because there has to be an image in the image and nothing else.
Sometimes this functionality is detrimental, because e.g. we need to publish a URL and we want one field to serve both as text and as a link (e.g. I will insert once https://google.com and I also want to put it on the web and I also want it to point to the link). But Elementor filters out the URL custom field so that it is not available in dynamic tags when text is set, but only when the link is set. And that’s a problem. In this case, we have to call the value using the key.
Setting keys when using ACF, or CMB2 and similar plugins is actually even easier, because we make up the name of the key ourselves (or let it be generated from the name of the field). However, we can read and use it in the settings of the field. It’s worse with other plugins, where we can’t figure out the name of these keys until we look at the code or the documentation (if there is any).
I recommend creating custom fields so that the field type that is most appropriate for the data is always used. I gave an example above with the floor area of the house. It is definitely a better solution to set this field as a number only and add m2 only at the level of the dynamic field on the front-end.
I have been programming websites since 2006. I have worked in several smaller and larger companies, always as a developer. I know how to program in PHP and lately I have been exclusively working on small and medium-sized projects in WordPress.
