Category: Weblogging

In the last post, I said I was a pusher of code, not a designer. As a pusher of code, then, I do feel comfortable commenting on the user of Atom or RSS for an import/export format.

Danny Ayers recently pointed out that there’s a new Atom format spec. Good, clean writeup with an interesting twist in the Introduction:

Atom is an XML-based document format intended to allow lists of related information, known as “feeds”, to be synchronised between publishers and consumers. Feeds are composed of a number of items, known as “entries”, each with an extensible set of attached metadata. For example, each entry has a title.

The primary use case that Atom addresses is the syndication of Web content such as Weblogs and news headlines to Web sites as well as directly to user agents. However, nothing precludes it from being used for other purposes and kinds of content.

That’s a bit like saying, “Here now, we have a specification for the banking industry wot would be a good spec for those of you who run petrol stations, what say?”

In my opinion, Atom, as with RSS, make a great syndication format, but there’s too much of the underlying purpose to the format to make them exceptionally good for universal weblog transforms, including pushing weblog data from one tool to another. For instance:

• Each item in Atom, or RSS for that matter, has a link associated with it. I suppose one could use this to hold a slug, or filename, but the two are not the same information.
• Atom has the concept of an identifier, atom:id, which doesn’t translate well in weblogging terms. Each tool would have it’s own unique identification system.
• Too many of the fields are associated with the mechanics of the feed, such as atom:generator. While this is essential for syndication feeds, there’s no need for this in weblog migration. Though you can say it’s optional, if you find there is no fit in the business for most (all?) of the optional bits, then you may be looking at a poor fit, overall, between the spec and the use.
• There is a lot of data missing in Atom. Keyword-value pairs is something I think a format has to support. There isn’t anything in the specification to do with categories, or how hierarchical categories would be managed. One could say the same for comments – right now they have to be artificially transformed into little feed items, when what they are, are comments to a post, not individual feeds.

The latter item is the kicker for me. If you say that one can extend the model to include this extra data since Atom supports namespaces, why not take this a step further and say, well, then we’ll go with a new model specifically focusing on migrating data between tools; a syndication feed is not the same thing as porting an entire weblog between tools.

Of course, saying something like “Atom is not a good fit for this purpose” is similar to invoking the Lazy Web to have it done, and I’m sure a dozen feeds will be created that use Atom, or RSS, to produce and consume migration data. However, I’m not saying it can’t be done; I’m saying that the forcing a specification for one purpose into being used for another purpose will, in the long run, be more trouble then its worth. Especially when you consider the political ramifications to using a syndication feed.

One could write a tool that both exports and imports data directly into the database, rather than interfacing through the tool, but this is not a comfortable option for many non-geeks. They could be concerned, and rightfully, that the underlying data model could change for the tools, and what worked one time may not work the next. The best approach is to use something that tools support, so that users have a degree of comfort with the post.

What we don’t need is one tool using an RSS formatted import mechanism, while another uses an ATOM formatted export. Asking all tools to support all syndication formats for weblog imports and exports is a bit much; generating multiple syndication feeds is a matter of a new arrangement of tags, but consuming the different feeds is a whole different game.

At the same time, telling people who are already apprehensive about learning a new set of template tags that they need to transform the output generated by one tool before it can be used the another (oh, and there will probably be loss of data between the two) is a Geeks Choice response.

I spent time yesterday working with the three sites ported from Movable Type. While I port each individual’s current look, I set up a PHP-based switcher they could use to try out some of the available WordPress Themes. There has been criticism that WP doesn’t look that great out of the box. I think the issue is that it doesn’t look like Apple wrote it – rounded corners and shaded lines, with bright lollypoppy or balloony colors. What the current style is, is functional. Best of all, it has a very clean layout that makes it easy to play around with different looks.

Loren gave me an okay to show what his site will look like under different themes. Here it is, in just a selection of the styles I moved into their sandbox environment:

Extreme Dark Time

Outback Dark Time

Silver Dark Time

Dots Time

Wp New

Serene Time

and

a kinder, gentler Loren

The switcher only works if you add the URL parameter wpstyle=whateverstyle to each page.

There are a whole lot more themes, but I noticed that some of the styles suited Loren’s writing style, some did not. For instance, some of the styles had writing blocks that fit across most of the page. These did not suit th poetry that Loren embeds in his page, leaving far too much white space to the right. Loren’s own style extends to fit the page, but he has a large enough sidebar to balance it.

The Pink Lilies narrow writing space would work for his style of writing, with his symmetrical paragraphing, and good use of visual breaks. However, it would not work well with Loren’s use of photographs. If he used smaller photos, it might work within the layout, but the graphics would compete with the image. And if you used photos embedded directly into the text, a triple column format with images could be too fussy, unless you kept the use of geegaws to a minimum.

Weblog style is more than just a matter of taste and what colors you like, or whether you’re into that Apple thing with the rounded and the shaded and the aluminized faux future looks. The style has to not only work with what you write but how you write, and other material included. Shorter paragraphs demand more narrow columns; larger photos need a style that can accomodate, without the sidebar pushed down below the main content; poetry shouldn’t have excessive white space showing on any one side.

However, I’m not a page designer, so take my opinion with a grain of salt.

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.

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.

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.