Contexts in WordPress – an Introduction
When working with contexts in WordPress, you sometimes get into a dilemma of how to query some information from the WordPress database correctly. You can often answer simple questions like: How do you query the post title? It’s easy when you are currently on the Single Post page. If you are in Elementor, you would very easily use the dynamic tag called Post Title. If you are in Bricks Builder, you would use the Dynamic Data macro called post_title.
Now, why does it matter where you are within WordPress if you are to query something as simple as a post title, and why can’t you just put the same dynamic data tag on an Archive page and have it return a correct value? The answer lies in the ‘WordPress Context’.
In this article, I will be demonstrating visually (by the use of images) the role of WordPress Contexts when working with Page Builders. Although the principles are virtually the same across most Page Builders, I will show most examples using both Bricks Builder and Elementor. To explain some use cases, I will make use of the Jet Engine plugin, as it is a great tool for querying WordPress data in a low-code way.
How Dynamic Data Tags Work with Contexts
Dynamic Data Tags are simple placeholders for some dynamic content stored in the WordPress database. However, they don’t just fetch content blindly. Realistically, the dynamic data tags ask questions that the user cannot see, but they have to answer. Let’s go back to our post_title example.
Clearly, the screenshot shows a template that will apply to each article published on the website. The dynamic data tag post_title would ask the question “Which post title should I show?” and the answer will be “Show the post title of the current context”.
Note that this works in Bricks Builder just as it works in Elementor. In Elementor, however, you would be using the dynamic tag “Post Title” inside the single post template.
What exactly is “Current Context” then?
The “Current Context” can be global, post-specific, user-specific, or even query-specific. Hold on, what does that even mean? It means that depending on either the page you are on, or the query that produced the page, or the loop within which a dynamic data tag is used, the Current Context of post_title, for example, can mean the post title of the blog post you are viewing, or the post titles of each loop item within the blog post, or even the post title of another related post that you queried by its ID. If that seems confusing, don’t worry, I will explain further.
Just so you know, Loop is the same thing as “Listing Grid” in Jet Engine, “Query Loop” in Bricks Builder, or “Loop Grid” in Elementor. They all act the same way. So, for simplicity, I will refer to any such listings as a “Loop”.
Let’s see a simple example of when the same dynamic data tag is used multiple times on the same page, and it outputs data differently depending on the ‘Current Context’.
As you can see in the screenshot, post_title outputs the post title of the single post page normally. But when it is used inside a loop, the “current context” changes by default and outputs the post title of the current loop item, and not the current post page anymore.
I created the post loop items using the Jet Engine Listing Grid feature. Here’s how it is set up with Dynamic Tags within the Elementor Page Builder:
In Bricks Builder, you would achieve the same thing using a Query Loop or Jet Engine Listing Grid, and making use of the post_title dynamic data tag within the loop. The effect is essentially the same.
Now that you understand how Current Context works, it’s time to discuss the type of contexts in WordPress. Understanding the following can help you make huge decisions regarding the structural layout of your dynamic content, and can assist you in handling the most complex of queries.
Types of Contexts in WordPress and Use Cases
If you want to display dynamic data correctly, you need to understand the type of context you are dealing with. I spend a lot of time assisting WordPress developers to get better at working with dynamic data, and one thing always stands out to me: the confusion arising from not knowing the type of context is the biggest reason why WordPress developers run into query problems.
Once you understand context types, it will be clear to you when to do what, if you need a certain type of data from your WordPress database.
The types listed here do not make up a complete list. Because plugins such as Jet Engine define their own contexts, it is difficult to cover all cases. The list below covers most cases.
The Global Context in WordPress
Some data in your WordPress database are accessible site-wide. It does not matter whether you are on a 404 page, in a loop item, a post single page, or even an archive page, the dynamic data tag that outputs such data does the same thing everywhere!
If you are paying attention, you will notice that this description fits what WordPress developers know as Options Pages. However, let me be clear: Even though the data in the options page(s) can be fetched from literally anywhere on the WordPress site, this does not mean that only data found in the options pages can be queried from anywhere. Other kinds of data such as the WordPress navigation menu, and Theme Settings also fit this description.
Example use case of the Global Context
The big question determining whether you would make use of a Global Context option would be this: What will be its content?
As explained, data retrieved from a global context such as an Options Page can be accessed on any page on the website. So, you would use this when you are confident that the content rarely changes, or would mostly be the same everywhere. Since this context is not page-specific, you do not need to worry about where it is used. What you need to worry about is what is contained in it.
See the following screenshot of the website’s footer and how data from the Options Page in the global context is used here.
Ensure that you use this context type when you are absolutely sure that the content in it does not change or very rarely changes. If content in it changes often depending on the page it appears, you are using the wrong context type and should consider changing it to simplify your workflow.
Post-Specific Context in WordPress
At times, you want the data that you output in the front end to change depending on the current post being viewed.
Post here refers to a Page, News Article, Blog Post, Product, or whatever else fits the description of a Custom Post Type.
Since the data needs to change on a post-by-post basis, the context of the dynamic tag fetching its content is post-specific. As such, data fetched from such a dynamic tag cannot be accessed from any other page unless the context on that page or its element is changed. We will delve more into manipulating WordPress contexts later in this article. For now, let’s take a look at examples of this context.
Example use case of the Post-Specific Context
To determine whether a dynamic data tag uses the post-specific context, you just need to ask yourself “Will viewing a different post change the content that is rendered by this tag?”. If the answer is yes, then it’s most likely a post-specific context tag.
Imagine that you have an Events Custom Post Type. Each event would have a Start Date. You can create a date- meta field and assign it to the Post Type, Event. Now, you can edit the single event post template, and use a dynamic data tag to fetch the meta field value of that event post.
When the page loads, the dynamic data tag of date- only looks within the current context (not globally!) – that is, the current post – to see if some value exists.
As you can see, you would want to use this context when the data in it changes per post. The Event date in this case would not remain the same when a different post is selected.
User-Specific Context in WordPress
This context relates to the current logged-in user’s data or other user-related data. You may want to show the username of the current logged-in user, for example. What will this mean for your dynamic data tag? No matter where you use it, the data returned in the tag will depend on one question: Who is currently logged in?
Now, that means that the same dynamic data tag can query different results. It all depends on which user is logged in, currently.
It is crucial to use this context when you want to show data that is both personalized to each user, and unavailable to regular site visitors.
Example use case of the User-Specific context
In the following screenshot, I implemented the use of this context type when I built a web application for folks in the beautiful city of Detroit.
Here, the wp_user_display_name dynamic data tag was used to return the name of the current logged-in user. This simply means that if the same page is viewed by a site visitor who is logged out, this dynamic data tag will return nothing (assuming you did not set any fallback value).
Let’s look at the Query Builder of Jet Engine and see how this context type can be used in querying only posts of the current logged-in user.
This is a typical example of using the user-specific context within a query to populate content in the front end as shown in the image above. Although the context in this case becomes query-specific, the data used within it is user-specific.
Jet Engine has a more indepth overview of this query type in their article, Query Builder Posts Query Type.
We will learn more about query-specific contexts, now.
Query-Specific Context in WordPress
This is where things start to get complicated. And the reason is this: there are so many ways of querying things in WordPress. And depending on the query, what the dynamic data tags or shortcode output in the front end may differ from page to page, remain the same, or change as a response to a user’s feedback (a good example of this would be “filters” used to sort or change a query on a page).
However, I will try to simplify this, by using Jet Engine’s visual shortcode builder to explain this clearly.
Most plugins that assist you in creating Post Types, Meta Boxes, and Options Pages have functionalities that enable you to fetch data from the different content types. Please see their documentation for more information.
Example use case of the Query-Specific context
Imagine that I want to return the Post ID of the queried context. That should be simple with the shortcode generator since I would just do this:
So, the question is: What will be queried? And the answer lies in where the shortcode is used, and what the context of the shortcode itself is. As I demonstrated at the beginning of this article in discussing the use of the post_title dynamic content tag, the same thing applies here. When used within a post loop, the Current ID will no longer be the ID of the page being viewed. It will be the ID of the “current context” or current loop item.
Pay attention to the “Context” option in the shortcode generator, and let’s see the options it presents and which ones are relevant to the query that the shortcode creates.
- Default Object would evidently refer to the “Current Context” of the query that the shortcode creates. So, we can expect the default behavior.
- Current User (global) in this case would not make any sense since the query of the shortcode has the “Post-specific” context. Think about it, when would we want to specify the “Current User” context? It is when we are querying something from the user-specific context such as the user ID. In that case, the query will return the ID of the logged-in user. It won’t matter if this shortcode is within a loop.
- Current User (for current scope) in this case would also not make any sense since the query is post-specific. If we were querying the “User ID” Object Field, and this is used, there are two possibilities here – It’s either the current logged-in user ID is queried, or the user ID of the loop item inside which the shortcode exists.
- Queried User in this case would also not make any sense since the query is post-specific. Again, if we were querying the “User ID” Object Field, and this is used, it will only get the user that was queried. For example, this is the context that would be used if a Jet Engine relations is set up and a post is related to multiple users. Querying the related users and using the shortcode in the listing would return the details of the queried user in each loop item or on the user page.
- Current Post Author is a user-specific context and does not directly relate to the “Post ID” object field. If it were used with the “User ID” Object Field, this context would return the ID of the Current Post Author. Note that the “Current Post Author” here can refer to the author of the post in the loop item or the post as in the case of a single post page.
- Default WordPress Object (for current page) will work to ignore any current context and look at the generated page. Remember the example of
post_titlequerying different things depending on where it is placed? If the context is changed to this, it won’t matter if the shortcode or the dynamic tag is within a loop item or elsewhere, it will always return the post title of the current page, ignoring its place inside a loop. - Parent Object looks one step above its current place and tries to get the Object Field from there. Assume that you had a loop within a loop. The one inside is the child. The one having another loop inside it? That is the parent. Placing the generated shortcode in the child and using this context will get the
post_idin this case of the parent loop, and not of the child. This helps in other situations too, but this use case explains it. - Current CCT Item Author works just like ‘Current Post Author’ except that it works for Custom Content Types, and not Custom Post Types.
As you can see, the context of the shortcode will always depend on what is queried in the Object Field. Both the Object Field being queried and the Context option selected have to belong to the same Context type or be related in some way, in order to work at all. This is why you can expect Current User Context to work if the Object Field being queried is “User ID”.
Archive-Specific Context in WordPress
This is the one people generally get wrong. And the reason for that is: Archive pages may not actually be real physical WordPress pages that a user can see and edit. Generally, when using Page Builders, the content of Archive pages is manipulated by using an Archive template assigned to that particular archive page.
Since archive pages are dynamically generated, almost all content in the template used for them has to be dynamic. But from where will the dynamic data tags fetch their data if these pages are not physical and editable? Well, technically, some are editable. Take the term taxonomy archive as an example. When you create a Taxonomy term such are a new Post Category, and view it in the front-end, you are essentially viewing an archive page generated with the use of the archive template.
Such things as archive_title, and archive_description are dynamic and can be found when you edit that particular term.
You should create a meta box with meta fields and assign that to the particular taxonomy, user, or other archive types when you need to add specific dynamic data to a particular archive type. However, if you need to add some dynamic data to an archive page that is not editable such as a Search Archive page, then you are better off using an Options Page for this.
Example use case of the Archive-Specific Context
On a taxonomy term page, you would expect to see all the posts belonging to a particular taxonomy term. Let’s focus, though, on the data from that particular term and displaying that on the generated Term Archive page.
In the screenshot, you can see that both the archive title and its description are fetched into the template because, in this context, that is really what matters and can be queried. Of course, if meta fields have been added to the term for which this archive page is generated, those meta field values can be queried here too either using a shortcode or using the dynamic data tag provided either by Elementor or Bricks.
But is it not true that on the archive page, you have regular posts belonging to that archive? How, then, do you ensure that when a dynamic data tag is used to fetch properties of a particular post, the correct value is returned?
The answer lies in the next and last item on this list.
Loop Context in WordPress
In describing “current context”, I touched the loop context of WordPress, and although I cannot cover all use cases where ‘loop context’ should be used, I can try to make it a lot less hard to understand. Anytime you think of a loop, just think of the content that will eventually appear on the page when you click on that loop item and load its single page.
Having a loop item based on a particular query changes the context within the loop to whatever data it queries.
To explain, assume that you are on an archive page of posts described above. The loop items there are all posts of a certain post type. But on the archive page, it will be impossible for post_title to give you any value if it’s just placed in the archive template without a loop. This is because post_title is not relevant to that archive term.
However, if you have a loop of posts and have that dynamic data tag within it, the result would be a fine query of the post title of each item in the loop because now the context has been changed and has become relevant to each item.
Example use case of Loop Context
On this ‘About Us’ page, I have a query of site users used to generate a loop. Within each loop item, I have the User Name, Profile Picture, and Description all fetched within each loop item.
It’s important to notice that an about page should have a post-specific context, so a way to get user-specific content such as the list of users on the site, will be to change the context with a loop context as demonstrated in the screenshot.
Although users are queried here as an example, note that the loop context can return basically any data based on its query and essentially adjust the context of all elements within it. Remember, each element can then adjust its value back to its parent or global context if necessary. Refer to ‘Query Specific Context’ above.
Best Practices for Managing Dynamic Data Across Contexts
Now that you understand how different contexts affect the display of dynamic data on any WordPress page, let’s talk about what you can do to manage your dynamic data across different contexts the right way.
Understand Contexts before creating them
Before deciding whether to create a meta field, an options page, a taxonomy, or even a Custom Post Type, think first about the context in which it will be used. Remember, the content of the dynamic data, and where it will be used is key! If it will repeat all over the site, you should be leaning towards a global context use case. If it will be used on a post-by-post basis, then you should be leaning towards a post-specific context use case.
Use reusable components
Wherever possible, use templates that appear in multiple places and use the same dynamic data tag to fetch their relevant data. For example, the same archive template used for one taxonomy term can be used for other taxonomy terms on the website. Using multiple templates partially defeats the purpose of using dynamic data tags in the first place. It was meant to help speed you up in case changes are made in the future. If you have to jump into multiple templates to fix dynamic data tag issues, then you are not using them correctly either.
Test across devices and user states
Depending on the number of various contexts in your website, you may want to test rigorously, as sometimes a shortcode or dynamic data tag may appear to be working, but may in fact be fetching what appears to be right in the correct context, and turns out not to be working. Test well.
Use conditional logic as a workaround
Many times, I have found that it is not always possible to just rely on a single dynamic data tag to return a needed value in a particular context. At times, I have found myself duplicating the element and showing or hiding each one depending on other contextual dynamic data tags. As a quick example, I would want to show a template to one kind of user and show a different template to another kind – all within one page.
Changing the context with a loop would work in this case, but would not be enough since the query does not determine what shows or hides. The dynamic conditions (conditional logic) come into play here.
Use conditional logic sparingly, and if possible, at a template level at all times. The more the dynamic conditions used within a page, the more the evaluations and the more the queries. This ultimately leads to a slower loading site in my experience. Object and Page caching help to a certain extent with this, but it’s better to avoid it whenever possible.
Conclusion
It is necessary to understand contexts in WordPress as a person cannot get better at developing dynamic web applications on WordPress without a thorough understanding of the concepts discussed here. Although simplistic examples were used in this article, more detailed use cases will be exposed in future articles, so keep an eye on the blog.
In the meantime, feel free to reach out if you have any questions or have a specific topic in mind that you hope to see in a future blog post.
Stay dynamic!