One of the most important things that a website needs is a way to display structured content. For example, a list of upcoming events, or a directory of office locations.

Time and time again I see websites where the same content is entered manually on separate pages, which is just bad news.  It may seem like an innocent task at first – “Got an upcoming event?  Just update the upcoming events listing on the homepage, and then update the event listings page too.”  If you’re ever entering the same data into a system twice, you’re going to introduce inconsistent data at some point in the future.  That sucks for your web visitors who are trying to get the story straight, and it makes you lose credibility in their eyes.  ”What date is this event on?  This event registration page says it’s on the 10th, but on their homepage it says the 14th.”  You may even be losing revenue from your website and not know about it.  Most dissatisfied web visitors will simply leave your site – not everyone will take the time to send you a complaint in writing.

The solution is straightforward.  You can help prevent the “Oops I forgot to update that page” syndrome by designing a content architecture to solve the problem before it starts.  Leave the world of novice web design behind and get your site organized like a pro.

As the web designer, you want to give the site editors a simple, single place to enter this structured data – and enter it one time only. Asking site editors to enter the same data in more than one location is burdensome, increases the complexity of staff training, and increases the risk of your site displaying incorrect data. It’s your job, not the site editors’ job, to display the data on the front-end in the various formats needed by pulling it out of the CMS database.

Before you start, you need to map out what sort of data is required. Let’s take a list of upcoming events, for instance. For each event you want to show on your site, you probably also want to show:

  • Event name
  • Event description
  • Event start date
  • Event start time
  • Event location
  • Event registration URL

WordPress has the ability to store these attributes in the form of custom fields, or post metadata. To keep things organized, and if user-level permissions are needed, I recommend creating a custom post type for each group of structured data you want to store.

In WordPress, you can just make a custom post type called Events.  The good thing is that for name and description we can just repurpose the post title and body fields.  All you have to do then is to create custom fields to store the data, and then create meta boxes for your users to enter the data in the edit post page.  Be thoughtful of the field names you use and follow good programming naming conventions so that there is no confusion about what a field may store (explicit and descriptive names like eventLocationURL are preferred to ambiguous ones like elu, locurl, etc.)  Don’t skimp on field name length!

Now that the custom fields are provisioned in unique custom post types, you need to create a custom query to display the output in a format that’s appropriate for the content.  In our upcoming events example, you may have two output formats – a simple bulleted list of upcoming events on the homepage, and a detailed table listing for the events homepage.  Since the data is in a single place, you just need to worry about writing the queries to grab the data you want and display it in the necessary format.  One data set, two different outputs, and both perfectly in sync with the correct, up-to-date data used throughout your website.

With these custom views in place, you’re now ready to go.  Just set your web editors loose on the site and let them create and maintain the post collections.  They’ll feel empowered and in control, and you’ll know the data is organized and accessible in a central location that’s straightforward to manage.  The entire team will be able to respond quickly and thoroughly when asked to make content changes.  Most importantly, website visitors won’t see outdated data lingering on a forgotten page.