rfair404

This plugin makes it possible to have a menu that is controlled by the primary site but used throughout all other sites in the network.
<ul>
<li>When a navigation menu position has no menu assigned, the “fallback” defaults to pages. This plugin over-rides that so that instead it uses the nav menu from the “main site” (site ID 1)</li>
</ul>

Network Menu Fallback

Gives multisite administrators the ability to create menus that can be used throughout a network.

Automattic

Ron Rennick

Donncha O Caoimh (a11n)

This plugin allows users of a WordPress MU site or WordPress 3.0 network to map their blog/site to another domain.
It requires manual installation as one file must be copied to wp-content/. When upgrading the plugin, remember to update domain_mapping.php and sunrise.php. Full instructions are on the Installation page and are quite easy to follow. You should also read <a href="http://ottopress.com/2010/wordpress-3-0-multisite-domain-mapping-tutorial/" rel="nofollow ugc">this page</a> too.
Super administrators must configure the plugin in Super Admin->Domain Mapping. You must enter the IP or IP addresses (comma deliminated) of your server on this page. The addresses are purely for documentation purposes so the user knows what they are (so users can set up their DNS correctly). They do nothing special in the plugin, they’re only printed for the user to see.
You may also define a CNAME on this page. It will most likely be the domain name of your network. See below for some restrictions and warnings.
Your users should go to Tools->Domain Mapping where they can add or delete domains. One domain must be set as the primary domain for the blog. When mapping a domain, (like ‘example.com’) your users must create an A record in their DNS pointing at that IP address. They should use multiple A records if your server uses more than one IP address. 
If your user is mapping a hostname of a domain (sometimes called a “subdomain”) like www.example.com or blog.example.com it’s sufficient to create a CNAME record pointing at their blog url (NOT IP address).
The login page will almost always redirect back to the blog’s original domain for login to ensure the user is logged in on the original network as well as the domain mapped one. For security reasons remote login is disabled if you allow users to use their Dashboard on the mapped domain.
Super admins can now choose to either allow users to setup DNS ANAME records by supplying an IP (or list of IP addresses) or set a CNAME but not both (entering a CNAME for the end user voids the use of IP’s)
There is a lot of debate on the handling of DNS using CNAME and ANAME so both methods are available depending on your preference and setup.
Things to remember:
<ul>
<li>CNAME records that point to other CNAME records should be avoided (RFC 1034 section 5.2.2) so only tell your end users to use your chosen domain name as their CNAME DNS entry if your domain name is an ANAME to an IP address (or addresses)</li>
<li>Only use the CNAME method if your main domain is an ANAME of an IP address. This is very important. How do you know? Check your dns or ask your hosting company.</li>
<li>Giving your users the option to just use your chosen domain name and not an IP (or list of IP’s) to set as their CNAME will make administration of your WordPressMU blog platform or WordPress 3.0 network easier, an example of this would be purchasing/deploying a new server or indeed adding more servers to use in a round robin scenario. Your end users have no need to worry about IP address changes.</li>
<li>Finally, telling your end users to use an ANAME IP or CNAME domain name is up to you and how your systems are deployed.</li>
<li>Further Reading: http://www.faqs.org/rfcs/rfc2219.html</li>
<li>For localization: place translation files (ie. wordpress-mu-domain-mapping-xx_XX.mo) in the directory wp-content/plugins/wordpress-mu-domain-mapping/languages. You will probably have to create that directory yourself.</li>
</ul>
<h3>Action Hooks</h3>
You can now hook into certain parts of the domain_mapping mu-plugin to enable you to extend the features that are built in without the need to modify this plugin. To do this, just create a script within the mu-plugins dir that is called AFTER this plugin (eg, call it domain_mapping_extended.php).
<ul>
<li><code>dm_echo_updated_msg</code></li>
</ul>
This hook is for when you want to add extra messages for your end users when they update their settings, the current usage would be to remove the existing action and replace it with your own as shown within the example further down the page.
<ul>
<li><code>dm_handle_actions_init</code></li>
</ul>
Before we add our own handlers for our users wanting to update their mappings, we can use this action to maybe connect to your datacenter API ready for communication. An example would be to load an API class and connect before we send and recieve XML queries. Once again, see the example down the page. Your function can make use of the $domain variable.
<ul>
<li><code>dm_handle_actions_add</code></li>
</ul>
When an user adds a domain name to their mappings, this action can be used to perform other tasks on your server. An example would be to check the user has already set up the DNS records for the name to correctly point to your server. Your function can make use of the $domain variable.
<ul>
<li><code>dm_handle_actions_primary</code></li>
</ul>
This may or may not be commonly used in most cases but is there just in case. Your function can make use of the $domain variable.
<ul>
<li><code>dm_handle_actions_del</code></li>
</ul>
When an user deletes one of their domain mappings, this action can be used to reverse what dm_handle_actions_add has done. An example would be to remove the domain mapping from your server using your datacenter’s API. Your function can make use of the $domain variable.
<ul>
<li><code>dm_delete_blog_domain_mappings</code></li>
</ul>
If the blog is ever deleted and you make use of handle_actions, then this action will enable you to tidy up. An example would be when an user has set up multiple domain mappings and the blog is deleted, your function can remove any mess left behind. Your function can make use of the $domains array (numbered array of domains). NOTE, this will also be called if the user has no mappings, care should be taken in the case of an empty array.
<h4>EXAMPLE USAGE</h4>
<pre><code><?php // Filename: mu-plugins/domain_mapping_extended.php


// NOTE,
// This example will not 'just work' for anyone, it is to show basic
// usage of dm_echo_updated_msg, dm_handle_actions_init and
// dm_handle_actions_add


// We do not need translations but would really like a message when a
// users DNS entry is not ready

function dm_echo_extended_updated_msg() {
 switch( $_GET[ 'updated' ] ) {
 case "add":
 $msg = 'You have added a new domain name.';
 break;
 case "exists":
 $msg = 'That domain name already exists, please try again.';
 break;
 case "primary":
 $msg = 'New primary domain created - enjoy!';
 break;
 case "del":
 $msg = 'The domain name has been removed.';
 break;
 case "dnslookup":
 $msg = 'The domain is not pointing to ' .
 get_site_option( 'dm_cname' ) . ', please set up your DNS.';
 break;
 }
 echo "<div class='updated fade'>$msg</div>";
}
// REMOVE THE ORIGINAL MESSAGES
remove_action('dm_echo_updated_msg','dm_echo_default_updated_msg');
// REPLACE WITH OUR OWN
add_action('dm_echo_updated_msg','dm_echo_extended_updated_msg');


// Prepare to use our Datacenter API

function dm_extended_handle_actions_init($domain) {
 global $datacenter_api;
 // There is a good chance we will be accessing the datacentre API
 require_once(dirname(__FILE__) ."/classes/xmlAbstract.class.php");
 require_once(dirname(__FILE__) ."/classes/xmlParserClass.php");
 require_once(dirname(__FILE__) ."/classes/datacenterAPIClass.php");
 $datacenter_api = new datacenter_api('MY_API_KEY', 'API_TYPE');
}
$datacenter_api = null;
add_action('dm_handle_actions_init', 'dm_extended_handle_actions_init');


// Check the users DNS is ready to go (we are using the CNAME option)
// then add the mapping to the datacenter API

function dm_extended_handle_actions_add($domain) {
 global $datacenter_api;
 // Check the domain has the correct CNAME/ANAME record
 $dmip = gethostbyname(get_site_option( 'dm_cname' ));
 $urip = gethostbyname($domain);
 if ($dmip != $urip) {
 wp_redirect( '?page=domainmapping&updated=dnslookup' );
 exit;
 }
 $datacenter_api->add_mapping($domain);
}
add_action('dm_handle_actions_add', 'dm_extended_handle_actions_add');
?>
</code></pre>

WordPress MU Domain Mapping

Successfully installed and configured in my site. Thank you! :-)

Works well

This plugin saved me so much work. Works great.

Perfect

The official WordPress Codex states: "In WordPress 4.5+, domain mapping is a native feature." 

Unfortunately, this plugin is no longer maintained, even though it is still the best, safest and easiest way to ensure perfect redirection to to correct (sub) blog. 

The mentioned define('COOKIE_DOMAIN', $_SERVER['HTTP_HOST']); often results in wrong redirections to the main blog:
In WordPress Network Admin: http://www.mydomain.org/ will likely make typing mydomain.org redirect to the main blog: https://example.com/?signup=new

At the time of writing this review I am still very happily using WordPress MU Domain Mapping on WordPress MultiSite 5.7.1-alpha-50553, PHP 8.0.2. to ensure that my visitors end up on the correct blog (http, https, with and without www).

In wp-config.php: 
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

/* Prevent redirection to /?signup=new */
define('NOBLOGREDIRECT', 'https://www.main-domain.com');
define('SUNRISE', 'on');



The defined COOKIE_DOMAIN will be set by this plugin to the correct url of all your blogs.

Still the best solution!

Excellent, minimalistic plugin that still works 8 years after its last update.

Still works with WP 5.3 👍

Map any blog/site on a WordPressMU or WordPress 3.X network to an external domain.

Network Menu Fallback vs WordPress MU Domain Mapping