Here’s an example of a solution I configured, which leaves the site in the network, but establishes a domain map from any registered domain, to the network. It makes the network site appear to be a completely independent site, with all the functionality (log-in, etc.) intact.
Goal:
Map client’s registered domain, both www.foosite.com and foosite.com over to our multisite network mymultisite.com – and make it as easy as possible on the client (i.e. no mucking around with CNAME or A records, at their registrar).
Procedure:
Using Amazon Route 53 as the DNS system.
-
With Amazon AWS Route 53 handles the DNS, so we first create a hosted zone for the client’s registered domain (
foosite.com) with a www CNAME record pointing towww.mymultisite.com -
Set up an S3 bucket in Amazon AWS for the (non-www) client’s
foosite.comand statically map that towww.foosite.com -
Back in the Route 53 hosted zone, create an A record for the (non-www)
foosite.comand specify it as an Alias, pointing it to the bucket created in step 2. This assures that bothwww.foosite.comandfoosite.comwill end up pointing towww.mymultisite.com -
In the multisite network, go to the client’s site in network admin and edit the site URL, changing it to
www.foosite.com -
In the hosting account that hosts
mymultisite.comspecify an add-on domain (or a parked domain) calledfoosite.comand point it to public_html (or wherever you have WP installed). This effectively creates a virtual host record in Apache config, for the incoming mapped site.
(note: If the multisite is hosted at a static IP address and is the only site at that address, and the hosting company allows dynamic mapping of incoming domains to the site’s document root…then you don’t have to use add-on or parked domains. Check with your hosting company if unsure).
- In your
wp-config.phpfor the multisite, you need to add a line:define('COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );If you have any issues with this setting, you may want to trydefine('COOKIE_DOMAIN', '');).
Result:
You’ve established a complete DNS solution for the mapped domain. All you have to do is tell the client to update their registrar for their domain, specifying the Amazon nameservers that are recorded in your hosted zone at Route 53 as their DNS. Your clients don’t have to mess around with CNAME or A records at all – you are handling the mapping completely, at Route 53. Furthermore, due to the magic of the AWS Alias record, your multisite doesn’t even need to be on a static IP address (although I keep it on one, just to be safe).
If using another system as the nameserver (e.g. Enom, or GoDaddy), you’d set up an A record for their domain which points to the static IP address of mymultisite.com. This is an ok answer but it carries the risk that if your static IP address ever changes, you’d have to tell your clients to go update the A record at their registrar.
I like the Route 53 solution a lot better. I also established a “white label” set of DNS at AWS following the guidance in this article. Now it is extremely simple – just tell clients here are your new nameservers to set at your registrar, and everything on the WP side works flawlessly. No need to maintain a static IP address in an A record.
Here is what the Hosted Zone looks like for foosite.com:
foosite.com A ALIAS <name of S3 bucket>
footsite.com NS ns1.vanityns.com; ns2.vanityns.com; ns3.vanityns.com; ns4.vanityns.com
foosite.com SOA ns1.vanityns.com hostmaster.vanityns.com x x x x
www.foosite.com CNAME www.mymultisite.com
Setting up the vanity nameserver is too much to enter here; follow the directions in that article I linked. One additional point on that: make sure for the nameserver entries for the vanity nameserver itself, you specify the list of vanity nameservers with glue records connecting to the real IP addresses of the actual AWS assigned nameservers in your reusable delegation set.
This boils down around 20 hours of research/experimentation into what worked out for me.