WordPress as a CMS: Making Your Content Unbreakable

It might surprise you how infrequently I build WordPress sites intended for actual blogging. More often, I’m building 15- or 20-page websites for businesses who need a bunch of static content displayed in a variety of ways. Some of this can be accomplished with plugins, but the rest must be inserted in the post-edit screen, making things messy for the client:

That’s one big drawback to using WordPress as a CMS: the lack of custom content types/groups, an area where Expression Engine really shines. EE’s custom field system allows developers to put restrictions on how clients insert content. This keeps the content clean, portable and relatively unbreakable because all the structural HTML is tucked away in the templates themselves, not in the post-edit screen.

In this sense, WordPress is not quite a “full-fledged” CMS and developers must create workarounds.

Custom Code

Here’s a page from a recent WordPress project:

spring creek

Notice the 6 thumbnails and excerpts in the left column. Any attempt by the client to add/edit that information could easily disrupt the HTML and potentially break the design:

spring creek

Even if the visual editor was turned on, the client wouldn’t be able to—or necessarily know how to—properly wrap those elements with the necessary HTML. And if the client tried to copy-paste content from another site, the visual editor would inherit that HTML, creating a jumble of inconsistent code.

Luckily in the case of Spring Creek, we ended up writing some special PHP mixed with custom fields and TimThumb to generate and format the content, but not every client can afford to pay for that kind of automated solution.

Content Chunks as “Pages”

Here’s another page from a recent project:

In the sidebar of each static page is a chunk of related content. One method we’ve tried in the past is breaking up sidebar content into separate Pages and using PHP to dynamically insert them wherever appropriate:

That keeps keeps the code cleaner, but unfortunately adds a layer of confusion for the client who must edit his Page content and Sidebar content in two different places.

The <!–nextpage–> Quicktag

So for VA Film, we decided another way to break the content into pieces without allowing the client access to any structural HTML was to deploy the nextpage function:

The sidebar content gets called from within the template, like this:


<div id="sidebar">
<?php if ($numpages > '1') { ?> <?php $temp_query = $wp_query; ?>
<?php query_posts('page_id='.$post->ID.'&page=2'); ?>
<?php if (have_posts()) : while (have_posts()) : the_post(); ?>
<div class="entry"> 	<?php the_content(); ?> 	</div>
<?php endwhile; endif; ?> <?php $wp_query = $temp_query; ?>
<?php } ?>
</div>

It’s still a hack, but it allows the client to edit primary content and sidebar content in the same place without inserting any extra <div>s. There are other useful hacks of the <!–nextpage–> function that I’ll write about again soon.

Widgets

The last obvious method would be to create multiple widgetized regions in your theme. This practice is becoming more common in themes like Thematic.

Unfortunately, while the concept of “widgets” might make sense to bloggers, it doesn’t always make sense to the business owner. And depending on the content, it may still require some HTML knowledge, for example: floating an image, inserting a list, or requiring certain <div>s:

Questions

Obviously none of these solutions is perfect. Static content can be displayed in a number of ways—columns, quadrants, floats, lists—but the more ambitious it becomes, the less likely the client can edit it cleanly. In my experience, nothing compares to the rigid control offered by Expression Engine’s custom fields.

Final thoughts:

  • What other ways can we prevent clients from breaking layouts?
  • Should we design page content to be as simple and linear as possible to allow clients easier editability?
  • Should we insist the client learn a bit about HTML before handing over the site?
  • Should we write elegant hacks based strictly on how much money the client can spend?
  • For larger sites with variable page layouts, should we just opt for a true CMS like Expression Engine instead? Should we not compare apples to oranges?