Planning a Wordpress CMS site
categories: howto, small business websites
There have been plenty of rumblings lately about how WordPress can be used as a content management system, beyond its core competency as a blogging platform. By harnessing the power of pages and subpages, writing custom Page templates, segmenting posts into category-based content feeds, and using handy little plugins like my brother's Page Link Manager, you can do some pretty neat stuff.
Lots of people have caught on, including small advertising and marketing agencies that want to be in the content and design business while staying away from programming. In my work with some of those agencies lately, I've often found that there's a gap between having the idea to use WordPress as a CMS and knowing the inner workings of WordPress that allow it to be used as a CMS. Since I often find myself needing to explain the building blocks of WordPress and how to use them as part of a lightweight CMS, I thought I should write my thoughts down. My goal here is not to get into the nitty gritty of actually implementing a WordPress-as-CMS site; I leave that to skilled WordPress developers ;). Rather, it's to give non-technical people an overview of how WordPress works so they can make the most of it during the site planning process.
Note: In doing my homework for this post, I discovered lots of posts that mentioned workarounds for earlier versions of WordPress. Many of these things -- such as setting a particular Page to be your homepage -- are build in to the newer versions of WordPress. Make sure if you're reading a WordPress as CMS tutorial that you are reading one for the current version.
Content building blocks
WordPress offers a few building blocks for content management: posts, categories, pages (better referred to as sections), and custom fields.
- Posts and Categories are used to organize related content. By assigning a Post to a Category, it can be grouped with other Posts in that Category. For example, you could have a "team members" Category and a "news" Category, and then easily display all team members in one location, and all news items in a completely separate location. You could even have a "blog" Category, which would allow you to have a blog on the site while still using Posts to manage other content as well. (Besides allowing this type of organization, Categories also automatically create Category Archives -- an easy way for your users to browse all content related to a Category, if you choose.)
- Pages are used to manage static content, and are used for the site's navigation. They can also display other content items -- both Posts and Pages -- that match certain criteria. (For the sake of this discussion, pages and subpages may be better thought of as sections and subsections; not every "page" (i.e. URL) on a Wordpress site is managed using a Page in the Wordpress admin, but every section and subsection is managed that way. When I'm talking about a Page with a capital "P", I'm referring to the kind that you manage through the WordPress admin; when I'm talking about a page with a lowercase "p", I mean any part of your site that has a unique URL.) It's important to note that, using the Page Link Manager plugin mentioned above, you can easily exclude any Page from the site navigation, which makes them much more powerful for managing pieces of content that don't need to show up in the navigation.
- Custom fields can be added to both Pages and Posts. They can contain all sorts of extra information related to a content item, which can then be accessed whenever the content item is displayed.
Theme building blocks
The design of a WordPress site is managed using a theme. Themes include a global header, footer and sidebar. They also include a variety of files for managing the design and structure of the content area, depending on the page you are viewing.
A very basic theme will include the following content area templates:
- Latest Posts template
- Single Post template
- Default Page template
- Search results template (used for displaying all Posts and Pages containing a term)
- Archives template (used for displaying date-, author- and Category-based Post archives)
Harnessing the power of custom templates
This is where things get interesting. On a regular WordPress blog, the default Page template will just display some static content that's entered into the Page using WordPress admin, plus the site's header, footer, and sidebar. This is fine for Pages that don't need to pull in any other content, like, say, an About section. When you start using WordPress as a CMS, you need to start doing more creative things with the content area of your Pages by using custom Page templates.
For the News Page of a site, you might create a custom template that would include introductory content entered via the WordPress admin, along with the 10 most recent posts in the "news" Category, ordered from newest to oldest, and a link to view all items in the "news" category. For the Home Page of a site, you might create a more elaborate custom template, pulling Posts from a variety of Categories, pulling static content from a variety of hidden Pages, and displaying it all in a variety of ways: full content, titles only excerpts, etc. You might even make use of custom fields. Do you want to be able to show a thumbnail with each Post in the "video" category, but only when you're showing those posts on your homepage? Add a custom field to those posts with the URL to the thumbnail, then tell your custom Home Page template to look for that custom field and use it to insert an image tag.
You could just as easily create a custom field containing the name of a PHP file to be used as a custom dynamic sidebar for that page; the options here are pretty much limited by your imagination (and your developer).
Developing the site architecture
In planning a site that will use WordPress as a CMS, it's imperative to think of how your content, sections and subsections fit into the WordPress model. It will save you lots of headaches when it comes time to actually develop the site, and lots of calls and emails from your developer trying to figure out what you had in mind. In fact, I strongly recommend getting a skilled WordPress developer involved early in the process, to help you turn your ideas into a viable spec.
Here's the basic process I recommend:
- Develop a simple sitemap for the site. Figure out what the sections and subsections are, and how they're organized.
- Identify the pieces content that will appear on each item in your sitemap, and evaluate how they should be managed. Is the content static and self-contained, such as "About Our Company" text? It should probably be managed through a Page. Is the content some kind of list of related items, such as news items or team members? It should probably be managed through Posts and Categories. Is it a secondary sidebar that appears on several pages? Consider using a hidden page if the sidebar is static or a PHP include if the sidebar uses other WordPress content items.
- Identify the Categories you'll use to distribute the Posts to their proper place(s). For each category, evaluate whether you'll need to collect information beyond title, body, and author. If so, identify these as custom fields.
- Identify the Pages you'll be using on the site -- including Pages that will be hidden in the navigation and used solely for placing static content on multiple pages.
- Decide how you will use your header, sidebar and footer to help users navigate your site. Will you provide links to Category archives? Will you allow your visitors to search your site? Will you show subpages of the Page a visitor is on?
- Identify which visible Pages will use a default Page template, and which will require a custom template, and identify the types of custom templates that will be required. Ideally, you will not require a separate custom template for every custom Page; look for similarities among the custom Pages, and try to identify the fewest number of custom templates that will do the job.
Plan the design based on the architecture
Once you've completed the site architecture, you are ready to actually design the site. For your own sanity, don't try to do too much design before this point. You'll need the information gathered in the site architecture phase to guide you in developing the design document upon which your template developer will base their work; a design document that doesn't take all of these considerations into account is going to lead your developer in circles as they try to make sense of what you had in mind.
Before you begin designing, you may want to draw up some wireframes that show the different elements you'll be designing -- header, footer, sidebar, custom page views, single post views, etc. They can guide the design process and be valuable to the developer who implements your design. When you're finished, your design document should include the following:
- General header. Note any ways in which the header should change according to the context in which it's being displayed -- for example, a breadcrumb or an indication of the current navigation item.
- General sidebar (or left and right sidebar). Again, note ways in which the sidebar should change according to the context in which it's being displayed.
- General footer.
- Latest Posts view. If you are going to give your visitors the ability to view your latests Posts, make sure you design a view for this. The latest Posts view will usually include 10 posts; for each Post, you'll usually show the title, author, date, category, body, and comment count.
- Single Post view. Ideally the structure of this design will vary little from one Category to another, though the visual presentation may change. This design will likely include the post's title, body, author, date, category/ies, navigation to the next and previous post, a comment submission form, and user comments.
- Archive view. This will be used for viewing all of the Posts by Category, month, year, author, etc. This is only necessary if you will give users the option of viewing posts this way. Usually this view will include multiple Posts. For each post, you'll show the title and an excerpt; you may also choose to show date, author and category information.
- Search view. This will be used for displaying user search results. It is usually very much like the Archive view: a list of posts, for which you show the title, an excerpt, and any other relevant information.
- Default Page view. This will be used for displaying Pages that do not have custom templates associated with them. Usually this will consist of the Page title and body, and potentially a secondary sidebar.
- Custom Page views. For every custom view identified in the site architecture phase, create a corresponding custom design.
Giving consideration to how a site will be built in WordPress is a tad more complicated than deciding that it should be built in WordPress and then handing it off to a developer; of course, you can do it that way, but it's not exactly the most cost-effective method. Understanding the system, working with a developer from the start, and doing the planning before you dive into design will give you the results you intend, and probably open your eyes to some connections and possibilities that you can then decide how to take advantage of, rather than leaving it up to your developer to see them and decide whether to bring them to your attention. It's a lot to wrap your brain around at first, perhaps, but I've found that the planning pays for itself by smoothing the rest of the process and truly taking advantage of the CMS features built into Wordpress.
