Ethan Kennedy

Hey!

Unfortunately the cache purging functionality is specific to WP Engine, and the varnish cache there. The headers work on other hosts, but otherwise the stuff actually purging is specific to WPE.

The functionality would be specific to the cache implementation and the functionality there. In varnish it can be purged by sending an http request to the backend with specific information. This can be written as a plugin and can be called with various hooks (new post is a specific on WP Engine uses). The others would really boil down to implementation more than anything.

Last-Modified headers can help with browser caching, as long as your new posts update that last modified value. My plugin does do this on any host.

Browser cache for statics is tricky, but version tagging them is a good solution there. This will change the URL, so it’ll be a whole new object for the browser to cache, and will force the browser to pick up the new content. Here is a good post about it https://www.theasta.net/blog/2014/11/04/Versioning-JavaScript-and-CSS-files-while-improving-page-load-time/ .

Logged-In users generally shouldn’t be cached, but fragment caching is something worth looking into: https://css-tricks.com/wordpress-fragment-caching-revisited/ .

I hope some of this information is helpful. If you do try out the plugin for last modified headers, let me know if anything behaves unexpectedly. The plugin is written and tested on WP Engine specifically, so I don’t have much insight on other hosts.

Thanks!

Hey Christopher!

1) It does, but in my experience it doesn’t affect content nearly as often as it does static assets, which the plugin doesn’t control. Last-Modified headers can also ensure this behavior as it’ll add a header that the browser then uses to know for sure if the content has changed or not. I am unfortunately a lot less well versed in browser cache behavior, but this has been my experience when troubleshooting. Let me know if it differs from yours.

2) That is not controlled by the plugin, the plugin just deals with Cache Control and Last Modified headers. Those headers are set to make sure all browsers don’t cache responses when WordPress doesn’t want it to. You can see that method here: https://developer.www.ads-software.com/reference/functions/wp_get_nocache_headers/ (It’s also Matt Mullenweg’s Birthday)

I don’t respect those headers on posts in the current version when logged in, which can lead to some browser weirdness, but I will push an update to fix that in the very near future. (I was only thinking about varnish when I wrote it originally)

3) That is also something set in the Varnish configuration, and not something that has introduced any weird behavior I have known of. It gets set in the varnish config to provide more information around what part of the config it’s ran through in my understanding.

It’s possible that is the case, in a lot of cases a site can be faster on mobile because it’s loading less content. I would recommend using webpagetest.org to get a better perspective though. In the advanced settings I’d recommend no traffic shaping, and at least 3 runs (makes sure you get a good picture of cache). In the other tabs you can alter it to replicate a mobile browser. That will show you the performance differences in a nice waterfall chart.

Hey Christopher!

The 1 hour times are defaults, and are set when the plugin is installed, so those are the current cache times. They can be dropped to 10 minutes (which is the WPE default), or increased to however long you’d like. I’d recommend however long you feel comfortable with, the longer the cache the less the site hits the back end.

WP Engine has built in cache purges associated with updates, so in the case of the smarter cache, the Varnish cache would be purged and new content would be displayed to users. This would be the case for any extended cache time. The only thing to look out for would be more organic changes not associated with a post update, like maybe side bars or headers, but in those cases it’d be a good call to just go ahead and purge everything using the button in the WP Engine dashboard.

Let me know if you have any other questions, thanks so much for trying the plugin out!

Hey!

I am not aware of any issues with CloudFlare caching in respect to the plugin. CloudFlare should handle all of their caching headers on their end and treat any other headers passed from the origin as it normally would.

If you do see any unexpected behaviors, please let me know and I can take a look.

After sleeping on this, the above solution isn’t a good option since it breaks the Ajax functionality on the backend.

I am not completely sure why creating the class on ajax calls is breaking that upload functionality, but I’ll continue seeing if there is anything else that stands out.

Hey Iain,

I think I figured it out. It looks to be due to the plugin building out the admin class on admin-ajax hits.

Updating this line to check if it’s an admin hit but not an admin ajax hit seemed solve the problem, which makes sense to me.

https://github.com/EthanKennedy/wpe-advanced-cache/blob/master/wpe-advanced-cache.php#L16

I’ll run it by Steven and see what I can do to get an update out to prevent this sort of thing from occurring.

Hey Iain,

I was able to find the chat, I should have said install name, my mistake.

I’ll take a look now and see what I can find.

Hey Iain,

These are all things that occur on the admin portal correct? Nothing that would be a front end user?

Are there any warnings or errors being reported in the logs on the site with the plugin enabled?

If possible, could you provide me with the install ID of the WP Engine installation? I should be able to dig in some more with that if that is okay. If you’d prefer you can provide me that information in an email.

Hey!

I think that is a different issue than the one initially addressed here. If you could go ahead and open a new thread that would be awesome! I haven’t heard any similar reports around the plugin, but I am happy to dig in and see what might be causing it.

Hey Fahmi!

I apologize for the delay in getting this done. This functionality has been added as part of the 1.3.0 update as previously stated.

If you see anything not behaving as expected, or have any other requests, please do not hesitate to let me know!

Thanks!

Hey!

Thank you for your patience on this, I apologize for the delay in getting the update pushed.

1.3.0 should take care of the issue you were having. If you see anything else strange while using the plugin, please do not hesitate to let me know.

Hey!

The update was just pushed to the plugin, which should take care of the issues you’re seeing in WooCommerce.

If you could go ahead and try it out, let me know if you see any strange behavior and I can go ahead and take a look.

Again, I apologize for the delay in getting that out. Thank you!

Hey!

We’re taking another approach to how one of the core functionalities of the purge path function works, which is the main feature of the 1.3 update, so it’s delaying it a little bit. We’re meeting again to discuss the implementation I have written, and I hope to have the update pushed on Thursday.

I am really sorry about the delay on this, I am definitely learning a lesson about workflow, and really should have pushed the bug fixes as minor versions to 1.2 before working on adding features.

I will go ahead and follow up as soon as that update has been processed.

Hey!

That is great to hear! Barring any feedback Steven has on the update, it should hopefully go out next Monday.

Hey!

There isn’t currently a way to manage exemptions through the plugin, since the exemptions take place on the Nginx layer on WP Engine’s side.

Those issues are something that is reported and addressed in version 1.3. I am hoping to have that updated and deployed in the very near future. The headers I added on the Cart and Checkout pages mess with the browser’s cache and lead to those issues in the other times I have seen this problem.

I’ll get that update out, and follow up to see if you’re seeing the same issues. I’d recommend leaving the plugin disabled in the meantime.