Support » Networking WordPress » Domain Mapping

  • Root Problem: When I am logged in as superadmin, I cannot reach the dashboard of any mapped domain site.

    When I click on My Sites >> Unmapped Site >> Dashboard, I get to the appropriate Dashboard. This works as expected.

    However, when I click on My Sites >> Mapped Site >> Dashboard, I am asked for a login, even tho I am superadmin.

    If I skirt around this and enter the default URL with the site slug, it does not work. I end up at the primary site’s dashboard.

    I have read that this login redirect problem is a cookies issue, but I have had no luck with those solutions. And it does not explain why the URL for the mapped site dashboard is taking me to the primary/default site’s dashboard.

    Here are the details of how I got here…

    I have a multisite that has been in place for about 3 years.
    – it has several subsites
    – it uses subdirectories (subdomains set to false)
    – two of the sites have a mapped domain
    – it was originally set up with the WPMUDEV Domain Mapping plugin (which is now legacy b/c of domain mapping since wp 4.5)
    – I had auto updates disabled and was on version 5.1(?) when this happened (now on 5.2.2)

    About 10 days ago, out of the blue, “something” failed miserably. I did not do any updates or make any changes to the site. There were other symptoms at first, which in retrospect seem somewhat coincidental but they may have been causative. When the smoke cleared and I got my site working again, there was an admin toolbar problem (not the issue I am reporting today) and a problem with links to the mapped domain dashboards.

    I have since learned that other people who were using the MU Domain Mapping plugin experienced very similar issues around the same time.

    I set up a test site. It was created as an exact copy of the original, so the database is the same, but

    – all plugins have been moved to a temp folder
    – all mu-plugins have been moved to a temp folder
    – all drop-in plugins have been moved to a temp folder

    Still, with all these things eliminated, the admin-side mapping is not working correctly, as described above.

    The default WP domain mapping instructions simply say to put the mapped domain into the URL field on the Sites >> [Site] >> Edit first screen. This changes siteurl and homeurl to the same value.

    It also makes the Dashboard URL in the My Sites menu mapped domain also: e.g., However, when I use that link, I am faced with a login screen. My superadmin login does not work.

    But by using the default domain, with the site slug in it ( I do get to the Dashboard without a login. However, it is not the Dashboard of the mapped domain site /nroc/. It is the Dashboard of the primary/default network site (ID 1)

    I can work around this by manually setting the siteurl to, so that the links in the My Sites menu are usable. But really all this does is save me the trouble of typing the URL manually. It doesn’t really solve anything.

    I tested further by creating a new subsite, and mapped my extra domain to that site. The same thing happens. I can now get to the admin dashboard for the site I want to get to! But the domain is not mapped to it, so on the front end, the site is broken.

    I have included what I think are the relevant constants from wp-config below. I have fiddled with various constants to fix this. None of them have had an effect. You can see what I have tried, and what is currently commented in and out.

    /* Multisite */
    define( 'WP_ALLOW_MULTISITE', true );
    define('MULTISITE', true);
    define('SUBDOMAIN_INSTALL', false);
    define('DOMAIN_CURRENT_SITE', '');
    define('PATH_CURRENT_SITE', '/');
    define('SITE_ID_CURRENT_SITE', 1);
    define('BLOG_ID_CURRENT_SITE', 1);
    // define('COOKIE_DOMAIN', '');
    // define('COOKIE_DOMAIN', $_SERVER['HTTP_HOST']);
    // define('DOMAINMAPPING_ALLOWMULTI', true);
    // define('FORCE_SSL_ADMIN', true);
    /* these were recommended for fixing a redirect loop, but they are not helping now */
    // define('ADMIN_COOKIE_PATH', '/');
    // define('COOKIE_DOMAIN', '');
    // define('COOKIEPATH', '');
    // define('SITECOOKIEPATH', '');
    /* baseline home and siteurl */
    define( 'WP_HOME', '' );
    define( 'WP_SITEURL', '' );

    I think there must be some core configuration error here, maybe something wrong in the database. I actually have a vague memory of this issue occurring during the setup of our site, but I apparently “fixed” it. This all makes me suspect that the issue was there all along, but masked by something — perhaps the domain mapping plugin.

    To that end, I tried reinstating the plugin. It did not fix the issue. But ultimately I want to fix whatever is at the root of this, not mask it with a plugin again.

    I will be grateful for any assistance! Thank you.

    The page I need help with: [log in to see the link]

Viewing 15 replies - 1 through 15 (of 15 total)

    Can I get a certificate for multiple domain names (SAN certificates or UCC certificates)?
    Yes, the same certificate can contain several different names using the Subject Alternative Name (SAN) mechanism.

    Does Let’s Encrypt issue wildcard certificates?
    Yes. Wildcard issuance must be done via ACMEv2 using the DNS-01 challenge. See this post for more technical information.

    Wildcard for not for
    UCC with SAN only allowed fully qualified domain names (FQDN)

    please can you show your htaccess?
    If you install a multisite based on subdirectories (percoso) as the host is the same for the primary site and secondary site you should not have cookie problems.
    Use only the unknown mode of chrome.

    I access very well without having to log in as superuser again from the root or any other folder (main site and secondary site with the same domain name)
    Edit: I tried to see the headers (Set-Cookie create cookie) of /nroc/wp-login.php many are enabled for the root directory and this behavior is not the wordpress default.
    The plugin may have created the mapping badly.

    A couple things come to mind…

    The first is you were running the WPMUDev site mapper plugin so your sunrise.php file might be interfering with WordPress’ rewrite abilities. You might try renaming sunrise to something else like sunrise.phpbak to get that out of the picture. And of course, the mapper plugin should be disabled already.

    The second is the best advice would be to run the multisite from webroot instead of a subdirectory. It appears you are running from a subdirectory which complicates things. Do make sure the addon domains are pointing at the proper subdirectory off the webroot directory for the install. In your case though I’m thinking you have already done that but double check if you can’t say for sure.

    This next step might be too much and might break your site worse but you might look at this article and get your multisite to run from webroot without moving the install. Do a good backup of all files and the database first so you can recover if necessary. If you already have something running from web root then you can’t do this!

    You might find some of this tutorial helpful… maybe not.

    And this whole thread and subsequent answer from me might help… might confuse you more. Hopefully, it will inspire you with more ideas and possibilities.

    Let us know how it goes.

    @autotutorial, was your reply meant for here or another post?

    Yes my answer was designed for this post the dev domain does not exist in the ssl certificate and other useful information.

    Thanks for all the help — and fast! Ok, here are some answers and questions before I go test some of the suggestions.


    I already tried backing out/deleting/renaming everything related to the mapping plugin and sunrise, but it didn’t fix the problem.

    run the multisite from webroot instead of a subdirectory

    I’m curious what you see that causes you to think that. It is running in webroot (which for me is /var/www/html) but it could be a clue if you’re seeing something suspicious….or if I’m doing something I don’t know I’m doing! (fwiw I have wp-config one level up, for security, in /var/www)

    Do make sure the addon domains are pointing at the proper subdirectory off the webroot directory for the install.

    Does that still apply if I’ve already got the mu running in webroot? If so, please elaborate because I’m not sure where I should point the domain.

    I tried to see the headers (Set-Cookie create cookie) of /nroc/wp-login.php many are enabled for the root directory and this behavior is not the wordpress default.
    The plugin may have created the mapping badly.

    This MIGHT be due to the fact that we don’t normally use the standard wp-login for anyone, for security reasons. We redirect in .htaccess to a page called /log-in

    So it IS possible that this is messing with the login for me as superadmin. But it works fine on the live site under normal conditions (or it did, until 10 days ago). I am really less concerned with the login issue (I included it just in case they are related) and more concerned with the mapping of the domain in admin. The fact that I cannot reach the dashboard of a mapped domain site is an untenable situation.

    If you install a multisite based on subdirectories (percoso) as the host is the same for the primary site and secondary site you should not have cookie problems.

    That’s what I thought, too. It has been fine for years, then suddenly – boom!

    Use only the unknown mode of chrome.

    I have tested with “incognito mode” in Chrome, but the login problem persists. Only since the crash of -10 days. It was fine before that.

    Wildcard for not for
    UCC with SAN only allowed fully qualified domain names (FQDN)

    I am not sure how this will help or how it’s related, but I may not be understanding what you mean.

    the dev domain does not exist in the ssl certificate

    This only interferes with security, yes? That is…google screams about it not being secure (it’s only dev, so I don’t care), but that should not be related to the problem I am having? That has been my assumption so far.

    please can you show your htaccess?

    Yes, see below.

    Thanks for the advice. I will review the rest of the tips provided and see what I can learn or be inspired by!

    This is my CURRENT .htaccess file (or at least, the relevant parts. There are also a lot of modrewrites that are not really part of this issue).

    # BEGIN HTTPS Redirection Plugin
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{SERVER_PORT} !^443$
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
    # END HTTPS Redirection Plugin
    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteRule ^index\.php$ - [L]
    # add a trailing slash to /wp-admin
    RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]
    RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
    RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
    RewriteRule . index.php [L]
    # END WordPress

    I have REMOVED the following, which I thought might be causing trouble. These sections have been in use on the live site for ages, and whenever we copy the server to use as a dev site, I do not touch these and they do not interfere. But also, normally when I use a copy of the site for testing, I am bypassing domain mapping, so it doesn’t matter.

    But removing these did not fix the issues I was having.

    # Stop spam attack logins and comments
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} POST
    RewriteCond %{REQUEST_URI} .*/(wp-comments-post|wp-login)\.php.* [OR]
    RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$ [OR]
    RewriteCond %{REQUEST_URI} ^(.*)?log-in(.*)$
    RewriteCond %{HTTP_REFERER} !.** [OR]
    RewriteCond %{HTTP_USER_AGENT} ^$
    #RewriteRule (.*) http://%{REMOTE_ADDR}/$1 [R=301,L]
    RewriteRule ^(.*)$ - [F]
    #RewriteRule ^(.*)$ [R=301,L]
    # Wordfence WAF
    <IfModule mod_php7.c>
    php_value auto_prepend_file '/var/www/html/wordfence-waf.php'
    <Files ".user.ini">
    <IfModule mod_authz_core.c>
    Require all denied
    <IfModule !mod_authz_core.c>
    Order deny,allow
    Deny from all
    # END Wordfence WAF
    • This reply was modified 11 months, 1 week ago by kalico.
    • This reply was modified 11 months, 1 week ago by kalico.

    Ok, I read up on all the suggestions and they all seem to relate to either the fact that I do not have https set up, or the idea that my entire mu is in a subdirectory rather than in the webroot. Neither of those is the problem here, unless I’m totally missing the point. Any other ideas? Or correct my understanding?

    • This reply was modified 11 months, 1 week ago by kalico.

    I read your problem more carefully if has been mapped to you will have problems with cookies.
    The domain mapping does not indicate how to proceed
    First check what you saved in the database, this link suggests multisite url modification but it is also fine to check the right paths. Do not change anything. Comment on your define in wp-config.php.

    Now all cookies refer to this domain.

    /* these were recommended for fixing a redirect loop, but they are not helping now */
    define('COOKIE_DOMAIN', '');
    define('ADMIN_COOKIE_PATH', '');
    define('COOKIE_DOMAIN', '');
    define('COOKIEPATH', '');
    define('SITECOOKIEPATH', '');

    your primary site is in the nroc folder when it is mapped in the root folder, unfortunately in the case of a different domain through code it is difficult to replicate the exact location of the cookie.
    I’m not sure if a primary site can be mapped to anything else if it’s possible to change “only” your wp-config.php from old to new domain. (PATH_CURRENT_SITE and DOMAIN_CURRENT_SITE etc ..)

    Prove this

    define('DOMAIN_CURRENT_SITE', '');
    define('PATH_CURRENT_SITE', '/nroc/');

    Or maybe

    define('DOMAIN_CURRENT_SITE', '');
    define('PATH_CURRENT_SITE', '/');

    Thanks @autotutorial

    I think there is some confusion here, because I am not trying to map a domain to /wp-admin/ or map a domain to the primary site or vice versa. I’m just trying to do very STANDARD domain mapping to one of the sub-sites in my network. It should be super simple (and it DOES work on the frontend) but something is affecting how the wp-admin links work. I posted a video below, hopefully that will help.

    I did as you suggested and reviewed every one of those in the database. I have not made any changes. You can see screenshots here and leave comments by selecting text or screenshots, if you wish:

    I also made a screencast showing what I am trying to describe, because I think that the situation is too confusing for words alone.

    Important: the primary domain is ( is the mapped domain) I have not mapped anything to /wp-admin/

    Observations about the database entries:
    – some of them are http, some are https – could that be a problem?
    – in wp_blogs, both the primary and mapped domain have the path / but the others all have /xxxxx as the path – that might be how it should be, not sure.

    I have followed all instructions at

    There is nothing mapped to “folders” in my site. I added a screenshot to the doc above (bitly link) showing what my folder structure looks like.

    Thanks for all the efforts to help me out!!! 🙂

    • This reply was modified 11 months, 1 week ago by kalico.

    Kalico, Did you ever resolve this issue? I am having a similar problem.

    No, not really. I pretty much came to the conclusion that wp domain mapping requires the superadmin to log in on every subsite by default.

    I have been doing extensive testing in a completely fresh install and I cannot get it to behave any differently, so I believe that to be the default behavior — it expects you to log in at least once to set a cookie, then you should be OK after that.

    I don’t like that behavior, because it messes with something we have done for security: we disabled access to wp-login (which gets slammed with malicious attacks) and created a different login page. So for my production configuration, this doesn’t work at all. I literally cannot log in as the superadmin to any subsite in the network if it has a mapped domain.

    The only “fix” I have found (in my sandbox site) is to use a legacy plugin from WPMUDEV which offers a cross-domain autologin feature.

    This is actually the plugin I was successfully using for several years on production, but in June we had some really massive and sudden failures which — after extensive plugin conflict testing — I could not attribute to anything but the domain mapping plugin. So I disabled it, hoping to just use default domain mapping. But for the reasons stated above, it does not work for us.

    As a workaround on my production site, I have set up an additional subsite with the slug /maintenance and marked it to discourage search engines. I made a home page there that says we are doing maintenance. When we need to post something on the mapped domain site, I point the mapped domain at the maintenance site, and put the real site back to its default site URL in Network >> Sites >> Settings (our multisite is configured with subdirectory URLs, so I am changing it to then we can temporarily access the dashboard via When we are done, I change the domain mapping back to how it should be.

    This is “easy” in the moment, but overall it’s a massive pain in the @$$ and not sustainable.

    My next step (tonight, actually) will be to test the domain mapping plugin again on my production site after hours when traffic is slow. I need to find out if I can enable it without bringing the site to its knees again. I’ll post back when I learn more, and if you have any specific questions I didn’t answer please feel free to ask!

    Any update on this? I’m having very similar issues where I can login to my main domain with my superadmin account, but not the mapped domains.

    I never had any luck getting around the default behavior after the domain mapping plugin failed. I still have the situation where all admins need to login at the mapped site’s admin page, which sets off our security trap and they are stuck. My workaround was to use the WPMUDEV “Cloner” plugin (which is legacy, but available as open source – … and of course they may be other options out there) to clone the one site that uses a mapped domain. Now, when anyone needs to edit the mapped domain site, I temporarily point the domain at the clone. This allows us to access the otherwise-blocked site via and every so often, I re-clone the site to keep it up to date.

    It’s a hassle. And not a good solution at all if you have multiple sites in your network with mapped domains that you need to edit on a regular basis. But for me, it happens to work well enough…for now.

    @kalico you can
    define('COOKIE_DOMAIN', '');
    one of them must work with the default behavior (without other plugins)

Viewing 15 replies - 1 through 15 (of 15 total)
  • The topic ‘Domain Mapping’ is closed to new replies.