Transcript As Follows:

First, let’s look at why many of us build on WordPress. WordPress is:

  • An extremely flexible CMS
  • An easily modifiable database
  • A strong foundation to jump-start projects
  • A growing app platform
  • …Sometimes a blog

Can WordPress do X?

It’s this question that led me to this topic, to help spread the word that WordPress is so much more than a blogging platform.

Presentation Goals

  1. See how a content-first development approach looks
  2. Review how WordPress displays and relates content
  3. Design a structure that supports content-first development

Customizing WordPress Requires A Content-First Approach

You may think you know WordPress, but I would bet some of you are actually stuck in a rut of doing things a certain way because it seems to work. That’s fine, but are you sure your way makes sense to the final content creator? Examining your process from a content-first perspective leads to cleaner themes and happier users.

Benefits of Content-First Development

A thorough understanding of how WordPress retrieves and relates content leads to:

  • More productive discussions with content writers
  • Better understanding of the site architecture by designers
  • Speedier sites
  • More efficient queries
  • Less confusion for the end user

But wait… how do you get started developing in a content-driven way?

This may depend on if you’re a single-person shop or within an agency of some sort. Personally, I’m in the marketing department of a large corporation, but I also develop custom WordPress builds for freelance clients. No matter your situation, a content-first approach begins with asking:

What is the relationship of this content to the rest of the project?

A Simple Example: Blog Considerations

  • Categories
  • Tags
  • Handle multiple authors
  • Have related sidebar content
  • Need layout modified frequently

In this example, the first three are native behaviors, but dynamically-related sidebar content and layout modifications need more considerations.

For successful content-first development, all possibilities for content relationships are identified up-front.

Learning to consider content relationships may lead you to think of even a “simple” marketing site in a more app-like way.

Another way to consider relationships is by asking:

What events would cause this piece of content to be modified?

Let’s look at developing the dynamic sidebar for our blog post example.

  • Dynamic sidebar content will be related posts widget
  • Related posts are based on matching the category
  • They are ordered with the newest first, displaying up to 5
  • They should exclude the current post

So – this means that choosing the category for a post should be very purposeful, possibly even limited to a few strategic options.

Or – maybe categories are actually types of portfolio work, so the related widget will pull in other logo posts.

Or – maybe categories are used to identify courses for a recipe focused website, so the widget will show related main dishes.

Content-driven development means being very purposeful in choosing the mechanisms for data entry.

Categories can be used in those previous examples IF the site is very focused on those types of subjects. But let’s look at a larger example.

Typical Marketing Website Needs

  • Unique front page
  • Non-central blog page
  • Multi-level navigation
  • Multiple menus (header, footer, sitemap)
  • Resources section with press releases, case studies, and white papers
  • Lead generation forms
  • Landing pages for services
  • Search

… and each of those comes with it’s own set of questions to narrow down the type of content to be entered for each. To figure out how to handle each of these, we need to find out…

How WordPress Handles Content

To determine our content creation structure, it’s helpful to learn how WordPress displays and relates different content.

Index vs. Home vs. Front-Page

Here’s where content-first approach takes hold. Even seasoned developers have trouble with or completely miss the concept of how to define home page content. It took me a few years to stumble upon the correct information. The confusion stems from…

Remnants from HTML Development

  • index.html – default page rendered
    • > loads >
  • “Index” equates both “Home” and “Front Page” for the root site

WordPress: Index, Home, and Front Page = 3 Different Use Cases

I think this refresher may help more than the n00bs in the crowd. Public confession: I’ve only done this setup correctly for sites I’ve built in the past 6 months.


  • The lowest-tier default template used if no unique templates exist above it in the template hierarchy (we’ll circle back to that)
  • Can be both the home and front page IF there is no intention to make the front page unique
    • Or if you want to deal with a crazy mess of conditionals


  • Relic of WordPress being a largely blog platform
  • Template for posts if either:
    1. Front page settings of site is set to show latest posts
    2. Blog is non-central to the site’s focus (i.e. not the “home” page)
      • Then set a different published Page as the “Posts” page under Settings > Reading


  • If this exists in a theme, will be first priority to be used to display the site’s front page, regardless if latests posts or a static page is chosen
  • “Front page” static page can be defined under Settings > Reading

Front Page Dictated By Site’s Purpose

Now that we’ve looked at how WordPress uses index, home, and front page templates, you can see why we’ve started there with our content-first development. It’s important to consider the site’s purpose before you even go so far as to create the structure for the front page. Here’s a few common scenarios that dictate the front page:

WordPress As A Blog

  • Create a unique home.php
  • Leave default Reading settings to display latest posts

WordPress For A Business

  • Create unique front-page.php
  • Publish a “Home” page
  • Define the “Home” page as the front page under Reading settings

WordPress For A Business With a Blog

  • Create unique front-page.php and unique home.php
  • Publish a “Home” page
  • Publish a “Blog” page
  • Define the “Home” page as the front page under Reading settings
  • Define the “Blog” page as the posts page under Reading settings


An example of #DoingItWrong would be to:

  • Not define the front and posts pages
  • Create your “home” page template on index.php
  • Create a custom page template and write an unnecessary query to create a paginated blog template

…I mention this because it’s how I did it until I took the time to finally get these three templates straightened out in my head! If you’ve been doing it this way too, perhaps you might benefit from knowing that defining the posts page means the query is all ready for you, including the paged variable. Just write a normal loop and include posts navigation and everything will work smoothly!

Posts v. Pages

Ok, this one is pretty basic. In fact, it’s probably the first thing you learned when you signed up for a account and upgraded from your Blogger account. But let’s review:


  • Date-based
  • Use categories
  • Displayed in RSS feed
  • Generally for blog or news articles
  • Template hierarchy in priority order:
    1. single-posttype.php (we’ll get to that)
    2. single.php
    3. index.php


  • Generally static
  • No categories or tags
  • Hierarchal (can define parent and child relationships)
  • Usually top-level content for non-blog focused sites
  • Template hierarchy in priority order:
    1. Custom template chosen from Page Attributes
    2. page-pageslug.php
    3. page-id.php
    4. page.php
    5. index.php

Custom Meta

An additional layer of data you can include by default on either posts or pages is custom meta. In terms of content-driven development, this allows you to expand on the content entry ability default posts and pages in a comfortable but very useful way.

Benefits of Custom Meta Data

  • Can be any key/value pair
  • Can be displayed automatically in a way dictated by the theme
  • Can be used to affect the main query

Greatest Benefit of Custom Meta Data

  • Can be entered via a custom-created meta box on the edit screen of any post type
  • Allows for precise data entry due to constraints of the form field chosen
  • Finer control over display or use information within the theme
  • Example: A meta box for a call-to-action button would have a text field for the url and a text field for the button text

Custom Post Types

If the site you’re building needs a blog, an About page, and a Contact page, sticking with just Posts and Pages is all you need to worry about.

But if you’ve spent time developing custom solutions, you know that Posts and Pages can be pretty limiting. For any advanced functionality, you may be creating numerous custom page templates, and likely struggling with relating content beyond a parent/child relationship for pages and categories or tags for posts.

Custom meta data can get you part of the way if you choose to use that to alter a query. However, custom meta can also lure you to the dark side of customization: offering too many options that aren’t needed for every single entry.

Custom Post Types, or CPTs, allow you to define a wholly unique type of content. Today we’ll look at CPTs more theoretically rather than discuss every option available in creating them.

Custom Post Type Benefits

  • Customize URL structure
  • Can be excluded from search and nav menu selection
    • Useful for: using entries as slide content in a carousel
  • Can prevent inclusion in front-end queries
    • Useful for: a documentation index displayed only in admin
  • Limit UI elements on edit page
    • Useful for: only showing the title, excerpt, and featured image to create an image carousel with non-html captions
  • Can define menu placement and structure for admin
    • Useful for: grouping related CPTs, such as for a Resources section
  • More clearly defined area to edit particular content
    • Meaning less calls and emails of “how do I change this?”

CPT Location: Theme or Plugin?

I am of the school of thought that any functionality that creates new content belongs in a plugin so that site owners don’t lose access should they switch themes. You could argue that CPTs belong in themes because you may need to create templates to accommodate them. We’re not going to spend time going over all the pros and cons today, but it’s something to consider as you create a site that best fits your client’s needs.

Marketing Site Example

Back to our earlier example, one of the requirements for our marketing site was a resources section with the following types of content:

  • Press releases
  • Case studies
  • White papers

Our Content-First Considerations Are:

  • What information is related to each unique content entry
  • What is displayed for each entry on the main resources page
  • What is displayed on the single view for each entry
  • Special circumstances for viewing content
  • How to make the content easily maintainable by the end user

Content Considerations For Each Type

  1. Title
  2. Description
  3. Document download

Special Content Case: Newsletters

  • Issues Archives

Resource Page View Considerations

  • Title
  • Excerpt
  • “Read More” link

Single Resource View Considerations

  • Title
  • Full Content
  • Access to document download
    1. Button for direct download
  • List of other recent resources of same type

Preparing for Content

Determine content entry UI elements

  • Title
  • Editor
  • Excerpt
  • Meta Box
    • Upload field for a document download
  • Unique Feature:
    • A way to link “Issues” for the newsletter CPT

Setup a CPT for each resource type

  • Benefits:
    • Pretty URL:
    • Archive page generation
    • More obvious editing access for end user
    • Can target edit screen by post type for including additional meta boxes and taxonomies

Custom Taxonomies

Our newsletter resource type is in need of a way to link posts belonging to the same issue, such as “Spring 2014”. Custom taxonomies are how we can achieve this because of:

  • Category-like capabilities
    • Can also function like tags if no hierarchy needed or multiples chosen per post
  • Archive page generation
  • Easy method to focus queries around
  • Can be added to any post type – and even to users!

Taxonomy vs. Meta Box

Now that we know what both of these are, a quick rule of thumb for choosing one over the other:

Taxonomies are for grouping things categorically. Meta boxes are for data that is customized per post.

Content Structure: Page Templates

When we reviewed pages, we saw that there were multiple options in the template hierarchy for pages, and we need to choose one to customize our resources page.

  • page-resources.php
    • Pro: Easily identified in our theme structure
    • Con: Loses association if a content editor changes the slug
  • template-resources.php
    • Pro: Keeps association regardless of slug
    • Con: Could be applied to other pages by content editors less familiar with the site’s architecture

For our purposes, we’ll chose to create a custom template template-resources.php because the risk of the slug changing is greater than if the template was applied to multiple pages. If you have fewer content editors, and perhaps have already had an SEO review validating your slug choice, you may decide to go with the slug option.

CPTs And Custom Taxonomies In Action!

Thanks to our careful content-driven structure, we can create the three loops we need on this page with ease!

Our wireframe included showing up to 10 case studies and white papers in their own section, plus a newsletter section with all entries from the latest issue.

Basic WP_Query $args For Each Resource Section Loop

$args = array(
    'post_type' => 'case_study',
    'posts_per_page' => 10

Adding the Issues Taxonomy To Newsletters

$args = array(
    'post_type' => 'newsletter',
    'posts_per_page' => 10,
    'tax_query' => array(
            'taxonomy' => 'issues',
            'field' => 'slug',
            'terms' => 'spring-2014'

Content Structure: Single View

One semi-tricky thing about Custom Post Types is they will use single.php as a default template. For our single resource views, we want a little extra markup to display the download document button, plus include a special sidebar.

I’d like to introduce a pattern used by the excellent starter theme _s. It keeps things simple by only having single.php but modifying the default loop as follows:

<?php while ( have_posts() ) : the_post(); ?>
    /* Line of awesome */
    <?php get_template_part( 'content', get_post_type() ); ?>

    /* pagination & comments */

<?php endwhile; // end of the loop. ?>

get_template_part() For A Case Study

get_template_part( 'content', get_post_type() )

/* == */

get_template_part( 'content', 'case_study' )

/* == */

include content-case_study.php

See the power in that? Now we can simply customize the guts of each post based on it’s type.

Conditional Inclusion

For our purposes, the case study and white paper pages content will be the same, so we’ll take this our single.php loop one step further:

<?php while ( have_posts() ) : the_post(); ?>
        if( 'case_study' == get_post_type() || 'white_paper' == get_post_type() ) {
            get_template_part( 'content', 'document' );
        } else {
            // i.e. 'post' or 'newsletter'
            get_template_part( 'content', get_post_type() );

    /* pagination & comments */

<?php endwhile; // end of the loop. ?>

Then, we can include the document download button just on content-document.php, and include the name of the issue on content-newsletter.php.

Conditional Sidebar

We can employ a similar conditional to alter which sidebar gets included back on the single.php template:

$resource_cpts = array('case_study', 'white_paper', 'newsletter');

if( in_array( get_post_type(), $resource_cpts) ) {


} else {

  // For single blog posts


Resources Content Structure Recap

  • Create a CPT for each resource type
  • Create a custom taxonomy for newsletter issues
  • template-resources.php
    • Three tidy queries to show each of our resource types
  • single.php
    • Keep a tidy loop with a simple conditional and get_template_part()
  • Create two content templates
    • content-document.php for both case studies and white papers
    • content-newsletters.php for… newsletters

Applied Benefits Of Content-First Development

  • Conclude that three CPTs are needed
  • Find that users would benefit from a meta box and custom taxonomy
  • Know to create one unique template:
    1. template-resources.php
  • Know to prepare UI elements for two content parts:
    1. content-document.php
    2. content-newsletters.php
  • Can note template files as wireframe notes for designers
  • Know that your end user will be able to find, edit, and create new content easily!

In Conclusion…

A content-first development approach to WordPress makes for:

  • cleaner themes
  • less back-tracking and exclamations of “oh yeah, we need to do this!”
  • happier end users
  • happier you

Related Topics

Content Strategy | Presentation