Domain mapping, SSL and theme customizer

Hi,

There seems to be a problem with the WordPress Theme Customiser in combination with the following setup.

1. Network in subdomain mode with primary domain (ex. network.dom) over SSL.

2. Domain mapping settings:
Administration mapping: original domain
Cross-domain autologin: yes / async
Force http/https (Only for original domain): yes
Would you like to force http/https in front-end pages: Force https

3. Sub-site (ex. site.network.dom) with mapped domain (ex. http://www.site.dom) non-ssl

When accessing the Customiser, the preview frame comes up empty in the Chrome browser.

The error in console:

Mixed Content: The page at 'https://site.network.dom/wp-admin/customize.php?url=http%3A%2F%2Fwww.site.dom%2F' was loaded over HTTPS, but requested an insecure resource 'http://www.site.dom/?customize_changeset_uuid=e195b0e7-235f-4002-…'
This request has been blocked; the content must be served over HTTPS.

After changing some settings like background, the preview content will become visible all of a sudden. The message in console remains similar but apparently the browser deems it less of an issue and does not block the requests anymore.

Still, to clients seeing the empty frame at first this is so worrying that they conclude it simply "does not work" and back out of the customiser. Sadly, there is no other way to change the background image for example...

Is there any way to solve this problem? Maybe similar to how the post Preview is done by adding a &dm=bypass to the URL? I tried this manually (adding &dm=bypass) but that has no effect (yet). Also tried changing the ?url=http%3A%2F%2Fwww.site.dom%2F to ?url=https%3A%2F%2Fsite.network.dom%2F but without effect.

Thanks!

  • Adam Czajczyk

    Hello RavanH,

    I hope you're well today and thank you for your question!

    The issue here seems to be that that the mapped domain is not protected with SSL.
    The sub-site works over "https://" connection and is forced to so it will always load that way. The WP customizer does load the site into an iframe element which is essentially a "browser within a browser" and it takes the Site URL as an URL that it loads.

    However, the mapped domain seem to be set to "Directed to mapped (primary) domain". Is it set that way? That would explain why that happens as Domain Mapping would perform such redirect from original to mapped domain and it has no way of knowing that it's been called by WP customizer (as that call is a part of core WP). Then, because the mapped domain is not loaded over https connection, the mixed content error comes up. Result may be different depending on theme - some of them would load pretty well, some would be slightly "messed up" and some may break completely, unfortunately.

    The "ultimate" solution here would be to either switch that to "Disabled and entered domain should be used" or to add an SSL certificate for the mapped domain. The first option has a "downside" of that kind that it would also let visitors use original domain in addition to mapped one. The second option though should fix "mixed content" and solve the case.

    That being said, while we cannot change the WP customizer behavior in that aspect and change the way it loads the site, we may look for the way to automatically "temporarily disable mapping" if the site is loaded via customizer. I would need to consult developers about that but before I do this could you please try switching the "Front end redirect should be:" option for one of the affected sub-sites to "Disabled and entered domain should be used" just to see if that works for you? If it doesn't, check also the "Directed to original domain" option and let me know please if and which one works on your setup.

    Looking forward to your replay,
    Adam

  • RavanH

    Hi Adam, thanks for the quick response :slight_smile:

    The issue here seems to be that that the mapped domain is not protected with SSL.

    Yes, that's what I tried to explain :wink:

    ... please try switching the "Front end redirect should be:" option for one of the affected sub-sites to "Disabled and entered domain should be used" just to see if that works for you?

    That seems to do the trick for now. Indeed, the downside being that there are now two domains on which the site is accessible... Adding each sub-site domain to the SSL license is not really an option either as there are simply too many domains mapped on the network.

    ... we may look for the way to automatically "temporarily disable mapping" if the site is loaded via customizer.

    Yes, I was hoping there could be found a way. But it does not sound easy, unless some "?dm=bypass" kind of trick could be implemented.

    Thanks for making this issue known to the devs! :slight_smile:

  • Dimitris

    Hey there RavanH,

    hope you're doing good and don't mind chiming in! :slight_smile:

    There's been some latest development about this, I just beta tested the latest commit and it seems to work at least for the following conditions:
    1. In network admin area under Settings -> Domain Mapping
    Administration mapping => mapped domain
    Login mapping => mapped domain
    2. In subsite admin area under Tools -> Domain Mapping
    Front end redirect => Directed to mapped (primary) domain

    If that's your setup, I could provide you the beta version.
    If not, please inform me about your settings and I'll keep you posted about any new development on this! :slight_smile:

    Warm regards,
    Dimitris

  • RavanH

    In fact, this is getting more serious... On another network, not using SSL anywhere, it now seems impossible to log in even on the main site. The login refuses users and comes back with this message:

    ERREUR : les cookies sont bloqués ou ne sont pas reconnus par votre navigateur. Vous devez activer les cookies pour utiliser WordPress.

    This means something like "cookies are blocked or are not recognized by your browser, please activate cookies..." with link to https://codex.wordpress.org/Cookies which is totally absurd of course.

    I have the feeling Domain Mapping is messing with the cookie domain or path but looking at the domain cookies in the browser dev tools, the cookies that are set look OK.

  • James

    We were experiencing the lockout on all subsites AND the main site upon this update - we've never experienced this issue before but when chatting with support they insisted that we deactivate all of the plugins thinking that there is now a conflict. Nothing else was changed on our server other than this domain mapping update, and removing the plugin brings functionality back.

    The issue prior to this update is that the customizer would break on any subsite that didn't have SSL - which was a massive catch 22 because the plugin wouldn't allow people to map WWW subdomains with SSL (all of our domains are mapped with CNAMES due to a load balanced setup).

    We've been looking at getting off of this plugin due to it's glaring issues but we have thousands of users right now with mapped domains and just switching plugins doesn't seem like it will be quite a process. Curious if you have any insight or what your plan is RavanH

  • RavanH

    My setup did not involve thousands of domains so I decided to go at it without plugin. Also because on this particular network, I do not need to offer users an admin page where they can add their own domains. I just take care of domain mapping from the Network admin.

    For anyone interested in going bare feet (without domain mapping plugin) there are good instructions on https://wordpress.org/support/topic/howto-domain-mapping-without-a-plugin-instructions/ (most important is the COOKIE_DOMAIN constant!)

    James in your case that would mean manually changing the home and site url on the network admin. Or create a batch sql query to do in on the database side... In both cases, it sounds daunting.

    So maybe here would be a strategy worth testing:

    Do you have a development version of your network that you can mess around with and break without causing problems? If so, then try simply deactivating Domain Mapping and uninstall it (including the sunrise.php). Next, install either Donncha's Domain Mapping plugin from the WP.org repo or the Mercator plugin from https://github.com/humanmade/Mercator and see if they recognize (all) the domains that were added via WPMUDEV's Domain Mapping plugin.

    All these plugins use the same DB tables as far as I know so it might be simply possible to switch from one to another... Just keep in mind it will involve more than de/reactivating plugins, there are also the sunrise.php and wp-config.php changes to make!

    Note that if you go with Mercator, there are also some interesting extensions among https://github.com/humanmade?utf8=%E2%9C%93&q=mercator that you may want to consider.

  • Dimitris

    Hey there RavanH, James,

    hope you're doing good and I'm so sorry for the late response here, it's been quite hectic lately in our end!

    I was able to reproduce the Customizer errors in a test installation of mine, which I provided for further testing to our devs.
    Me or another colleague of mine will keep you posted here about any development.
    I'm truly sorry once again for the frustration here.

    Warm regards,
    Dimitris

  • James

    Dan - thanks for the information - that's something we can at least test but unfortunately it's not really a possibility for us on production. We house all of our training on the main site on the network and people need to be logged in to the network to access it, which (from memory when we tried this before) caused issues with the cross domain login abilities.

    Maybe its going to come down to the lesser of 2 evils. Either have a bad user experience without the cross domain functionality but be able to update WP and all of our outdated plugins, or risk continuing to use an outdated version of WP. Will have to weigh the pros and cons i guess.

    Thanks again

  • Dan Berdal

    That's the choice I made as well. In my case only 10% of my users have mapped domains. Everyone else doesn't need to login a second time. WordPress seems to login network wide unless you're using mapped domains.

    I've also discovered you can login network wide if you don't access the login screen at the mapped domain.

    For example:

    Scenario 1 - If you access mappeddomain.com/wp-admin it'll forward to rooturl.com/mappeddomain/wp-admin and you'll be forced to login again even if you're logged in at the root site.

    Scenario 2 - However, if you directly access rooturl.com/mappeddomain/wp-admin/ it'll accept a login credentials from the network and you will not need to login again (if you're already logged in at the root url).

    I don't know what that is, something must happen in the redirect, that screws up which cookie domain to use for logging in.

    The second issue you'll have if you ditch cross domain login is that users will not be logged in while viewing the front end of their site. For me that was ok most of the time, but certain pages I wanted them to be logged in. The domain mapping plugin has a workaround built in.

    If you link to rooturl.com/mappeddomain?dm=bypass it WILL NOT forward to mappedomain.com

    Hope that helps