We’re migrating our corporate site to Wordpress. Our first article in the series discussed why we’re doing this. Our second article established project scope. This article will dive into some specific strategies and tactics.

We’re a paid search marketing agency. Our people and our technology are top-notch at search. However, we’re WordPress beginners, not experts. Other impediments: we are new to blogging; we develop in Perl, not PHP; and we’re working on this intermittently, just a few afternoons here and there.

So please read our suggestions with all those warnings in mind. We hope this series helps others implementing WordPress as a CMS. And, hopefully, we’ll benefit from comments from real WordPress experts out there.

This process seems to be working for us. Your mileage may vary.

1. Install WP2.x.

   Don’t waste your time trying to work with an older version. Many of the plugins you’ll need will require WP2. If you’re building a fresh site, use a fresh modern WordPress install.

2. Use one WP install for your CMS; use another for your blog.

   You’ll be playing enough games with your templates and plugins to coerce WP to look like a CMS. Don’t make your life more complicated by trying to use one install for both your blog and your core site — you’ll end up with conditionals everywhere. Easier to have two installs.

3. Set up a Technorati account for just for this project.

   Install the little browser widget (we use the FireFox version) so you can tag pages with a single click. You’ll be bouncing across the web reading documentation. It saves a time to tag every useful page you encounter so you can find it again later. It also helps share knowledge between the different folks working on the migration.

4. Use pages, not posts, for your static content.

   That is WP wants you to do and it works better.

5. Start with a sitemap.

   Use Visio, Excel, Denim, or good old pen and paper, but start by sketching out the static pages you’ll need. We thought our corporate site was small — it is — but we ended up with over 40 distinct pages nonetheless.

6. Map your sitemap onto a WP page hierarchy.

   With your sitemap in hand, create empty pages for every page on the site. Try to write decent titles and post slugs, but don’t obsess over them at this point. What is important is to make sure the pages are organized intelligently into subpages and, if needed, subsubpages. If you’ve already planned your hierarchy, this should take 10 or 20 minutes of rote button punching. For a huge site, one could script this by pumping data directly into the WP database tables.

   Here’s an example of our site hierarchy from earlier in the week. Following WP conventions, a leading dash indicates a subpage, a leading double dash indicates a subsub page, and so on. (Note the dashes aren’t part of the titles; they’re presentation chrome put on by wp-admin/edit-pages.php.)

   
ID Title
27 About RKG
29 — Management Team
25 — — Alan Rimm-Kaufman
26 — — George Michie
57 — — Larry Becker
62 — — Greg Brennan
28 — Retailer Background
30 — Affiliations
37 — Guarantee
19 — Jobs
50 — — IT
51 — — — About IT
53 — — — IT Intern, Summer '07
21 — — — Senior Developer
63 — — — Developer
52 — — About RKG
49 — — CS
20 — — — Analyst, Client Services
54 — — — Marketing Internship, Summer '07
55 — — Job Footer
31 Search Marketing
46 — Paid Search
32 — — Brand Versus Non-Brand
33 — — Search Technology
34 — — Shopping Feeds
35 — — Client Service
36 — — Pricing
38 — Natural Search
39 Web Effectiveness
40 Speaking & Writing
41 — Articles
42 — Speaking
47 — — Slides
43 — Studies
44 — Press Center
45 Contact Us
48 — Driving Directions
65 — Privacy Policy
66 — — Compact Privacy Policy
64 Home


7. Use a /home for your homepage.

   You have several choices on how to handle your homepage. One option is having simple html or php page entirely outside of WP, served directly by Apache. We dismissed this option because (a) you then have hassles keeping the header and footers consistent, and (b) site maintainers can’t edit the homepage through WP. Another option is putting homepage content in the index.php (aka Main) template. We did this until we figured out it is a bad idea, as it violates the keep content and presentation apart rule, generating confusion and unhappiness. The best option, in our opinion, is to place your static homepage content in a page called /home, and use static homepage plugin. This keeps all the standard top and bottom nav out of the /home page, and instead in the page.php template.

8. Breadcrumbs, if desired.

   At this point, the Breadcrumb Navigation XT plugin should get you nice bread crumbs, if you want ‘em. We made small tweaks, supressing crumbs on the home page (as they are redundant and confusing there) and using the » symbol as our crumb delimiter. (Note: we installed the code markup plugin on both our CMS wordpress install and on our blog wordpress install to display code snippets.)

   if (class_exists('breadcrumb_navigation_xt')) {
   // new breadcrumb object
   $mybreadcrumb = new breadcrumb_navigation_xt;
   $mybreadcrumb->opt['separator'] = '»';
   $mybreadcrumb->opt['static_frontpage'] = TRUE;
   $mybreadcrumb->display();
   }
   ?>

   


   Use is_home() to turn off crumbs and unwanted nav on the homepage.

9. Contextual nav, if desired.

   Many sites show a sitemap in the left or right nav, with sections “folding” in and out. Typically, contextual nav trees show the ancestors of the current page, the siblings of the current page, the immediate children of the current page, as well as all top level pages.

   Here are two examples. When someone is viewing our ‘Paid Search’ page, the nav should look like this:

   
* About RKG
* Search Marketing
oo Paid Search
+++ Brand Versus Non-Brand
+++ Search Technology
+++ Shopping Feeds
+++ Client Service
+++ Pricing
oo Natural Search
* Web Effectivess
* Speaking & Writing
* Contact Us


   And when they’re on our ‘Contact us’ page, the contextual nav should fold to look like this:

   
* About RKG
* Search Marketing
* Web Effectivess
* Speaking & Writing
* Contact Us
oo Driving Directions
oo Privacy Policy


   While this is hard to explain, it makes sense in practice. This nav folding is easily accomplished by the well-written Fold Page List plugin. If you want contextual nav, this is the plugin for you.

   As a good usability rule of thumb, try to make sure pages never link to themselves . Jakob Nielsen named this the tenth of the Top Ten Web Design Mistakes of 2003. It is still often violated today. The never-self-link rule applies to top nav, breadcrumbs, bottom nav, contextual nav, the homepage logo, everything. If you can’t easily omit the self-links, at least fake it by rendering them as non-links using CSS. (Sorry to the purists for that suggestion.)

10. Don’t hard-code permalinks in pages.

    Your static pages will reference one another, and it is tempting to just cut-and-paste internal links via their permalinks like this: href="http://myblog.com/some-other-page". We suggest avoiding this, as it makes your content brittle to any changes in your permalinks.

    As we described in our second post in this series, our WP CMS lives at rimmkaufman.com/wp for the time being. We’ll later hide all the /wp stuff through heavy rewrite rules, to be described later. If we embed links to, say “/wp/search-marketing” in our top nav, we don’t want to have to go back and edit this to remove the “wp”, nor do we want the site issuing 301 redirects on every internal site click to remove the “wp”.

    Our solution is to reference every page by number in posts and on pages. Page IDs should never change, even when page slugs and/or permalink structures change. For aesthetics and SEO benefit, we can remap these numbers to permalinks on the fly using a filter, so outsiders never need see the ugly IDs. Thanks, Wordpress, for offering so many nice hooks.

    Here’s a tiny 8 line plugin that accomplishes this remapping across the site:

    
/*
Plugin Name: RKG Page Permalinks
Plugin URI: none
Description: change "/index.php?page_id=\d+" links into permalinks
Version: 0.1
Author: RKG
Author URI: http://www.rimmkaufman.com/rkgblog
*/
// changing permalinks breaks links embedded in pages.
// to avoid this, we'll use the "/index.php?page_id=25" syntax to reference
// wp pages from other wp pages and wp posts.
// we install a filter to modify all these links into permalinks on-the-fly
// thus, these keep working when we modify permalink structure.
// note this strategy fails gracefully in the absence of this plugin or if the regexp
// doesn't match correctly (in contrast to inventing our own page-link-by-number
// syntax) because WP accepts "/index.php?page_id=25" as valid syntax to reference a page by number
//
// see also: http://codex.wordpress.org/Filters
// see also: http://codex.wordpress.org/Template_Tags/get_permalink
// see also: http://codex.wordpress.org/Linking_Posts_Pages_and_Categories
function quoted_permalink ($num) {return '"' . get_permalink($num) . '"';}
function rkg_pagepermalinks($content) {
// case one: relative index link (so by definition is on our site)
$pattern = '/"\/index.php\?page_id=(\d+)"/e';
$content = preg_replace($pattern, 'quoted_permalink(${1})', $content);
// case two: absolute index link (must make sure is on our site)
$pattern = '/"http:\S*rimmkaufman\.com\S*\/index.php\?page_id=(\d+)"/e';
$content = preg_replace($pattern, 'quoted_permalink(${1})', $content);
return $content;
}
add_filter('the_content', 'rkg_pagepermalinks');
?>


    Make sure to modify the ‘rimmkaufman’ in ‘case two’ to match your domain.

11. Use safe-includes to put code in content.

    It is easy to put php code in a template — indeed, php code is all a template is. For security, and to separate code from content, WP makes it hard for you place php code in posts. There are times, though, when you need a smidgen of php on a page. For example, we place the current date atop our jobs page to indicate the page is fresh. (It is; we’re hiring.)

    While there are several plugs which allow php in pages and on posts, we opted to use the Safe Include plugin. Rather than allow arbritrary code in posts and pages — which could be a major security hole — Safe Include makes you define a chunks of text via external files which are then be included via double braces: . This offers more protection from user mistakes and from bad guys than the php exec plugin.
12. Use subpages and the page hierarchy to include common content.

    Some areas of the site have common chunks of content. For example, we end each job posting with a common slug of benefits:

    RKG benefits include 17 paid vacation days; 9 paid holidays, including your birthday; profit sharing plan;
401k plan with company match; health insurance; great weather; blah blah blah

    We don’t want to repeat this slug manually on each post, as they’ll get out of sync. We don’t want to mangle the page template, as (1) this slug is content, not presentation; and (2) we want site maintainers to be able to edit the slug easily. Likewise, we don’t want to use the Static Include plugin for such slugs, as site maintainers couldn’t edit them through the WP interface.

    Our engineers proposed including chunks of content by exploiting subpages and the page hierarchy. The following snippet lives in the page.php template. Here’s their trick:

    
if (!is_home()) {
// here's how we do page includes
// include page 55 on page 19 and all of 19s descendents
$footers = array('19' => 55);

    $p = $post;
    while ($p) {
    // dont include page on itself
    if (array_key_exists($p->ID,$footers) && $post != $p->ID) {
    $f = get_post($footers[$p->ID]);
    echo "\n" . $f->post_content . "\n\n";
    break;
    }
    $p = $p->post_parent;
    }
    }
    ?>

    What this code does is insert page 55 (“Job Footer”) on page 19 (“Jobs”) and on all of page 19’s subpages. Slick. We could easily add other pages to other parts of the hierarchy as well. As example, changing

    $footers = array('19' => 55);

    to

    $footers = array('19' => 55, '29'=>66);

    would also place our compact privacy policy on the bottom of all our management team bio pages. That’s not something we’d ever want to do, but it illustrates the point.

13. Put more important content higher in the source.

    For modest SEO benefit, it is helpful to place core page content above generic page content. We’ve opted to place our right contextual nav at the bottom of the source, versus the more customary place at the beginning. We’ll use CSS to render this element where it belongs, on the top right of each page.

Well, that’s about all for this installment in the series.

With the page framework of the site in place, we’ll next be turning our attention to tweaking our marketing content.

And, as described in a previous post, we’re also working finishing up the code to use WP posts (not WP pages) to handle our “upcoming” and “recently occurred” events, as well as the date issues involved in our print articles in the trades.

A very happy New Years to all — may 2007 be full of health, peace, and success for you and your family. See you next year!

Technorati Tags: Blogging, Web Usability