Open orenwolf opened 8 years ago
Hi @orenwolf!
This is a really interesting problem. I'm not sure what the right answer is, but let's talk this out a little bit.
Purgely manages invalidation and purging that is common to most WP sites with the ability to customize as needed through useful APIs.
When it comes to static files, WP has limited abilities. There are a few issues:
My rule of thumb with changing assets is to change the asset name (or append a version query string to the end) in order to fully purge the asset at every layer, including the browser. This allows me to set far future expiration headers for these assets. So, I think that purging the assets via Fastly is only half of the issue.
So...this isn't a well thought out response, but just me thinking through some of the initial concerns. I think we have the potential to do something cool here because even though your setup might be unique, purging wp-content/uploads
files could be really helpful for everyone.
Hello,
Thanks for modernizing the Fastly purge plugin infrastructure :)
We have a slightly unique setup - files within wp-content/ are served from a different fastly service (one tuned to static files, without all the VCL overrides for logged-in users and such). Most of these files, of course, are not added by wordpress, and likely do not get purged by wordpress as a result (with perhaps the exception of editing templates? We don't do that from the GUI so I'm not sure).
However, the one thing that is affected by wordpress is wp-content/uploads. If someone changes content there, we'd love to purge it by a different service ID.
I think the best way to handle this is probably one of two options: a separate option for purging uploads (and perhaps template files), if they are treated uniquely in wordpress itself, or, an option to change the service ID based on the url passed back by WP when you are gathering objects to purge?
Thanks!