WordPress MU in a development environment
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
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?
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
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!
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.
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.
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.
For my dev server, I’ve always set the hosts replacing the “.com” with “.local”. Thus:
willnorris.local