-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Cache for date-based archive views not cleared when post is updated #724
Comments
@jaswsinc I was looking through the Comet Cache Automatic Cache Clearing options and I realized that we don't even have anything for date-based archive views. Am I missing something or have we never had support for this? This seems like a pretty important thing to support, given that date-based archive views are on-par with category and tag archive views in terms of how often they're used. |
Great catch. I'm not seeing anything either.
Agreed. |
I was just taking a closer look at this issue. The permalink structure should not matter, should it? If a Post is updated in some way (regardless of permalink) the date-based archive view should be cleared as well, when that functionality is enabled. Does that sound right? So it seems like what we need is a routine that can look at the original publication date and then clear the date-based archive views for that publication date, regardless of permalink. |
Yes, that sounds right. All we need to consider is that the date-based archive views may be paginated, and the post that's being updated might be somewhere other than page 1. I just did some testing and it appears that for a post published on April 9th, 2016, we would need to clear all of the following:
It's unfortunate that the cache for a whole years' worth of archives will get cleared each time a post is published/updated, but I'm not seeing any way around this. Also noting that we should use We should add a new option to Automatic Cache Clearing that allows a site owner to control this behavior: Auto-Clear "Date Archives" Too?
|
Copy that. Sounds like a plan then.
Agreed. Our existing code for regex formulation should already handle this properly. Once we implement a new method to clear the date-based archive views for dated variations as you outlined above, the pagination will be taken into account by some of our existing regex handlers. |
… clear the cache for date-based archive views whenever any single post is cleared due to changes in content, title, etc. See: **Dashboard → Comet Cache → Plugin Options → Automatic Cache Clearing → Auto-Clear "Date-Based Archives" Too?**. See also: [Issue #724](wpsharks/comet-cache#724).
- **New Feature:** Comet Cache can now be configured to automatically clear the cache for date-based archive views whenever any single post is cleared due to changes in content, title, etc. See: **Dashboard → Comet Cache → Plugin Options → Automatic Cache Clearing → Auto-Clear "Date-Based Archives" Too?**. See also: [Issue #724](#724). - **New Pro Feature:** Apache Optimizations now include a new option that allows site owners to enforce an exact host name for all requests. See: **Dashboard → Comet Cache Pro → Plugin Options → Apache Optimizations → Enforce an Exact Host Name?**. See also: [Issue #101](#101). - **Bug Fix:** Apache detection sometimes inaccurate. So instead of using default WP core globals for server detection, Comet Cache now uses it's own set of Apache/Nginx/IIS detection functions. And, this release enhances our Apache and Nginx detection routines; making them smart enough to catch additional edge cases; i.e., to further reduce the likelihood of there being a false-positive. See [Issue #748](#748). - **Bug Fix:** Some XML-RPC and REST API requests were being cached inadvertently. See [Issue #855](#855). - **Bug Fix:** Broken textarea field due to `white-space:nowrap` in Firefox. See [Issue #866](#866). - **Bug Fix:** This release resolves empty directories being left in the cache folder, in some scenarios. See [Thread #866](https://forums.wpsharks.com/t/cache-folders-not-removed-during-clean-up-process/866). - **Bug Fix** (Pro): Some REST requests were being redirected incorrectly whenever Apache Optimizations were enabled. See [Issue #855](#855). - **Compatibility Bug Fix:** Some Jetpack API calls were being cached inadvertently. See [Issue #855](#855). - **Enhancement:** Notes in HTML source now indicate fully functional on first load for improved clarity. See [Issue #860](#860). - **Code Cleanup:** Enhancing security by removing `basename(__FILE__)` from direct access notices.
Not workingTested using WordPress Version: 4.7.2 Set Steps to reproducePublished a new post, and visited that post as a logged out visitor to generate a new cache file. Create New Test Post Visited the date-based archive view for the post, Archive Updated the published post, and cache files are cleared, the post cache itself, and Home Page cache. Cache Cleared upon updating Post Front End Post Update and Cache Update Observed behavior The post cache file all get cleared as expected, but the date-base archive cache does not. Archive Manually clearing the cache will clear the Archive and generate a new cache upon visit: |
Recording incorrect link formulation found during follow-up tests.
|
Recording correct link formulation after bug fix:
|
- **New Feature:** Comet Cache can now be configured to automatically clear the cache for date-based archive views whenever any single post is cleared due to changes in content, title, etc. See: **Dashboard → Comet Cache → Plugin Options → Automatic Cache Clearing → Auto-Clear "Date-Based Archives" Too?**. See also: [Issue #724](#724). - **New Pro Feature:** Apache Optimizations now include a new option that allows site owners to enforce an exact host name for all requests. See: **Dashboard → Comet Cache Pro → Plugin Options → Apache Optimizations → Enforce an Exact Host Name?**. See also: [Issue #101](#101). - **Bug Fix:** Apache detection sometimes inaccurate. So instead of using default WP core globals for server detection, Comet Cache now uses it's own set of Apache/Nginx/IIS detection functions. And, this release enhances our Apache and Nginx detection routines; making them smart enough to catch additional edge cases; i.e., to further reduce the likelihood of there being a false-positive. See [Issue #748](#748). - **Bug Fix:** Some XML-RPC and REST API requests were being cached inadvertently. See [Issue #855](#855). - **Bug Fix:** Broken textarea field due to `white-space:nowrap` in Firefox. See [Issue #866](#866). - **Bug Fix:** This release resolves empty directories being left in the cache folder, in some scenarios. See [Thread #866](https://forums.wpsharks.com/t/cache-folders-not-removed-during-clean-up-process/866). - **Bug Fix** (Pro): Some REST requests were being redirected incorrectly whenever Apache Optimizations were enabled. See [Issue #855](#855). - **Compatibility Bug Fix:** Some Jetpack API calls were being cached inadvertently. See [Issue #855](#855). - **Enhancement:** Notes in HTML source now indicate fully functional on first load for improved clarity. See [Issue #860](#860). - **Enhancement:** Enhancing security by removing `basename(__FILE__)` from direct access notices.
Comet Cache v170220 has been released and includes changes from this GitHub Issue. See the v170220 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 (#724). |
Steps to reproduce
/%year%/%monthnum%/%postname%/
/2016/03/
to generate a cache file that includes that post.Expected behavior
All cache files associated with the post are cleared, e.g., the post cache itself, and the date-based archive view that includes the post (
/2016/03/
).Observed behavior
The post cache, category archive cache, and tag archive cache files all get cleared as expected, but the date-base archive cache does not. Visiting
/2016/03/
shows an archive view that includes an old copy of the post (because that cache file was never cleared when the post was updated).The text was updated successfully, but these errors were encountered: