I haven’t posted recently, but that doesn’t mean I haven’t been working on my blog.
I’ve completed a first-cut version of a plugin for displaying Picasa photos in WordPress. I just tested it with Post to Post Links II error: No post found with slug "lews-wedding" if you want to see. I named it Shashin (pronounced sha-sheen), which is Japanese for photograph. I started working on it while I was in Japan, so I thought it deserved a Japanese name, and shashin sounds cool.
The mPicasaIntegration plugin I’ve been using so far has some real drawbacks. One is that it copies down the pictures from Picasa to your web server, so you’re eating up disk space (to be fair, the author did this because he was concerned at the time about what was allowed under the Picasa user agreement, but it’s pretty clear now Google is happy to let folks re-display their Picasa images). You also can’t adjust the size – every image is 640×480. In contrast, my plugin displays the images directly from Picasa, which means once I move all my pictures from my old Coppermine installation to Picasa, I can get an account for my site with a lower disk quota, and a smaller monthly bill 😉 . Also, Shashin can display images in any of the 17 sizes supported by the Picasa API. Picasa’s on the fly scaling is pretty good – much better than the browser scaling I had to use with mPicasaIntegration.
I’ve also given it some nice display options – you can choose to have the photo link to the Picasa image, and optionally display the photo description as a caption (I eventually gave up on finding the “correct” way to caption an image in xhtml and just went with a div set to block display). Getting the xhtml to work the way I want has been driving me crazy though, due to WordPress’ autoformatting. For example, WordPress sticks a line feed and a break tag between nested divs, even if there’s no line break in my code. I set the priority of my content filter to the maximum level, to try overriding the autoformatter, which helped with some problems, but not all of them.
I’m not quite ready to share it yet, mainly because I don’t have an admin page done yet for the photo table (I’m parsing the Picasa RSS feed on demand and then syncing it to local tables). I’d also like to offer some options beyond just displaying single images…I hope to be able to invite folks to beta test in a couple weeks.
I spent a fair amount of time on the architecture of the code. It’s all OO, and I went a bit over the top with the abstraction. That made the setup time longer but is now paying off, as I can add features without having to do a whole lot more coding. I also now have a good foundation of generic functionality for building other plugins (I have another in the works for managing real estate listings, for my dad).
mPicasaIntegration is no longer available for download on my site. Björn Teichmann now has it, and you can download it from his site. Björn started with my fixed version, and has added some new features. He plans to continue working on it. As I mentioned before, I made some fixes to it after its original author stopped working on it. I decided not to do any further work on it though, as its design is not something I want to stick with (It downloads the images from Picasa and stores them on your server. I’d rather just point to the images on Picasa, which lets me scale the images arbitrarily, and then I don’t have to worry about going over my disk quota either.) Since then I’ve started working on my own plugin, but I probably won’t finish it until sometime after I return to the US (i.e. sometime this summer).
I’ve finished my emergency surgery on Markus Steinhauer’s mPicasaIntegration plugin, so it can now read the new Picasa RSS feed. Post to Post Links II error: No post found with slug "mpicasaintegration-wordpress-plugin", with more information and a download link. It’s still 95% Markus’ code – most of my changes are in the RSS parsing, and I added some code to get the image dimensions and update the database, since that information is no longer in the RSS feed.
In my previous post, I experimented with putting my photos on Picasa. I’ve been posting my photos to my own site until now, but it’s a real chore. Also, I severely hacked my Coppermine installation to make it do some things I wanted, which has made it hard enough for me to upgrade that I haven’t done so. For a long time I was thinking about writing my own photo management application, but never had the time. Picasa’s come along and it does about 80% of the things I’ve been wanting, so I want to start putting my photos there. The trick is getting it to integrate with WordPress.
I looked for a plugin, and found folks discussing the mPicasaIntegration plugin. It’s a plugin that reads the Picasa RSS feed and stores data from it in custom tables, and then caches images as it needs them from Picasa. The only problem is that the plugin’s author and his website vanished from the web a few months ago, and I couldn’t find the code. So I was emailing people who I found were using it, and a kind person sent me a copy. He also informed me that it no longer worked. Google had significantly changed the Picasa RSS feed, which broke the plugin.
The time I normally set aside for blogging has been consumed the past few days by trying to fix it. I have it reading the RSS feed correctly again, but unfortunately some of the data the plugin relied on is no longer in the feed, so some of its features will need to be re-thought. In a few days I should have it working well enough so that at least some of the key features are working. Then I’ll post the code, as I know there are others who have been trying to track down this plugin as well (the author released it under a GNU license, so I don’t think he’ll mind).
I mentioned in an earlier post that I installed Gallery for managing my photos. Gallery turned out to be a train wreck: the features are nice, but the programming behind it reminds me of 80s style spaghetti code, making it almost impossible to customize. For example, I burned a few hours trying to figure out how to display a random image on a page other than “the random image page” before I concluded it wouldn’t be possible without a massive rewrite. So I dumped it in favor of Coppermine. Here are the photo albums I’ve created so far.
Coppermine allows you to create a custom theme, which consists of a style sheet and a couple of template files (they contain most of the HTML widgets that are used in building the pages). The implementation is hardly perfect though: there is a fair amount of hardcoded HTML inside the PHP functions, so you have to do some detective work if you want to change certain things (e.g. the code it has for embedding video files only works in IE, so I had to track it down and tweak it to support Firefox/Mozilla). Also, it’s filled with a sloppy mish-mash of HTML and XHTML tags, so coaxing it to generate a valid document has required me to touch a lot of code. But those are my only complaints: the features suit my needs and the management interface is nice. A real plus is that you can integrate it with the Windows XP “publish to web” feature, so you can publish images with just a few mouse clicks – no more FTP’ing!
Integrating Coppermine with WordPress has been an adventure. I’m using psnGallery2, which gives you custom WordPress tags and PHP functions for embedding Coppermine photos in WordPress. First I installed the latest stable release, but couldn’t get it working at all. So I installed the current alpha release, and with some hacking, got it to work. I described the problems and my solutions in this WordPress forum post.
I also wanted an easy way to link Coppermine pictures to their related blog entries. I did this by creating a “burl” tag in Coppermine. In the title or description of a photo I can type, for example, [burl=29]some link text[/burl] and it’ll link to WordPress entry number 29. It was easy to do. In bb_decode() – located in include/functions.inc.php – I added:
$text = preg_replace("/\[burl=([0-9]+)\]/", '<a href="/blog/index.php?p=$1">', $text);
$text = str_replace("[/burl]", '</a>', $text);
It’s all set up, so now I just have to slog through all my photos and get them in Coppermine 🙁 . Don’t expect it to happen overnight, but I will try to at least fix all the images that are now broken in my old blog entries as soon as I can 😉 .
The clever little URL rewrite I mentioned earlier is now out the window. I noticed the URLs it generated weren’t technically correct (with a slash between index.php and the URL argument) but they worked, so I let it be. That was a few weeks ago, and in that time, not unexpectedly, all my old Movable Type URLs disappeared from Google. But they haven’t been replaced by the new ones – except for the top page, my blog is not in Google anymore. I’m guessing Googlebot didn’t like how I was doing the URL rewriting. So I’ve shuffled things around, and now my blog really is in the “blog” directory, and hopefully Googlebot will like that better. Unfortunately, that means I can’t use WordPress to manage pages outside the blog directory. But I’ve realized that doesn’t matter much, as I’ll eventually fold the Kai and wedding pages into Coppermine, and the Route 50 pages into the blog, so there won’t be many static pages left.
I’ve also become active in the WordPress forums – I explained how to get past the bugs that have been plaguing a lot of folks trying to use psnGallery (it’s a plugin that gives you easy access to Coppermine photos from within WordPress) and how to fix a bug with sorting the WordPress archive listings (the WP folks have since released their own bug fix).
So this is my first WordPress post. But if I did a good job matching it to my old Movable Type stylesheet, things should look pretty much the same (although I haven’t updated the templates for any of the pages besides the main page, so the archives, etc. are still a bit ugly).
Something I was looking forward to with WordPress was using it for managing all the pages on toppa.com. But I immediately ran into trouble when I discovered that, in order to do this, you have to install WordPress at the top of your web docs directory (which makes sense), and you can’t have the main page be named anything other than index.php. This was a potential show-stopper, since I’m not about to give up my uber-cool custom homepage for a same-as-everyone-else’s blog page.
I found a discussion thread on this, but the hidden option to change the filename they mentioned has been removed in the latest release of WordPress. It’s no longer a variable in the database, and they didn’t even have the decency to make it a variable in the code. Instead, the code alternates between hard-coded references to index.php, or it just assumes the default index file of the install directory. Lame.
But I like all the other aspects of WordPress enough that I decided it was worth a bit more investigation. First I thought of making a symlink, but I don’t have shell access to my site, and the FTP server is configured with a restricted set of SITE command options that doesn’t include symlink. So this is what I ended up with:
RewriteEngine On
RewriteRule ^blog(.*) /index.php$1 [R=301,L]I have to thank Pat W for his comment on my post yesterday – he suggested I try WordPress and TextPattern. I’ve done a test installation of WordPress, and it’s a dream. I had been resisting checking out other blog applications, as I’ve become so familiar with Movable Type I didn’t want to have to learn a new system. But there’s no denying the superiority of WordPress: the installation was fast and easy, and after even just a quick run through the administrative interface, it’s obvious that the features for creating entries, theme management, etc. (even including overall site management), are superior.
I’ve realized the problem with Movable Type is that it’s based on a web programming paradigm that’s at least 8 years old, when a “dynamic” page was something you generally only saw after filling out a form, and you needed to stick with static pages whenever possible anyway, for the sake of conserving server resources (it’s the kind of stuff I used to teach in my CGI/Perl class in 2000). The web has moved beyond that, but only with the latest version of Movable Type does it seem that Six Apart has even started to catch on. What’s ironic is that the early success of Movable Type has allowed Six Apart to become a real company (now with at least 50 employees), but they’re clearly not keeping up with what the smaller competitors are doing. Instead they’ve let themselves be distracted with developing TypeKey, a project they would have known was doomed from the start if that had just asked somebody (not even Microsoft has the market leverage to get everyone to sign on to a central registration system – how many of you use Microsoft Passport?). A slightly out-of-date but still useful overview of Movable Type and its competitors is at the Unbounded blog entry Goodbye, Movable Type.
The time-consuming part of the transition will be migrating my stylesheets and templates away from the custom Movable Type tags and into PHP. But since PHP is the main language I program in now, it’ll ultimately be a good thing.