Planning your Toolset project

So you’re building a CMS site and you have chosen the Toolset family as your main build tool. So far so good. If your project has a simple structure, then you may be able to just crack on and start building. If you have any complexity in your structure, then you probably need to sit down and plan your project first.

Key considerations

• What post types are we going to need?
• How will our post types be related?
• How will we classify our posts?
• What fields will each post need?
• How will we present the post data on our site?

So where do we start?

Toolset makes it easy to create our Custom posts, taxonomies and fields. But we often get a choice of approaches and selecting the wrong one at this stage can be costly. We get a lot of clients coming to us with an implementation that they have been working on for days, sometimes for weeks, only to find themselves stuck with a data structure that will not easily fulfill their site requirements.

Both the structure and the presentation of our data is going to be a big influence. So let’s do two things. Map out our Posts, and think about how the data is going to be displayed.

What are we going to build?

We are going to build and information portal for tourism in a specific coastal are.

We want to list, map and describe the following collections for our site visitors.

• Restaurants
• Beaches
• Sites of interest

Defining our post types

Straight away we are faced with some choices. Have we just described three custom posts types, or just one - let’s call it an ‘Area listing’?

Let’s look at the data for each of the listing types we have described.

At a glance we can see that the data for each of our Listing types is quite different. There are fields which are common to each type, but if we did decide to use a single ‘Area listing’ post for all three, then we are going to have to use a lot of rules on our site to display them as we want. So we will want to define a custom post for each Listing type.

Custom fields and taxonomies

Now we can start to look at individual fields. WordPress posts come with set of core fields for each post, such as Title, Description (body), Featured image. We can also create taxonomies to classify our posts, and then we are left with the custom fields we are going to need to create using Toolset Types.

Choosing taxonomies

Taxonomies are ideal when you want to classify your data with one or more term. So for example, our Food style could be Modern, Vegetarian and Asian for a single restaurant. Now we could use a custom checkboxes group for these values in our Restaurant Post. So how do we decide.

Archive pages

Taxonomies are going to give us archive pages automatically, this is just a feature of Wordpress. So in our restaurant example, we will have pages for each of our Food styles which automatically list all of the Restaurant which share this style. And with Toolset, we can tweak our archive queries adding paging and search with ease.

Speed

Taxonomies are the WordPress way of doing things and they are fast. Adding more and more custom fields to your post can have an impact on performance. Wordpress aggressively indexes taxonomies and they will often perform better than custom fields. Just don’t over do it, if you have tens of thousands of posts, and multiple taxonomies, your taxonomy relationship table is going to get very slow to query.

Search

Think of your search form layouts. Will your users want to select multiple terms in this case for Food Types? - taxonomies make it easy.

Using WordPress post fields or not

Post title is a no brainer. Unless you want the url to be different to the name of your post, then you should be using the post title.

Post body is a little less clear. Most posts are going to have a description. If you plan to allow your users enter text, images and markup, then Post body is perfect for that. If you want to control the output of your description more closely, and only allow text with no markup, then you might want to consider a custom field - this is often a good choice.

Featured image used to support different properties to custom types images - now they are pretty much aligned - so go for featured image. Featured images will also be responsive and generate srcset of available images sizes using a single shortcode.

Post relationships

For this site we have no post relationships which makes life simple. When you are considering relationships between your posts, then here are a few things to consider:

Don’t go too deep - Toolset is good for your Parent -> Child relationships, but don’t carried away - Parent -> Child -> Grandchild can cause problems and complex views.

Parametric search is not going to work for you across your parent child relationships - there is some support but it is very limited.

Many to many relationships are hard with Toolset - this may change soon!!

Depending on the site, we will often use taxonomies to create relationships. If we look at Artists and Events (see Toolset course), then instead of creating an intermediate post type, we could assign an Artist taxonomy to both artists and events. We’d create a single entry in the Artist taxonomy for each artist custom post entry, and for each event, we could assign the artists attending the event. The taxonomy will provide the glue to link the two posts in our views and custom templates. This type of solution needs to be carefully considered in the context of the site as a whole.

Custom field groups

Although we decided the fields we need are not common between posts, we can simplify our site Views and speed up our build process by a good choice of field groups.

On our site we are going to want to create list views for our three post types, but we probably want these to look very similar, and perhaps even display on the same page.

Both our Sites of interest and Restaurants have addresses, contact details and social icons. If we share the same custom field groups for both post types, then we can create a single content template to display on both the Single restaurant page and our Single site of interest page.

Let’s look at how we might organise our Post field groups

Address fields

• address-line-1
• address-line-2
• address-town
• address-postcode
• address-postcode

Location

• Latitude
• Longitude

Contact

• contact-tel
• contact-mob
• contact-email

Social links

• social-fb
• social-tw
• social-web-site

Opening hours

• To/from hours (repeating)

Images

• Image (repeating)

Listing fields

• family-friendly
• short-desc

There are still some post specific fields, we’ll add a post specific field group (e.g Restaurant fields) and add them there.

So let’s look at the field assignment for our post sites.

Making our field groups work for us

Now we have some clear build tasks for our project.

List views - All of the views that list one of these post types on our site can use the same content template for the list item. We just need to use the WP post fields (for our title and links and image), and the Listing fields for the short description and family friendly indicator.

Plotting on the map - our maps are going to work faster if we use lat and lon. We can plot all our markers with WP Post fields, Listing fields and Location fields. Just one content template for all three.

Components for our other pages - we can create content templates for Opening hours, Address, Contact, and Social link and use these on both the single Restaurant and single Sites of interest pages.

This type of approach isn’t just going to speed up our build, it makes maintaining and enhancing the site much easier.

De-normalising our data based on usage

Our site layout is going to allow users to select a Town and display Restaurants, Beaches and Sites of Interest in or near our town. We already have the Town as part of our address. That’s not really the ideal structure for displaying and grouping our posts by town.

We could create a Town post and then add all our listing posts as children for the town. But it’s likely that we may have a beach of a site of interest that could be near two towns and we’d want it listed by both. So what we actually have is likely to be a many-to-many relationship.

What we can do easily is to add a Town taxonomy to each of our listing items. This will give us a nice url structure for our towns, and a natural archive page for each town. We can extend our town information by adding term custom fields to our Town taxonomy.

We are repeating the town information on our posts, and we will have to select the town and set the town taxonomy for each post (with an address), but this will really help our site structure.