As mentioned in my previous entry, I converted davidchiu.net from MT to WP. The migration was pretty easy and I just followed the instructions I found on Wordpress.org. The only thing is that I didn’t care for their solution for redirecting previous MovableType permalinks to new Wordpress pages. So I came up with my own solution: create a custom WP 404 page which redirects the user to a search results page. The effect would be this:
If a user comes from an old MT permalink such as http://davidchiu.net/2003/05/some_old_title.php that does not correspond to an existing Wordpress page, convert the filename to a title fragment (ie, some_old_title.php becomes “some old title”) and return a Wordpress search result.
This should take care of all old permalinks. The corresponding code is pretty simple. I just added the following code to the top of my custom 404 page:
<?php
$filename=basename($_SERVER['REQUEST_URI'],”.php”);
$filename=basename($filename,”.html”);
$title=ereg_replace(’_|-’,’ ‘,$filename);
header(”Location: http://”.$_SERVER['SERVER_NAME'].”/?s=\”".$title.”\”");
?>
The first two lines strip either the “.html” or “.php” extension from the original request URL. The ereg_replace() function converts any underscores or dashes to spaces. Finally, the header() function redirects the user to the Wordpress search result page for the title fragment.
In my initial tests it works great. Let me know if this code could be better.
I’ve finally converted my longest running blog - davidchiu.net from MovableType 4.1 to Wordpress 2.5.1. This wasn’t an easy decision since I’ve been using MovableType since 2003 but Wordpress now provides a compelling solution for blogging. One of the deciding factors was the template/styling implementation in Wordpress. If you do quick Google search for Wordpress Themes you will see the amount of support that Wordpress has - granted, most of the Wordpress themes out there are crap, but there is a huge community developing for Wordpress. The same is true for Wordpress plugins. Conversely, MovableType does not have the same amount of community development. The only thing I worry about Wordpress is performance. MovableType has the option to pre-render an entire site and publish static files to the file system, whereas Wordpress dynamically creates pages on the fly. MovableType has the obvious advantage here but there are caching strategies people are using through plugins to overcome this disadvantage. Ultimately, Wordpress is just easier and faster to use than MovableType and with web2.0/syndication plugins such as Wordbook and Twitter-Tools Wordpress is too attractive to pass up. Plus, migrating to Wordpress was painless.
Tonight I realized that the upgrade I did from MovableType 3 to MovableType 4 broke any and all links to my old articles once I had rebuilt my blog. The problem lies in the configuration option named “Basename Length” under Preferences->Blog Settings->Entries in MT4. The default value in MT4 is 30, whereas the default setting in MT3 was 15. Now I thought I could easily fix this by changing the value to 15 in MT4 and republishing my site, but that didn’t work. So instead I wrote this little PHP script to make copies of all my old archives articles and truncate the filenames to 15 characters. Here’s the script I wrote. Maybe it will help someone else. Be sure to CHMOD -R a+w archives/* before you run the script so that the script has permissions to create the new files. Then make sure you put the permissions back to what they should be when you’re done.
<?php
function changeext($directory, $verbose = false) {
$num = 0;
if($curdir = opendir($directory)) {
while($file = readdir($curdir)) {
if($file != '.' && $file != '..') {
$srcfile = $directory . '/' . $file;
$string = "$file";
$str = strlen($ext1);
$str++;
$newfile = substr($string, 0, 15);
$newfile = $newfile.'.php';
$dstfile = $directory . '/' . $newfile;
if (eregi("\.php",$file)&&(strlen($file)>19)) {
($srcfile, $dstfile);
//echo "copy $srcfile, $dstfile
";
}
if(is_dir($srcfile)) {
$num += changeext($srcfile, $verbose);
}
}
}
closedir($curdir);
}
return $num;
}
changeext('archives', 'false');
?>
I was having caching problems with the search functionality across two of my MovableType blogs. At first I thought it was a problem with the FastSearch plugin I was using. But my other blog was having similar problems and was not using the FastSearch plugin. It turns out that I had the page caching option enabled in mtview.php:
$mt->caching = true;
Once I commented out this line the search worked fine.
I also noticed that in migrating over my blogs from MovableType 3 to MovableType 4, MT4 created a different naming convention - leaving all the old MT3 files in the archive directories. So I decided to delete all the archive files and just rebuild/republish the site. I needed a Linux command that would recursively go through all the directories and delete all php files. After consulting google I found my answer:
find . -name \*.php -exec rm {} \;
I recently noticed that I wasn’t receiving any comment email notifications from Movable Type so I decided to dive into the system to figure out what was going wrong. Running mt-check.cgi reported back that sendmail was installed so I thought it might be a permissions issue between the the apache user process and sendmail. I typed in ’sendmail’ at the prompt and received back a message talking about “Exim“. Well, I’m not a Linux guru, but I do know that Sendmail!=Exim. So I turned to google to tell me what the heck Exim is and how do I figure out what’s going wrong. Google pointed me to the exim log file on the system which I watched as I sent test emails from Movable Type. The exim.log showed that it could not resolve the email addresses and was failing. A second thing I noticed was the ton of spam it was successfully blocking. So I went back to google to find out more info. I tried searching on keywords “exim movabletype”, “exim configuration” and couldn’t find anything useful. Then after staring at the exim.conf file for 10min, the lines “domainlist local_domains=” hit me. Google had told me that Exim was used for transferring and relaying local mail. My mail is being hosted at google through google apps. So I did a new google search for “exim google apps“. That search gave up a clue that got me one step further: If you are using a linux server, don’t forget to edit the /etc/remotedomains file to delete your domain. Well after poking around the file system I knew that I didn’t have a “remotedomains” file, but it did sound very similar to my “/etc/virtual/domains” file mentioned in my exim.conf. So I googled “/etc/virtual/domains“. And saw my final clue titled: Disable SMTP to certain local domains? That article did not have the exact answer but gave me enough information for me to solve the problem. To disable SMTP/mail service for specific domains just copy “/etc/virtual/domains” to some other file such as “/etc/virtual/domains_with_smtp”, edit the file and delete all the domains which use google mail, then point exim.conf “domainlist local_domains=” and “domainlist relay_domains=” to use this new file.
Voila! Email notifications now work!