I thought maybe the fixes I found were specific IIS server setups, but not necessarily mine. So, I looked at my sorry IIS server’s phpinfo() output, which revealed some obvious problems with my wp-settings.php. Apparently IIS/PHP doesn’t set some of the variables that WordPress wants, so WordPress attempts to create those variables, based on variables it supposes IIS/PHP ought to set. But my server’s variables weren’t named quite right for WordPress to suss out the variables it wanted. I changed the variable names in wp-settings.php to match my phpinfo() output and it worked.

I did end up having to delete the database tables for each install attempt. I don’t know how many people run into install issues, but if there are a lot maybe it’d make sense for WordPress to do some sort of post-install sanity check. Even better if that sanity check involved a form where one could hardcode in those problematic server variables.

Update: I should have seen this coming based on what I saw browsing the forums earlier, but the admin emails from WordPress wouldn’t work out of the box. I’d guess that the dear IIS host I’m working with has had issues with spam so they don’t allow PHP to send unauthorized mail. Fortunately, there’s a plugin that lets you manually set WordPress to use an arbitrary SMTP server. There are actually a couple, but WP Mail SMTP is working for me.

Another update: I just installed another instance of WP on the same IIS host and had a little different experience. First I tried installing without changing anything in wp-settings.php. The install failed when I went to the install page through index.php, but I thought I’d try going directly to wp-admin/install.php before editing anything. For some reason that worked just fine, maybe because then the relative paths worked?

• wget http://wordpress.org/latest.zip (download the latest version)
• unzip wordpress-XXX.zip (extract it)
• mv wordpress [your-site's-folder-name] (rename the wordpress folder to the name of the folder your blog lives in on the server)
• rsync -avrz [your-site's-folder-name] [username@server]:[path-to-blog-folder] (update the remote folder with the local folder)

Repeat the last two steps for each install you want to update. I’m sure it’s possible to write a script to do this for a whole bunch of installs at once if desired. You may want to test all this out on your local testing server beforehand.

Update: Jonathan’s right, Subversion is a VERY easy way to update WordPress…once you’ve got it set up. This Codex page describes the process. It’s easiest to do if you’re either just setting up your blog or if you only have a couple of plugins or themes installed. There are other benefits to using Subversion. You can easily switch from using the current release version to using the bleeding edge version, for instance to test out a release candidate. The WP Subversion repository also wasn’t affected by the recent security exploit, so there may be a security advantage.

The first problem: Giving the admin a nickname that’s the same as an existing username breaks that user’s author page.

I thought it would be nice to give the admin user the nickname ‘isaac’ because then when I commented on posts without remembering to log out the comments would say ‘isaac’ rather than the Orwellian ‘admin.’ Obviously, I wasn’t thinking straight – one should only do serious admin tasks when logged in as the admin. The danger of making a mistake isn’t the only drawback – it somehow confuses WordPress, breaking the author archive page of the user whose nickname the admin uses. This may only happen with permalinks – I didn’t investigate it extensively.

The solution: Set the admin’s nickname back to ‘admin’ (and log out after doing admin stuff!). Or I guess you could promote your normal user high enough to do most admin tasks.

The second problem: Broken author pages for users with ‘@’ and such in their usernames.

Some of my users have registered using their email addresses as usernames. That shouldn’t be a problem – WordPress allows ‘@’ and ‘.’ in usernames, so it should be able to deal with them, right? Apparently not with permalinks turned on. Without permalinks the author page receives an author ID to identify which posts to show. With permalinks the author page receives the author nicename to identify which posts to get. Unfortunately, the WordPress function the codex suggests using to get the author info is get_userdatabylogin(), which wants (duh) the author’s login. The login has things like ‘@’ and ‘.’ but the nicename does not. So, for my users crazy enough to use their email addresses for login names the author page was showing nothing.

The solution: Rewrite the author page to use this query instead of get_userdatabylogin():

$wpdb->get_row("SELECT * FROM $wpdb->users WHERE user_nicename = '$queried_name'");

This should probably be in a cascade of if…else statements so that turning off permalinks doesn’t break the author page.

The biggest improvement is in the album manager. Thumbnails can now be turned off, which should help with large image collections. It’s also now paged by category, which should help too. The delete function should work properly now.

Download photopress.zip or photopress.tar.gz.

You can always find the most recent version (and older versions too if you know where to look) at wp-plugins.org.

Known issues:

• no dropdowns in the album manager: haven’t figured out how to do this yet
• descriptions aren’t stored: the description you enter in the uploader is only used to make the image tag to insert in a post – it’s not stored in the database
• missing options: see this post for details (upgrade to the latest WP to fix this)
• broken buttons: try enabling the failsafe buttons on the options page
• broken album layout: edit album.php, in the photopress folder
• bad paths: the plugin tries to guess the right paths, but it sometimes fails – you can set the paths manually at the end of photopress-inc.php
• resizing fails: your GD install needs to be working properly, sometimes re-installing seems to trick it into working

I also figured out how to list posts containing an image. It’s turned off by default because it doesn’t work perfectly – the default sidebar thinks individual images in the album are searches when it’s turned on. This can be fixed by editing sidebar.php, but that’s lame.

Finally, Photopress now looks in your theme folder for a template called pp_album.php and uses that for the album template if it exists. Seems like it makes more sense for custom album templates to go in with the theme files, and now when upgrading there’ll be no need to worry about overwriting your custom template. If it doesn’t find a custom template it still just uses the default.

So, if you want to try it out, download photopress-0.5.1.zip or photopress-0.5.1.tar.gz. Let me know if you find anything broken, or if you have ideas about how to make it work better.

Download photopress.zip or photopress.tar.gz.

You can always find the most recent version (and older versions too if you know where to look) at wp-plugins.org.

Known issues:

• missing options: see this post for details
• broken buttons: try enabling the failsafe buttons on the options page
• broken album layout: edit album.php, in the photopress folder
• bad paths: the plugin tries to guess the right paths, but it sometimes fails – you can set the paths manually at the end of photopress-inc.php

Download photopress.zip or photopress.tar.gz.

You can always find the most recent version (and older versions too if you know where to look) at wp-plugins.org.

Download photopress.zip or photopress.tar.gz.

You can always find the most recent version (and older versions too if you know where to look) at wp-plugins.org.