This photo was taken in the Toronto Zoo a few weeks ago.
Archive for June, 2006
Onlooking Bird
Saturday, June 24th, 2006New ChangeLog features
Wednesday, June 21st, 2006Kyu Lee, one of the new Interns we have in the Toronto Red Hat office, has been working on the ChangeLog plugin, trying to implement some new features.
He’s made great progress, and yesterday we pushed an update of eclipse-changelog 1.1.0 into both devel and the FC5 updates-testing repository. This version has a ChangeLog editor, which has nice color highlighting, and also allows you to jump to a file by Ctrl-Clicking it’s name in the ChangeLog. A modest, but very nice start. I think this plugin can become much more useful and usable with a very minimal amount of love. If you use Eclipse, give it a twirl.
PyDev Status (1.1.0)
Wednesday, June 21st, 2006In the past few weeks I spent some time preparing patches that backport PyDev (the Eclipse Python plugin) from Java 1.5 to 1.4 so that it can be shipped in Fedora, since for some time now PyDev has been developed on Java 1.5. Last week I updated my patches to PyDev 1.1.0, which is the latest version that will support Eclipse 3.1.2, and so the latest version that can go into FC5. Last week version 1.2.0 was also released, which is the first version that will be targeted for Eclipse 3.2, which is what will get into FC6.
I spent some time last week trying to make PyDev has sane defaults out of the box for settings like the path of the Python and Jython interpreters, I got something sort of working, but it wasn’t quite there yet. I’m planning to push PyDev into Fedora Extras in FC6, since it will now have an optional dependency on Jython. But I’m wondering whether I should release 1.1.0 as a Core 5 update, because it really is a *huge* update in stability and functionality over the version we currently we have in. I’ll probably try to make a test RPM that has the Jython bits ripped out tomorrow and push it into updates-testing, and see what kind of reaction I get.
Over the weekend or maybe next week I’ll probably prepare the PyDev 1.2.0 patch and a corresponding SRPM, that I’ll submit to extras pending on my other submissions (Jython and friends).
Pink Flowers
Monday, June 19th, 2006Far From The Eye
Monday, June 12th, 2006Aligator Texture
Sunday, June 11th, 2006PyDev 1.0.6 backporting
Thursday, June 1st, 2006As I mentioned 2 weeks ago, I decided to backport PyDev 1.0.6 to Java 1.4 so that we could include it in Fedora. I’m glad to say that I’m done, and the patches are available here . Fabio, the author of PyDev, has released versions 1.0.7 and 1.0.8 in quick succession last week, which are bug fix releases, so I’ll be updating my patches for that shortly.
Right now I’m working on getting Jython into Fedora Extras because PyDev has Jython support. I could disable that support, and push the PyDev update into Core. But I decided it would be better to get Jython in extras, it’s a pretty important package I think. What I’ll probably end up doing once that’s done is splitting the PyDev SRPM in to several binary RPMS and make the eclipse-pydev-jython one depend on Jython itself.
If anybody is willing to be the shepherd of any of the 5 packages that include Jython and it’s dependencies in Extras let me know, as I probably won’t have time to maintain them.
Migrating MovableType to WordPress 2.0.2 (or The Good, The Bad and The Ugly)
Thursday, June 1st, 2006Over the last weekend and the week before that I spent a lot of time trying to migrate the blog at Pyre to use WordPress instead of the ancient MovableType installation it was using before. Unfortunately it wasn’t a very smooth ride, so I’ll write my conclusions here so that they could be useful for others.
Exporting from MovableType
The first step in the process was to export the post information from MovableType. This wasn’t really a hard step and the WordPress Importing from MovableType tutorial does a very good job of explaining this step. Unfortunately this didn’t quite work for me because MovableType doesn’t export post id #’s into this file. Why would you want that you ask?
Well…
Apparently MovableType hosts multiple blogs in the same database and uses the same tables for all the blogs. It actually goes even further and has global post id numbers so that the sequence of id’s for any one blog is not consecutive, you’ll have breaks in the numbering wherever someone posted to one of the other blogs. Huh! So maybe I should export all of the blogs at once? Well it turns out that you can’t. No single user, including the administrator can export all the blogs, they can only export the ones they “own”, which I guess means they started.
*sigh*
Importing into WordPress
This means that when I import entries into WordPress the post id #s will be completely different and maintaining links will be close to impossible.
At this point I went through the exercise of inserting my foot into my mouth from 10 different angles, after having said that the importing step “should be a breeze”. I tried writing a program to fetch all post numbers and titles from the old blog, trying to compare to how they import into WordPress and then making a file with all the correspoinding ids. In the end it was decided that maybe if we only preserve internal linking it would be OK. At that point I went and wrote a program that would go through the exported MT entries and substitute the correct addresses from my previously created massive file. This had it’s own problems.
In the end everything ended up working out quite nicely. Here’s how.
The Final Solution
First I found a very useful hint on how to export post ids from MT, which worked like a charm.
I then proceeded to to hack up WordPress to import the entries correctly. The hints at the website above gave me a good idea of what needs to be done but it was a bit old, using WordPress 1.0 instead of 2.0. Here is a patch for my WordPress hack. This also inserts print statements that show you that everything is indeed going according to plan. I’m going to explain the main points of the patch below, but these are copy/pasted parts of the patch that won’t apply if you use them by themselves, please use the full patch.
The first part of the patch is for the wp-includes/functions-post.php file, which defines functions for inserting a post into the database. The first chunk of the patch makes WordPress think that it’s creating a new post, instead of updating, by commenting out the update code.
@@ -16,11 +16,13 @@
// Are we updating or creating?
$update = false;
- if ( !empty($ID) ) {
- $update = true;
- $post = & get_post($ID);
- $previous_status = $post->post_status;
- }
+ // igorfoox
+ printf(__('In wp_insert_post, ID is %d'), $ID);
+// if ( !empty($ID) ) {
+// $update = true;
+// $post = & get_post($ID);
+// $previous_status = $post->post_status;
+// }
The second chunk makes WordPress always set the post id to the id we extracted from the comment.
@@ -45,8 +47,8 @@ $post_status = 'draft'; // Get the post ID. - if ( $update ) - $post_ID = $ID; + //if ( $update ) + $post_ID = $ID;
The third chunk is just a strategically placed print statement. The fourth chunk adds the post id to the fields that are inserted into the database.
@@ -142,12 +145,14 @@
menu_order = '$menu_order'
WHERE ID = $post_ID");
} else {
+ printf(__(' Running insert query'));
$wpdb->query(
"INSERT IGNORE INTO $wpdb->posts
- (post_author, post_date, post_date_gmt, post_content, post_content_filtered, post_title, post_excerpt, post_status, comment_status, ping_status, post_password, post_name, to_ping, pinged, post_modified, post_modified_gmt, post_parent, menu_order, post_mime_type)
+ (post_author, post_date, post_date_gmt, post_content, post_content_filtered, post_title, post_excerpt, post_status, comment_status, ping_status, post_password, post_name, to_ping, pinged, post_modified, post_modified_gmt, post_parent, menu_order, post_mime_type, ID)
VALUES
- ('$post_author', '$post_date', '$post_date_gmt', '$post_content', '$post_content_filtered', '$post_title', '$post_excerpt', '$post_status', '$comment_status', '$ping_status', '$post_password', '$post_name', '$to_ping', '$pinged', '$post_date', '$post_date_gmt', '$post_parent', '$menu_order', '$post_mime_type')");
+ ('$post_author', '$post_date', '$post_date_gmt', '$post_content', '$post_content_filtered', '$post_title', '$post_excerpt', '$post_status', '$comment_status', '$ping_status', '$post_password', '$post_name', '$to_ping', '$pinged', '$post_date', '$post_date_gmt', '$post_parent', '$menu_order', '$post_mime_type', '$post_ID')");
$post_ID = $wpdb->insert_id;
+ printf(__('||| end of insertionn with id %d'), $post_id);
}
The second part of the patch makes WordPress extract the post ids from the exported MovableType data. The first chunk ads the ‘ID’ field as a parseable token
@@ -222,6 +222,9 @@ case 'AUTHOR' : $post_author = $value; break; + case 'ID': + $ID = $value; + break; case 'TITLE' : $post_title = $wpdb->escape($value); break;
Then we also send this information to the wp_insert_post function in the second chunk
@@ -281,8 +284,9 @@
$post_author = $this->checkauthor($post_author); //just so that if a post already exists, new users are not created by checkauthor
- $postdata = compact('post_author', 'post_date', 'post_date_gmt', 'post_content', 'post_title', 'post_excerpt', 'post_status', 'comment_status', 'ping_status', 'post_modified', 'post_modified_gmt');
+ $postdata = compact('post_author', 'post_date', 'post_date_gmt', 'post_content', 'post_title', 'post_excerpt', 'post_status', 'comment_status', 'ping_status', 'post_modified', 'post_modified_gmt', 'ID');
$post_id = wp_insert_post($postdata);
+ printf(__('Id was %d, wanted %d'), $post_id, $ID);
// Add categories.
if (0 != count($post_categories)) {
wp_create_categories($post_categories, $post_id);
These things will probably slightly change with new versions of WordPress, but hopefully it stays similar enough so that people can figure out how to apply it.
Finally I also had to make sure that the old blog feed remained available, because WordPress uses a different address for its feed. I accomplished this with the following .htaccess rule
RewriteRule ^index.rdf$ /blog/rdf [R,L]
I know, it’s not so subtle, doing a full redirect to get the feed right, but I couldn’t figure out how to do it in any other way. What seems to be happening is that WordPress’ internal redirect system interferes with this rule unless I do a full redirect. If anybody has a more elegant solution, I’ll be glad to hear about it.
I think this needs to be put up on the WordPress wiki, because the information there is sooo out of date. Unfortunately I spent way too much time working on this, and so I don’t have that much time to do it, but hopefully after writing it all down, I’ll be able to find the time to stick it there as well in the near future.



