How WordPress falters as a CMS: Multiple content fields

WordPress is amazing and keeps getting better, but I want to be clear about an inherent limitation that WordPress has as a content management system (CMS). That limitation is that WordPress doesn’t handle multiple content regions on web pages.

Too strong? With WordPress, you can try to use custom fields or innovative hacks like Bill Erickson’s approach to multiple content areas using H4 elements in his excellent theme “Thesis”. Unfortunately, neither of those approaches really deals with the depth of the design problem that often requires multiple content areas for pages.

As an information architect/user experience designer, I’ve been involved in many projects that required more types of content on any single screen than WordPress is designed to handle.

Let me draw out what I’m talking about here.

Exhibit A: Page content that WordPress is designed to handle

In a standard WordPress page or post, you’ll see these author-controlled pieces of content.

  • Post/page Title
  • Body
  • Excerpt (often not-used)
Standard WordPress content fields include the title, excerpt, and body.
Standard WordPress content fields include the title, excerpt, and body.

There are other sets of data for a page or post that an author can control, too, but these are meta-data such as tags, categories, slug (shows up in the URL), and possibly search engine optimization information like title, description, and keywords.

For a normal blog, many online trade journals, and a lot of basic websites, this really covers the bases. The body contains the bulk of the content including images, video, and audio that can be intermingled with the text itself. This model is very flexible, and it has definitely proven itself.

Exhibit B: Page content that pushes WordPress too far

In 2009, there was a small project at work to develop the website Covenant Musicians, and because the person who would keep the site updated was already using WordPress, we made the decision to build this site with WordPress too.

Well, if you look at one of the destination pages for this site, the musician profile page (here’s one for example), you’ll notice some different pieces of content which may or may not be present on any particular musician profile page. When they are present, they need to be in certain places and sometimes with certain content.

This custom WordPress page uses fields in addition to the standard options: Musician Image, URL, and Video.
This custom WordPress page uses fields in addition to the standard options: Musician Image, URL, and Video.

The problem is, to control those extra pieces of content: the video, the band image, the link to the band’s website, the site owner needs to use WordPress’s custom fields in very precise ways, without the benefit of WordPress’s content editing tools. What a drag!

To make life easier for the site owner, we ended up recording screencast instructions on how to use these fields and delivered those help files with the site itself. (We used Jing by Techsmith, by the way.)

It would’ve been better had the interface been clear enough so that we didn’t feel the need to document the process of updating these destination pages, but that’s the trouble with stretching WordPress beyond its default content fields.

Ask too much of WordPress and ease-of-use is the casualty

Do you see the difference? When an effective design solution requires multiple types of content per page, using WordPress will actually make your website difficult to manage. WordPress is usually so easy to use that when you hit this wall, it is very apparent.

When you’re at that point, WordPress is probably not the right CMS to choose.

Should WordPress improve in this area?

Whether through the core application or through an excellent plug-in (is there one already that I missed?), if WordPress is going to grow in the content management systems field, this shortfall will need to be addressed.

However, WordPress is really excellent at what it does already, and the better course might be to decide to keep the features in check and let other systems compete in the mid-to-enterprise scale CMS arena. Scope creep never stops, and a good application strategy knows when to say “no.”

Am I wrong?

Am I off-base here? This is just one aspect of WordPress that should limit its use. Another that should cause designers to think twice is when dealing with faceted-navigation which requires more than one dimension (tags can probably handle one dimension). But, again, those are more complex design requirements.

I’m not a WordPress consultant, and I’ll bet some of you would like to point to the errors in my thinking. Let’s hear it.

Switching to WordPress

In 2003, I started this blog on the then young Blogger.com service, linked in with my web space at MSU. Shortly thereafter I switched to MovableType and stayed with MT for a few versions. In a recent MT upgrade, I wasn’t pleased with the process. So, I’ve just switched to WordPress, which I had used for a number of prior web projects.

Over the next week the existing files at davingranroth.com/blog will go away and be redirected to blog.davingranroth.com, which is the WordPress-based site.

If you find broken links or missing files, please let me know so I can fix them. I should have taken care of the bulk of them already, though.

Authenticate, commenters!

I upgraded to MovableType 3.32 recently, and just turned on TypeKey authentication, so as to avoid comment spam.

This means that you will need to have a TypeKey profile in order to comment here. Sorry for the hassle! It is pretty easy to get a free TypeKey profile, so just do it 😉

This will also mean that when you do comment, your comment will be published immediately, instead of waiting for me to get around to manually clearing it.

[nav links above do not lay out properly in some browsers]

I’m trying a slightly different layout with the nav links above, and they don’t lay out as I want in some browsers. They are fine in Firefox on the Mac, but not in IE or Safari on the Mac. I’m guessing there are some issues on Windows, but I don’t have the time to deal with it at the moment.

The issue is related to the css float property.

I’ll see what I can do over the next couple days.

Rewrote the main page code and css of this blog

Just a note, this evening I rewrote the markup and css for this blog. I basically just deleted both and started over. This page is now more lean and the css is much less bulky.

I also ditched the monthly archive link list and the calendar. Instead, there is now a longer list of recent entries, and I posted in some articles I wrote for my business site–mostly just to get some visibility on them.

Why your movable type blog must die.

So Noel has this interesting link to a rant about how movable type sucks and bloggers, that is, people who blog, suck, etc. Now not being a technocrat I don’t understand much of the ranting but I find it really amusing that people can get that bent out of shape about someone else’s personal journal.

Davin likes to remind me that there is such a thing as a BLACK WEB, which, I guess, means that there are zillions (that is a technical term) of sites and pages out there that search engines, bots and people simply cannot find or access due to bad code or intentional obscurity.

I love that concept. I’m a conspiracy theorist at heart.

The thought of hidden stuff is exhilarating; even though I know most of it is probably like the site I had to build for my English 453 class in college. BAD! Either way, Ranting will not stop the flow or stem the tide and movable type works for dingbats like me (and apparently, Noel). SO, MOOOHAHAHAHAHAHAH, you angry ranter. I shake my fist at you with indignation.

Gotta go. Grading papers.