Tag: wordpress

I’d heard it’s difficult to get WordPress working well on an IIS host but had never experienced it myself. In my case the install appeared to be working, but then looked like it’d failed on step 2. Browsing to the site, the text was all there, but clearly the style sheet hadn’t been loaded. The internal links were also all messed up, with “?step=2” thrown in instead of the folder name where I’d installed the blog. A bunch of browsing of the WordPress forums revealed widespread IIS problems and a few proposed solutions. I tried a couple, involving editing wp-settings.php, but without effect.

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?

After the recent flurry of WordPress upgrades I started looking for an easier way to upgrade. This post at techites.com was a good start, but this comment on the post, using rsync, sounded much easier. Here’s the workflow I figured out:

• 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.

I just noticed that my author pages at wedin.org were pretty messed up and now that I’ve fixed them I figured I’d make some notes about what I did.

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.

See isaacwedin.com for a new version of Photopress. I figured it could use a home of its own. Might be nice to have something like a forum there too.

It seems to be working well enough to package another release. I appreciate all of the bug reports I’ve gotten. If your favorite annoyance isn’t fixed or listed below as ‘known,’ please let me know.

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