Plugins working on subdomain, but not mapped subdomain

Posted November 21, 2015 6.7k views

Hey all. I have a WordPress site named I have a subdomain, via WordPress Multisite, called I have mapped to

When I access the dashboard as well as visit the public-facing site for, all plugins and functionalities work as expected. However, when I do the same for, they don’t.

In the dashboard for, the Visual Editor is “whited out.” When I visit the public-facing site, my syntax highlighter plugin (which works on doesn’t apply.

  • For WP Multisite, should I be using the dashboard for the subdomain, or the domain to which the subdomain is mapped?
  • Ideas on how to resolve this problem? My instinct is that it is not a permissions issue.

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
3 answers


Please post your configuration , the steps taken to setup WordPress MS and any DNS changes you’ve made. That’ll help to better resolve the problem :-).


–> Config: This is probably the relevant stuff.

// ========================
// Custom Content Directory
// ========================
define( 'WP_CONTENT_DIR', dirname( __FILE__ ) . '/content' );
define( 'WP_CONTENT_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/content' );
define( 'ADMIN_COOKIE_PATH', '' );

/* Multisite */
define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define( 'DOMAIN_CURRENT_SITE', '' );
define('SUBDOMAIN_INSTALL', true);
define( 'SUNRISE', 'on' );

–> Steps taken to setup WordPress MS: I’m unfortunately not exactly sure. A friend did it for me. To the very best of my knowledge, there was no plugin used. I have a subdomain on the site - - which maps to This is enabled/visible in the Super Admin control panel under Domain Mapping.

–> DNS: I have 3 Digital Ocean nameservers listed on my domain registrar for both and I’ve added A-records + the same 3 nameservers for each of:,,,, and

edited by kamaln7
  • I’m not sure if this will help, but try deleting the ADMIN_COOKIE_PATH line.

    Also, do you see any errors in your browser’s console?

  • @cavaunpeu

    Would you mind posting the rest of your wp-config.php (comment out the database information please)? I’d like to see exactly where those lines are as the line:

    define( 'SUNRISE', 'on' );

    … indicates that a plugin is being used (for sub-domain mapping) as that is not a standard definition for WordPress Multi-Site (and where that line goes does matter).

    Also, please post your .htaccess file.

    • With great pleasure. wp-config:

      // ===================================================
      // Load database info and local development parameters
      // ===================================================
      if ( fileexists( dirname( _FILE__ ) . ’/local-config.php’ ) ) {
      define( ‘WPLOCALDEV’, true );
      include( dirname( FILE ) . ’/local-config.php’ );
      } else {
      define( 'WPLOCALDEV’, false );
      define( 'DBNAME’, 'example’ );
      define( 'DB
      USER’, 'will’ );
      define( 'DBPASSWORD’, 'XXXX’ );
      define( 'DB
      HOST’, 'localhost’ ); // Probably 'localhost’

      // ========================
      // Custom Content Directory
      // ========================
      define( 'WPCONTENTDIR’, dirname( FILE ) . ’/content’ );
      define( 'WPCONTENTURL’, 'http://’ . $SERVER['HTTPHOST’] . ’/content’ );

      /* Multisite */
      define('WPALLOWMULTISITE’, true);
      define('MULTISITE’, true);
      define( 'DOMAINCURRENTSITE’, '’ );
      define('SUBDOMAIN_INSTALL’, true);
      define( 'SUNRISE’, 'on’ );

      // ================================================
      // You almost certainly do not want to change these
      // ================================================
      define( 'DBCHARSET’, 'utf8’ );
      define( 'DB
      COLLATE’, “ );

      // ==============================================================
      // Salts, for security
      // Grab these from:
      // ==============================================================
      define('AUTHKEY’, 'XXXX’);
      AUTHKEY’, 'XXXX’);
      INKEY’, 'XXXX’);
      KEY’, 'XXXX’);
      define('AUTHSALT’, 'XXXX’);
      AUTHSALT’, 'XXXX’);
      INSALT’, 'XXXX’);
      SALT’, 'XXXX’);
      // ==============================================================
      // Table prefix
      // Change this if you have multiple installs in the same database
      // ==============================================================
      $tableprefix = 'wrd’;

      // ================================
      // Language
      // Leave blank for American English
      // ================================
      define( 'WPLANG’, ” );

      // ===========
      // Hide errors
      // ===========
      iniset( 'displayerrors’, 0 );
      define( 'WPDEBUGDISPLAY’, false );

      // =================================================================
      // Debug mode
      // Debugging? Enable these. Can also enable them in local-config.php
      // =================================================================
      // define( 'SAVEQUERIES’, true );
      // define( 'WP_DEBUG’, true );

      // ======================================
      // Load a Memcached config if we have one
      // ======================================
      if ( fileexists( dirname( _FILE__ ) . ’/memcached.php’ ) )
      $memcachedservers = include( dirname( _FILE__ ) . ’/memcached.php’ );

      // ===========================================================================================
      // This can be used to programatically set the stage when deploying (e.g. production, staging)
      // ===========================================================================================
      define( 'WPSTAGE’, ’%%WPSTAGE%%’ );
      define( 'STAGINGDOMAIN’, ’%%WPSTAGING_DOMAIN%%’ ); // Does magic in WP Stack to handle staging domain rewriting

      // ===================
      // Bootstrap WordPress
      // ===================
      if ( !defined( 'ABSPATH’ ) )
      define( 'ABSPATH’, dirname( FILE ) . ’/wp/’ );
      require_once( ABSPATH . 'wp-settings.php’ );


      Fix www redirect

      RewriteCond %{HTTPHOST} ^$ [NC]
      RewriteRule ^(.*)$$1 [R=301,L]
      RewriteCond %{HTTP
      HOST} ^$ [NC]
      RewriteRule ^(.*)$$1 [R=301,L]

      BEGIN WordPress

      Options +FollowSymlinks
      RewriteEngine On
      RewriteBase /
      RewriteRule ^index.php$ - [L]

      add a trailing slash to /wp-admin

      RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

      RewriteCond %{REQUESTFILENAME} -f [OR]
      RewriteCond %{REQUEST
      FILENAME} -d
      RewriteRule ^ - [L]
      RewriteRule ^(wp-(content|admin|includes).) wp/$1 [L]
      RewriteRule ^(.
      .php)$ wp/$1 [L]
      RewriteRule . index.php [L]
      Require all granted

      END WordPress

      Thanks, @jtittle.


The following information will only apply if you’re currently using the WordPress MU Domain Mapping Plugin (link). You can verify this by logging in using your admin account and then by visiting:

My Sites » Network Admin » Plugins

If you see a plugin named WordPress MU Domain Mapping, we’re good to go :-).

First off, there’s quite a few custom modifications to your wp-config.php file. To ensure that those modifications are not causing the issue (or any other issues), please make a backup copy of your current wp-config.php file and store it in a safe place (Dropbox, Box, Google Drive, etc). Leave this copy alone and download another to edit.

Now wipe the one you’ll be editing clean (blank), copy and paste the code from the following PasteBin in to it, and save. You’ll need to fill out some of the values with your own. You can use your backup copy to reference these values. Specifically, you’ll need to add your keys and salts back in place of the blank ones and replace all instances of YOUR_* with your actual values.


The above is pre-configured for WordPress Networking and the WordPress MU Domain Mapping plugin already, so no further modification should be needed as everything that needs to be in there, is.

Now, like you did for your wp-config.php file, download a copy of your .htaccess file and store this copy in the same place as your backup wp-config.php. Now download another copy to edit, wipe it clean and replace it with the code from the following PasteBin and save it.


Now, we need to make sure that you’ve configured the WordPress MU Domain Mapping plugin as it needs to be, so first thing we need to do is head over to:

My Sites » Network Admin » Settings » Domain Mapping

You’ll need to add your Droplet’s Public IP Address to the input box tagged Server IP Address and click save so that the IP is stored to the database.


Now you’ll want to navigate to:

My Sites » Network Admin » Settings » Domains

And make make sure that the domain is mapped to the correct Site ID. Ideally, you should only enter domain.ext for the domain (i.e. without the http:// or www. prefix).

If you’re not sure what the Site ID is, you can obtain this by navigating to:

My Sites » Network Admin » Sites

… now hover the URI that is associated with the site. The link contains id=NUM where NUM is the Site ID, which is what you’ll use to map the domain to a site ID.

With these changes in place, the next item to check would be to look at your DNS Zone File. You’ll need what is commonly referred to as a “WildCard” A entry, which looks something like:

A            *            DROPLET_PUBLIC_IP

If that entry is missing, you’ll need to add it.

Next, you need to make sure that the domain that is being mapped points to your Droplet’s Public IP. This requires that an A entry be setup for the domain which will look like:

A            @            DROPLET_PUBLIC_IP

Once all changes through ./wp-admin/ have been made, upload your newly modified wp-config.php and .htaccess files, refresh the page and log back in.

If neither of the above DNS entries are currently in place, it may take up to 24-48 hours for the DNS to fully resolve. In most cases (especially if you’re hosting your DNS with DigitalOcean), DNS will resolve almost immediately, though it depends on numerous factors, though all DNS should resolve in 24-48 hours unless there’s an issue elsewhere.

With these changes in place, you should have a working WordPress Multi-Site installation with Domain Mapping fully enabled and working.

  • @jtittle

    Thank you so, so much. Will give these changes a shot later and report back. Just to clarify, given my example domains, “domain that is being mapped” would be, yeah?

    • @cavaunpeu

      The reference to “domain that is being mapped” would mean a physical domain such as domain01.ext, domain02.ext and so forth :-).


      The screenshot above is of the domain setup area for the WordPress MU Domain Mapping plugin. In the Site ID input box, you’ll add the ID of sub.yourdomain.ext and then in the Domain input box, this is where you’ll add the domain that you want to associate with sub.yourdomain.ext. This is the actual “mapping” (from within the WordPress Admin CP).

      You’ll then modify the existing or add a new A entry for domain01.ext (the domain that you choose to map to sub.yourdomain.ext) that points to the IP Address that you set in the Server IP Address input box (

      Essentially, all domains that you wish to map to a sub-domain created by your WordPress MS installation need to point (by creating or modifying the existing A entry for each physical domain) to the server IP set in that screenshot.

      You create the actual “mapping” inside the WordPress Admin CP and then “map” the domain name associated with the sub-domain to the server IP :-) (either through DigitalOceans CP if you use them to manage your DNS, or your domain registrar).

      Does that make sense? If not, just let me know :-). Always happy to help!