Domain Mapping - The solution?

Hi there everyone!

It's been a while since I've encountered problems with Domain Mapping because I've mostly been busy working on invoices, multi-db, my own nameservers and load balancing through memcached.

With that all working it was finally time to write my own API so mapped domains automatically get into my DNS servers so the users won't have to do a thing - the beauty is: even their MX and SPF records get all set up correctly for them, plus with some more API work you can even let your users create mail accounts through the WordPress dashboard - even better: read their mail!

But that's all for later - I'm just teasing you with a plugin that will be released for free soon on these forums :slight_smile: Also, I'm digressing.

The problem that I've encountered with Domain Mapping is strictly related to SSL, even more so: Theme previews/editing, redirecting and in-page editing either doesn't work or creates unnecessary server load, bad browser cache and bad Google SEO score.

The original MU Domain Mapping from wordpress.org seems to be a great one, because, well, WordPress.com uses it!
But that's not the case - WordPress.com does a lot of behind the scenes coding, most of which we'll never see - like their beautiful (and self-advertisement filled) theme editor, extremely well page caching, in-dept forums, and more but not not limited to their domain mapping. (yay Oxford comma)

WordPress.com recently announced that they'll move to a full HTTPS makeover, this is their reaction to Google's recent announcement that they rank pages higher if they support the correct TLS connection (SSL is dead now since POODLE). As par of this, you'd expect their plugin to be updated as well - but it doesn't. I did some looking-in into their websites and they suffer from the same problem we do with HTTPS. It's because you want to do something client side: redirecting - while at the server side you still want everything to be canonical.

I might get too technical here, but let's make it simple with an example:
You have a your mapped user's domain:
http://awesomedomain.com
And its original domain is:
https://notsoawesome.host.com

In the WordPress core, everything that's going to http://awesomedomain.com comes from https://notsoawesome.host.com

The Domain Mapping takes care of this by rewriting the URL's in the system and creating a cache for it (briefly looked into the code - correct me if I'm wrong) while removing the https:// links.
See line 548 to 583 in domain_mapping.php.

Now you have several options in the Domain Mapping section - for now, we'll just look at the Network settings, under Administration / Login mapping, you'll see these three options:
1. domain entered by the user
2. mapped domain
3. original domain

And this is where it gets tricky: you're on one domain; one IP address - and you want to redirect the user between your domain's administration area where passwords are handled (so you want HTTPS) and his own site (no HTTPS).

A few things are happening here:
1. When should be called what?
1a. So the cache gets funky.
2. Everything is being written for both https://notsoawesome.host.com and http://awesomedomain.com on different occasions.
2a. So the cache gets funky.
3. You want the blog links to work like described in the Network settings for Domain Mapping. Be it either of the three.
3a. So your cache gets funky.

So a lot is going on - for a lot of websites! And it's just not working correctly in most combinations. Now I know why edublogs.org hasn't chosen mandatory https for their subdomains (let alone their main domain - the login page is HTTPS though - and they let you log in non-https home page >.< oh well)

So we're dealing with something extremely difficult here and we must be very happy that WPMUdev has taken a lot of effort to create something great from this massive problem.

For now, I've figured out the problems and their fixes, read on and you'll know what they are. Before I go on, I would like to stress that you should under no circumstances use the wp-config.php solutions for HTTPS. They all will result in Certificate warnings across the blogs when domain mapping. This also counts for iThemes Security. I also do not recommend the WordPress HTTPS plugin because it takes a toll on your server plus I've encountered too many issues in MultiSite and Domain Mapping with it (these date 5 months back so I can't name them).

Bugs (can not be fixed without rewriting code):

1. With "domain entered by user" OR "original domain" selected in both Administration and Login mapping and with Force http/https to any option but "force http" you'll get a redirect loop between HTTPS and HTTP if you force all original subdomains to be HTTPS through the code below in your .htaccess file. All non-mapped domains will function as intended and will be always on HTTPS without problems.

RewriteCond %{HTTPS} off
RewriteCond %{HTTP_HOST} ^(.*)\.host\.com [NC]
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

This makes our wanted achievement impossible. If you set Force http/https to "Yes" and "Force https" nothing changes here.

2. While testing these scenario's out - all blogs remain bugged - even with "mapped domain" selected, even with default domain removed.
The solution, this is what I did:
2a. Remove all blogs from domain mapping (write them down on paper where they belong before you have angry customers with mismatched domains).
2b. Backup sunrise.php from /wp-content/ somewhere on your computer and remove it from your server.
2c. Deactivate Domain Mapping.
2d. Empty all caches if needed.
2e. Make some tea and take a deep breath (sorry for the long post).
2f. Go to the Network settings of Domain Mapping to see the warning and set the following options (in order):
- mapped domain
- mapped domain
- Yes
- No
- No
- No
- Your pro site levels (if applicable)
2g. REMOVE the following option from the user to be used:
"Front end redirect should be: -option-" and let it be our default. Read below this list for the code and how to.
2h. REMOVE the https:// option from the user to be used in the same line as 2g. See below for the code and the howto.
2i. Reinstate the sunrise.php in /wp-content/
2j. Clear your browser caches and flush your dns (ipconfig /flushdns in CMD).
2k. Login to network and add the domain again to the users' websites in their dashboard.

To achieve 2h. and 2g. Edit ../plugins/domain-mapping/classes/Domainmap/Render/Site/Map.php

2g code: Beginning on line 173 to 181, change to:

$mapping_types = array(

			'user'     => __( 'disabled and entered domain should be used', 'domainmap' ),
/*
			'mapped'   => __( 'directed to mapped (primary) domain', 'domainmap' ),

			'original' => __( 'directed to original domain', 'domainmap' ),
*/
		);

You see those nice /* and */ there? Lovely. We removed the two buggy options!

2h code: From line 249 to 257, change to:

<select type="text" name="scheme" class="domainmapping-input-prefix">

                                <option value="0">http://</option>
<!--
                                <option value="1">https://</option>
-->
                                <option value="2"><?php _e("Force none", domain_map::Text_Domain); ?></option>

                            </select>

Lovely! Those <!-- and --> will do the trick :slight_smile:

Alright, we've achieved a few things:
1. Remove the Super Admin network options (that's what they are!!!) which I removed above from the user's Domain Mapping page.
2. Disabled HTTPS for paying customers :slight_frown:
3. No more redirects! Yay!?

Well, at least we have a clean experience for our users now - and a little less load on our servers too :slight_smile: And if they get a MITM attack at StarBucks it's not our fault, right? Wrong! That's why we want to use HTTPS in the first place. Not because it's beautiful and green (although I do love my green bar at https://hostmijnpagina.nl/)... but because it's secure.

The real fix, for our WPMUdev and/or WordPress developers:
1. Remove the recently introduced function "force HTTPS in dashboard". We can do that in our .htaccess as you can see in the code above.
2. Make all links to the mapped domain from the dashboard canonical.

So:
- //HTTPS://notsoawesome.host.com => HTTP://awesomedomain.com/anypage/

Instead of what's happening now:
- HTTPS://notsoawesome.host.com/wp-admin/ => //notsoawesome.host.com/anypage/ => Redirect => Cert Error => HTTP://awesomedomain.com/anypage/

3. Remove those Super Admin Network options from the users' panel and place them where they below: In the Super Admin Network options.

Solved.

What can you do, as a user?
1. Try IE11, it's amazingly fast, beautiful, works well with responsive websites and doesn't crash at 9GB RAM used (darn you Chrome, I was busy!).
2. Wait out.

What if the above solution didn't work for me?
1. Buy a horse
2. Ride it and feel free in nature

Okay, I'm getting cheesy here - It's 6:56 AM now too! So I'm off to bed :slight_smile:

Good night!