Login form action remains http for unmapped domain on HTTPS only site

Hi there,

we have the following config:

– Subdomain Multisite

– HTTPS only for original and mapped domains

– FORCE_SSL_ADMIN is set to true in wp-config

Nginx rewrite rules to rewrite all HTTP requests to HTTPS.

On the main site (no Domain mapping) everything works fine. On sites with a mapped domain the login also works fine with the mapped domain.

On a subdomain (virgin site in the multisite) without domain mapping the login forms action remains on http thus no login is possible.

All the other ressources are correctly loaded via HTTPS. Certificate is obviously working fine.

Domain Mapping Plugin config is set to:

– Use mapped domain everywhere

– Force https for everything

I enabled support access for the installation and left the URL to the login there in the note field. So take a look yourself.

Eager to hear from you!


  • Nastia
    • Support Rock Star

    Hello Jan ,

    I see it now, thank you for the clarification. It is a Mixed Content error, means that the SSL is not forced on the form page.

    The Domain Mapping plugin forcing HTTPS/HTTP only for the original domain, if the site’s network structure is domain based it will not work for the subdomains.

    Please try a different way to force HTTPS on the subdomain, use this plugin to fix the Mix Content error:


    Let me know how it goes!

    Kind regards,


  • Jan
    • Design Lord, Child of Thor

    Hi Nastia,

    Can you please clarify the difference behavior between the “original Domain” and the “original Subdomain”?

    Because technically,, a Subdomain is a Domain too.

    Before throwing plugins in to solve this, I would like to understand the exact issue first.

    I will nevertheless test the suggested Plugin, after I took a look at its sources and what it does.



  • Nastia
    • Support Rock Star

    Hello Jan,

    Technically a sub.domain.com it is a different domain name from domain.com. Even if it is a subsite on a multisite WordPress, sometimes WordPress can’t tell automatically if you are forcing SSL. Most often this is because of a website configuration.

    If you had a multisite with subfolder network, you will not have an issue with forcing HTTPS on domain.com/sub1, domain.com/sub2., because subsites are located “under” the same domain name.

    Using a plugin to force HTTPS, helps WordPress to detect mixed content errors and solves these issues.

    Let me know if you have any further questions!



  • Jan
    • Design Lord, Child of Thor

    I installed the Plugin you suggested. No change. The login still posts to http.

    Edit: And just to be clear after I digged deeper into the Plugin: I will not use the Plugin in the “Capture” mode. This will most likely solve the issue, but the price is much to high ressourcewise and the issue itself is not fixed at all.



  • Nastia
    • Support Rock Star

    Hello Jan

    I am sorry to here the plugin didn’t fixed the issue. Please try another method, by forcing HTTPS through the .htaccess.

    Please locate the .htaccess file within your site’s directory , edit it and add the following rules:

    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

    If the above will not work, please replace the FORCE_SSL_ADMIN with the line below inside the wp-config.php file:

    define('FORCE_SSL_LOGIN', true);

    Let me know how it works for you!

    Kind regards,


  • Nastia
    • Support Rock Star

    Hello Jan , I hope all is well!

    My apologies for the delay!

    I tested again the Domain Mapping plugin on my site and can’t replicate the same. The action form is forcing HTTPS with and without the Domain Mapping activated.

    In your original thread, you’ve mentioned that FORCE_SSL_ADMIN is set. Would you please replace it with

    define('FORCE_SSL_LOGIN', true);

    And see if this fix the issue? Please clear the site’s cache before testing.

    Also would you please run a check for a conflict with another plugin? Deactivate all the other plugins, switch to a deafult WordPress theme. Try to login again into a subsite. I everything is well, activate one plugin at the time till you replicate this issue again.

    In case this issue still persists with only the Domain Mapping plugin activated, please send to us your credentials so we can have a closer look.

    You can send credentials by using our secure contact form


    Subject: “Attn: Nastia”

    – WordPress admin username

    – WordPress admin password

    – Login URL

    – FTP credentials (host/username/password)

    – Link back to this thread for reference

    – Any other relevant URLs

    Let me know how it goes!

    Kind regards,


  • Jan
    • Design Lord, Child of Thor

    Hi there!

    I finally found the error… After the last update also the ajaxurls in the wp-admin started to go wrong (http instead of https, rendering all ajax calls useless) so we were forced to finally fix his by all means.

    If you set “Administration mapping” to “mapped domain” your custom “admin_url” function is hooked into the “admin_url” filter. Mapping.php L#1373.

    Independent of the input URL you (try to) rewrite the URL and the protocol. But if there is no mapped domain you end up with “use_ssl()” returning false and thus always removing HTTPS.

    Two solutions / fixes:

    1. If there is no domain mapping for the current site, do not change the url in admin_url or anywhere else. Just return the URL that was given to you from the original WP admin_url or other filters. Should be fixed asap for the admin_url filter.

    2. If a Domain is HTTPS just leave it this way (unless “Force HTTP” is enabled). This should reduce the risk of falsy removing HTTPS drastically.

    Hotfix / Workaround: Set Administration Mapping to “domain entered by the user”.

    Took me a long time to finally find this, but I hope this helps to improve the DM plugin once more.

    Best regards,


  • Dimitris
    • Support Star

    Really appreciate the feedback here Jan :slight_smile:

    I’ve already shared this with lead developer of Domain Mapping.

    I am also unable to replicate this in my testing site, but as there’re some other recent, already reported, issues with mixed-content errors, hopefully these will be resolved in next plugin update.

    Warm regards,


  • Nahid
    • Tech Support

    Hey blue !

    Hope you are having a great day!

    Thank you for your query. I can see that you have already responded in the mentioned thread with your discovery and it is under investigation by the respective Support team. They’ll be back with updates as soon as they’re done with their investigation.

    For further cases alike this one, please note that we are really keen on keeping an issue specific to the respective thread only as it really depends on a lot of other factors (e.g. conflicts with other plugins, server/site configurations) even though it is caused by the same plugin. We really appreciate your consideration regarding this. Thanks!

    Kind regards,


  • wp.network
    • The Bug Hunter

    I force all login/admin to original network domain as a critical feature at my subdomain networks (eg. security, availability, etc.) and I have seen issues with the login page generally, including on occasion the form action.

    Even when things are working, often if I look closely during a hard page refresh at login screen, I can see it load at first with what I know to be mixed content issues from wp-load for styles and such – then it usually kicks back to https:// within a fraction of a second or so…

    (one exception that I know of, and can reliably reproduce, where login is essentially broken bcs it fails to kick back to https:// is kinda edge-case so I’ll save it for new ticket)

    It seems likely that the issue outlined here could also be causing/effecting the behavior I’ve been seeing when using ‘original network address’.

    fwiw, in my wp-config

    define('FORCE_SSL_ADMIN', true);
    define('WP_CONTENT_URL', 'https://' . $_SERVER['HTTP_HOST'] . '/app' );
    define('WP_PLUGIN_URL', 'https://' . $_SERVER['HTTP_HOST'] . '/app/plugins' );
    define('WPMU_PLUGIN_URL', 'https://' . $_SERVER['HTTP_HOST'] . '/app/mu-plugins' );

    in my .htaccess

    ### BEGIN HTTPS Catch-All
    <IfModule rewrite_module>
    #RewriteCond %{HTTP:X-Forwarded-Proto} https [NC]
    #RewriteRule ^ -
    RewriteCond %{SERVER_PORT} 80
    RewriteCond %{THE_REQUEST} ^[A-Z]{3,9} /(?:.*) HTTP/ [NC]
    RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
    ### END HTTPS Catch-All

    and so that all SITEURL and HOME values in db have https:// scheme (also have tried just setting values manually),

    in an mu-plugin

    * Fixes SITEURL and HOME scheme
    * if server is properly configured, expected result always https scheme in SITEURL and HOME
    * @see https://www.lyquidity.com/devblog/?p=427
    // Basic security, prevents file from being loaded directly.
    defined( 'ABSPATH' ) or die( 'Cheatin’ uh?' );

    function max_fix_home_option($option)
    // If the option starts with 'http' strip it
    if (strpos($option, 'http') !== false)
    $pos = strpos($option, ':');
    $option = substr($option, $pos + 1);

    // Otherwise add 'http' or 'https' as appropriate
    $option = (empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === "off" ? "http:" : "https:") . $option;
    return $option;

    add_filter('option_home', 'max_fix_home_option');
    add_filter('option_siteurl', 'max_fix_home_option');

    I have seen the various issues with http:// requests to wp-load and such at wp-login regardless of efforts to enforce https:// (at all levels, from plugin config to WP to server) on fresh installs and despite above configs. I have also used WebAware’s fixer plugin on occasion and it is very effective as a temporary fix for various issues if needed – obviously though, its not an acceptable ongoing solution.

    Especially if SITEURL and HOME use ‘https://’ as scheme (since if this is true, it is only bcs the admin took specific action to set the scheme to ‘https://’:wink: then it seems DM really should respect that and just leave it be.

    I’ll open a thread for my specific issue when I have some time to document it more carefully with nice screenshots and replication steps… again, just wanted to add this here in for dev bcs I really do think that the issues are likely very related in the code.

    Cheers, Max

  • Dimitris
    • Support Star

    Really appreciate the feedback on this wp.network :slight_smile:

    A release candidate of Domain Mapping plugin is already in the queue of our QA team and will be published as soon as it passes their tests and resolves the reported issues around mixed-content errors.

    Please keep an eye in your WPMUDEV Dashboard for any plugin update, backup your website and proceed with it, or set Automate do that for you!

    Warm regards,


  • 360ninja
    • New Recruit

    Can confirm the same still happening even with the newest Domain Mapping version, which right now is:

    What is the manual solution to this, that we ourselves can quickly do, until the plugin is updated?

    None of the above solutions helped.

  • 360ninja
    • New Recruit

    Sharing a simple solution that fixed it here on a non mapped subdomain using https.

    1. Go to: YOURDOMAIN/wp-admin/tools.php?page=domainmapping

    2. Under: “Excluded pages”, check: “Force SSL for all pages”.

    3. In the field: “Add page urls below to force https”, add url:s to all other pages on your website.

  • Nahid
    • Tech Support

    Hey 360ninja !

    Hope you are having a great day!

    I’m sorry to hear about the issue that you encountered. Could you please try using the current beta version of the Domain Mapping plugin which I have attached to this response and see if that fixes the issue? You can go through the following steps to replace the existing plugin folder with the uploaded beta version:

    1. Download and uncompress the uploaded domain-mapping- file.

    2. Log into your site’s FTP or cPanel’s File Manager and navigate to the {WordPress Installation Directory}/wp-content/plugins folder.

    3. Replace the existing ‘domain-mapping‘ folder in that directory with the uncompressed ‘domain-mapping‘ folder.

    Please note that this is still in testing phase so it would be best to install it on staging site and test there, or if you go for a live site right away make sure that you have full backup ready so you can restore easily in case that anything goes wrong.

    We appreciate you testing it out. If you encounter any issues regarding it or it doesn’t solve the issue, please consider reaching us out by starting a Live Chat session or creating a new support thread.

    Hope this helps. Let us know if you need any further assistance regarding this. Thanks!

    Kind regards,


  • Ben
    • The Reaper

    fyi: issue not fixed all the way…just a heads up.

    1.networkblog in https

    2. add two domains to your sub-blog

    3. choose a primary domain

    4. Front end redirect should be: Disabled and entered domain should be used (VERY important setting because with other options the bug doesn’t exist, I repeat this setting must be set in domain mapping for the bug to show)

    5. Find a page that is https://networkname/subblog/somepage that is requesting the url wp-admin/admin-ajax.php (ie divi visual builder)

    You will see there is a mixed content problem because admin-ajax.php is being requested via http url, when it should be using http

  • Nastia
    • Support Rock Star

    Hello Ben

    I trust you’re doing well!

    I’ve tested the set-up you’be described above on my end and could not reproduce it. We would like to have more information about Multisite and Domain Mapping setup so we could reproduce it. Would you please open a live chat with us here or open a new support thread in our forums? This way, the author will not be getting email notifications each time when there is a new post in the thread since the original issue is resolved.

    Please also grant access from WPMU DEV > Support to your site so we could see it up close.

    Please advise,

    Kind regards,


  • Leonidas
    • Developer

    Hello there Jan and wp.network ,

    sincere apologies for the delay here, but this issue proved to be quite tricky. Since the latest release, we have noticed that most members that couldn’t force admin-ajax.php to load over https, are having their issues fixed, but there were some cases where the issue persisted. So, on your end, could you install the latest beta I’m attaching and see if your issues are/remain fixed?

    Backing up your installation and updating the Domain Mapping plugin to this latest beta should fix this issue and some additional ones, so you can update Domain Mapping and you can all let me know how that goes, in this very thread. I’m attaching the beta below:

    Best regards,


Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.