Year: 2004

A trackback got through on MT, and ended up causing a rebuild that overwrote the stylesheet, index.php (which is the WP template), and various other files. Luckily, this time I had backups.

Trackbacks should have been turned off, but with all the hacks to overcome spamming, turning TB off in the database isn’t reliable.

If you do move from MT to WP, you’ll have to move the MT installation. Completely. You can’t trust that something won’t sneak through and cause a rebuild.

Recovered from the Wayback Machine.

Right off, I’m going to issue a disclaimer: If you want to change weblogging tools to reduce how much you have to tweak your tool installation, forget using WordPress; at least for now. The product is barely in version 1.0 release, and some major changes to the code are being made for version 1.2. Even after this release, WordPress will require tweaking of the template code for at least some time to come; even if the tweaking is only function calls.

I don’t want people to move to WordPress because I said so, or because I moved to the product–not that any of you would–without being aware that this tool is going to take some effort. In particular, if you’re a Movable Type user, it’s going to be very unfamiliar and you are going to be dabbling your fingers in PHP code unless you go with one of the pre-packaged themes that are available.

Having said that, why should you consider moving to WordPress?

The primary reason I wanted to make this move, as already discussed, is that I like the thought of using an open source tool. I like knowing that I may have some influence on future directions of the tool. At a minimum, I can even code some of the functionality I might want, or help out documenting the product at the Documentation wiki.

Of course, another reason is the nextpage feature I already discussed, but this is pure gravy – I like the fact that I can dig my fingers into the tool and maybe pull up something special from the depths.

I’m also intrigued by the energy level of the people working on the product, and some of the innovative ideas they’re coming up with. I think that’s one of the good things that can happen from an active open source application, with a lot of minds from a lot of different backgrounds all churning up interesting ideas, and new perspectives.

And did I happen to mention how fast it is? Not just with posting, but also with comments. No lagtime, at all. Wonderful.

BUT, if you’re not comfortable with touching PHP (for function calls); or with having to maintain more careful procedures with the product (think about me accidentally deleting my main page template), then you might want to consider either staying with Movable Type, or moving to one of the commercially supported projects.

Still here? Okay, then–let’s do some damage.

(Note: You also may want to wait for version 1.2. This way, you can start fresh with the new infrastructure.)

Installing WordPress is simple – following the five minute installation, and make sure you start with a fresh database and you’re ready to go. For those of you using Movable Type, though, I recommend installing the tool in a separate subdirectory for now–to play with until you’re comfortable with the product, and to start making the modifications to the templates to incorporate your look and feel.

Once installed, you can take a quick look around at the product and try posting a couple of posts, and maybe check out the comment management. WordPress, at this time, does not support comment registration, but it does support moderation. When you turn on moderation, comments are held in a queue until you okay them for posting.

Now is the time to look at all of the pages – all of them. Now is also the time to spend some time at the Documentation wiki, going through the pages–in particular, check out the hacks–and also at the WordPress support forums. In fact, if you have the time, spend several hours going through the support forum threads for the past month or so. Much of the information you’re going to want to know at some point is in this forum. You can also use the search facility to search through the forum postings.

If I had spent time especially going through the existing WP hacks (similar in concept to Movable Type plug-ins), I would have realized that the code for my category icon display had already been created by Matt the lead developer of the open source team feverishly working on release 1.2. In fact, I think Matt even mentioned this in my comments, but I didn’t understand the reference at the time. I do now.

However, my code isn’t quite the same since I’m using SPAN tags to remove the block-level nature from the images, and a few other odds and ends. Still, why code if you don’t have to? Check out the hacks.

Among the hacks I will be installing, eventually, are the following:

automatically shutoff comments. Since WP is dynamic, you don’t have to rebuild to shut off comments. The best way to manage comment spam is, and will remain, turning off comments on posts over 30 days old.

I have my own code for recent comments with some special formatting, so I won’t be installing the hack for recent comments. In fact, I have turned my code into a hack, and once I clean it up to use Wordperfect’s database functions, I might upload it as an alternative.

There’s several hacks for statistics, but I’m pretty happy with the applications that come with my web server.

I’m definitely interested in several hacks from this site including one that will backup both the WordPress database, and the files that are usually customized, such as the template.

There are others, including a WP version of mt-blacklist, that will keep me hacking for awhile, but I don’t want to go too crazy. WordPress version 1.2 will be releasing a newer, cleaner plug-in interface that will eliminate the need for ‘hacks’. In addition, the release will also have many of the features that I want now, but don’t have: including post preview and comment preview.

Not having post preview leads to the next thing I want to cover: what you can expect from the user interface.

The WordPress interface is fairly plain and usable, but there are features you’re used to with MT that you won’t find with WP. At least, with WP 1.02.

First, you can only create one weblog in a WP installation. You can copy the code (it’s not very big), and create a new set of tables within the same database (different names) for another weblog, but you can’t do it in one button click.

Second, there is no page that lists all of the posts, simply and cleanly, and neither is there a power editing page. Not yet anyway, and I say this because I will build it if it’s not planned for version 1.2. Right now, published posts display, most recent at the top, in the Edit page; including much of the text of the post, which can get cluttered. You also have a dropdown box with the titles for the last several posts, and you can search for a specific post. Click on one of the posts, and it will open in the Edit page, ready for editing.

This is for published posts. You won’t get this for drafts. In fact, drafts are going to surprise you.

I wonder if I’m one of the few people that has a lot of draft posts. The reason I ask this is seeing how WordPress handles these. Rather than in the list with the published posts, these draft posts are listed, one after another, across the top of the page.

I would strongly recommend that you deal with draft posts before exporting and then importing your MT entries into WordPress.

Also notice in the image that the are relatively darker lines around each of the web page elements. The initial installation for WordPress using the light gray color (#cccccc) for all outlining, but if you’re like me, this color is hard to see and that makes the form harder to use. The first thing I did when I installed WordPress is open the wp-admin stylesheet, called wp-admin.css and change the fieldset and textarea borders to #333333, and add a border around all input fields. It may not be as elegant, but it sure is a lot easier to use. At least for myself.

(If you want a copy of my stylesheet, holler. These changes are the only ones I made.)

Another change I made was to set the path location for archived files. I follow what has become a defacto standard among webloggers now, and use a combination of date and file name for my individual archives. These pages aren’t physically created, but thanks to an addition to the .htaccess file, your users won’t know the pages don’t physically exist.

The .htaccess modification is generated for you via the Permalink option, found in the Options menu. If you use the recommended archive setting, given in the form and below, you’ll get archive pages like many of you already have implemented in Movable Type:

/archives/%year%/%monthnum%/%day%/%postname%/

Clicking the button will generate the code, and you just copy and paste it into your .htaccess file, if one exists. If one doesn’t, just create it using a text editor. Make sure you include the period (’.’) preceding the htaccess filename.

(My use of this format puts my new pages out of synch with my existing MT files, and they’re still on my site. Until I come up with an elegant redirect solution for handling what is now my sixth file naming convention change since I started weblogging, I’ll just leave the files. Comments are turned off, so it’s not an issue.)

Once you’ve looked around and played around and set your archive and all of you base weblog options (Name of weblog, whether to ping weblogs.com, and so on) then you’re ready to import your MT entries. I would suggest doing this before updating the templates.

After you clean up your MT databases – no need to bring over garbage– export your entries using the MT export facility to create a file containing all the posts, comments, and trackbacks. I exported close to 10,000 comments and several thousand posts and trackbacks, and didn’t have any problems with either the export or import. At least, not that I can see in the recent postings. As for the old postings, eh, such is life.

There is a file in wp-admin called import-mt.php. Access this in your browser and make the modification that it tells you to, to set where the exported MT file is located. When you run it after this change, you’ll get a listing of all the imports being made until you get a message that all is done at the end. If something happens, just run it again – the import tool doesn’t load duplicate records, so you can’t double load the same entry.

Once run, you’ll see that the tool made the appropriate categories to match those in the import file, as well as any author names from the file. Each user is created with a default password, ‘changeme’, and you’ll need to immediately go in as the user and reset the password.

(Also note that at this time WordPress passwords are stored in plain text, not encrypted format, in the database. Not sure yet whether there is plans to encrypt passwords in the database in the future. However, only the administrator of the site should have database access so this isn’t too bad a problem now…but it is one I hope is addressed in the future.)

You won’t be able to see draft mode posts, even as administrator, that belong to another person. You’ll have to log in as that person to see these posts.

After importing would be a good time to run the script to backup the database and the files that are normally modified. Just follow the readme instructions with the script.

At this point in time, you’re ready to start customising the templates, and adding your own code, if you wish.

The main page template is called “index.php”, which is a fairly vulnerable circumstance. Especially when you move your WordPress installation to your MT site, and then you accidentally update something, anything, in MT. If your MT installation is also based on “index.php” for the main page, kiss the template good-bye. You can see why frequent backups are critical.

There are several template files including ones to generate the RSS and Atom feeds (which you may not need to modify, unless you want to remove the full feed content encoded tag, which I did), one for comments, and trackbacks and other pages, which you probably won’t have to change.

Most of the PHP script is blocked off with comments that tell you not to touch it, or consists primarily of PHP function calls surrounded by the PHP begin and end tags. A portion of the template from my file is below, so you can get a feel:

<div class=”blog”>
<?php if ($posts) { foreach ($posts as $post) { start_wp(); ?>

<?php the_date(‘’,'<div class=”date”>’,'</div>’); ?>

<div class=”blogbody”>
<a name=”post-<?php the_ID(); ?>”></a><?php the_image_category() ?><div class=”titlebox”><span class=”title”><a style=”text-decoration: none” href=”<?php echo get_permalink() ?>” rel=”bookmark” title=”Permanent Link: <?php the_title(); ?>”><?php the_title(); ?></a></span></div>

<?php the_content(); ?>

<p><?php link_pages(’<br />Essay pages: ‘, ‘<br />’, ‘number’); ?></p>

<p><span style=”font-family: Cursive”>Shelley</span></p>

<p><a style=”text-decoration: none” href=”<?php echo get_permalink() ?>” rel=”bookmark” title=”Permanent Link: <?php the_title(); ?>”><?php the_title(); ?></a>
<?php comments_popup_link(’No Comments’, ‘1 Mousie Squeeked’, ‘% mice roared’); ?></p>

<!–
<?php trackback_rdf(); ?>
–>

</div>

<?php } } else { // end foreach, end if any posts ?>
<p>Sorry, no posts matched your criteria.</p>
<?php } ?>
</div>

This is the entire template to handle my main page contents (excluding sidebar) –including the title bar with the icons. Not bad, really.

As you can see, it’s similar to MT except that instead of template tags, you use PHP function calls. In some ways, I prefer function calls, as it’s easier to figure out how to put in parameters (as compared to template tag attributes.

Needless to say, you’re going to want to carefully go through the template tag documentation.

Now, index.php also handles archives and individual entries and categories. This might be okay if you want to have the same look and feel with each page. I don’t, so what I did was created specialized versions of the pages for each of these functions, and then add a few extra tweaks to the .htaccess file to ensure these pages are used instead of index.php

I created a page, category.php, to handle category archives. The code is basically the same, except that I removed the post contents. Some of my categories have several hundred entries, many with photos. A page consisting of all the contents for these wouldn’t finish loading until your 3-year old child was ready for college. In addition, I removed most of the sidebar contents, because I like my archive pages to be clean.

To ensure that category.php is accessed, I modified the predefined .htaccess entry given with WP for categories to the following:

RewriteRule ^archives/category/?(.*) /category.php?category_name=$1 [QSA]

Prior, this rewrite rule was directed to index.php, rather than category.php. That’s the only change you need to make.

For my individual archive page that lists the last 50 entries, I used the WP function get_archives, passing in the following parameters:

< ?php get_archives(’postbypost’, 50,’html’, ‘’, ‘’, 0) ?>

This creates a list of 50 entries, all nicely formatted and ready for clicking. This is added to the archives.page, and a link to this page can be found on my main index page.

I also created an individual page, and the code is again, about the same, though I added my own formatting for the display of the comments. I called this individual.php and modified the entry in .htaccess for individual entries:

RewriteRule ^archives/([0-9]{4})?/?([0-9]{1,2})?/?([0-9]{1,2})?/?([0-9a-z-]+)?/?([0-9]+)?/?$ /individual.php?year=$1&monthnum=$2&day=$3&name=$4&page=$5 [QSA]

Note that my preferred archive format is post-by-post, which is a WP option setting. You’ll need to add or modify pages accordingly to match your preferred format.

Now, there may be other ways of modifying the .htaccess file from within WordPress, or other ways of dealing with the individual pages, but this worked so nicely that, at worst, it’s an alternative.

The other customizations I made were to the WP hacks file.

At this time, any modification to code should be made as a separately named function, and loaded into a file called my-hacks.php in the weblog root directory (usually where the index,php page is). You’ll also need to turn on the hack file setting, which can be found in Options->General Blog Settings. Setting this to ‘true’ will make WordPress load your hacks file, and make your functions available.

When writing the PHP functions, it’s critical that there are no spaces or empty lines outside of the opening and closing PHP brackets. In addition, when you create the functions, you’ll want to use the WordPress coding standards, and make use of the WordPress database functions. Once I have cleaned up my functions (after this time checking to make sure what I need hasn’t already been implemented), I’ll post the code and probably a file for downloads.

One such custom function I’ve made is to split comments from trackbacks/pingbacks in my individual page. The reason for this is because I don’t necessarily consider the two as interchangeable.

In the last essay, I mentioned how the creator of Textpattern didn’t implement trackback because he wasn’t sure the purpose of the functionality. I think this was a good idea, and the reason why is because I don’t think we’re all on the same page about exactly what a trackback is.

A trackback is NOT a link to a referrer. If that’s all we needed, there is code and script and even Technorati to show who has linked to us.

No, a trackback is more subtle. Rather than sending a ping because you link to someone, we should be sending each other pings when we feel we’ve discussed something associated with our post, or which could be of interest to the readers of our post. But we may not necessarily link to your post, because our own readers may not be interested.

For instance, if you’re talking about comment spam in Movable Type, and how frustrated you are by it, and I see your post, I should send you a ping to my comment spam workaround posts. Doing so, you, and your readers, can see what I’ve written on the topic, and even follow through on the suggestions.

However, it doesn’t make sense for me to link to you – my readers don’t need to know you’re having problems. They already know people are having problems.

Trackback is a way of connecting the threads together, when the connections we normally use, hypertext links, are missing.

This has been clarified by Phil Ringnalda, and was part of what I hoped to capture with the long defunct Threadneedle implementation. It’s almost most likely a part of what David Weinberger and others were originally thinking of with ThreadsML.

(There, I’ve just put in a ping to David from this post. Hi David!)

If a weblogging tool doesn’t support trackback, and you can’t implement a stand alone trackback server, the only want you can drop a link to the posting is to go into comments and add it. Workable, but trackback is better.

However, that’s why I like to separate comments from trackbacks in my individual pages, and why I created the custom function to handle this within WordPress.

I’m beat, and about ready for a break from WordPress customization and documentation of the migration. I’ll probably just play for a time, and then come up with a list of hacks that you can use if you’re interested.

I also want to contribute to the WordPress project by trying my hand out on some documentation at the WP wiki. The use of a wiki for documentation of an open source product is about one of the best uses of the technology–as long as there’s an infrastructure in place, and this is now being shaped. A good time to dive in.

If you want a zipped file of my custom pages and functions, send me an email and I’ll email it to you. I don’t want to post it online at the moment until I’ve had a chance to refine.

In the meantime, welcome to my happy new WordPress home. I hope you wiped your feet off before entering.

Recovered from the Wayback Machine.

As you’ve seen, I am moving Burningbird to a new weblogging tool this week. After testing several, and after long deliberation, I decided to move to WordPress. Once that decision was made, I have been spending the last couple of days making some extensive template and code changes to WordPress 1.02 to match what I had with my original Movable Type-based weblog. And I’ve made some important discoveries about what to do, and not do, when moving to WordPress. However, before getting into the details of the migration process, a quick overview of why I went with WordPress over the other fine products easily available.

When shopping for a new tool, I had some specific requirements in mind. The first was that the tool must support MySQL. If the tool’s storage is based in MySQL, I can access the weblog data directly using SQL and add my own innovations to my pages, such as the recent comments list on this page. I had no interest in working with what are more primitive text and file based tools to manipulate either the post text or comments/trackbacks–or both. Nor am I that comfortable with the other personal database systems out on the market, such as Berkeley DB.

A second requirement is that the tool supports PHP. I can work with Perl or PHP, or even Python for that matter (but not as comfortably), but the challenge with Perl is that it is a rather cryptic, (though powerful) language. In addition, effective use of Perl or Python requires a great deal of object-oriented design, and the problem with OO is that it can be very difficult to make customizations to code–especially if you’re not a programmer by either vocation or interest.

Frankly, PHP is a looser language. By this I mean, though it’s generally not considered as powerful as Perl, it isn’t as cryptic, either, or as easily obfuscated with object-oriented design. PHP (as with ASP, a similiar type of environment supported by Microsoft) is also, in my opinion, a more comfortable language for non-geeks to learn. By using PHP and supporting PHP, I hope to be able to work less with the geeks, and more with the rest of the world–people who don’t write code either for a living or as a passionate hobby. It’s not that I don’t like working with geeks; after all, I’ve worked with geeks most of my programming life. It’s just that at this time, I’m enjoying the opportunity to work with people who have a different perspective about code; who code for a specific reason, rather than code for the sheer joy of it. (Or because they get paid to code.)

Besides–most of my in-page hacks have been with PHP. By using a PHP-based weblogging tool, I can focus on one language, and probably incorporate my in-page hacks directly into the tool infrastructure itself if it supports a customization (i.e. hack or plugin) type of interface.

A final major requirement, and somewhat supported by my choice of PHP, is one I’ve gone back and forth on for some time now: statically generated pages as compared to dynamic ones. There are advantages and disadvantages to both.

Static versus Dynamic Pages

Statically generated pages are generally less burdensome than dynamic pages, because extra resources are necessary to serve up a page each time it’s accessed. For instance, if a post is output to an individual page, a dynamic system would mean that the contents for that post would have to be accessed from the database, formatted, and then output as HTML (or XHTML) each time the page is accessed (read). The database access and formatting would only be done once with a static page.

However, there shortcuts and optimizations that one can build into a dynamic system, such as caching the post contents so that frequent access of more recent posts does not require round trip access to the database each time the page is accessed. Since database access is generally the most costly aspect of dynamic pages, caching recently accessed post data should improve the performance of each page access.

(By caching what I mean is that the data is stored locally, such as in memory, for faster access.)

Before comments and trackback, it made sense to statically generate pages. Now, though, what we’re finding is that page rebuilding has become all too common, and a burden all of its own within a static system. And when you add in rebuilding to syndication files (RSS and/or Atom), especially if you support comments syndication feeds, the overall use of system resources tends to level out over time.

An even bigger factor in my choice, though, is my own past experience. I have, too many times, published a post only to find an error in it once uploaded. I then have to re-edit the post and re-generate the static page, and this can be a frustrating experience at times. With a dynamic system, I can make the change and once it has been saved to the database, the change is now visible. This is a faster process, and one that overall should cut down on my own personal frustration with static page systems.

Of course, if I have a page that’s Slashdotted, and hit with thousands of requests at once, a dynamic page will fail much more quickly than one that’s statically generated. However, since I’ve only been Slashdotted twice in my entire weblogging career, I’m not using this as a criteria for choosing a product. Besides–few systems can survive Slashdotting easily, even with static pages.

Once I defined my basic requirements for a system–MySQL, PHP-based, and dynamic–then it was a matter at looking at the many different tools.

LAMP Weblogging Tools

To all intents and purposes, the weblogging tools I was most interested in were those that could be considered LAMP tools. By this I mean that the tools run within a Linux environment, on the Apache web server, using MySQL for data access, and based on PHP.

(Note that most of these tools will also work in a Windows environment.)

I wrote once before about looking at a couple of different tools: pMachine’s ExpressionEngine and WordPress. I can’t afford ExpressionEngine, but I could afford the original pMachine, the free version and the Pro.

I also evaluated b2evolution, which, like WordPress, is open source; and Textism’s new Textpattern.

After overcoming a couple of mistakes in the installation of Textpattern, I was able to get a weblog up and running. Textpattern has an elegant editing interface consisting of layered tabs. In addition, much of the product’s effort is focused on simplifying template editing, with template tag generation for every aspect of a page:

In addition, Textpattern also features a plug-in called Textile whereby you can insert special characters into the text for specific HTML tags, and the product then converts these characters into their HTML equivalent.

With Textile, an underscore around text would automatically enclose it in the appropriate HTML tag, after first annotating the text with paragraph markings. Thus the following:

_this is a test_

Would become:

<p><em>this is a test</em></p>

When registering new users, you can designate whether they are a specific type of user. For instance, I can add a new user who is a Freelancer, as compared to a new person who is a Designer, and each, we presume, has different authorizations. However, when I logged in as Designer, I found I could post new essays but not access Presentation; whereas I could access Presentation and post when logged in as a Freelancer. To me, the semantics of each role doesn’t seem to match the access granted.

One widely used weblogging mechanism that Textpattern doesn’t support is trackbacks or pingbacks. I searched in the Textpattern forum, and found this from Dean Allen, who is the Papa of Textpattern:

There’s a mechanism built in to Txp called ‘mentions’, which harvests the url, page title and an excerpt of referrers pointing to specific articles. It still needs some work, but the idea is you’ll be able to output a list or summary beneath the relevant article -’This article was mentioned on the following pages’ or some such.

I think Trackback and Pingback are good ideas, but difficult to grasp. As such I don’t have plans to implement them in Txp.

Nothing to prevent them from appearing in a plugin down the road, however.

Unfortunately, though, the power of trackback isn’t in capturing referrer information, which I’ll get to in more detail in a later posting.

Textpattern is an attractive interface, with its elegant tabs and good use of white space. One quibble I have is that the editing page shares some of the same problems of Movable Type in that elegance can actually overcome usability by making the editing field itself too small. However, the biggest drawback I saw with the tool is, like pMachine, Textpattern is a proprietary tool. Though there are advantages to a proprietary tool, I wanted to go open source for my next weblog lifetime.

Proprietary versus Open Source

A major decision to make when picking a weblogging tool is whether to go with a proprietary product, or whether to go open source. All the tools I’ve used in the past–Blogger, Radio, and Movable Type–have all been proprietary, or closed source.

The strongest advantage to a proprietary product, especially a commercial one, is that there is ownership of modifications to the system, and even accountability if you pay for a product. With applications like pMachine and ExpressionEngine, or even Movable Type for that matter, you can expect that the company is going to pay attention to problems with their code, and if they want to stay in business, fix them in a timely manner.

In addition, there is greater control over what modifications get incorporated into the product with each release, and how the documentation is managed. Even with source code control systems like CVS, open source applications tend to be marked by rather frenzied and even chaotic activity at time, unless certain people have been designated as administrators of the product’s direction.

An advantage, though, to open source applications is that when you see something that needs to be fixed, and you come up with a good fix, chances are you can incorporate that fix directly within the code for the next release of the product. You may have to work with the product’s administrative team to ensure the code meets the standards of the development effort–but anyone can contribute, if they can prove that they know what they’re doing.

A good demonstration of the types of problems the power of the open source development could solve more quickly can be found in the events surrounding the comment spam problems we’ve had with Movable Type in the last year.

The team working on Movable Type was fairly small in the beginning, and could only work on so much code at a time. Several people uninvolved with Six Apart, the parent company for Movable Type, did write code that handled individual aspects of it, but there wasn’t an easy way to incorporate all these changes because they couldn’t be incorporated back into the product in an interim release. I actually had to write a post describing the approach to take to integrate the code, like a human CVS system.

If MT had been open source, the code changes could have been incorporated into the product code itself, and then rolled out in the next bug release. More hands would have been involved in the develpment, and consequently, the fix rolled out sooner.

But there’s another reason why I went with open source this time around, and it has a long history.

Hard to believe now, but once upon a time I was almost a pure Windows developer, starting with the very first beta of Windows (and IBM’s OS/2) years ago when I worked at Boeing. I took, and passed, several of the Microsoft certification exams when they were still beta. I attended WinDev in Boston. I learned about the early versions of COM directly from Kraig Brockshmidt, before he went new age and became known as “Satyaki” (code will do that to you after a while). I learned about the Windows API from Charles Petzold.

My bestselling book for O’Reilly was “Developing ASP Components”.

However, all this changed when Microsoft came out with .NET. I took a look at .NET and knew that this was _not_ a direction I was comfortable with, and felt that Microsoft was heading in opposite directions from the rest of the technical community–going with a larger, intertwined, proprietary infrastructure rather than a smaller, open, component-based systems. I liked COM and COM+, but was less sanguine about .NET. I was frustrated that I had no impact on the direction of this product, and all my work towards COM+ (not to mention my newest edition of my book) was now abrogated in favor of a ‘new deal’. I was disappointed, and basically quit working within the Windows environment.

This decision didn’t come without cost. Professionally, I moved from one environment to something completely new (Java, though I had been working with C and C++ in Unix parallel to working in Windows), and had to become established all over again (including taking Java certification tests). In addition, it’s taken me years, but I’m now at the point that when Win2K is no longer supported, I can move off of Windows completely; to either Linux on my PC, or to the Mac.

Still: years to pull out of a large, complex, and troublesome (to me at least) proprietary system to something that’s either non-proprietary, such as Linux; or at least more liquid, such as OS X is not something you forget the lesson of quickly, or easily.

Now I’m faced with the open source decision, as we await a major new release of Movable Type: either move to open source or stay with proprietary code. Frankly if I wanted to stay proprietary, I’d probably stay with Movable Type.

Ultimately, though, staying with proprietary code makes no sense considering that my focus is now so strongly towards an open source environment. If I’m going to make a move to open source, now is the time to do it–before getting more entangled with a MT specific way of doing things with the release of MT 3.0.

Once my non-proprietary source decision was made, my choices were narrowed down to two products (at this time): b2evolution and WordPress.

WordPress versus b2evolution

Both WordPress and b2evolution have an extensive codebase; both are supported by a group of people with enough ownership of the process to ensure it doesn’t falter or break down. Each has a documentation wiki, b2evolution’s here and WordPress’ here. Each has unique features that make it stand out, but both support most of what I would look for in a tool.

b2evolution has the more polished interface. It supports multiple blogs as well as hierarchichal categories. In addition, the current editing screen provides post preview, as well as spell checking. It also provides smileys, but I swear that’s not the reason I didn’t use it.

Both WordPress and b2evolution share the same heritage, being forks off an original open source weblogging tool, b2 (cafelog), which came to a full development stop a year ago.

With the same heritage, meeting my initial requirements and a more polished interface, why did I choose WordPress over b2evolution? The simple answer lies in the code, and in the direction that I see both tools going.

WordPress has been focusing more on an infrastructure than an interface, from my initial review. Because of this, it minimizes the amount of PHP code in any of the templates, as compared to b2evolution. In other words, there’s a lot more going on behind the scenes to set up a good, extensible environment than what I’m seeing with b2evolution (though b2evolution is, I believe, the newer tool and may not have as much time in).

Multiple blogs and hierarchical categories, and spell check are great–but I’d rather see more effort put into keeping the templates as clean of PHP code as possible; and creating a clean, extensible interface.

Once you have a good foundation, then you can add the goodies, including spell checking and post preview (which, like comment preview, is planned for the next major release–1.2).

In addition, I am seeing a broader community support within the WordPress community, and that’s essential for an open source product; otherwise the members will burn out and the tool will go by the wayside. At times the community energy may seem chaotic, but there is a method to the madness, as I found after only a couple of days ‘messing’ around, and getting help from community members.

There was, also, one other major factor that decided me on WordPress; a feature I consider so important to my own weblogging efforts, that it overcomes limitations on not yet having Post Preview. This feature is one you’ve seen used in this post: multiple page weblog entries.

Nextpage

WordPress has several quicktags that can be used to insert commonly used XHTML tags into a document, including EM for emphasis and IMG for images. However, it also has a specialized tag called “nextpage” that looks like the following:

<!–nextpage–>

When you insert this into the document, WordPress knows to split the content into a separate page, which can then be accessed by its specific page number from any of the entry pages. Unlike the concept of more.., which just basically takes you to the individual page entry and to a specific anchor point in the page, the nextpage feature from WordPress literally gives you separate URLs for each section.

If you believe that weblogs should be short posts and links, you will never use this. However, if you believe that weblogs are nothing more than a loose framework and that a person should write as they want, how they want, and when they want, then the concept of nextpage should have immediate appeal.

For instance, I am the type of writer that pulls together separate topics within one writing, each of which can be accessed individually in a meaningful way; all forming a comprehensive whole. There is no way to do this elegantly with existing weblog tools, at least those I’m familiar. What I end up doing is splitting the sections into multiple postings, with a ‘part number’ to each; or I smoosh the sections into one, long, jumbled, breathless entry.

Writings with different part numbers doesn’t work in weblogging because the entries are posted chronologically. This means, then, that if you want Part 1, you have to move backwards in a page, rather than moving from top to bottom for oldest to newest, which is more natural for the majority of us. In addition, you know how difficult some of my long writings can be to read at times–not to mention how long the pages are, and how slow to load if I use a lot of images.

Neither works for me–not after seeing nextpage. It could have be created just for people like me. And it’s not something that would be easily created as a plug-in or hack, either.

Now, with this very long posting, you can read all the sections, or just those of interest. (Note to WordPress: attribute on the tag that allows one to label each page with topic heading would be mighty nice. Maybe I’ll write this). In addition, if you want to comment on the document from your own weblog, you can link to the entire document, or link to a specific section that you’re specifically addressing! For instance, if you want to post about this essay, but specifically the section on nextpage you can by grabbing the URL for just this section, and then linking directly to it.

Once discovered, I cannot live without this feature. No matter what’s missing in WordPress now (and most of what I want is planned for release 1.2), nothing compares to having this simple little tag–and what it means to me as a writer.

Quite simply, I’ve falled in love with a tag. Those of you who may yearn for me from afar, alas, but my heart is given to another–and it’s markup. Choice was made: Burningbird is moving to WordPress.

Well, choosing the tool was the easy part. Now it’s time to go to work, and begin the migration process from Movable Type to WordPress. Moreso, now it’s time to move a weblog that was heavily integrated into Movable Type into a completely different product.

However, this will go into a separate post. Don’t want to wear my new little buddy, nextpage out. And I’m still in the midst of tweaking.

Later today.