Open simonwistow opened 8 years ago
Hey @simonwistow!
Thanks for the PR. As I've walked through this code and thought some more about the problem, I would like to suggest a different direction.
Let me give a little background on this to contextualize what I will propose. Fastly is a bit of a unique snowflake in its ability to "tag" cached objects with the surrogate keys. As you know, this is a powerful feature, but has not often been a mechanism that people get to use to purge caches.
When I initially began work on this plugin, I did not take advantage of surrogate keys. I used a different mechanism for "group" purges. In the Purgely_Related_Urls
class, one can feed in a post identifier (id, $post
object, or URL) and get back a list of URLs that are likely to be related to the post passed in. For instance, it would give you the URL for the term pages, author pages, and feeds in which the post is or should be on. These URLs can then be used to purge each of these URLs individually. Currently, this method is only used in the CLI when the related
parameter is passed.
Reviewing this now, the Purgely_Related_Urls
functionality has a slight advantage over the surrogate key purges in that it can predict where content should be after it is finally published. With surrogate keys, content is only grouped after it is published. That said, it only has this advantage because of deficients in the way I've implemented surrogate key purges. Specifically, I'm only looking to do one surrogate key purge per post save. In retrospect, this is shortsighted.
I went back over the primary page types to see what we would be able to purge, specifically in the case of when a new piece of content published, using our two types of purging: Surrogate Keys and Related URL purging (i.e., purging a list of URLs). Here's what I found:
Page Type | Surrogate Key | Purgely_Related_Urls |
---|---|---|
Home | ✅ | ✅ |
Post | ✅ | ✅ |
Term | ✅ | ✅ |
Author | ✅ | ✅ |
Feed | ✅ | ✅ |
Post Type Archive | ✅ | ✅ |
So...the results are the same! There is no reason we cannot purge the same (and even more content) with surrogate keys. The difference is that we need to change our strategy for how we do purges when we publish content for the first time. The big difference is that content should have the post ID surrogate keys once published; however, when new content is published that is not the case. As such, when new content is published, we need to find all of the related surrogate keys and purge them.
What I envision is something like the Purgely_Related_Urls
class (say, Purgely_Related_Surrogate_Keys
) that identifies surrogate keys related to the post (e.g., because post 5 has category 10, the category-10
surrogate needs to be purged) and purges those keys. I'd imagine that we have a different purging strategy if the current post is moving from draft
/ future
status to publish
, than if it is moving from publish
to publish
(i.e., being updated after being published).
So, the main issue with the current patch is that it only addresses a portion of the issue, not the whole problem. I think the bug has uncovered a bigger problem that needs to be addressed.
I also think two changes will help this process:
Fortunately, this problem is related to some purging issues that we are experiencing on WIRED right now. I'm hopeful that I can land these changes as part of fixing the WIRED bug.
In the meantime, I can can give you some very simple code that your customers can use to purge the home page when a new post is published. I think that was the original problem and it's a quick fix with a few lines of custom code.
Purge the front page when a new post is created.
Purge the parent id if the post is a revision.
Fixes #27