Choosing the right hostname

Part of my custom setup is that I have a whole slew of bogus hostnames pointing to localhost, which Apache then dynamically maps to the correct document root. For the most part, I just drop the TLD from the actual hostname… so http://willnorris/ is my locally hosted development site for this blog http://willnorris.com/, and http://will.norris/ is my development site for http://will.norris.name/. I also keep a handful of WordPress versions running locally, so I can test plugins in those different environments — http://wordpress-2.3/, http://wordpress-2.5/, etc. When I began to setup my WordPress MU (and BuddyPress) instance, I used the site http://wpmu/. The installation went fine, but when I tried to login it failed every time. Given that this same setup worked fine with single-user WordPress, I was quite confused. I quickly realized though, that the authentication cookies were never being set for WPMU… in fact no cookies were.

The difference between the two versions of WordPress is the value of COOKIE_DOMAIN which is passed to setcookie(). Both flavors of WordPress allow you to define this constant in wp-config.php, but they differ in what happens if it is not defined there. WordPress sets it to the boolean false, whereas WordPress MU sets it to '.'.$current_site->domain. This results in a different Set-Cookie HTTP header between the two. Take for example the wordpress_test_cookie cookie. WordPress sends the response header

Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/

whereas WordPress MU sends the response header

Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/; domain=.wpmu

The difference of course is the domain=.wpmu there on the end. In a production environment, this wouldn’t make a bit of difference. But because I’m using fake hostnames in a development environment, this makes all the difference in the world. You see, the HTTP Cookie Spec (Section 4.3.2 Rejecting Cookies) requires that the domain attribute includes an “embedded dot”. This is a security feature that prevents a site from setting a cookie on a top level domain like “.com”. Since single-user WordPress wasn’t specifying a domain attribute, it didn’t have any problem setting the cookie. Because my hostname wpmu doesn’t contain an embedded dot, the browser was properly rejecting the cookies, preventing me from being able to login. So our solution here was to use the site http://wp.mu/ (note the added dot in the middle) for hosting our WordPress MU development site.

Sending Mail

The other main problem I had with WordPress MU was that none of the notification emails were being delivered. This was actually a problem with single-user WordPress as well, but it didn’t matter as much then. Now I’m needing to test the account sign-up process a bit more, and so I need the activation emails that are being sent out. It’s been a long time since I’ve administered an email server, so I won’t embarrass myself by trying to explain what the problem was (something along the lines of my ISP’s SMTP server not liking what mail() was sending) . I was however able to fix it by writing a very simple plugin, Development Mailer, that changes a few configuration options of PHPMailer. This works for me on Mac OS X (Leopard), but I make no guarantees for anyone else. Keep in mind that his plugin should only ever be needed for a development environment… if you’re unable to send notification emails from your production blog, then you’ve got other problems.