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)
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.
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.
14 responses to “How WordPress falters as a CMS: Multiple content fields”
[…] How WordPress falters as a CMS: Multiple content fields | Davin's blog […]
“There’s a workaround for that!”
This wordpress.org post talks about applying tinymce to a custom content field. http://wordpress.org/support/topic/331589
There’s also a plugin for it called more fields: http://wordpress.org/extend/plugins/more-fields/
That’s cool. I didn’t know about those workarounds. It looks like “More Fields” is listed as broken at the moment, probably because of the recent upgrade to WP 2.9. Hopefully the plugin gets fixed pronto for all those WordPress users that are using it.
Zach, perhaps I’m old fashioned, but a “workaround” should, well um, work 🙂
I had this problem a few hours ago, then I installed the Magic Fields plugin, created a new custom write panel, then created some custom fields for that panel. Now I have something that would have been useful for your musicians, and useable without the screencast. New post interface: http://imgur.com/YX0V8
I spit all the fields back out at the page within The Loop.
Hovering the ‘What’s this’ shows the tooltip text I defined when I set up the new fields in Magic Fields. It’s really slick! You can even change the type of fields, their default values, what category the post defaults to and which fields are required in order to publish.
Here’s my loop/field processing, it’s inelegant but I wanted to get it working before I prettied it up.:
Projects out to bid:
, Bids:
<?php echo " Estimator: “,$Estimator,”Addenda: “,$NumAdd,”
Prevailing
wage: “,$PrevWage,” Special Goals: “,$SpecialGoals; ?>
Hmm, the comment ate my loop! Trying again. If it fails and anyone wants it, just email me.
Projects out to bid:, Bids:
<?php echo " Estimator: ",$Estimator,"Addenda: ",$NumAdd,"
Prevailing
wage: ",$PrevWage," Special Goals: ",$SpecialGoals; ?>
Eric, thanks for linking that image to the post interface. Yep, it seems like Magic fields could really handle a lot of these types of problems.
I still lean towards thinking that that type of functionality should be part of WordPress itself, not a plug-in that might break with each WP upgrade.
Hey Eric, just checked out your site. Your artwork over at http://www.ericthomasbostrom.com is intense!
Heythanks, I appreciate it! In my opinion, the flexibility of WP is what is intense!
I’m now doing some crazier stuff. After I built that posting interface with Magic fields, I spread that data out as necessary. I’m using category-N.php and single-N.php (with a functions add_filter) to have special category and single post templates for just one part of the site I’m working on. My next step is going to be an implementation of Role-scoper to limit the access to that special category and custom write panel for just one user, so the one user can only post to that category (much like your add-new-musician example). Once I’m done defining post access I can set up an interface that will let my subcontractors auto-reg for level 0 accounts, so they can view content (like plan sheets and specification manuals) that I want to hide from other general contractors or plan rooms.
Since I work alone and I’ve got no one to geek out with, behold:
(please disregard the tabular data at the bottom of these examples, that’s a holdover. also: disregard template aesthetics 😉
Old plans site, uses hand built php/csv style fread/write: http://is.gd/5TuUa
Same content using Magic-Fields as mentioned: http://is.gd/5TuVC
Same content using Magic-fields, custom page template, with that category in The Loop below it: http://is.gd/5TuYo
Same content using Magic-Fields, custom category-N.php template: http://is.gd/5Tv9O
Here’s a single post, using a custom single-N.php template: http://is.gd/5TveA
Here’s a different post, using the default single.php template: http://is.gd/5TvR4
The reason this was important is that the custom Magic Fields don’t appear within The Loop or the_content() you have to call them, so they aren’t going to show up in RSS on the default single.php. This is a huge hole for my usage and probably for yours…
What this all means is start to finish I can offload this job to a receptionist, have her post or edit the appropriate content for the plans site, and have that data automagically post to twitter and rss like normal. Saving us $$ in long distance faxing, and overhead emailing that same content to our subcontractors. Now the problem will be getting subcontractors on board, when their most impressive technology is a plain paper fax machine. 😀
Cheers!
That looks great. I haven’t tried Magic-Fields yet, but as you point out w/your examples, the fields are called in the template files so you can have them show for specific page types (templates).
But, on the wp-admin add/edit post page, the Magic-Fields form always appears, regardless of the page template you choose, right? Or not?
And, yeah, isn’t fax where good data goes to die a low-res death? 😉
Nope, If I’m in the regular ‘Post’ write panel I get the default WP layout (or whatever I’ve customized). All of the magic fields entry and customization appear if I click on the ‘Plans’ write panel.
Just for the record, Magic Fields is a fork of Flutter, the former attempting to correct some shortcomings of the latter.
For very large sites, this is not the way to go, since the ‘custom fields’ are stored in the database in a very inefficient way. In my experience, however, this is only a practical problem for internationally-oriented sites with very large amounts of content (I’d say Amazon or eBay, but that’s probably stretching it a bit). It’s not an issue if you’ve got a ‘mere’ 50.000 posts and, say 10.000 visitors a day. Inefficiency is, of course, inefficiency, and it would be a huge plus if WordPress accomodated a bit more flexibility in using custom fields.
Depending on your needs, Pods is the better, more scaleable option. Pods allows you to create a whole separate content system inside of WordPress, separate db tables ‘n’ all. And that’s also one of its limitations. If your ‘custom’ content needs to be heavily integrated with your posts, this is difficult to do in a user-friendly way.
For example, if you look at http://www.tail-out.com/, the banners at the top of the page and the videos in the left column are ‘pods’, whereas the extra information in the left column on http://www.tail-out.com/archives/50-demon-games.html is stored in custom fields. For me, a combination of both approaches usually works best.
Totally agree! I am just working on an new website, it need to be multilingual & have different field on the main page.
I use WPML for the multilingual part and am using WP 3.0.
And tried Magic Fields & Flutter but they do not work with WPML!
The thing I am not able to do is simply create 4 fields under the main page admin where the owner can add different content to each fields.
Like:
– Box 1 left
– Box 2 right
– Box 3 bottom left
– Box 4 bottom right
The site owner is not very technical and I can not use plug-ins or custom fields, it is just not as easy to use…
If only WordPress had Template Variables like MODx CMS or MODx CMS had a blogging system like WordPress….
I fully agree WP needs to have build in support for multiple content areas / blocks. It’s a fundamental component of a CMS in my mind.
Sure WP has some great features like custom post types and custom fields, but sometimes you just want plain old editable areas. Page.ly MultiEdit definitely is a good start, it adds tab in the editor for each region which is awesome, but the Multiple Content Blocks plugin (http://wordpress.org/extend/plugins/multiple-content-blocks/) seems simpler and more stable. Hopefully finally someone with WordPress will maybe take one of the plugins and built it into the core. You can’t have to a true, robust CMS without content areas.
Let’s keep the push for this going! Keep making noise about it and hopefully folks will listen.