Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aliased domain cache is not cleared #608

Closed
kristineds opened this issue Nov 10, 2015 · 13 comments
Closed

Aliased domain cache is not cleared #608

kristineds opened this issue Nov 10, 2015 · 13 comments

Comments

@kristineds
Copy link

Quick Cache Pro is not clearing cache for multiple sites/domains e.g. alias domains.

Referencing Ticket: Ticket # 9371


According to @jaswsinc:

That is to be expected. ZenCache only clears the cache for the currently configured domain in a WordPress installation. The only way it can clear multiple sites is if you run it in a Multisite Network installation and click the "Wipe" button that is presented whenever you are running a Multisite Network

Having said that, whenever ZenCache automatically wipes the cache, everything is dealt with (for both domains), but unless you're running a Network, the Clear Cache button will not handle this gracefully I'm afraid.

@kristineds kristineds added the bug label Nov 10, 2015
@jaswrks
Copy link

jaswrks commented Nov 12, 2015

@raamdev Thoughts on how to handle this? We could expose the Wipe Cache button for standard installs also I guess, but that seems like it would confuse most people; i.e., I imagine it is very rare for a standard installation to be associated with more than one domain.

However, there are cases when that could occur. In addition to the report above, there was this other case also. See: #101 (comment)

@raamdev
Copy link
Contributor

raamdev commented Nov 12, 2015

@jaswsinc I would handle this by adding a new section under ZenCache → Plugin Options → Automatic Cache Clearing → Misc. Auto-Clear Options called "Auto-Clear These Aliased Domains Too?" that allows a site owner to define a comma-delimited list of aliased domains, so that ZenCache can take those additional domains into consideration whenever clearing the cache.

@yoffe
Copy link

yoffe commented Nov 13, 2015

Hi,
I think that this issue may occur also on a regular page update.
The cache engine need to update all the cached pages also in the alias domains...

@jaswrks
Copy link

jaswrks commented Nov 16, 2015

@raamdev writes...

define a comma-delimited list of aliased domains

Is there a specific reason why you feel this should be configurable?

Now that I'm looking at this again, it seems like the expected behavior would be for ZenCache to clear everything whenever it's running in a standard WP installation, right? So if that's the case, then maybe we just need to tell ZenCache that on a standard installation a cache clearing should clear all domain variations; i.e., behave as if there is not more than one domain to consider, but if there are, they are just cleared away at the same time. Nothing to configure that way.

@raamdev
Copy link
Contributor

raamdev commented Nov 16, 2015

@jaswsinc If we visit aliased domain alias.com, generate a cache file that goes in cache/alias-com/, and then visit the primary site on example.com and update the post we visited via alias.com, then the automatic routines that clear the cache file for that post will only look in cache/example-com/, right? That seems like the problem with aliased domains.

An aliased domain is essentially another way of referencing the same site. So you could have a site example.com onto which you alias several other domains, e.g., alias.com, foo.com, etc. When someone visits alias.com or foo.com, they do not get redirected to the main example.com, but instead they get to browse the entire site as whatever domain they typed in originally. That's how aliased domains are supposed to work.

So, to properly support aliased domains, ZenCache would need to know about all the domains it needs to consider when clearing cache files, e.g., a comma-delimited list supplied by the site owner.

If we're only talking about a full "Clear Cache" command, then yes, I agree, simply wiping out everything in wp-content/cache/zencache/cache/* would be sufficient. But that's not the problem with aliased domains I thought we were addressing. :-)


I haven't looked very carefully into how well supported aliased domains are with WordPress itself, so that might be something worth looking into. Also, seeing as how this is probably a not-so-common scenario, I'd be fine with making this something that you can support via an MU-Plugin (pass in an Array of domains).

I'm assuming that such a change would just require adding a few lines of code to each of the clear cache routines, but if it would require more work than that I might just consider punting this or putting it on the back burner.

@jaswrks
Copy link

jaswrks commented Nov 17, 2015

If we visit aliased domain alias.com, generate a cache file that goes in cache/alias-com/, and then visit the primary site on example.com and update the post we visited via alias.com, then the automatic routines that clear the cache file for that post will only look in cache/example-com/, right? That seems like the problem with aliased domains.

Correct. That is the problem in my view also. The assumption (for the moment) is that a standard WP installation is only ever associated with one domain name. The home_url() domain.

If we're only talking about a full "Clear Cache" command, then yes, I agree, simply wiping out everything in wp-content/cache/zencache/cache/* would be sufficient. But that's not the problem with aliased domains I thought we were addressing. :-)

Copy that. I agree. I hadn't considered the automatic clearing routines also.

I haven't looked very carefully into how well supported aliased domains are with WordPress itself, so that might be something worth looking into. Also, seeing as how this is probably a not-so-common scenario, I'd be fine with making this something that you can support via an MU-Plugin (pass in an Array of domains).

I agree. I'm marking this as Needs Research.

@raamdev raamdev changed the title Bug :: Quick Cache Pro :: Multisite :: Clear Cache for multiple sites Aliased domain cache is not cleared Apr 28, 2016
@raamdev
Copy link
Contributor

raamdev commented Apr 28, 2016

Referencing this GitHub issue with the WPML plugin, which allows integration with aliased domains to support specific domains for versions of the site in different languages.

Quoting #750 (comment)...

We have two domain names, one for each language:

  1. english-example.com
  2. spanish-example.com

They are not sub-domains. The hyphens are deliberate.

The server is configured to use spanish-example.com as the root domain. english-example.com is an addon domain. Both domains point to the same server space.

WPML has an option for setting a domain name to use for the alternate language versions of the site.

When a request is made to the server, WPML detects which domain is requested. WordPress serves the requested page. WPML detects whether an alternate language version of the page exists and if one does then WPML displays a link to the alternate language version. The WordPress admin pages are served under the primary domain name.

Note that "addon domain" mentioned above is specifically referring to an aliased domain (ServerAlias), configured in Apache like the following (as described in the WPML docs on this feature:

<VirtualHost *>
  DocumentRoot /your_wp_install_directory/wordpress
  ServerName www.english-domain.com
  ServerAlias www.french-domain.fr

  ... your other stuff here ...
</VirtualHost>

My feeling is that Comet Cache should support aliased domains. This doesn't seem very difficult to do: it seems it would just be a matter of allowing the site owner to define a list of aliased domains, and then Comet Cache could include those domains in the regex patterns when clearing cache files.

Thoughts @jaswsinc?

@jaswrks
Copy link

jaswrks commented May 10, 2016

I agree that we should support aliased domains in CC. This is going to be something that needs to lay on top of (and/or together with) the existing functionality in CC that covers multisite domain mapping, because in the use case you mentioned with WPML we are talking about each individual site (whether it be in a network or not) being accessible over multiple domain variations.

So yeah, we would need to have a list of the aliased domains for multisite compat. Either by detecting popular plugin configurations and/or providing a box where the site owner can enter those.

On a single-site, I think this should be automatic; i.e. not need a list of aliases to work from. Any URL that is cleared on a standard WP installation should just be cleared by its URI and not by the full URL that includes a host name. That would resolve most of the issue here in that one change, because on a standard WP installation if we clear by URI alone, that would cover all domain variations.

Since our clearing routines operate on regex, it would be as simple as altering the regex; i.e., changing /[host]/ to /[^\/]+/ in order to clear all domain variations. In short, clearing by the URI alone.

@raamdev raamdev added this to the Future Release milestone May 10, 2016
@VR51
Copy link

VR51 commented May 10, 2016

A suggestion to speed this up a little bit. A temp. fix would be to add a 'Delete Cache Directory' button to the Comet Cache menu when aliased domains are in use. This way affected users won't need to manually delete the cache directory via FTP.

@raamdev
Copy link
Contributor

raamdev commented Jun 20, 2016

@jaswsinc So I see this as involving two fixes: one for Standard WP installations and one for Multisite WP installations, correct?

If that's the case, let's start with improving this for Standard WP installations. If all that's required is an update to the RegEx, that sounds easy enough.

I think it's a great idea to clear all variations of the domain when operating on a standard WP installation, as that seems to be what would be expected anyway, e.g., if the site has both http and https variations of their URL and their site is mixing the two, it would be nice to ensure that both variations of the cache are cleared when necessary.

For Multisite installations, I can see how it will get a little complicated. If each site in a multisite network can have its own domain and its own set of aliased domains, then we'd need a way for the Network Admin to provide a list that maps Sites to Aliased Domains (e.g., site1.com:alias1.com,alias2.com).

From what I've seen, all of the reports that mention this aliased domain issue have been Standard WP sites not Multisite installations, so I think we should start by getting this fixed for Standard WP sites and if there's a demand for this 'feature' in Multisite as well, we can come back and add that later.

@jaswrks
Copy link

jaswrks commented Jun 20, 2016

@raamdev Sounds like a plan ...

General Outline for Standard Installations

  • After this line add the following:

    // On a standard installation delete from all hosts.
    // See: <https://github.com/websharks/comet-cache/issues/608>
    
    if (!is_multisite() && !$___considering_domain_mapping) {
        $regex = ltrim($regex, '^\\/');
    
        if (mb_strpos($regex, '(?:\/') === 0 || mb_strpos($regex, '(\/') === 0) {
            $regex = '/^https?\/[^\/]+'.$regex;
        } else {
            $regex = '/^https?\/[^\/]+\/'.$regex;
        }
        return $this->deleteFilesFromCacheDir($regex, $check_max_age);
    }

@raamdev
Copy link
Contributor

raamdev commented Jun 24, 2016

Next Release Changelog:

  • Bug Fix: If your site uses aliased domains, Comet Cache now properly considers all possible domain variations when it clears the cache on WP Standard installations. Props @kristineds, @jaswsinc, @yoffe, and @VR51. See Issue #608.

@raamdev raamdev closed this as completed Jun 24, 2016
raamdev added a commit that referenced this issue Jul 7, 2016
- **New Feature! Apache Optimizations.** This release includes a completely new option panel for Apache Performance Tuning. Current options for Apache tuning include GZIP Compression, Leverage Browser Caching, Enforce Canonical URLs, and Send Access-Control-Allow-Origin Header (for Static CDN Filters). These options automatically add or remove from your `.htaccess` file the appropriate configuration based on the options you enable or disable (all options are disabled by default, so your `.htaccess` file is not modified unless you say so). If you prefer to update your `.htaccess` file manually, the necessary configuration can be viewed beneath each option. Props @jaswsinc, @renzms. See [Issue #789](#789).
- **New Feature!** A new "Enable GZIP Compression" option has been added to the new Apache Optimizations panel. This option will automatically add the appropriate configuration to your `.htaccess` file to enable GZIP compression. This option is disabled by default. The old "GZIP Compression" panel has been removed in favor of the new option inside Apache Optimizations. Props @renzms, @jaswsinc. See [Issue #764](#764).
- **New Feature!** Multisite Host Exclusion Patterns. It's now possible to exclude entire sites from the cache in a Multisite Network environment. Domain mapping is also supported! See _Comet Cache → Plugin Options → Host Exclusion Patterns_. If you're running a Multisite Network with Sub-Directories, you can exclude sites using the existing URI Exclusion Patterns feature. Props @kristineds. See [Issue #754](#754).
- **New Feature (Pro)!** A new "Leverage Browser Caching" option has been added to the new Apache Optimizations panel. This option will automatically add the appropriate configuration to your `.htaccess` file to enable Browser Caching. This option is disabled by default. Props @renzms, @jaswsinc. See [Issue #764](#764).
- **New Feature (Pro)!** A new "Enforce Canonical URLs" option has been added to the new Apache Optimizations panel. This options adds the appropriate `.htaccess` code to enforce the correct canonical URLs according to your WordPress Permalink settings (Comet Cache detects if the Permalink Structure ends with a trailing slash, or without a trailing slash). Props @renzms, @jaswsinc. See [Issue #554](#554).
- **Bug Fix**: In some scenarios the Cron Event that cleans up expired cache files (`_cron_comet_cache_cleanup`) would never run, or the Next Run time would constantly reset to 1 minute away from running every time a page was reloaded. We suspect this is a race condition and in attempt to work around this issue we now skip all of our Cron-related checks if Cron is currently in the middle of running a process. Props @xberg and @lkraav for help reporting. See [Issue #653](#653).
- **Bug Fix**: If your site uses aliased domains, Comet Cache now properly considers all possible domain variations when it clears the cache on WP Standard installations. Props @kristineds, @jaswsinc, @yoffe, and @VR51. See [Issue #608](#608).
- **Bug Fix** (Pro): Fixed a bug where Comet Cache would appear to prevent WordPress from redirecting Permalinks that don't include a trailing slash, to the URL that does include a trailing slash. This was due to the fact that Comet Cache loads very early on (for caching purposes) and as a result the WordPress `redirect_canonical()` function never gets run. This was fixed by adding an option to the new Apache Optimizations panel that allows you to Enforce Canonical URLs. Props @renzms, @jaswsinc. See [Issue #554](#554).
- **UX Bug Fix** (Pro): If you had your WordPress Dashboard login details saved by your browser, the browser autofill would automatically fill in the Pro Plugin Updater fields with those details, which then needed to be replaced with your actual Pro license details. The browser autofill has been disabled for those fields (tested in Chrome, Firefox, and Safari). Props @renzms. See [Issue #741](#741).
- **Enhancement**: Added links the Options Page for the Comet Cache [Twitter](http://twitter.com/cometcache) and [Facebook](http://facebook.com/cometcache) accounts. Props @renzms. [Issue #771](#771).
- **Enhancement:** Added full support for UTF-8 (multibyte strings). This release adds full support for UTF-8 throughout the Comet Cache codebase, greatly enhancing Comet Cache's ability to deal with file paths and URLs that may contain UTF-8 characters. Props @jaswsinc. [Issue #703](#703).
- **UI Enhancements**: Improved the Logged-In Users and the Client-Side Caching options panels to dim additional options when the feature is disabled. Additionally, the "Enable HTML Compression for Logged-In Users?" option has been relocated from the HTML Compressor option panel to the more appropriate Logged-In Users option panel. See [Issue #768](#768).
- **UX Enhancement**: Improved the inline docs for Auto-Clear List of Custom URLs to clarify that full URLs must be provided. Props @renzms. See [Issue #781](#781).
- **Enhancement** (Pro): The Pro Plugin Updater has been improved to allow for better compatibility with hosting platforms that use Apache's ModSecurity. In some cases, site owners were seeing a 404 error when attempting to update the Pro version using the Pro Plugin updater because certain ModSecurity rules were blocking the Pro Updater requests. The Pro Plugin Updater now uses WP Transients to store the necessary metadata, which works around the issue with ModSecurity. Props to @seozones for reporting and @jaswsinc for help fixing this. [Issue #416](#416).
- **Enhancement** (Pro): When Static CDN Filters are enabled, it's now possible to disable the automatic insertion of rules into your `.htaccess` file that are designed to prevent issues with [CORS](https://cometcache.com/kb-article/what-are-cross-origin-request-blocked-errors/). See _Apache Optimizations → Send Access-Control-Allow-Origin Header?_ See [Issue #787](#787).
- **Enhancement** (Pro): The HTML Notes added to the bottom of a cached page now specify if the page was cached as the result of an HTTP Request or if it was cached by the Auto-Cache Engine. Props @kristineds. See [Issue #292](#292).
- **Enhancement** (Pro): The Auto-Cache Engine now supports a fallback to cURL using the WP HTTP API. If your PHP configuration has `allow_fopen_url=0`, the Auto-Cache Engine will use the fallback to download the XML Sitemap and parse it from a temporary file. If you want to force the use of this fallback even when `allow_fopen_url=1`, you can use [a filter](#440 (comment)). See [Issue #440](#440).
- **UI Enhancement** (Pro): A second button has been added to the bottom of the Pro Plugin Updater page that allows you to "Save and Update Comet Cache Pro" in one step. Props @renzms. See [Issue #741](#741).
- **UI Enhancement** (Pro): The "Cache Stats" button in Admin Bar is now linked to the Cache Stats page. Instead of hovering over the button and then clicking "More Info" inside the popup panel, you can now just click the "Cache Stats" button to go directly to the Cache Stats page. Props @Presskopp, @renzms. See [Issue #780](#780).
- **Comment Mail Compatibility:** Improved compatibility with the Comment Mail plugin by automatically clearing the cache whenever Comment Mail options are changed. Many of the Comment Mail options affect front-end portions of the site, so it's important that the cache is cleared whenever Comment Mail options change. See [Comment Mail Issue #278](wpsharks/comment-mail#278 (comment)).
- **PHP Compatibility:** Improved compatibility back to PHP 5.2 (the lowest version allowed by WordPress). Comet Cache still requires PHP 5.4+, but if you install Comet Cache on a site running PHP 5.2, it will now fail gracefully with a Dashboard notice indicating PHP 5.4+ is required, instead of producing a fatal error. See [Issue #784](#784).
- **WP-CLI Compatibility**: Fixed a bug with deactivating Comet Cache using WP-CLI. Doing so was producing a "Invalid argument; host token empty!" error message. This has been resolved. Props @MarioKnight @jaswsinc @renzms. See [Issue #728](#728).
- Renamed `COMET_CACHE_ALLOW_BROWSER_CACHE` constant to `COMET_CACHE_ALLOW_CLIENT_SIDE_CACHE`. Backwards compatibility has been maintained.
- Renamed `allow_browser_cache` plugin option to `allow_client_side_cache`.
@raamdev
Copy link
Contributor

raamdev commented Jul 7, 2016

Comet Cache v160706 has been released and includes changes from this GitHub Issue. See the v160706 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 (#608).

@wpsharks wpsharks locked and limited conversation to collaborators Jul 7, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants