Porting WP to MT: template tips

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:

<div class=”container”>
<div class=”wholething”>

<div class=”mainblog”>

<div class=”menu”>

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>

<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:



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.




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>

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.


Noggin Blogging and WP to MT permalinks

I don’t remember hitting my head at any time, but I have painful and biggish swelling a couple of inches behind my left ear, about the size of a lime; the scalp in front of it is numb, and my ear and jaw hurt a bit. I’d like to say that I went out on the town last night, indulging in all forms of vice, waking up in strange surroundings with a lump behind my ear, a rose in my hand, and no memory of how I got there – but I spent last night watching the movie, “Love Actually”. It actually wasn’t bad (interesting insight into what the Brits would like their PM to say to the US President), but it sounds so mundane. I also watched “Hellboy”, too. Double matinee.

I may have picked up another tick, and since I’m allergic to their bites, this reaction wouldn’t be unusual. Or perhaps I’ve been thinking so hard about tool independence in weblogging that I’ve sprained my brain.

Speaking of which, I managed to convert the main page template, in addition to porting one of my WP plugins to the new MT/PHP plugin environment. I’ll detail these in two separate posts, following.

I won’t get into installation issues, as these are documented at the Movable Type site. About the only problem I have with the new PHP dynamic pages is that accessing the directory of the weblog without giving an ‘index.php’ or ‘index.html’ fails within the current installation, as you can see clicking here. You have to access the page specifically. Since Six Apart has come out with a 3.11 release, and I haven’t installed it, perhaps this is fixed in that.

Turning to the move, now:

One of the areas of most concern when it comes to moving between weblogging tools is permalink breaks, as the tools handle permalinks so differently. When I get into moving the Movable Type weblogs into other environments, I’ll detail what you need to do to ensure a clean port in these environments, and it is a challenge, as is moving between other environments; but for once, the direction of the move today, from WordPress to Movable Type, is absolutely problem free.

The script I used to export WP entries also exported what is known as the ’slug’ – the filename given for the specific entry. This can be the title of the entry with dashes between words, or some abbreviation that an individual provides. The slug is exported as a MT keyword, and imported accordingly. Since the slug is exported with dashes, complete and ready to use as a filename, then it’s only a matter of providing a Archive File Template entry for the Individual archive:

<$MTArchiveDate format=”%Y/%m/%d”$>/<$MTEntryKeywords$>/

The above matches exactly with the recommended WordPress permalink structure of YYYY/mm/dd/slug/. No filename extension – none needed since the .htaccess entries handle file serving. An absolutely painless port as regards permalinks.

In fact, if we were pushing for standardization across weblogs, I think that WordPress set the direction on this one – providing a field with the entry where the person could put whatever they want for the entry filename. With this, no worries about dashes as compared to underscore, or titles too long, or anything of that nature. This is a simple addition to the databases, too.

Once the file structure is working, then it’s a matter of porting the template, covered in the next post.

I also spent time today reading the reactions of the guys out at the Yahoo Groups, MT Plugin Development mailing list as they basically beat the shit out of the new PHP-dynamic environment within MT. Personally, I rather like the new environment. And this gave me an idea: I figured since all these gentlemen aren’t interested in porting their Perl-based plugins to PHP, I would do it for them. For a fee of course. After all, they’re now part of the new Six Apart Professional Network; they’ll be rich as Croesus.