Fairly new to Fastly. Trying to help someone who is using your service with the Fastly WordPress plugin.
Is there a way to view a log of purge requests a fastly service has received?
Fastly service ID and token are saved, and “Test Connection” succeeds. The VCL has also been updated and activated (and verified in the fastly console).
After a site user updates content on the page, viewing the page in a fresh browser still shows the stale content. If I enable Log purges in error log in the fastly plugin, and I tail the log file, I can see the purge request even occur from the WordPress side once they save the changes. However, viewing the page in a fresh browser instance shows the stale content, and curl’ing the page shows HIT.
If instead I go to the Advanced admin panel for the plugin and do a “purge by URL” for the page, I can see the request in the error log AND viewing the page in a fresh browser shows the updated content.
I’d like to match up the request in the error log when saving a page with a log on the Fastly side to verify it’s receiving the Purge request to help figure out why “stale” content is being served.
Hey @gilzow we only have event logs for purge all events, though I think what you’re wanting to investigate here are single URL or a surrogate key purges. Those purge events aren’t logged in our system due to the volume we receive and process every second across the network.
Based on some past reports I’ve seen over the years, I’d like to rule out any underlying configuration issues. When you test purging a single URL on your site via curl, does the object clear? Purging | Fastly Documentation
Yes. And i think I’ve figured out what is happening.
The user makes a change to the page/post, then saves/publishes the page/post. They then visit the page/post in a private/incognito browser (or one that has never visited the page) and they see the “old” content. Based on the description of the plugin:
Using this plugin means you won’t have to purge content in Fastly when you make changes to your WordPress content. Purges will automatically happen with no need for manual intervention.
The user then concludes that the plugin isn’t working because they’re still seeing the old content.
What is actually happening is that the cache is being purged, but the first request after the PURGE is issued is serving stale content while Fastly retrieves a fresh copy. The end user doesn’t see a notification in the browser that they were served stale content so assumes caching is not working. If I have them do a page refresh after initially seeing the stale content, they then receive the updated content.
I think it was a misunderstanding of what was happening and therefore, incorrect expectations.