Thank you for joining us for Part 2 of this discussion on Toolset. If you missed our last blog post, catch up by taking a look at Part 1
What is the Toolset WordPress Plugin & Why Use It?
On a simple level, Toolset is a set of plugins that hook into WordPress’ native support for custom post types. Using it, site developers can build content and the surrounding logic for it that would have previously required a programmer to build.
Toolset is a very expansive tool, and the full scope of it will not be covered in this article. Instead, I will overview the basic mechanisms of it that could be used to build a scalable case study component since that is the example used in Part 1. Those mechanisms are:
Post Types
Taxonomies
Custom Fields
Content Templates
You will see as well, near the end, where drag-and-drop page builders still have their place in this solution and work alongside Toolset.
Post Types, Taxonomies, and Custom Fields
I bundled these together because it seems fruitless to have one without the others, and they are almost always used in combination.
Post Types
Post Types allow you to create a custom post type as well as determine the basic attributes that go along with a post type. If you are diving into this concept for the first time, think of the basic WordPress “post” in the backend of the CMS for publishing blogs. Out-of-the-box, “posts” are reserved for blog articles. Additional and custom post types can be created for anything, though, like case studies, movie reviews, events, testimonials – you name it.
You can also read more about custom post types in the official WordPress Codex.
Custom post types have traditionally required some programming knowledge in order to create, but with Toolset, a non-programmer can use a simple visual tool to achieve the same result.
In the image below you can see the basic graphical user interface (GUI) for creating a Case Study post type.
This image only shows the first few fields for setting up the custom post type, but the remaining options are fairly self-explanatory and Toolset has nice helper tips throughout the plugin to explain some of the more technical parts. The remaining options pertain to things like choosing if the post type should allow users to comment on it or not, if there should be a featured image or not, etc. Many of these things are pre-filled out, and it has been my experience that most of the time the default settings are exactly what is needed.
Once my new post type is created I now have this addition in my left rail admin menu of the WordPress back-end:
To add a new case study, I could simply click “Add New.” However, at this point adding a case study won’t be that spectacular since it is just an empty post type not uniquely set up for case studies yet.
In order to start that setup, we’ll start with configuring a basic taxonomy for the custom post type.
Taxonomies
Taxonomies add a layer of categorical organization to custom post types. In this case, adding a taxonomy will enable us to categorize our case studies.
For example, I can create a taxonomy called “Practice Areas” for the imaginary legal firm in our Part 1 example and after doing so, my post editor will now have a category box with my custom practice areas to choose from. As you can see, this is a very versatile law firm with a wide range of experience.
Now that we have a basic categorical taxonomy set up, we can go a level deeper and begin to build out the Case Study post type to hold very specific data that we want to communicate to visitors.
Custom Fields
Within Toolsets custom fields module, we can begin to structure the data for our Case Studies.
Custom fields can be almost anything you can imagine. Generally speaking, the custom fields you create for the custom post type should be information that is applicable to every piece of content within the type. For example, a few good examples for Case Studies might be:
Client
Date
Country
In order to create these fields within Toolset, there are several different types of fields to choose from.
In order to create these, I opted for these choices:
Client > Single Line Text field type
Date > Date field type
Country > Select field type
Once those fields have been created and added to the Case Study custom post type, those fields are now present when adding and publishing a new Case Study.
Quick Recap & Benchmark
We just made three large changes to our WordPress setup, so I think it is important to pause and review what exactly just happened.
So far we have created a custom post type for Case Studies. Then we added in a layer of categorization so that individual case studies can be appropriately labeled and organized. Finally, we added custom fields to our custom post type so that we can actually collect, log, and publish specific attributes and data that pertain to case studies.
From an architectural standpoint, these steps are large and significant. By creating custom fields to go with our post type, we’ve created hold tanks for specific data that are now able to be queried from the database. In other words, all of this data can feed into other functionality like site search and filterable facets.
Now that we’ve essentially created the back-end CMS components for creating, managing, and editing case studies, we need to address what they will look like on the front-end of the website for a person viewing them. This is where visual builders come back into the picture.
Content Templates
A custom post type without a template doesn’t do much for our website stylistically.
Depending on how the theme of your site is structured, it could be that custom post types inherit the layout of an ordinary post or blog article. Some fields like the featured image and the title might map over to those layouts well, but it is unlikely.
In a nutshell, publishing a custom post type without a content template will likely result in a bunch of un-styled text getting tossed onto a blank page. Yuck.
By using the Content Template module of Toolset, we can use a drag and drop editor like Visual Composer or Beaver Builder to structure how exactly we want the published front-end versions of our custom post type to look.
The flexibility of this setup is in the fact that we can now visually build a full content template using dynamic values based on the custom fields for our post type. Better yet, what would have previously required work to be done by both a front-end developer and a programmer, can now be done with a drag and drop editor and applied to our content in a modular and scalable way.
About Author
