The two environments, Movable Type and WordPress, are very different. Apart from one using Perl for core functionality, the other PHP, another significant difference is that WordPress uses PHP function calls directly in the template, while MT uses template tags, and then relies on the Smarty Template Engine (more on this in a separate post), for the dynamic page option. Still, the weblog page templates for both tools have a very similar structure regardless of type of template element. This structure is as follows:
Header: This includes in pre-HEAD tag code or HTML, which should be left alone in the new system. This also includes all the data between opening and closing HEAD tags.
Blog Body: This includes the opening and closing DIV element tags to wrap the entire weblog, and usually will include the TITLE and DESCRIPTION if one is used for the weblog.
Main Loop: A main loop has enclosing tags or other delimiters that marks the beginning and ending of the list of entries on the page.
Loop Body: This includes the post body, date, title, trackback RDF statement, comment count, any of the items included with each entry on a weblog page.
Sidebar(s): Depending on how tightly integrated you are with the product, you may not have to do anything more with sidebars then copy directly.
The Header should be left as close as possible to what you find. About the only modification you’ll make is to change the name of the stylesheet to the you’re using currently with WordPress (if porting from WP to MT). One important key to making a move easier is to leave your stylesheet alone, and change the template, rather than working with the new template, and trying to change the stylesheet. The reason is that the templates will be very similar in organization, and thus easier to migrate; but stylesheet differences can be considerable.
(Now you can just use whatever stylesheet name comes with the new tool, such as styles-site.css in MT,and copy your old sheet settings into the new file. Make a backup first of the MT one – you might like to keep bits of it.)
In Blog Body I specifically refer to DIV elements forming the body of the page, rather than HTML tables. The reason is because HTML tables can complicate the porting process because they layout will most likely differ considerably between your old template and the new default template. In fact, you might want to consider converting your HTML table to CSS before moving tools.
The use of DIV elements and CSS aid tool independence because most weblog tool templates now use DIV tags for layout, and it becomes a fairly simple matter to deduce the layout in the new tool and map to the old.
Case in point:
My WordPress blog body opening tags are as follows:
<body>
<div class=”container”>
<div class=”wholething”><div class=”mainblog”>
<div class=”menu”>
Burningbird
</div>
Compare this to the Movable Type default template:
<div id=”container”>
<div id=”banner”>
<h1><a href=”<$MTBlogURL$>” accesskey=”1″><$MTBlogName encode_html=”1″$></a></h1>
<h2><$MTBlogDescription$></h2>
</div><div id=”center”>
<div class=”content”>
Both of these blocks of template-driven HTML are the beginnings of the BODY element, just before the main loop. Though the template tags are different, the structure is the same and that’s key for making your porting job simpler.
One caveat from this example: Though I replaced the existing MT template with my own design, pulled directly from my WP weblog, I may be alter the page to return parts of it. For instance, I’m not using a header tag (H1) for my page header. By not using a header, I’m removing some of structural semantics from the document.
A better approach would be for me to redefine the ‘menu’ DIV as a header element, contained within the mainblog element, so that I can reserve the default H1 for other uses:
.mainblog H1 { ….}
In addition, I’m embedding the weblog name directly in the page, and though there’s nothing wrong with this, a better approach would be to use the weblog tool’s template tag/function call. Again, this helps map your old style to new, as most tool’s default templates use a template marker for the title.
The next section of the code is the main body, contained within the ‘main-loop’. Movable Type marks the loop with an opening and closing tag:
<MTEntries>
…
</MTEntries>
WordPress has:
<?php if ($posts) : foreach ($posts as $post) : start_wp(); ?>
…
<?php endforeach; else: ?>
<?php _e(’Sorry, no posts matched your criteria.’); ?></p>
<?php endif; ?>
Though one is a template tag and the other is PHP code, the differences aren’t critical as long as you recognize the begin and end of the loop, and know that the post processing is contained within it. As for the actual values, loop code or template tags, leave them as is unless you’re very comfortable with the tool and the code.
As for the post itself, again, the similarities are more common than not, reflecting a fairly common data model associated with weblogging posts. Typically, a weblog post will start with a title, which may or may not have a permalink wrapping it. Following may be a list of categories, or not, and then the post text. At the end is a line or two containing the author’s name, date, permalink, and probably a comment count.
Title
(categories)
Body
Signature permalink date comments
All tools use mnemonics for naming, so it’s not hard to tell what function or template tag does what, especially when you see the element within the context of the page. So, best approach to port your design is to open your old template in one browser window, and edit the new template in a second. Or use browser tabs to hold each.
As an example, if your post footer has a permalink wrapping around the post’s title in WordPress:
<a href=”<?php echo get_permalink() ?>” rel=”bookmark” title=”Permanent Link: <?php the_title(); ?>”><?php the_title(); ?></a>
It’s a matter of mapping this to the appropriate MT template tags:
<a href=”<$MTEntryPermalink valid_html=”1″$>”><$MTEntryTitle$></a>
As you can see, WordPress’ function get_permalink maps to MT’s MTEntryPermalink, and the the_title to MTEntryTitle. Any other differences between the two are syntactic sugar: PHP function call compared to MT’s angle brackets and dollar signs.
My hopes are to do a one-to-one mapping between MT and WordPress elements in table format when 1.3 comes out.
After the main-loop is the sidebar in most tool templates. A main body as first block followed by a sidebar layout is the cleanest design you can provide–default templates shouldn’t be pretty as much as they should be simple, clean, and uncomplicated; easy for the user to modify. Ease of use beats out pretty any day.
Sidebars can vary considerably, depending on what you include. Most include a reference to recent posts, categories, and comments, and probably a blogroll. Most tools provide a simple template tag or function call to provide the listing of each of these.
In my WordPress template, the function call to return the ten most recent entries is:
<?php get_archives(’postbypost’, 10,’other’, ‘<div class=”sidecomments”>’, ‘</div>’, 0) ?>
The same functionality in MT is an opening and closing loop block, and a tag for each entry:
<MTEntries lastn=”10″>
<div class=”sidecomments”><a href=”<$MTEntryPermalink$>”><$MTEntryTitle$></a></div>
</MTEntries>
Again, intuitively similar. But this example leads to another adaption I may make to my original WordPress weblog design, based on my work with the MT converstion.
The original MT template actually uses an unordered list UL and list items LI for each entry, while I’ve been using a separate DIV element for each. Again, the MT approach is better because it preserves the structural semantics of the list. In addition, it’s also the approach that WordPress and most other weblogging tools use. And anything that makes mapping between the tools in the template easier, is goodness.
I used UL/LI with categories in the new Movable Type template, using CSS to remove the list bullet graphic and modify the appearance so that it resembles my existing ’sidecomments’ style.
The only sidebar item in the new MT weblog that doesn’t use existing tags is my Recent Comments. This is a custom plugin in WordPress, and I’ll need a custom plugin in Movable Type. I’ll cover this in the next WeblogTweaks post, as well as provide an introduction to the spiffy new Movable Type PHP dynamic plugin environment.