willnorris.com

there's more to life than this

WordPress MU in a development environment

Published on by Will Norris

Most of the development I do for my job is within WordPress, so I have quite a few WordPress instances running on my local workstation. I’ve been using the same custom Apache setup for three years, and have been developing on WordPress for almost as long, so I’ve been a bit bewildered with the amount of trouble I’ve had the several times I’ve attempted to get WordPress MU running on my laptop. I identified a couple of specific problems and solutions, which I wanted to outline here.

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.

Comments and responses

senthil

I was facing this issue for long time, but could not find out the cause. But you have explained it very clearly..

Btw, is there any way we can use intranet url?

Will the problem get solved, if we could remove the domain PART in the cookie code?

Will Norris
@senthil: yes, if you turned off the domain part of the cookie response header, it should probably work. If you’ve got WPMU setup to use sub-domains for user blogs (like wordpress.com does), then this will likely break the ability to go between hosted blogs and still be logged in. If however you are using sub-directories, it should work fine. (Keep in mind, I’ve not actually tested this, but it seems reasonable).
Miranda

So close and yet so far.. I am attempting to run MU on an XP SP3 virtual server and after much struggling, have gotten this far. Finally get to this login and I have exactly the same issue. If you put in the correct auto-generated pass, it just comes right back (as if nothing happened).

I cannot remame the Virtual XP machine anything with a dot in the name

Will Norris
@Miranda: you shouldn’t actually have to rename the machine itself, just setup a virtual host in IIS or Apache that has a dot in the name. You will of course need to add an entry to the appropriate hosts file so that your browser knows how to resolve that hostname.
Miranda

Sorry to seem such a newb. Could elaborate on how to do this? I have added the line:

ServerName wp.mu
DocumentRoot ${path}/www

to apache’s config. This seemed like the logical step? I am a little confused how this works since the name “wpmu” is being directed by my DNS, where it is defined. Where exactly am I making the change to wp.mu without renaming the machine, in the DNS?

All apache is doing is running locally on the virtual server (attempting) to run MU.

Sorry if this sounds way off, I have just been spending SO much time on this, made it this far and am shattered. I’d love to be able to make this work, but am almost ready to approach this whole thing differently. Thanks for anything!

Will Norris

You need to add an entry into your hosts file. Depending on your OS, it is in different places. If you’re doing this from the virtual server itself, you’ll want to add the following:

127.0.0.1  wp.mu

If you’re connected from a different machine (like the host machine which the virtual one is running on), you’ll change the IP address to be the IP of the virtual server.

sean steezy

Um, I may be retarded when it comes to this stuff (design mostly), but I have this same issue, but I have no idea what you’re talking about. I’m running wpmu on iis 6 and got this far.

I can remote in to the server, windows 2003, but I have no idea where to add the dot to the domain, or to set the cookie.

where do i change the “domain part of the cookie response header”?

any help is much appreciated.

Will Norris

Sean: I’ve not tested it but you should just be able to set the following in wp-config.php:

define('COOKIE_DOMAIN', '');

If you simply use a hostname that includes a dot, you shouldn’t need to mess with that though.

Will Norris
Stephen: in most cases, that will work fine, but various vendors do different things with the .local TLD. So you may get unexpected results depending on how you have your hosts file setup, or even the network you happen to be on at the time. Like I said, you’ll probably be fine, but if you really want to play it safe, don’t use .local. I typically just drop the TLD altogether for most sites.
sean steezy
Hey, I finally got it to work by just adding a dot to the domain. now my cookies are going through properly, just starting to configure the email part. thanks for writing this article, i was banging my head on the wall for a week and finally got into my admin panel.