WordPress is cool because…

WordPress is cool because it’s simple, it’s extensible, and it’s the right tool for the job.

It’s Simple

WordPress makes no apologies for its strengths. It provides one of the best user content generation and editing experiences around. With this great simplicity, a designer needs to take an equally simple and straight-forward approach to extending WordPress’s core functionality. There are many reasons one might choose WordPress, but this post focuses on why it worked well in rebuilding our website; why WordPress is the right tool for us.

Fourkitchens.com needed a better editor experience and an equally impressive mechanism for telling effective stories. Our previous site was built using the popular static site generation tool, Jekyll. Jekyll is great for just that: simple static sites, but our content needs outgrew Jekyll’s constraints. In this post I’m going to talk about my first attempt at leveraging existing plugins to facilitate reusable components in WordPress.

It’s Extensible

Creating new content types

Knowing WordPress’s strengths help to solve for its shortcomings. One shortcoming, or strength depending on perspective, lies in providing content authors limited content stream options. This is where custom post types enter the picture. WordPress has offered the possibility of adding custom content/post types since version 3.0.

By default, WordPress provides authors with two core content publishing streams: pages and posts. From those two streams, one can categorize posts with terms, add media attachments, and use the main menu system to organize pages and present them to users.

But what if this isn’t enough? In our case, we needed unique field data and content streams for case studies and for site-wide call to actions. As a developer, you can create custom post types in code, or you can use a plugin and benefit from using a UI construction kit. The plugin approach can be helpful for on-the-fly content changes and to expedite the initial content type creation.

Our custom content types include:

• case studies
• callouts

Both case studies and callouts benefit from custom field groups and flexible content components. Case studies are a mix of site-wide components and specific case study field data, while callouts are a component themselves in addition to being a custom content type.

Let’s componentize WordPress!

Now that we’ve identified our custom post types we need to add extra field data to them. Enter the Advanced Custom Fields (ACF) plugin. For our specific purpose, the pro version of the plugin is necessary.

Using the ACF pro plugin we can use the flexible content functionality to create reusable components via field group. When authors begin creating a new page, case study, or callout, they are presented with a button prompt asking which component they would like to add.

The flexible content functionality allows developers to create global components that can be themed to be as modular as possible. Using PHP “includes,” one can create content parts and reference them from page templates or other content includes. The big win lies in creating the component once, providing its code in a template, and then referencing it from allowed content streams across the site.

For the sake of illustration, say our page template file structure looked something like the following – where structure-example is our theme directory:

1. The page template (page-flexible.php) sits in the theme root. It sets the outer HTML markup for the page content. From there it calls content “parts” or PHP includes to construct and complete the page content. View code example here.
2. PHP includes (template-parts) that are referenced from the page-flexible.php template:
   a. content-page-full.php includes the page title and any standard WordPress content pieces—title, body, featured image, edit functions, etc.

b. flexible-content.php includes custom field loops and conditional markup. One could take this further and create new file directories for each “component type” which would then be referenced in this catch-all type collection file.

With these files/parts in place content authors simply select a page template from a drop-down menu of available templates. They are then presented with an open content area, to start placing content/components upon.

One of the biggest challenges, and something I’m still contemplating, is the question of when you should componentize content and when should you create a distinct field.

Case studies

Our portfolio section needed to tell a story. Each case study gives our clients insight into what it’s like working with us and the degree to which we value every interaction.

When creating a new case study, authors are guided through the editorial experience in sections. This way, we can adhere to a standard narrative structure, but offer flexible components to tell each unique story.

The summary section includes basic client details—subtitle of the case study and teaser summary—both of which appear on the homepage for the “featured” case study.

The narrative, problem, and solution sections each are made up of components and can be tailored to individual client/project details.

All other sections are more prescriptive in their content-to-field model. This way, we are able to easily stick to a defined content structure. This will inform our own content strategy guidelines as we build our further phases of our website.

Site-wide callouts

We’ve established a callout custom post type but now we need a way to reference callouts from pieces of content.

Our callouts have the following fields:

• title (h1)
• content (WYSIWYG)
• button/link field (.button formatted internal link)
• featured image (standard WordPress featured image)
• callout color (gray, green or blue)
• callout style (decides how the image and text will render on the frontend)

A content author can choose which style of callout renders:

• regular (our Web Chef team images and headline)
• prefooter (illustration style image and headline)
• no image (prioritizes the text content)

Callouts can be pulled into our flexible page template to be rearranged and mixed in with other content—headings, paragraphs, images, etc.—in whatever order the page author dictates. This makes all content very modular, purposeful, and far more uniform, design-wise, than an open WYSIWYG would or could accommodate.

It’s the Right Tool for the Job

Overall, the biggest benefit to using WordPress lies in knowing both how and when to use it. For our content needs, and future content goals, WordPress has swooped in and accommodated our needs nicely. Jekyll is an outstanding blogging and static site platform. However, scaling and broader team/authoring experiences are difficult if not cost prohibitive and productivity killers. Not every author that contributes knows how to use GitHub, which Jekyll requires (the question of should they learn GitHub is another topic entirely). The learning curve is relatively high and the technical debt of writing your own plugins or maintaining your own toolset can be high.

From a marketing perspective, WordPress has a seemingly endless amount of plugin options for integration. Another future-phase goal of ours is to integrate our site with more services using these custom plugins, like social share, SEO, and lead generation, to name a few. WordPress makes it easy to try service integration with existing plugins at little risk or time investment.

I look forward to iterating our site, and others, further using WordPress. There are sure to be more epic quick wins to uncover and share.