WordPress

Moving a WordPress blog

by

Since I’m preparing to release a new app next week, I wanted to make my MC Development site focus on software and services, so I moved my personal blog off that site. One major goal was to maintain all of my existing posts and preserve all of the old permalinks, which I accomplished.

Here’s how I did it.

The first step was to do a clean install of WordPress on this site. Meanwhile, I went to my old site and exported all content at /wp-admin/export.php. When it finished exporting, I returned to this site and imported the XML file from the last step at /wp-admin/import.php. Since the file was huge, the import took several minutes. When it finished, all of the posts, pages, and comments were intact. Finally, I had to make sure I installed & enabled all of the appropriate plugins at this site.

To preserve the old permalinks, I had to add a few rewrite rules to the old site. Since I’m using nginx, I added the following lines to my nginx.conf file:

# redirect permalinks to blog.mcohen.me

rewrite ^/blog/ https://blog.mcohen.me/ last;

# all other requests go to WordPress
    if (!-e $request_filename) {
	  rewrite ^(/20../../../.*)$ https://blog.mcohen.me/$1 last;
      rewrite ^.*$ /index.php last;
}

location ~ /\.ht {
    deny  all;
}

The first rewrite rule does a simple redirect of http://example.com/blog to this site.

The second rule is a bit tricky. I’m using permalinks of the form /%year%/%monthnum%/%day%/%postname%/ and I wanted to redirect only those permalinks and nothing else to this site. The first part of the rule, ^(/20../../../.*)$ matches 4 characters starting with 20 (since my earliest posts are in 2002), followed by a slash, followed by two more characters, another slash, two more characters, another slash, and any number of characters. The second part of the rule creates a URL at this site using the matched characters.

The final rewrite rule simply passes anything else to WordPress.

If you’re running Apache, you would have to use similar rules in your .htaccess.

WordPress 3.0

by

I upgraded this site to WordPress 3.0, which took less than a minute and was completely painless. I also upgraded the themes & plugins. Upgrading the Suffusion theme, which I’m using, messed up all of the options so things might have looked weird while I was fixing the theme options.

MarsEdit 3.0

by

MarsEdit is one of my favorite applications and it just got even better with version 3.  I have been using MarsEdit for this blog almost since the beginning. I’ve looked at other blog editors, but I always came back to MarsEdit because it just seemed more comfortable and it just worked exactly the way I wanted.

Until now, MarsEdit only supported HTML editing, but version 3 also adds a new Rich Text editor. MarsEdit 3 also adds support for WordPress pages & custom fields and a new media browser that supports iPhoto, Aperture, and Lightroom.

The only thing MarsEdit is missing now is an iPad version.

Rich Text Editor

WordPress & WPMU are merging in 3.0

by

This is why I’m looking forward to WordPress 3.0:

It was announced at WordCamp San Francisco last year that WordPress and WordPress MU would be merging codebases. This has now happened in 3.0-alpha, and we’re working on smashing bugs and tidying up a few screens. If you’re currently using a single install of WordPress, when you upgrade to 3.0 you won’t see any of the extra screens associated with running a network of sites. If you’re currently running MU, when you upgrade you’ll notice a few labels changing, but upgrading should be as painless as usual. If you’re going to set up a new WordPress installation, you’ll be asked as part of the setup if you want one site or multiple sites, so that’s pretty simple. If you want to turn your single install into one that supports multiple sites, we’ll have a tool for you to use to do that, too.

Right now WPMU, which we use at Teens In Tech, always seems to lag behind WordPress for updates and many plugins don’t fully work in WPMU. I’m really interested in seeing how they manage this.

Server crash

by

As you’ve probably heard, wordpress.com was down today, which means ICanHasCheezburger, FailBlog and other related sites were down. Since my feed proxy script used for the iPhone app accesses those sites, it eventually ended up crashing my entire server.

A support person at Dreamhost explained:

Yeah, the issue was likely that your PHP scripts were hanging due to not
getting a response, which then caused the requests to build up and
overload the running PHP processes.

Nginx update

by

After running Nginx for a day everything seems stable. The memory usage is much lower – I was able to reduce my PS from 458M to 304M. The sites seem faster & more responsive, and memory usage remains pretty much constant rather than fluctuating based on the number of connections, as it did with Apache.

Screen shot 2010-01-29 at 9.18.15 PM.png

Using Nginx at DreamHost

by

All of my sites are now running Nginx rather than Apache, which has several major advantages. Apache uses a separate process for each connection, so if you have a very busy site with lots of simultaneous connections it can use a huge amount of memory. Nginx, on the other hand, uses one worker process with a fixed number of CGI processes no matter how many connections it’s serving.

As you can see from my resource chart, the memory usage dropped dramatically when I switched over to Nginx.

Screen shot 2010-01-28 at 7.31.50 PM.png

Nginx has a few drawbacks, however. It doesn’t support Subversion or WebDAV, so I first had to move my Subversion repositories off my virtual private server. I ended up moving them to ProjectLocker. Most importantly, Nginx doesn’t use a .htaccess file. Instead, it uses its own configuration files, which DreamHost documents here.

Basically you need to create a nginx folder in your home directory, and make a subdirectory for each domain, for example ~/nginx/mcdevzone.com, and create a configuration file, which can be named anything. The syntax is different than .htaccess, although it has many of the same capabilities such as access control or rewriting URLs.

For a WordPress site, all you need is this:

#######################
# Permalinks

if (!-e $request_filename) {
  rewrite ^.*$ /index.php last;
}

DreamHost provides many more examples on their Wiki page, and you can find even more at the official Nginx site.

One important rule you should add to your config file, which DreamHost leaves out, is this one which will prevent users from viewing your .htaccess file, if you still have one.

location ~ /\.ht {
    deny  all;
}

I ran into a few gotchas, but once I figured them out I was able to get everything running smoothly. According to DreamHost’s documentation, the site-wide Nginx configuration file is at /dh/nginx/servers/httpd-psXXXXXX/nginx.conf, but I found that it didn’t exist, at least on my server. Instead it was named nginx.conf.pushing, so as a result Nginx refused to start. Once I renamed it, I was able to start nginx. You WILL need to have an admin user on your private server in order to access that file and restart nginx.

UPDATE: The problem I ran into with the missing config file was because the update didn’t finish properly for some reason.

DreamHost’s older virtual private servers don’t support Nginx, so if you want to use it, you may have to request to have your PS moved to a newer system.

If you have a very busy site, Nginx can help you deal with the load, so it’s worth checking out. Several major sites including WordPress.com, Hulu, and Github are using Nginx, so it’s definitely production quality.