Can't force schema on a mapped domain

In DM v4.4.2.4, the 'force schema' key icon next to each domain mapping in a site dash doesn't seem to work. Not in our installation, at least.

I can see (in my browser) the AJAX requests go to the server and the JSON response coming back (with the schema value cycling 0,1,2) and I can see the access log entry on the server but, when I reload the page, the schema reverts back to http://.

[Note to devs: The AJAX request uses the GET verb where it really should be using the PUT (or POST) verb because the request is intended to have a side-effect, namely, to update a setting. That would actually cause a problem for us, but for the WP auth cookies.]

I've tried deleting the mapping and replacing it, but it makes no difference.

Why does this matter? Aside from the obvious apparent bug, Google, in its infinite wisdom, have decided to give SSL-enabled URLs a slight edge in page ranking. They say it isn't much of an advantage but that they might change the weighting they give to SSL later. I suspect that they will.

Moreover, Automattic have announced the intention increasingly to enforce/require SSL, although they haven't yet specified for what they will require SSL.

As a result, I guess I'm going to have to get SSL certs for all the domains I host *sigh*. (Yes, there's LetsEncrypt but that's a bigger PITA than first meets the eye especially if you use Varnish.) Until I do, I want to be able to force SSL on a site-by-site basis rather than force it network wide by the network dash.

  • James Morris

    Hello David King,

    I hope you are well today.

    I just tested the schema switching on DM on my dev site, that is a barebones install of WP 4.7. The switching worked properly. This leads me to believe there may be a conflict of some sort on your installation.

    There's a couple troubleshooting steps I'd like you to try to see if we can narrow down the cause of this problem.

    First, could you please run a plugin conflict test as outlined in the following article? This will eliminate the possibility of a conflict with another plugin.

    If that does not lead to a solution, could you please enable WP_DEBUG and provide us with the output of your debug.log file?

    To enable WP_DEBUG, change the following line in your wp-config.php file:

    define('WP_DEBUG', false);

    To this:

    // Enable WP_DEBUG mode
    define( 'WP_DEBUG', true );
    // Enable Debug logging to the /wp-content/debug.log file
    define( 'WP_DEBUG_LOG', true );
    // Disable display of errors and warnings
    define( 'WP_DEBUG_DISPLAY', false );
    @ini_set( 'display_errors', 0 );

    After you've visited the pages that are causing you problems, please go to wp-content/ on your server via FTP and download the debug.log file to your local computer. Then, rename that file to debug.txt and attach it to your reply here so we can examine it further.

    I look forward to seeing the results of your tests.

    Best regards,

    James Morris

  • David King

    James Morris

    Okay, yeah, I put a copy of the mapper on a simple install and it worked there, and it also worked on a different site on the production network — so it must be something local and specific to that site.

    The disable-everything routine isn't really feasible on our production instance (and in fact, reverting to the default theme severely damages the config for the Genesis + extender theme we use, idk why).

    Our staging platform doesn't use mapped names (the transfer process TRUNCATEs table wp_domain_mapping in the staging DB) but will see about setting up a mapping to experiment with on the staging platform to see if I can isolate the problem by disabling plugins.

    Meanwhile, I'll close the ticket on the assumption that it is a local problem and therefore not your problem, lol :slight_smile:


  • David King

    James Morris, Sam,

    After some debugging, I think I can confirm that there is, indeed, a bug that manifests in one corner case only — when the mapped domain has a www prefix — and that there is a straight forward if obscure work-around.

    In any other case, whether bare domain or any other prefix (including or!), everything works as expected. I suspect the reason for this corner case has to do with the addition of the automatic simultaneous support of both bare- and old-style domains (see inc/sunrise.php:27).

    (That feature has actually been the source of problems in the past: sunrise.php:28 used to set COOKIE_DOMAIN to the bare domain regardless of the preferred canonical style, which caused some very subtle problems with stale cookies, hence why I'm tagging Sam.)

    First, it is evident from querying table wp_domain_mapping that clicking the key icon in the mappings dash does, indeed, work but regardless of what the scheme field is set to, the mappings dash behaves as if scheme = 0 (ie forced http://) — but only for a domain with a www prefix.

    So the problem is not in the UI, the problem lies in how DM interprets the content of table wp_domain_mapping.

    Second, the work-around for the case where the canonical mapping has a www prefix is to add the bare domain as a secondary, non-canonical mapping. Clicking the schema force icon on the old-style domain will be ignored by the plugin (well, the table row will be set, but it won't do anything). Clicking the schema force icon in the bare-style domain will update the schema for both old-style and bare-style domains, and DM will observe the schema for the bare-style domain, even when redirecting to the canonical old-style domain. Obviously, this will only work where the network dash is set to permit multiple mappings.

    Third, here's how to reproduce the bug:

    1. add two mappings to a site, and, and test to ensure web server and DM are configured to respond correctly (correct vhost etc).

    2. via the site DM dash, force SSL on both. Observe in table wp_domain_mapping that the schema field for both entries is 1 where before they were 0.

    3. reload the mapping dash. Observe that the www prefix reverts to http:// (as I reported), but the dev prefix keeps its new https:// schema even though, in table wp_domain_mapping, both have schema = 1.

    4. set as the primary and load a front-end page. Satisfy yourself that requests to get redirected to and likewise requests to redirect to

    5. set to force http:// schema. Satisfy yourself that redirects behave as expected.

    6. set as primary domain. Satisfy yourself that domain redirects behave as expected. Observe that it is impossible to force SSL.

    7. add bare-style to mapping dash and set it to force SSL. Observe that the forced schema for the old-style mapping also changes, and that now requests from the front-end are forced to SSL.

    8. force non-SSL on the bare-style domain. Observe that the front-end now redirects to non-SSL and that (after reloading the dash) both bare and old-style domains in the mapping dash show forced http://.

  • brightfire

    We're experiencing the exact same behavior that David King outlined above. Basically, I can't force SSL on any site with the "www" subdomain. Any other subdomain works perfectly.

    I suspected that it may be a filter but determined the problem is in the force_ssl_on_mapped_domain() method in the class Domainmap_Utils. Line 235 has the following code:

    $domain = str_replace("www.", "", $domain );

    I'm not sure the intent of this line but it only targets domains with "www" as the subdomain which allows any other subdomain to bypass this str_replace(). Commenting it out solves the issue for me. This allows me to switch the scheme on the Domain Mapping admin page and it correctly redirects to the selected scheme.

    Can a developer please take a look at this and verify if this line is needed?


  • Luís

    Hi David King and brightfire ,

    Hope you're doing well today!

    After further investigation, when we select the HTTPS protocol with "www" as a prefixed url in a mapped domain, it actually revertes it to HTTP. This issue was already reported and our developer is working to fix it asap.

    Either myself or the developer will reply back here once we have pushed a fix out.

    brightfire , regarding to your question, I already pinged the developer to get his valuable feedback.

    Cheers, Luís

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.