«Return to Blog List When developing WordPress CMS websites, extend the non-bloggy parts of WordPress
WordPress is an amazing success story, worldwide powering 30% or more (as of this date) of all websites built on a Content Management System (CMS). There are some good reasons for this: ease of use, a rich ecosystem of plugins and ready-made themes, ease of use, a committed and accessible development community, and ease of use. You get my point: ease of use is a major reason people like the platform.
But let’s be clear: out of the box, as is, WordPress is not a particularly great CMS platform. It must be extended with the use of custom post types, custom fields, and a strong understanding of how the platform works (the WordPress Way) and how to manipulate it intelligently. Too often, developers destroy WordPress’ ease of use while building CMS features.
The WordPress Way, unfortunately, is slanted toward the needs of blogging, not toward the broader CMS needs of a business or organization website. When creating an effective, easy-to-use CMS, it’s often important to extend the the non-bloggy features of WordPress rather than the bloggy features, understanding when to abandon the WordPress Way when necessary to support the needs of the website owner/CMS user. Let me give you an example with a fairly common scenario.
As all WordPress developers know, there is such a thing as the template hierarchy. Without explaining it in detail, one of the things this allows is automatic usage of templates which are named in certain ways. For instance, if you create a “news” custom post type, an individual news item will automatically be displayed on a template named single-news.php, and a listing of news items will automatically be displayed on a template named archive-news.php (of course, appropriate code must be on each template). The simplicity of this is that all news items display on the single-news.php template and are automatically added to the news listing: no need to update the listing page to point to the news item.
Here’s where confusion and complexity start to replace ease of use for the CMS user.
But here’s the problem. Suppose the website owner wants, in addition to a news listing, a press release (custom post type) listing and a press downloads page in his news section, making both “child” pages appear under the news listing “parent” page. Although you can make it appear in the menu that an archive page is a parent to other pages or archives, it actually cannot be: it can only be a parent to the single items that it lists. Here’s where confusion and complexity start to replace ease of use for the CMS user, although the developer has done things the WordPress Way. Meanwhile, the CMS user just wants a simple way to add a child page under the news listing page.
The whole problem is easily avoided by creating a page template that includes a news query to list news items (and another listing page template that lists press releases). It serves as both a news listing page, and can also serve as the parent of other pages. This isn’t exactly not the WordPress Way, but many developers (who, let’s face it, tend to have OCD) insist it’s not the “right” way. The average CMS user could care less about that. What they care about is what makes it easy to do their job.
There may be some legitimate reasons why it’s better to use the template hierarchy for displaying listings in cases like that described above, but I’m pretty sure they don’t over-ride the importance of ease of use and flexibility for the CMS user. In my view, WordPress developers building CMS must maintain the primary reason their clients want to use WordPress: ease of use.
