Domain Mapping plugin breaks Multi-domain sites

The latest version of Domain Mapping plugin (4.2.0.6) causes the following redirect error on sites using the Multi-domain plugin:

The webpage at https://clas-math.uncc.edu/math-placement/ has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer

Reverting to Domain Mapping plugin version 4.2.0.2 fixes the problem.

WordPress 4.0
Multi-Domain 1.3.4.3
iThemes Security 4.4.23

We run both the front and back end under SSL using rewrite rules:
RewriteCond %{HTTP_HOST} ^www\.(.*)
RewriteRule (.*) https://%1/$1 [R=301,L]

  • Rob

    This seems to be a problem across WP domain mapping plugins since the free version of the WP plugin is having the same problem. I purchased the plugin from WPMUDEV hoping to solve this problem and it only replicated it, but costing me 19$ in the process. 1) Is there any way for me to get a refund, because I feel ripped off right now 2) how do I install the older plugin? I do not have a zip of the older free domain mapping plugin from WP and I don't know how to install a previous version of your plugin. You can read all about this problem on the following wordpress support page for the free version of the plugin:

    https://wordpress.org/support/topic/new-sites-can-no-longer-be-mapped

  • Ash

    Hello @Rob

    Please note that, https://wordpress.org/plugins/wordpress-mu-domain-mapping/ is not our free version and we don't have any relation with that plugin.

    If you want to download previous version you can get here:
    4.2.0.5: https://premium.wpmudev.org/download/791539637_domain-mapping-4.2.0.5.zip
    4.2.0.4: https://premium.wpmudev.org/download/1354030377_domain-mapping-4.2.0.4.zip
    4.2.0.3: https://premium.wpmudev.org/download/34646519_domain-mapping-4.2.0.3.zip
    4.2.0.2: https://premium.wpmudev.org/download/591488568_domain-mapping-4.2.0.2.zip

    And about your issue, would you please create a new thread?

    About the refund, unfortunately we can't deal about billing question in the forum. Would you please use our contact form: https://premium.wpmudev.org/contact/ to contact our billing department. Select I have a billing question and post your message. They will help you there.

    Thank you for your understanding.

    Cheers
    Ash

  • clas-web

    Attached is a copy of our .htaccess file and the server logs for one of the domains used by the Multi-Domain plugin whose sites are broken after updating to the latest version of the Domain Mapping plugin.

    We have updated the Domain Mapping plugin on our PROD server and our DEV server is not accessible outside our network. We'll try to set up another copy of our site where we can give you access.

  • Ash

    Hello @clas-web

    I don't see any significant error in the error log.

    And yes please, when you can create a copy please send me admin login and ftp login.

    To send me details, please use our contact form: https://premium.wpmudev.org/contact/

    Select: I have a different question
    Subject: Attn-Ash
    Details: Send all required details (admin info and ftp details) with a link of this thread, so that I can track.
    Also post a note here once you send the info.

    I will be happy to take a look :slight_smile:

    Cheers
    Ash

  • wp.network

    Hi @clas-web

    I looked at your htaccess for a minute and see that you have what looks like a bit of legacy code meant to force SSL - its commented out, just wanted to mention that I noticed it... seems like you've tried a few things...

    I notice that in your original post above the url your quote is
    https://clas-math.uncc.edu/math-placement/
    This url does NOT use 'www' yet the htaccess rules you have in use are setup to only match when HTTP_HOST begins with 'www.' this might be part of the issue, especially if you have also some mixed settings in WP re. www/non-www and http/https...

    I'd recommend making sure that your consistent in the url values used for SITEURL and HOME etc. are correct (can also edit/check via network>sites>edit>settings).

    After much experimentation, I generally use and recommend the following for this purpose with WPMS:

    #BEGIN Catch-All SSL Address Control
    	RewriteCond %{HTTPS} !=on
    	RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
    #END Catch-All SSL Address Control

    All it does is look for the HTTPS flag, and if its not set, it rewrites to https :slight_smile:

    (also, its got a smaller footprint as the RewriteCond for the HTTPS flag is super simple relative to complex pattern matching)

    You could add an exception if needed, or if your environment is a bit more complex we could work out some more fine-tuned rules... (are there parts of your network that do NOT use https?)

    Then do all your other rewrites in diff rule blocks... and btw, keeping huge ban lists in htaccess is not the greatest performance move, imho... Since you use iThemes Security anyways, you could try to just use their 'cloud' service and uncheck the option to maintain a local ban list - you could always add some manual entries if needed.

    You might also take a gander at the rule sets I posted over at https://premium.wpmudev.org/forums/topic/how-to-setup-ssl-for-mapped-domains

    Hope this can be helpful :slight_smile:

    Kind Regards, Max

  • clas-web

    @PortlandWP, thanks for these tips. We did a lot of tweaking of our .htaccess, but it seems that all methods of enforcing SSL produce the same problem with v4.2.0.6 of the Domain Mapping plugin.

    With this latest version of the plugin the browser gets forwarded to the non SSL version of the sites. Our rules then redirect back to https and we get a redirect loop.

    RewriteCond %{HTTP_HOST} ^www\.(.*)
    We definitively need this line. If we remove it, the domain and path are stripped out of the url. I should note that we do NOT have any domains that start with www. Here's our latest .htaccess rewrite rules:

    #Force SSL
    #RewriteCond %{SERVER_PORT} !^443$
    #RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

    #BEGIN Catch-All SSL Address Control
    RewriteCond %{HTTPS} !=on
    RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
    #END Catch-All SSL Address Control

    RewriteBase /
    RewriteCond %{HTTP_HOST} ^www\.(.*)
    RewriteRule (.*) http://%1/$1 [R=301,L]
    RewriteRule ^index\.php$ - [L]
    # uploaded files
    RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [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).*) $1 [L]
    RewriteRule ^[_0-9a-zA-Z-]+/(.*\.php)$ $1 [L]
    RewriteRule . index.php [L]

    • wp.network

      Hi @clas-web, I have a couple of points/ideas...

      1)

      With this latest version of the plugin the browser gets forwarded to the non SSL version of the sites. Our rules then redirect back to https and we get a redirect loop.

      On my networks I do not experience the behaviors you seem to be referencing in the above description.

      For detailed info re. my domain mapping settings please see screenshots attached to my comments at https://premium.wpmudev.org/forums/topic/how-to-setup-ssl-for-mapped-domains.

      The htaccess rules are needed to enforce URL cannonicalization and to enforce desired behavior re. SSL - in other words, to restrict the already present functionality as desired per project.

      I'm not sure what is going on to cause the behavior you describe; my first thought is to make sure that the domains are being mapped to use the https scheme specifically and that SITEURL and HOME are set to use https as well...

      2)

      RewriteCond %{HTTP_HOST} ^www\.(.*)
      We definitively need this line. If we remove it, the domain and path are stripped out of the url. I should note that we do NOT have any domains that start with www.

      Frankly, this makes very little sense to me... I don't get it - especially if you don't have any sites using 'www.' in their url structure.

      Also, in the htaccess file you attached above, you have the rule block:

      RewriteCond %{HTTP_HOST} ^www\.(.*)
      RewriteRule (.*) https://%1/$1 [R=301,L]

      Yet your updated rules posted inline above seem to indicate that you have altered this to:

      RewriteCond %{HTTP_HOST} ^www\.(.*)
      RewriteRule (.*) http://%1/$1 [R=301,L]

      So, even though the Cond pattern in both cases will only pass if the http_host value begins with 'www.' you have changed this so that should the Cond ever pass, the Rule will rewrite to an insecure http address...?

      My feeling is that (lacking a deep understanding of your environment) the above rule block should be removed.

      3)

      #BEGIN Catch-All SSL Address Control
      RewriteCond %{HTTPS} !=on
      RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
      #END Catch-All SSL Address Control

      The above will rewrite any request that is not already using https to use https - this should mean that generally, if you have problems remaining then they are likely originating from your WP settings/setup.

      Hope that this can be helpful and am confident that WPMUdev Staff will be able to move forward with you toward a lasting solution :slight_smile:

      Kind Regards, Max

  • clas-web

    Hi @PortlandWP
    Thanks for all your help. I'll just admit at this point that I do not really understand how rewrite rules work beyond the very basics. I don't understand what the following rule does:
    RewriteCond %{HTTP_HOST} ^www\.(.*)

    However if we comment this line out of our .htaccess, When we view a site, the domain is stripped out of the url and we're left with just the path...

    Thanks for catching the following error in our .htaccess file.
    RewriteRule (.*) http://%1/$1 [R=301,L]

    We changed this back to:
    RewriteRule (.*) https://%1/$1 [R=301,L]

    We tried the Catch-All SSL Address Control rule block based on your recommendation. Adding or removing it doesn't make much difference...

    We looked at your screenshots for setting up mapped domains for SSL and we think we have everything right. Indeed we do NOT have problems with domains mapped using the Domain Mapping plugin.

    We have problems with domains mapped using the Multi-domain plugins ONLY WHEN we update the Domain Mapping plugin to the latest version.

  • wp.network

    We have problems with domains mapped using the Multi-domain plugins ONLY WHEN we update the Domain Mapping plugin to the latest version.

    Ah! Ok, well, in that case I don't know how much help I can be as I haven't spent alot of time working with the Multi-Domain plugin - may have to just wait for WPMUdev Staff to respond...

    As for understanding the htaccess...

    RewriteCond %{HTTP_HOST} ^www\.(.*)
    RewriteRule (.*) https://%1/$1 [R=301,L]

    1) RewriteConds are processed in descending order, but only after the RewriteRule with which they are associated has been found to be a positive match... the RewriteRule will not actually rewrite until/unless the Conds are also found to be positive matches.

    So, your rewrite rule above is
    RewriteRule (.*) https://%1/$1 [R=301,L]

    The (.*) is the pattern to match against and since this is essentially a wildcard pattern that says 'match any/every thing' and it has been used in a position that matches against the path (not the host/server) in the request it will apply to everything... and since it is in parenthesis the matched value will be captured and stored for use... the captured value is represented above as $1

    Your RewriteCond above is
    RewriteCond %{HTTP_HOST} ^www\.(.*)
    This is your primary control on the extremely broad RewriteRule... it says 'Ok, so the path matches, but first lets examine to http_host value and get more specific in our action'

    So the above Cond says to only proceed with the RewriteRule if the http_host value begins (the ^ metacharcter means start of line) with 'www'

    The \. represents a literal period

    and (.*) is, again, a pattern to match anything and to capture the value matched... so we are here looking for any path at any http_host, as long as the http_host value begins with www.

    Also, the last sucessfully matched RewriteCond using parenthesis to capture matched values can be back-referenced in the RewriteRule as shown in the above example as %1 (actually, one can use up to 9 if needed, counting opening parenthesis from left to determine correct reference #)...

    I highly recommend 'Mastering Regular Expressions' by J.Friedl if you want to really dive in :slight_smile:

    Perhaps more immediately focused would be R.Bowen's 'Definitive Guide to Apache mod_rewrite'
    edit: just remembered, he has a newer (slightly simpler) book in the works... read/fork the book 'mod_rewrite And Friends' at http://mod-rewrite.org/book/

    And a very, very useful too (free/donation) is Regex Coach
    http://www.weitz.de/regex-coach/

    For a simpler, more recipe-based resource, check out Jeff Starr's 'htaccess made easy' at htaccessbook.com (attached is a free cheat sheet from Jeff's book).

    Hope all this can help, look forward to seeing the solution y'all work out (and I'm sure you will).

    Kind Regards, Max

  • clas-web

    We have identified the code in the latest version of the Domain Mapping plugin (v4.2.0.6) that break sites that use the Multi-Domain plugin.

    protected function get_original_domain( $with_www = false ){
       $home = network_home_url( '/' );
       $original_domain = parse_url( $home, PHP_URL_HOST );
       return $with_www ? "www." . $original_domain : $original_domain ;
    }

    If this function is updated to include code from v4.2.0.5 the issue is resolved

    protected function get_original_domain( $with_www = false ){
       $home = network_home_url( '/' );
       //$original_domain = parse_url( $home, PHP_URL_HOST );
       $original_domain = parse_url( apply_filters( 'unswap_url', $home ), PHP_URL_HOST );
       return $with_www ? "www." . $original_domain : $original_domain ;
     }

    We don't understand why this fixes the issue... We simply compared the current version with the previous and reverted changes until the issue was resolved.

    We also don't understand why more people aren't experiencing the same issue. We suspect it might be related to our use of SSL for the front and backend and possibly our use of the iThemes Security plugin

    It would be great if the developer could review this suggested revision and release an update.

  • Sam

    Hi @clas-web

    Please note that in latest version of DM we have methods to force ssl for both mapped domain and original domain, and while u're using htaccess to force schema ( https or http ) most probably a conflict between these two ends up in the redirect loop.

    Please try to comment out the code in ur htaccess file that's trying to force ssl and then see if u still have the issue, if the problem persists, please send me your ftp like bellow and i'll be happy to take a look and help:

    Please visit https://premium.wpmudev.org/contact/
    - Mark to my attention - ATTN: Sam Najian
    - Link back to this thread
    - Include admin/network access
    - Include FTP
    - Include any relevant URLS for your site

    Cheers,
    Sam

  • clas-web

    @Sam,
    Thanks for offering to help. Unfortunately, giving you FTP access to our server will be difficult as it requires a VPN connection. We may be able to temporarily make our server accessible to your IP address...

    As a workaround, we have turned on wmpmudev support access and have enable file edit, so you should be able to view and edit DM plugin code. The file that contains the function (get_original_domain) we altered to resolve the issue is:
    domain-mapping/classes/Domainmap/Module.php

    We've attached the latest version of our .htaccess file. Commenting out any code that forces SSL does not resolve the issue.

    For more information about the issue including relevant urls, see:
    https://clas-pages-test.uncc.edu/

    Thanks again for your help. Hope this means of accessing our instance will be sufficient for you to troubleshoot.

  • Ash

    Hello @clas-web

    I hope you are well today.

    As a workaround, we have turned on wmpmudev support access and have enable file edit, so you should be able to view and edit DM plugin code. The file that contains the function (get_original_domain) we altered to resolve the issue is:
    domain-mapping/classes/Domainmap/Module.php

    This is very risky to edit the file via wordpress editor. Because, if there produces any error, the whole site will be down and can't be fixed without ftp access. So, it's better to provide ftp so that we can keep a backup of the working file and make changes.

    Please try to provide us ftp access.

    Maybe @sam is away in this weekend, but he will surely reply you about sharing his IP address.

    Cheers
    Ash

  • clas-web

    @Sam,

    There's no code in our htaccess file that is trying to force https/http that we can see (I attached the current htaccess code to an earlier post above (#post-809950).

    We only made 1 modification to the DM plugin ( to the get_original_domain function) and this modification has been commented out.

    For a full description of our issue, our temporary solution and the urls needed to observe the issue, see:
    https://clas-pages-test.uncc.edu/

    Thanks for your help with this.

  • clas-web

    We have done some more debugging to solve this issue and have figured out exactly what is causing the issue.

    As you know, only domains setup using the Multi-Domain plugin have the issue of the redirect loop. After some test, we found your force_schema function in ./classes/Domainmap/Module/Mapping.php was always redirecting sites with Multi-Domain URLs to a non-secure version, then our own server setup was trying to force SSL and redirected to the secure version of the page. Then your code once again redirect back to non-secure and so forth. This is what was causing the loop. Take a look at the code below (specifically at the the LOOP!!! part):

    ./classes/Domainmap/Module/Mapping.php
    Line 673:

    /**
     * Force single page
     */
    if( !is_admin() && ( $this->is_ssl_forced_by_id( $post->ID ) || $this->is_ssl_forced_by_request() ) && !is_ssl() ){
    			wp_redirect( $current_url_secure  );
    			exit();
    }elseif(  $this->is_mapped_domain() && self::force_ssl_on_mapped_domain() !== 2 && !( $this->is_ssl_forced_by_id( $post->ID ) || $this->is_ssl_forced_by_request() ) ){
    			/**
    			 * Force mapped domains
    			 */
    			if( self::force_ssl_on_mapped_domain() === 1 && !is_ssl()  ){ // force https
    	  				wp_redirect( $current_url_secure  );
    	  				exit();
    			}elseif( self::force_ssl_on_mapped_domain() === 0 && is_ssl() ){ //force http
    		  			// LOOP!!!
    	  				wp_redirect( $current_url);
    				  	exit();
    			}
    }

    The problem with this code is that self::force_ssl_on_mapped_domain() was always returning 0 due to the domains not having an entry in the DOMAINMAP_TABLE_MAP table since these domains were setup through the Multi-Domain plugin. We were able to fix the issue by altering the force_ssl_on_mapped_domain function:

    ./classes/Domainmap/Module.php
    Line 232:

    public static function force_ssl_on_mapped_domain( $domain = "" ){
    		global $wpdb;
    		$current_domain = isset( $_SERVER['SERVER_NAME'] ) ? $_SERVER['SERVER_NAME'] : $_SERVER['HTTP_HOST'];
    		$domain = $domain === "" ? $current_domain  : $domain;
    		//clas-web changes (2015-03-09)
    		//return (int) $wpdb->get_var( $wpdb->prepare("SELECT <code>scheme</code> FROM <code>" . DOMAINMAP_TABLE_MAP . "</code> WHERE <code>domain</code>=%s", $domain) );
    		$result = $wpdb->get_var( $wpdb->prepare("SELECT <code>scheme</code> FROM <code>" . DOMAINMAP_TABLE_MAP . "</code> WHERE <code>domain</code>=%s", $domain) );
    		if( $result === null ) return 2;
    		return intval($result);
    }

    This disables any force redirects on Multi-Domain setup URLs. Though, I believe it might be better to have the option to completely disable the force schema section.