Improve compatibility with MU Domain Mapping plugin

[raamdev]

In a WordPress.org support thread, Andrew writes...

I disabled Domain Mapping and suddenly QuickCache began working for all blogs.

This led me to find the route cause of the problem - for me anyway.

I have Multisite and have Domain mapping. WordPress is installed on domain1.co.uk. For site two (on domain2.co.uk), my WordPress URL was domain1.co.uk/domain2/wp-admin/, and the site URL domain1.co.uk/domain2 with Domain Mapping mapping it to domain2.co.uk.

When I changed the site URL for site two to be domain2.co.uk/ in WordPress (so the admin interface became domain2.co.uk/wp-admin/, QuickCache started working - when posts were updated, the cache was cleared.

---

Referencing MU Domain Mapping plugin: https://wordpress.org/plugins/wordpress-mu-domain-mapping/

---

Support threads referencing this issue

• https://wordpress.org/support/topic/cache-not-clearing-on-multisite-when-a-post-is-edited
• https://wordpress.org/support/topic/zencache-not-purging-cache-on-postpage-update-using-multisitesubfolder

[ThePopularizer]

I'm having the same issue with a subdomain multi-site installation with domain mapping on the sub sites. Can you please look into it? I'm using ZenCache Pro (multisite) v.150409.

I should add that the site setup is such that the admin address is on a subdomain (as per installation), but the front-end is on its own domain (set as primary domain). It's with the following setting enabled: "Redirect administration pages to site's original domain (remote login disabled if this redirect is disabled)". The plugin is <a href="https://wordpress.org/plugins/wordpress-mu-domain-mapping/" target=_blank">Wordpress MU Domain Mapping.

[raamdev]

@ThePopularizer Thank you for sharing that helpful information. :-) Full WordPress Multisite compatibility is a priority on development roadmap.

[isaumya]

+1 for this feature request 👍

[scottelkin]

+1, but I don't see this as a feature request. Posts don't clear cache on update currently while using the domain mapping plugin. I was disappointed not seeing this fixed for the next release as this is crucial for our users.

[isaumya]

@scottelkin Hey I am disappointed too to not see a fix for this in the upcoming release. But hey, lets be honest. This upcoming release is the most major update of zencache supporting multi site. Previous of this release you can just activate it as network activate but practically it was useless in terms of multisite. But with this upcoming update, multisite has been taken seriously for the first time and that is why a lot of major improvements are coming up like cdn support, cache support etc. So, I'm not sure when zencache team will work on domain mapping thing, but I think they will work on it may be in the next next release. As almost every multisite uses domain mapping plugin, hence this is a serious feature request. Hope to see it soon. 👍

[raamdev]

@scottelkin Have you tested the latest release candidate with Domain Mapping or were you testing the last public release (v150409)?

[scottelkin]

I have not tested it. I was just commenting from the RC notes which didn't include this bug fix. If this functionality was fixed, I sincerely apologize!

[raamdev]

@scottelkin There was a lot of functionality added to the latest RC related to multisite. Domain Mapping should work as of the latest RC, however this GitHub issue was specifically left open because we haven't fully tested the latest multisite functionality with Domain Mapping. Once it has been tested and confirmed working without issue, I will update this GitHub Issue.

[raamdev]

Update: Domain Mapping Compatibility (as of v150605 RC)

I just got through testing ZenCache Pro v150605 (Release Candidate) with a WordPress Multisite Network using Sub-Domains (e.g., site1.example.com) mapped to full domains (e.g., site1.com) with the Domain Mapping Plugin.

The following works as expected:

• Cache files generated when visiting the mapped domain (e.g., site1.com) are generated as expected:

  <!-- ZenCache file path: /cache/zencache/cache/http/site1-com/2015/06.html -->
  

• Clicking the "Clear Cache" button in the toolbar when visiting the mapped site properly clears the cache files for only that site.

• Clicking the "Wipe" button in the toolbar properly clears all cache files across all sites in the Multisite Network.

Everything else also works as expected, as long as one of the Domain Mapping Plugin options is disabled (see below).

Automatic Cache Purging when Publishing/Updating Posts on the Dashboard

By default, the Domain Mapping Plugin options are configured with an option that says to "Redirect administration pages to site's original domain". With that option enabled (the default), visiting the Dashboard for site1.com will redirect you to site1.example.com/wp-admin/.

That currently poses a problem for ZenCache. When you do anything in the Dashboard that requires ZenCache to purge a cache file (such as updating a published post), ZenCache looks for a cache file for site1.example.com. However, since the front-end of the site is loaded with the mapped domain (site1.com), there was no cache file generated for site1.example.com (it was generated for site1.com). Therefore, ZenCache doesn't purge the cache file associated with the post being updated.

If we uncheck that Domain Mapping Plugin option that redirects administration pages to the original site, then visiting the Dashboard for the mapped domain does not redirect you and instead you get sent to site1.com/wp-admin/ (now the Dashboard domain matches the front-end domain). Then, when you edit a published Post, ZenCache will purge the proper cache files (because the front-end and the Dashboard domains both match).

How ZenCache can improve Domain Mapping Plugin support

When building the path to the cache file that should be purged, ZenCache should check if the Domain Mapping plugin is installed and if there is a mapping in place for the current domain, e.g., if the domain is site1.example.com and ZenCache finds there's a mapping to site1.com, ZenCache should instead use site1.com to build the path to the cache file that needs to be purged.

Because that issue (automatic purging not working because Dashboard and front-end domains don't match) was the original issue described in this thread, I'm leaving this GitHub issue open and considering Domain Mapping Plugin support to still be broken.

We either need to fix this so that ZenCache searches the mapped domains table, or we need to provide a clear warning message to site owners when they have that particular Domain Mapping Plugin option enabled (as that option, which is enabled by default, effectively breaks ZenCache in a quiet way).

cc @jaswsinc

[jaswrks]

Cool. Thanks for that insight Raam. That makes it crystal clear.

If I remember correctly, domain mapping plugins alter the $current_blog global, so we could read in the $GLOBALS['current_blog']->domain property on a Multisite Network to be sure that we get the right domain name. I'll have to double-check that, but dumping this global object in a MS network should give us the details we need to fix this.

[raamdev]

we could read in the $GLOBALS['current_blog']->domain property on a Multisite Network to be sure that we get the right domain name

I just checked this by doing a print_r($GLOBALS); in an MU-Plugin, and when I'm viewing the Dashboard for site1.example.com there's no mention anywhere of the mapped domain (site1.com), so it looks like we'll probably have to query the database to look up the domain mapping.

[raamdev]

$GLOBALS['current_blog']->domain references the sub-domain (e.g., site1.example.com), not the mapped domain.

[jaswrks]

I see! Thanks then.
Referencing: https://github.com/wp-plugins/wordpress-mu-domain-mapping/blob/master/sunrise.php

[jaswrks]

So after looking closer at the wordpress-mu-domain-mapping plugin, I am seeing the following query being needed to determine the WordPress core sub-domain instead of the mapped domain.

if (defined('DOMAIN_MAPPING') && DOMAIN_MAPPING) {
    global $wpdb, $blog_id;
   $sub_domain = $wpdb->get_var("SELECT `domain` FROM `".$wpdb->blogs."` WHERE `blog_id` = '".esc_sql($blog_id)."' LIMIT 1");
}

Untested code sample ↑ ... just observing at the moment, and trying to help.

[raamdev]

to determine the WordPress core sub-domain instead of the mapped domain.

@jaswsinc I was thinking we wanted the exact opposite: When someone is visiting the Dashboard for a mapped site, the Dashboard will use the sub-domain address (e.g., site1.example.com), which means that when ZenCache tries to purge cache files as the result of an action on the Dashboard (editing a post, for example), ZenCache will be using the sub-domain to build the path to the cache file, which is wrong: It should be using the mapped domain (e.g., site1.com) to build the path to cache files, because that's what was used to generate the cache file in the first place on the front-end (when someone visits the site on the front-end, they visit http://site1.com/, but the Dashboard for that site has the URL of http://site1.example.com/wp-admin/).

I say that's "wrong" because I'm thinking the cache files should be built using the mapped domain (e.g., /cache/http/site1-com/) as opposed to the original WordPress Sub-Domain (e.g., /cache/http/site1-example-com/).

It sounds like you're saying that the front-end of the site where cache files are generated should actually be using the original Sub-Domain address (not the mapped domain address) to generate cache files, and should ignore the domain mapping altogether.

(Either approach would work in my mind--I'm just trying to clarify what you're thinking here.)

[jaswrks]

It sounds like you're saying that the front-end of the site where cache files are generated should actually be using the original Sub-Domain address (not the mapped domain address) to generate cache files, and should ignore the domain mapping altogether.

Thanks for pointing that out. Nope, I wasn't saying that, I was just plain wrong. I agree, I had this backwards in my last reply.

(Either approach would work in my mind--I'm just trying to clarify what you're thinking here.)

I would vote for the approach that you first mentioned here; i.e., that we cache the site1.com as it was originally requested (we are already doing this), and then lookup the site1.com domain from the backend whenever a site owner is working from the site1.example.com sub-domain in the WordPress Dashboard (not doing this yet).

I think, and agree, that this makes the most sense. I'd rather see us caching the actual Host: used by visitors, and then work some magic to translate the sub-domain whenever the cache needs clearing.

---

Here is a revised code sample. Again, this is untested at the moment.

if(is_multisite() && function_exists('domain_mapping_siteurl') && get_site_option('dm_redirect_admin')) {
    $mapped_domain = (string) parse_url(domain_mapping_siteurl(home_url()), PHP_URL_HOST);
}

A closer look at the above...

• function_exists('domain_mapping_siteurl') i.e., is the MU Domain Mapping plugin running?
• get_site_option('dm_redirect_admin') i.e., is that box checked that redirects the admin panel?
• domain_mapping_siteurl(home_url()) i.e., ask that plugin to convert the domain for us.

[raamdev]

Here is a revised code sample. Again, this is untested at the moment.

Thanks! I did some preliminary testing with that code and it appears to work as expected.

As per our private discussion, I'm opening a new GitHub issue (#505) to work on refactoring the codebase to make implementing this code a bit easier, as there are several places in the codebase where we need to look up the hostname.

This GitHub issue is blocked until #505 is complete.

[raamdev]

Next Pro Release Changelog:

• Multisite Domain Mapping Compatibility: ZenCache is now fully compatible with the WordPress MU Domain Mapping plugin, including Multisite Networks using domain mapping on top-level domains, sub-domains, and sub-directories. Multiple variations of each site spread across an unlimited number of domain mappings and/or the original blog domain/path is also supported. All other features of ZenCache, including the Auto-Cache Engine, Static CDN Filters, and HTML Compression are also now compatible with domain mapping. See Issue #339.

[raamdev]

ZenCache Pro v150821 has been released and includes changes from this GitHub Issue.

See the ZenCache Pro v150821 announcement for further details.

---

This issue will now be locked to further updates. If you have something to add related to this GitHub Issue, please open a new GitHub Issue and reference this one (#339).