Ethan Kennedy

I no longer work at WP Engine, so I am not sure if anything has changed with their cache config that would inform any issues with the plugin.

There haven’t been any changes I am aware of that would cause any issues. I just haven’t bumped the version, but I can.

Optimally WP Engine would maintain this, I’d recommend letting them know your concerns given their recommendations in their documentation.

There are also a couple forks of the GitHub repo that have more features and changes than my latest. This one looks like some good work was done, but definitely check and confirm before using https://github.com/DevskillerTech/wpe-advanced-cache

Yeah, I used to work at WP Engine but have since moved on. They are unfortunately mistaken, the plugin isn’t able to alter headers on anything that isn’t rendered by WordPress directly. Since images are served by Nginx in their stack, the plugin code is not run.

The static assets served by WP Engine should have headers set to 1 year currently, so those headers should be there currently. WP Engine sets max-age headers instead of expires headers, which take precedence over expires anyway.

If you look at the headers on any of your images, you should see something like:
cache-control: public, max-age=31536000 in the response headers like you see here:
https://wpengine.com/wp-content/uploads/2020/11/WPE-Photo-YoungPeopleOnPhones-800×540-1.jpg.webp

If the cache control headers and max-age are present, I would disregard the plugin warning since the cache will be maintained for a year. If not, I would follow up with WP Engine for possible solutions for altering headers on your static files.

Unfortunately the plugin doesn’t interact with static files, so you’d need to have the headers set in another way.

WP Engine should be able to help you set the headers, or I’d recommend something like a Page Rule at Cloudflare to set the expiry headers, and cache the content for a longer period of time.

You could write a cron job to clear the cache using the method I use in this plugin, but it’s not something I plan on adding unfortunately.

Hey!

That would be correct, the plugin is set up to look only for pages/posts that are set up as post types in WordPress so custom pages won’t work.

It’s not a priority at the moment, I had some ideas to add the ability to add a list to the plugin of custom URLs but I am concerned with the possible performance implications that could have.

Nope! I think that would work fine. Depending on how the page is rendering, you could probably just rip out the portion that sets the header on a hook and set it. If you want to hardcode it you could even do it on https://codex.www.ads-software.com/Plugin_API/Action_Reference/send_headers . The only reason I use the hook I do is because I am relying on the WordPress object to be loaded to identify the post type, so if you’re relying on some custom logic requiring database information then send headers probably won’t work.

I’d probably just set the header in the template file personally unless there is a need to customize it more than once. https://github.com/EthanKennedy/wpe-advanced-cache/blob/master/inc/wpeac-core.php#L106, so just hard linking a value instead of using the variable should do a similar job.

I hope that helps! I’d also recommend something like a CDN if these pages are static. CloudFlare or fastly could help take some load off the backend, and with pagerules you could cache them basically forever.

Hey! Just to follow up on this one, WP Engine pushed through a change to update all statics to be cached for a year, so you should start seeing those benefits super soon.

Hey!

The cache time on statics are dictated by rules in the Nginx config at WP Engine that the plugin doesn’t control, I’ll raise that feedback though!

The plugin’s options have the option to increase the cache time for posts, which should be dynamic in this case, to about a month. I’ll consider adding an option for a year though. The plugin can meet the need for “everything else” in the settings page.

Let me know if you have any other questions.

Hey!

What changed between it working and not working? Did you add the plugin and that is what made the media library stop responding?

I’d love to know more so I can get to the bottom of what could have caused the issue.

Thanks!

Yeah!

For the average person just using WordPress as a front end it probably won’t make a difference, but if you’re using the APIs to pull content into a headless frontend or something like that, increasing the cache of those endpoints is super important.

The APIs are just like the concentrated version of your site’s content, so it makes even less sense to cache them for only a short amount of time, especially when they could theoretically do a lot of concurrency. In most cases it’s probably better to think of the posts/page cache and the APIs as an or solution instead of an and, since you’re probably only going to be getting the benefit out of one or another at any point.

I am really excited about WordPress as a headless CMS, so allowing customization to the rest routes allows the plugin to be feature forward for something I am hoping takes off in the future.

That sounds like it probably is cloudflare if I’d have to guess, their plugin has the ability to kill the cache when the “appearance of the site changes”, so I’d try that and see if it helps with the stale content. Also try an incognito tab to make sure it isn’t chrome caching it if you haven’t already.

It does work for custom post types, but not rest routes. The cache for the routes is killed on updates too, so I don’t think it’d get much of a benefit outside of the normal cache increases. I’ll keep it in mind when I revisit that stuff though in the future.

Thank you! I appreciate the feedback! There are some more things coming down the pipeline at WP Engine that will impact performance that I am looking forward to, so hopefully you’ll get to take advantage of those.

I do understand the use case here, and it is something I would hope to implement for another reason in the future. In some themes the homepage isn’t associated with a post type, so the plugin never picks it up, so it defaults to 10 minutes. That would be a big use case for being about to increase the cache time, in addition to this one here.

That said, when a post or page is created, the homepage is purged as part of that function, so if there is a feed or anything like that on the homepage, it should be getting the updated content. This would allow you to leverage the longer cache time while also getting that content live on the homepage that much faster.

Another option would be the “Smarter Cache” option and a smaller time. If the other pages aren’t updated, it’ll start setting the cache times to 6 months but won’t touch anything that’s been updated more recently.

Let me know if you’re seeing any challenges with either of those options, and I can see what I can do to help.

Thanks!

Hey Vladimir!

Unfortunately, as those assets are served from the server on Nginx, the plugin isn’t able to manipulate the headers displayed to the end user.

CDN assets are by default stored for 24 hour hours, and I believe the browser should be expiring the images based on the last modified value included in the response header.

Turning up the cache on the CDN should be possible in a request to support (or maybe it could be something WP Engine should just do), but the browser should store those images until that last modified date is updated.

If you’re looking to invalidate the cache, I’d recommend tagging files you want to change with a version, like “?v1” at the end of the url, since that will break the cache and force both the browser and CDN to revalidate the asset. Otherwise, they should update eventually as the CDN picks up the new version, and the browser sees the last modified change.

I see, My apologies, I assumed the editor could see the plugin page, which they can’t.

The possible abuse would be from someone purging the cache too much, which can cause a load on the site. I don’t think I’d be too worried about it from a one off, but making it a global option could be a concern for other users of the plugin. This is my understanding of why the options is locked down to Administrators.

This seems like something the WP Engine plugin should do, that is exacerbated by the increased cache time. Since the WP Engine plugin doesn’t allow it, I kind of feel like I shouldn’t overwrite those wishes. I’ll bring it up the next time we revisit the Varnish configuration.

Hey!

Thank you for the feedback, it’s super helpful!

I definitely see the need in allowing the option moving forward, but I am a little apprehensive since the plugin isn’t gated to specific selectable user roles at this point in time. I think that functionality would be required before I start adding things explicitly meant to drop all caches on the site, especially since it’s something the WP Engine plugin requires administrator usage for. I’m a little nervous about possible abuse, so I’d want to have the ability to restrict access before adding it. I am not opposed to that change, I just don’t know when I’d be able to get it implemented.

That said, the varnish cache can be dropped using the “Purge Path” option for the entire site. When a “/” is entered into the box, it regex matches all paths for the site and clears it. This would be a work around in this case for this unless object cache needs to be purged as well.

Do you have anymore detail on what sort of changes are being made? Are these theme updates, or anything of that nature? If this is part of a pretty typical workflow, it might be something WP Engine could do automatically.

Thanks!

Hey!

I haven’t seen something like this occur, but it seems like something that might be more specific to an issue in wordpress not just this plugin. Does it occur when activating anything else, or just this plugin?

If it’s just this one, could you remove the plugin entirely and try to redownload it? Also maybe run a permissions fix on your install, and ensure there aren’t any readonly tags in your wp-config?