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

Bug :: Multisite :: Sub-Directory Install :: Cache Clearing #540

Closed
jaswrks opened this issue Aug 5, 2015 · 8 comments
Closed

Bug :: Multisite :: Sub-Directory Install :: Cache Clearing #540

jaswrks opened this issue Aug 5, 2015 · 8 comments

Comments

@jaswrks
Copy link

jaswrks commented Aug 5, 2015

Overview

Clearing the cache from the main site when there are child blogs in sub-directories, results in all child blogs being cleared from the cache, not just the main site as would be expected. In short, this results in what is essentially a full wipe of the cache, when in fact I just want to clear the cache for the main site.

Steps to Reproduce

  • Setup MS network w/ sub-directories.
  • Create sites example.com/child1 and example.com/child2
  • Enable user-specific caching for easier testing.
  • Hit the front page of the main site and let it cache you; i.e., example.com/
  • Hit the front page of each of the child sites as well; i.e., example.com/child1 and example.com/child2
  • Clear the cache from the dashboard of the main site.

Expected Behavior

That only the cache for the main site would be cleared.

Observed Behavior

All child blog sub-directories are cleared as well. It's a full wipe when it should just clear the main site. This happens due to the fact that child blogs are stored in sub-directories; i.e., they are not associated with their own host.

@jaswrks jaswrks added the bug label Aug 5, 2015
@jaswrks
Copy link
Author

jaswrks commented Aug 5, 2015

Noting that the HTML Compressor cache is immune to this. It only impacts ZenCache itself. Files cached by the HTML Compressor are stored in nested directories that work around this issue.

@jaswrks
Copy link
Author

jaswrks commented Aug 5, 2015

This also has the potential to cause performance issues whenever the cached is cleared from the main site in a sub-directory network. ALL of the child blogs are being scanned, instead of just the main site.

@raamdev
Copy link
Contributor

raamdev commented Aug 5, 2015

@jaswsinc Thanks for the detailed bug report! My feeling is that the priority for this bug can slip to the following release; I see this as confusing and potentially harmful (for performance reasons), but nothing catastrophic.

If you've already started working on this and you feel it's a relatively easy fix, I certainly wouldn't mind getting it into the next release, but if not I wanted to share my thoughts on priority. :-)

@raamdev raamdev added this to the Future Release (Pro) milestone Aug 5, 2015
@jaswrks jaswrks modified the milestones: Next Release (Pro), Future Release (Pro) Aug 5, 2015
@jaswrks jaswrks self-assigned this Aug 5, 2015
jaswrks pushed a commit to wpsharks/comet-cache-pro that referenced this issue Aug 5, 2015
@jaswrks
Copy link
Author

jaswrks commented Aug 5, 2015

Changes to Branched Cache Structure

Legend: [URL] = [cache path]


  • Old way: http://wp-multisite.com/child1/ = http/wp-multisite-com/child1.html
  • New way: http://wp-multisite.com/child1/ = http/wp-multisite-com-child1/child1/index.html

If the installation is in a sub-directory:

  • Old way: http://wp-multisite.com/base/child1/ = http/wp-multisite-com/base/child1.html
  • New way: http://wp-multisite.com/base/child1/ = http/wp-multisite-com-base-child1/base/child1/index.html

Summary

If there is a multisite base directory and/or child sub-directory, that collective path becomes a suffix of the host fragment used in cache path generation. This way each child blog has a host-based root--which makes clearing the cache much more logical and it improves performance considerably in a MS network that runs from a sub-directory base and/or uses a sub-directory structure for child blogs.

In addition, each multisite base directory and/or child sub-directory gets it's own /index in order to resolve the issues documented in: #536 & #409

@jaswrks
Copy link
Author

jaswrks commented Aug 5, 2015

Another example of the new behavior:

<!-- ZenCache HTML Compressor took 0.05899 seconds (overall). -->
<!-- ZenCache file path: /cache/zencache/cache/http/wordpress-vm-child1/child1/index.u/1.html -->
<!-- ZenCache file built for (http://wordpress.vm/child1/; user token: 1) in 0.38910 seconds, on: Aug 5th, 2015 @ 10:05 pm UTC. -->
<!-- This ZenCache file will auto-expire (and be rebuilt) on: Aug 12th, 2015 @ 10:05 pm UTC (based on your configured expiration time). -->

@jaswrks
Copy link
Author

jaswrks commented Aug 5, 2015

From the main site:

<!-- ZenCache HTML Compressor took 1.61151 seconds (overall). -->
<!-- ZenCache file path: /cache/zencache/cache/http/wordpress-vm/index.u/1.html -->
<!-- ZenCache file built for (http://wordpress.vm/; user token: 1) in 1.98672 seconds, on: Aug 5th, 2015 @ 10:05 pm UTC. -->
<!-- This ZenCache file will auto-expire (and be rebuilt) on: Aug 12th, 2015 @ 10:05 pm UTC (based on your configured expiration time). -->

@raamdev raamdev added the DMOZL label Aug 12, 2015
@raamdev
Copy link
Contributor

raamdev commented Aug 12, 2015

Next Pro Release Changelog:

  • Multisite Bug Fix: Fixed a bug where clearing the cache from the main site of a multisite network, when there are child blogs in sub-directories, resulted in all child blogs being cleared from the cache, not just the main site as would be expected. This has been resolved and only the main site is cleared when clicking the Clear Cache button. Note that the Wipe Cache button can still be used to clear the cache for all sites in a Multisite Network. Props @jaswsinc. See Issue #540.

@raamdev raamdev closed this as completed Aug 12, 2015
@raamdev
Copy link
Contributor

raamdev commented Aug 21, 2015

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 (#540).

@wpsharks wpsharks locked and limited conversation to collaborators Aug 21, 2015
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

2 participants