Continuing yesterday’s post on Wordpress (WP) as a content management system (CMS)…

Why Might Online Retailers Give A Whit About WordPress?

The focus of our blog is search and online marketing. Wordpress isn’t an e-commerce platform. It would make a terrible base for an online store. So why are we blogging about all this?

While WP isn’t appropriate for an online store, it is still a handy tool for web marketers.

If you needed to toss up a micro-site quickly, or a content site supporting your selling site, WP is worth considering. (Heck, you could even run your blog on it. )

There are several reasons Wordpress is an attractive choice for a content management system: it is easy to install; it is easy to modify; it is well-documented; it has a great ecosystem of plugins; and it is free.

One disadvantage of using WP for a CMS is that fundamentally WP is a blogging platform. Coercing WP to pretend it is a CMS takes a couple of hours of PHP fiddling.

(Of course, there are many other CMS platforms available, including many excellent free open-source options.)

Whether you go with Wordpress or something else, we strongly recommend using a CMS. The ease and power gained from using a CMS to power your content site is tremendous.

Dealing with our old semi-static site was a hassle. Making changes was too hard, and too often involved IT assistance for check-ins and publishes. Links broke, and content got lost. Yuck yuck yuck.

Many of us here at RKG have run large retail sites with considerable associated content, and frankly we’re still blown away by simplicity and power of a good CMS.

Finally, another reason we’re blogging about our new site is that some of the challenges of platform migration apply regardless of site size. One example of this is preserving URL structures for SEO benefit — more on that topic tomorrow.

One WP or Two?

We’re actually running two Wordpresses on our new site — one for our core site (nicknamed “wp”, which lives at rimmkaufman.com) and one for our blog (nicknamed “rkgblog”, which lives at rimmkaufman.com/rkgblog.)

Why two?

The two sites are different enough to merit distinct installs, and maintaining two is zero additional hassle.

On wp, we use pages for content (for example, pages like http://www.rimmkaufman.com/paid-search and http://www.rimmkaufman.com/website-effectiveness, and we use posts for things like talks and articles.

On rkgblog, we don’t really use pages at all, and use posts in the traditional manner.

To get a common look, rkgblog’s header.php and footer.php are actually linux symlinks to the corresponding files on wp.

The two Wordpresses thus share a single main CSS file.

The one, two, and three-column layouts used on wp are triggered by a class selector on the main body tag, and aren’t used on rkgblog. The CSS gets a bit clever with selectors for switching functionality — much of that is Deb’s handiwork.

A little tip when running multiple blogs: change the CSS so the admin screens are different colors. Otherwise you can get mixed up as to which site you’re working on. Our core site (wp) is pink and our blog (rkgblog) is blue. Here’s a snippet from wp-admin/wp-admin.css for making the admin screens pink:


#adminmenu { background: #ffaaff; border-top: 3px solid #990099;}
#adminmenu a:hover, #adminmenu a.current { background: #ddeaf4; color: #333;}
#adminmenu a.current { background: #551155; color: #fff; padding-bottom: 8px;}


Which Wordpress?

We’re running WP 2.2.2 on both /wp and /rkgblog.

After the holiday crunch, we’ll look at upgrading to a fresher release next year.

Great Plugin: Jack Born’s Safe Include

We like Jack Born’s plugin, Safe Include.

Using this plugin, our programmers can wrap up little bundles of functionality and offer them up as dynamic tokens to our writers, shielding our authors from scary PHP code. SafeInclude uses double braces to mark the tokens.

Here’s an example.

Our Talks page (http://www.rimmkaufman.com/talks) lists our recent and approaching talks at the trade shows. Here’s the content of that page, in full:


<h2> Past Talks </h2>
<div> {{talks_past}}</div>
</div>
<div id="sidebar">
<h2> Upcoming Talks </h2>
<div>
{{talks_future}}
</div>


That’s it. 8 lines. All the dynamic magic is hidden in {{talks_past}} and {{talks_future}}.

{{talks_past}} is just a quickie stub into talks_helper_functions.php:


<?php
require_once ‘talks_helper_functions.php’;
talks_past();
?>


The talks_helper_functions.php lets us refactor common code in one place (DRY). Even so, there’s only a screenful of code to pull and format talks. (Under the hood, “talks” are posts in category 8 with relevant meta information.)


<?php
 
function talks_past() {
$where ="pm.meta_key = 'talk_date' and pm.meta_value <= curdate()";
$orderby = "pm.meta_value DESC";
render_talks($where, $orderby);
}
 
function talks_future() {
$where ="pm.meta_key = 'talk_date' and pm.meta_value > curdate()";
$orderby = "pm.meta_value ASC";
render_talks($where, $orderby);
}
 
function render_talks($where, $orderby) {
global $wpdb;
global $post;
$sql = "
SELECT *
FROM $wpdb->posts p, $wpdb->postmeta pm, $wpdb->post2cat pc
WHERE
p.ID = pm.post_id AND p.ID = pc.post_id
AND
p.post_status = 'publish'AND p.post_type = 'post' AND
pc.category_id in (8) and $where order by $orderby
";
$pageposts = $wpdb->get_results($sql, OBJECT);
if ($pageposts):
echo "<ul class=\"talklist\">";
foreach ($pageposts as $post):
$loc = get_post_meta($post->ID, 'talk_location', true);
$date = get_post_meta($post->ID, 'talk_date', true);
list($dy, $dm, $dd) = split("-", $date);
$date = date('F j, Y', mktime(0, 0, 0, $dm, $dd, $dy));
$who = get_post_meta($post->ID, 'talk_speakers',true);
$org = get_post_meta($post->ID, 'talk_org',true);
$ename = get_post_meta($post->ID, 'talk_name',true);
echo "<li>";
 
if ($date) {echo $date . '<br>';}
echo "<a href=\"" . get_permalink($post->ID) . "\">";
echo get_the_title($post->ID);
echo "</a><br>";
if ($who) {echo $who . '<br>'; }
if ($org || $ename) { echo $org . ' '. $ename . '<br>';}
if ($loc) {echo $loc . '<br>';}
echo "</li>";
endforeach;
echo "</ul>";
endif;
}
 

(Even though — imho — PHP feels like training wheels without the bike, it is fine for quick hacks like this.)

The takeaway for online marketers? Your IT folks can expose functionality through dynamic tokens like {{talks_future}}, giving your writers a simple and secure way to handle database-driven content.

Next Up: You Broke All My URLs!

In the next post in this series, I’ll discuss how we’re migrating from our old URL structure to our new structure — without destroying all our hard-won and much appreciated inbound links.

Beyond the obvious (“use 301 redirects”), we’ll describe our approach, which might be useful to larger sites facing a forced change to all new URLs.

Stay tuned.