I saw your post earlier and hoped someone more knowledgeable of multisite would answer. Lacking such a response, hopefully my limited knowledge will do. Domain mapping is similar to domain aliases. The underlying foobar.example.com domain remains in use internally. It’s not available for other usage. AFAIK any foobar.example.com request will be redirected to the mapped “alias” foobar.com.
I suggest doing some simple tests to confirm what I think to be true. If you have a localhost installation to test on, you can use unregistered domain names with it by adding them to the machine’s hosts file and mapping them to 127.0.0.1.
Hi @bcworkz
Are your thoughts based on wordpress.com behaviour? I did some testing and on a wordpress.com blog. The foobar.example.com address seems to redirect to the example.com address in this case. They must have implemented something custom because this doesn’t happen in a wordpress.org self-hosted install.
In a wordpress.org install, the foorbar.example.com address seems to cease to exist when domain mapping is active for a blog. For example if you enable domain mapping for foobar.example.com and example.com and then attempt to register foobar.example.com as a new user, the registration is successful
Apologies, in a wordpress.org install, I do actually get “Sorry, that site is reserved!” when attempting to register foobar.example.com as a new user.
I actually think “Sorry, that site is reserved” is a bug. A condition for this text to be displayed is username_exists( $blogname ) which is a definite bug because username_exists() should accept a user name, not a blog name
I don’t really know much about wordpress.com behavior. I’m mainly going on memory from a multisite installation I used to have. Even though the subdomain doesn’t appear to be in use once it’s domain mapped, it’s still used internally to keep track of which sub-site is being requested. It’s one important reason why another user cannot use the same subdomain.
While the resulting error message may be misleading and inaccurate, the gist remains that you cannot register a site using the data provided. I don’t have a strong opinion on whether that’s worthy of improvement or not. I’ll let you all over at Trac decide. I’m staying out of it 🙂
Good point!
It actually gets even more interesting. Here’s an example:
Imagine domain mapping is active for foobar.example.com > foobar.com.
Now, if there is a user with a username of foobar then the sub-domain foobar.example.com isn’t available to register. However, if there isn’t a user with a username of foobar then the sub-domain foobar.example.com is available to register.
This is for wordpress.org by the way. wordpress.com may do things differently. I’m not familiar with wordpress.com either.
If that’s the case, my conception of the internal workings of WP is wrong. Thinking about it some more, it’s not the subdomain WP uses to internally route requests, it’s the associated “virtual subfolder”. Even subdomains are an alias of sorts. Subdomains and mapped domains both get assigned to a virtual subfolder to handle internal routing. It’s that subfolder name that is reserved, not the subdomain. In its heart, WP is always subfolder based. Subdomains are a mere overlay on top of that.
The virtual subfolder name normally takes the name of the assigned subdomain. If that name is already reserved by another subsite, I imagine WP would just auto-increment the name, such as /foobar-2/. In a subdomain installation, no one ever sees this virtual subfolder. This has caused issues when someone happens to create an actual server folder with the same name. Then all requests go there and WP never even sees it. Sorry if I caused any confusion.
Thanks for your help with this and thanks for explaining the virtual folder part. Multisite can be a steep learning curve when you start using it and gradually through conversations like this it all makes sense 🙂
thanks for sharing your knowledge its really helpful
