cjhaas

We didn’t measure anything, so it is a micro-optimization. And almost all of the hooks registered are in the admin-area, too, whereas the global functions are probably more likely to be used on the public-facing side of things, so an even less of a deal. This just felt like an area that eventually additional future hooks could be added (for whatever reason), so it might be better to nip this in the bud early.

Thanks for taking this on, btw! We loved Fly and we love that this is almost a drop-in replacement for it! And the focal point feature is a really nice addition.

Thanks for your very quick response and resolution!

You use that function, along with fly_get_attachment_image_src and/or fly_get_attachment_image.

We ran into some problems after installing WP Rocket but it turns out it was related to also upgrading jQuery (via https://www.ads-software.com/plugins/wp-jquery-update-test/). After downgrading jQuery to core’s native version that fixed it for us.

We’re seeing the problem, too. The line right above it (305) actually does a proper index check already, that just needs to be unified or copied down.

isset( $plugin_data['slug'] ) ? $plugin_data['slug'] : sanitize_title( $plugin_data['Name'] )

Hi Brian,

We found one bug but we’re not sure exactly if it is your issue. Are you having a problem with the entire cache not clearing when you publish/update a single page? Or is it a single page not being purged when being updated. The latter is the bug that we uncovered and will be supplying a patch for.

If it is the former problem, we’d recommend manually removing the cache folder,
vendi_cache, from your wp-content folder and letting the system recreate. If that fixes it then it is almost definitely a permissions issue. If that doesn’t, could you get me your basic system specs such as PHP version and OS and version?

Thanks,
Chris

Hi Brian, we are still debugging this along with a Divi issue but we should hopefully have something today still.

Thanks,
Chris

Hi Brian, to the best of my knowledge there should be nothing in 4.9 that would affect this but we’ll run some tests and update this thread.

Thanks,
Chris

Hi Tuscanytrace,

Our main goal of the fork was to keep a stable version of what we thought (and still do think) was a simple but effective caching engine. We are working on features on the GitHub repo (https://github.com/vendi-advertising/vendi-wordpress-caching) but we don’t want to force these on everyone so we’re only pushing bug fixes back to the WordPress repo right now. We’ve heard from several people that it just works and they like that so we’re trying to respect that.

That all said, if there is a feature you want or you find a bug by all means we’d be glad to hear about it! The GitHub repo also takes PR’s if you want to send any!

Thanks,
Chris

Hi @magneticeye, when we forked Wordfence’s code we were able to simplify their options away from a dedicated table and into WordPress’s native option system. In theory, changes to their table shouldn’t affect Vendi Cache in any way whatsoever. That said, for compatibility reasons we decided to support their PHP constants (such as WFDONOTCACHE and DONOTCACHEPAGE) and their current code appears to still set these constants under certain circumstances.

But to your question, to the best of my knowledge there shouldn’t be any problems with what you did and since caching is no longer supported by Wordfence it is probably the correct action.

Thanks,
Chris

Hi Doni,

This plugin is still active but we are trying to get a lot more unit tests completed before we start introducing changes. As for multisite, it is still a feature that we’re looking into.

If you want to follow a more recently updated version you can checkout the GitHub repo:

https://github.com/vendi-advertising/vendi-wordpress-caching

Thanks,
Chris

Sorry, I meant to address that but got distracted!

There is a checkbox in the backend that is _not_ checked by default that disables caching for HTTPS sites. As long as that’s checked, there’s nothing else in the code that cares one way or another about HTTP or HTTPS. That checkbox is from before things like Let’s Encrypt became big and is something we’re considering changing for new installs or at least explaining a little better.

I would estimate that about 90% to 95% of the sites that we build and maintain run over HTTPS so we’re very confident that there isn’t an issue there.

Hi @zaewin, I apologize for missing your original post.

The logic for disabling the cache is wired into PHP’s native error/exception handling. If PHP raises an error or throws an exception, even if it is silent, we still disable the cache. At the trap level there’s no filter that we can set so we have to rely on filtering it at the handler level and unfortunately we haven’t had time to look into this further yet. We still recommend looking through your debug logs to see if you’re getting any errors or warnings.

Once we add the capability to cache pages that have silent errors (that phrase still scares me) we’ll let everyone know.

Thanks,
Chris

Hi Jay,

The cache is over-sensitive when it comes to PHP errors. Currently if it detects any PHP error, even a warning, it won’t cache the current request. There was an edge case where someone had a error that didn’t happen too often and was caused by a third-party website but we happened to cache that specific request which resulted in everyone seeing that error message.

We’re planning on addressing the sensitivity soon but I’m 99% certain that this is your problem. Mostly likely there’s some plugin on your site that’s generating a PHP warning which is deactivating the cache for the given request. And most likely that plugin is running on every cache so the cache if effectively disabled.

We’re also thinking about adding logging options to help troubleshoot things but for now if you temporarily set WP_DEBUG to true you should be able to see what’s causing the request to not be cached.

Thanks,
Chris

In the two files you pointed out, to the best of my knowledge the || should be changed to &&.

The left condition is “does that array have that key”. If that’s true the \\ (an OR) would never fire. If that isn’t true, however, then that key doesn’t exist so the second condition will always fail.

Unless I’m reading this wrong, which I’m pretty sure I’m now.