Static vs. Dynamic Content in a CMS-setting
It will be useful to look at what we mean by static and dynamic Content. For starters, if the site doesn’t use a CMS, then the content is static because a developer will need to make changes when needed.
A static CMS-powered page is one that can be edited by someone without needing to “write code”. For example, in the page below we have a simple editing process:
However, in our definition, this is still a static page because the user has to directly change the content on the page.
Dynamic content in a CMS-setting is quite different however. There are three things to consider:
- Typically this content has already been created and is resident in the CMS-persistence layer (usually a database).
- The process and user interface for creating this content has nothing to do with the eventual page(s) on which it will be rendered
- We programmatically associate this content with the page
For eg. hypothetically, we might determine that we want the text for the section shown earlier, to come from a blog post that we created earlier. To do this, we would need a dynamic association between the blog post content and this particular section:
As shown below, the process and interface to create this blog post had nothing to do with where this content would show up eventually:
There is a level of “indirection” between content creation and content consumption. This makes dynamic content tough to comprehend and design for.
What then do we mean by “Data-Driven” Dynamic Content
“Data-driven” content pushes the idea of dynamic content further wherein we are concerned with modeling business entities into data models and defining relationships between these data models. That’s a lot of verbiage! So, let’s look at a concrete example.
Exemplifi is an enterprise website development firm. We build sites for clients and we typically partner with a design agency to accomplish this. The end result is a successful customer for which we have a case study on our website. This case study describes how the customer’s site was built, what CMS platform was used and how this was integrated into their marketing tech stack. Furthermore, we have website build solutions for different industries and want to highlight them along with case studies relevant to a particular industry.
To build a truly data-driven dynamic website, we had to model these relationships in a database schema and have that database power the entire site. The schema for the business looked something like this.
Implementing the Schema in WordPress
To implement this schema, we selected Pods (Link) — a plugin that enables custom content types and relationships between these entities.
An entity such as a case study has the following relationships:
- The client that we did it for
- The industry that the client operated in
- The CMS platform used to build the site
- The Design Partner that we collaborated with on the engagement
To see how these relationships are implemented in Pods, you can see below that the case study entity has relationships to the Client, Design Partner and CMS Platform entities:
When we drill down further into the “Platform” relationship, you will see that it is mapped to the CMS-Platforms table and the user will only be able to select from the values in that table.
In Part 2
In this post, we differentiated between “static” vs “dynamic” content. We then went beyond that and discussed what data-driven content really means. In the final section, we discussed how we implemented the database and relationships within WordPress.
In the next post, we will conclude by discussing how to build dynamic pages that build on this foundation. Specifically we will show how the “case study” module will behave truly dynamically. For example, on the healthcare industry page it will only show healthcare case studies. On the Drupal page it will only show Drupal case studies etc.