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.
