Fix purging of front page

[simonwistow]

Purge the front page when a new post is created.

Purge the parent id if the post is a revision.

Fixes #27

[coveralls]

Coverage remained the same at 100.0% when pulling 020b84a on fastly:fix-purging-of-front-page into 0f48431 on CondeNast:master.

[tollmanz]

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:

1. WordPress 4.6 is on track to introduce a major change to its HTTP request API; it will introduce the ability to issue parallel requests, which theoretically allows this solution to scale as we won't need to make a ton of serialized requests.
2. Fastly needs the ability to purge multiple surrogates with a single request. @simonwistow and I have discussed this possibility.

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.