Mapping Domains Without a Plugin

Recently I wrote WordPress Murder Mystery. The day I released it, I got on a plane to fly to Miami, and proceeded to have a pretty awful travel day, thanks to a storm that pretty much knocked travel to the SouthEast out of commission. While I waited for my flight to DFW, I got pinged. “Hey, I can’t add anything from your store to my cart!”

I pulled up my laptop and thought about what I’d changed. Oh. I’d turned off domain mapping. But not really.

Ghost Cookies

You see, I love the WordPress Domain Mapping plugin. But I’m not using it here. No, I’m actually doing something I expressly and patently tell people not to do … because time has changed with 3.9 and it’s almost okay to do things this way. The change here is that WordPress is smarter now, and it’s safer, and you actually can just edit the home and site URLs in the Network Dashboard. But you know how I said ‘almost’ back there? Your ability to shoot yourself in the foot is directly proportional to how smart you think you are.

What I did? It’s basic but assumes you already know how to add a domain onto another.

  1. Go to Network Admin -> Sites
  2. Edit the site in question
  3. Change the URL to the mapped domain, check the ‘change home and site URL’ box, and click update

That was it! Three steps and everything still worked! This also let me force change a site to https all the way, and since I didn’t have content, I didn’t bother with a search/replace. If I had, I’d use that Interconnectit Script or WP-CLI for it. Still, like a wise person, I always get the domain ‘right’ before I add content.

And at this point, everything seemed to work just fine! And so I left it as is and published my book. And as you know, it all failed, spectacularly. I rolled everything back (because I knew what I’d changed last, see? always remember that!) and it worked again, so I knew I had to have missed something big here. Since I was stuck in an airport with choppy wifi, I disconnected everything and fired up my localhost version of my site. Banging on that for a while, I saw I missed a small, but hugely important factor in the plugin.

See most of what it does is that pretty interface to say “Pull domain.foo content from site #2 (aka foo.example.com)” and force redirects. It also lets you do cool things like “Allow users to log in from foo.example.com instead of domain.foo” but really I didn’t need any of that. The meat of the code is in the sunrise.php file, which when I studied, I realized was just doing the redirects “Send Site #2 to domain.foo” and for me, by renaming the home and siteURLs, I was already doing that.

So what had I missed?

define( 'COOKIE_DOMAIN', $_SERVER[ 'HTTP_HOST' ] );

That was it. I forgot to tell it “Cookies belong to the domain you’re on.” What this means is that if you log in at example.com, the cookie you get is for example.com and not domain.foo! For the most part, this isn’t a problem since no one logs in but me … until you try to make a purchase and it validates a cookie which doesn’t match the domain. I added that to my wp-config.php (down at the end of my Multisite section, where the SUNRISE define had been earlier) and everything magically worked.

Two lessons! First, test everything. Second, you can map domains without a plugin, safely.

I will note that, over time, it’s possible those settings for home and site URL may vanish from display. They’re powerful and dangerous settings, and you should not mess with them without a good backup.

About these ads
StudioPress Theme of the Month

Comments

  1. Those cookies always confuse me. The plugin never seems to handle it correctly for me and I end up either not able to log in on some domains, or erratically logged in or out depending on, well, things beyond my comprehension :/

    I wasn’t aware of that definition causing problems, so I might need to have a poke around with that some time.

Half-Elf? Try Half OFF WordPress ebooks!