Skip to content

Loading…

"Posts page" cache auto-purged when visiting admin "Add Post/Page" #43

Closed
bridgeport opened this Issue · 14 comments

3 participants

@bridgeport

This is somewhat related to issue #42 which I recently posted about.

The following problem only occurs when the following Quick Cache Pro option is set:
Clearing the Cache > Auto-Purge Designated "Posts Page" Too? > Yes, if any single Post/Page is purged/reset; also purge the "Posts Page".

Let's say I have the following blog "posts pages" cached.

http://www.example.com/blog/
http://www.example.com/blog/page/2/
http://www.example.com/blog/page/3/

When I visit the "Add Post" or "Add Page" portion of the WordPress admin area, it purges the following page from the cache:

http://www.example.com/blog/

It doesn't purge page 2 or 3 from the cache, just the first index page. Keep in mind, I'm not actually adding a page or post. I'm not adding a draft. I'm simply visiting/browsing the add post/page (taking no action) and Quick Cache immediately purges the first posts page and displays the following prompt:

Quick Cache: detected changes. Found cache file(s) for the designated "Posts Page" (auto-purging).

I understand the logic of purging the cache if a post is actually published, but not passively browsing an admin page.

Here's another thing. When I actually did publish a dummy page, it did purge the index page, but not page 2 or 3. Not purging page 2 or 3 is problematic because when a new post is published the last post on page 1 gets clipped instead of rotating to page 2.

If possible, it would be ideal if a newly published post would purge all posts pages (1, 2, 3, etc) instead of just the first.

@raamdev
WebSharks, Inc. member

@bridgeport Could you please update to the just-released v131224 and test this again? I believe this was fixed:

https://github.com/WebSharks/Quick-Cache/releases/tag/131224

Please let me know if this release fixes the issue so that I can close this issue or investigate this bug further. Thank you.

@bridgeport

@raamdev this release does fix the issue of it purging when visiting add post/page. Although, when a draft is saved or updated, it purges the "posts page" (page 1 only), but it doesn't purge the home page. I did test with home page and posts page auto-purge set to true.

@raamdev
WebSharks, Inc. member

@bridgeport That sounds like the expected behavior to me. If you're saving or updating a draft, it makes no sense to clear the Home Page cache, as a draft won't appear on the home page. Am I missing something?

@bridgeport

@raamdev I agree that's the appropriate behavior. I was saying it was good that the homepage cache was not being cleared, but strange that the "posts page" cache was still being cleared, even though it isn't necessary as the draft won't appear on the posts page either.

@raamdev
WebSharks, Inc. member

@bridgeport I'm trying to reproduce this issue, but I've been unsuccessful so far. I tried publishing a new post, visiting that post (to create the cache file), then changing the status of the post from published to draft, and then saving the draft, and no cache is cleared. I'm not see the "Posts Page" cache being cleared when saving as a draft.

Could you please update to the latest version (v140104) and then provide me with exact steps to recreate the issue you're seeing?

@bridgeport

@raamdev The issue persists in the latest version.

Clearing the cache (settings): Yes, if any single Post/Page is purged/reset; also purge the "Posts Page" (enabled).

The issue does not occur on when that setting is set to "No."

Steps to reproduce:
1) Go to "posts page" to create cache of page
2) Within admin area, go to "Add New Post" page, then "Save Draft."
3) The previously created "posts page" cache is purged.

I've been testing on a Windows development server replicating the live environment.

It's not a huge issue for me as I don't publish frequently and I could always disable that particular setting. It was more of an FYI report.

@raamdev
WebSharks, Inc. member

@bridgeport I have confirmed this unexpected behavior and I will get this fixed.

@raamdev raamdev added this to the Next release milestone
@raamdev
WebSharks, Inc. member

Confirmed this bug still exists in trunk as of today, even after the cache structure rewrite. I was able to reproduce the issue using the steps @bridgeport describes above. Clicking "Save Draft" incorrectly clears not just the Posts Page cache, but also the Home Page cache.

screen shot 2014-04-18 at 1 40 46 pm

This should definitely not be happening, as the post has not been published but has only been saved as a draft.

Adding this bug to the Next Release milestone.

@raamdev raamdev self-assigned this
@raamdev
WebSharks, Inc. member

@JasWSInc If you have a moment, I'd like to get your thoughts on how this bug can be fixed. (I consider this a bug because cache files are being cleared unnecessarily.)

The problem here is that auto_purge_post_cache() attaches to the save_post hook, which fires even when saving a post as Draft. Checking the post status before purging the cache isn't enough though, because if the post's status was going from Published -> Draft, we would want the relevant cache files to be cleared.

I'm thinking the best solution would be to modify auto_purge_post_cache() so that it includes an extra parameter (public function auto_purge_post_cache($id, $purge_draft=false)) and then add a new subroutine that attaches to the transition_post_status hook and specifically looks for the scenario where a post is being transitioned from Published -> Draft, and then calls auto_purge_post_cache($id, $purge_draft=true) to purge the cache as usual.

Thoughts?

@raamdev
WebSharks, Inc. member

Actually, I just realized there are several other scenarios that need to be considered here as well:

Saving as these post statuses, regardless of current post status, should trigger auto_purge_post_cache():

  • publish
  • private
  • trash

Transitioning from a publish or private status to any of these statuses should also trigger auto_purge_post_cache():

  • draft
  • future
  • private

See also: get_post_status() Return Values.

@jaswsinc
WebSharks, Inc. member

I'm thinking the best solution would be to modify auto_purge_post_cache() so that it includes an extra parameter (public function auto_purge_post_cache($id, $purge_draft=false)) and then add a new subroutine that attaches to the transition_post_status

I agree, that sounds like a good idea to me.

See also: get_post_status() Return Values.

I think this could be tricky. There are also custom post statuses that we might need to consider.
http://codex.wordpress.org/Function_Reference/register_post_status


I noticed there are several other hooks in the wp_insert_post() function. Of the ones I just reviewed, this one in particular might help us out; maybe. See post_updated where you get the $post_before and $post_after.

Note also that we currently are not taking full advantage of all that save_post has to offer. There is an $update flag that we could look for that would tell us if it's a new post or being updated. Not sure how much that helps, just thinking this through with you at the moment.

@raamdev
WebSharks, Inc. member

I think this could be tricky. There are also custom post statuses that we might need to consider.

I think that's fine. If we want to introduce a Pro feature that allows a site-owner to specify custom post statuses that should be cleared, we can do that later on. I'm not sure there is any way for us to predict what custom post statuses might exist and what those might even mean with regards to purging the cache.

I noticed there are several other hooks in the wp_insert_post() function. Of the ones I just reviewed, this one in particular might help us out; maybe. See post_updated where you get the $post_before and $post_after.

I saw that too, but if all we're going to be doing is comparing the $post->post_status values, using the transition_post_status hook seems far more elegant (as we get only the data we actually need).

I'm almost done implementing the code for this and so far in my tests it works well. I'll submit a Pull Request shortly for review.

@raamdev raamdev added a commit that referenced this issue
@raamdev raamdev Fix bug in auto_purge_post_cache() that purged the cache unnecessarily
- Previously purged on most statuses, including saving as `draft`. Now only purges post status `publish` and `private`
- Also purges when transitioning from `publish` or `private` post status to `draft`, `future`, or `private`.

See websharks/zencache#43
1a0634b
@raamdev
WebSharks, Inc. member

@JasWSInc I submitted Pull Request #122 for review.

@raamdev raamdev added a commit to websharks/zencache-pro that referenced this issue
@raamdev raamdev Fix bug in auto_purge_post_cache() that purged the cache unnecessarily
- Previously purged on most statuses, including saving as `draft`. Now only purges post status `publish` and `private`
- Also purges when transitioning from `publish` or `private` post status to `draft`, `future`, or `private`.
- Cache get_post_status(), use strict post status comparison, and clean things up.

See websharks/zencache#43
8833a04
@raamdev
WebSharks, Inc. member

This issue has been fixed by #122 and will go out with the next release.

@raamdev raamdev closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.