digitalpoint

Not sure where we are supposed to disclose it other than the standard minimum PHP version needed. But yes, it works with any version of PHP 5.4.0 or higher (including as far as the latest branch PHP 8.5.x).

• This reply was modified 1 week, 2 days ago by digitalpoint.

In that context, “name” is the site title. Specifically, in your WordPress admin area, make sure that Site Title isn’t blank (under Admin -> Settings -> General).

If it’s blank, set something there and the error should go away (on my end it probably makes sense to throw a more understandable error to the user). 🙂

While I too, find all the size variations that WordPress generates annoying, honestly that’s a different thing (and just deleting them all could cause problems with themes that expect them to be there). This plugin isn’t intended to be an all inclusive solution to everything related to images. I imagine there’s already something out there that does it already (I don’t actually know, but I would think so)?

Building a separate backup location just opens up a lot potential problems. Doing it the way it’s currently done (with a special image variation) allows other plugins to keep working as expected. An example of this is the backup can automatically be stored in the cloud with R2 if you use my Cloudflare plugin (allows you to store media in the cloud) without plugins needing to change things to then also manage a special custom backup location. It could in theory be done, but you are introducing a lot of extra complexity and you would lose the ability for third-party plugins to work with the custom backup location without them changing their code.

Doing it as it’s done (as a WordPress variation of the image), other things like deletions (even if doing something with a different plugin, like storing them in the cloud) is automatic.

TL;DR: I’m trying to keep it simple and efficient as well as using things (like image variations for backups) so it all works as expected even with third-party plugins.

There’s a fine line between simplicity and functional overload. So rather than add a ton of things right out of the gate, I wanted to see what real users wanted vs. what I personally thought might be useful.

Keeping an internal backup variation is one of the things I thought might be useful, but wanted to see if anyone else thought the same. Part of me didn’t like storing the original since it’s potentially a much larger file/different format (it could eat a lot of storage space if someone has a ton of images). I also don’t love that WordPress’s media variations are all publicly accessible if someone knows the URL, so it would allow a smart malicious user to pull non-watermarked versions of images).

So ya… that was the reasoning about not having it right on day 1.

Thanks for the feedback, it’s much appreciated. Just to clarify, the Pro version is a perpetual license (meaning it continues to work indefinitely without additional annual [or any other] payment). Say 5 years down the road, there’s some new fantastic feature you can’t live without, you can get another year of updates (which is also discounted for existing licenses).

TL;DR: the Pro version will work indefinitely with a single purchase.

Nothing should have changed recently as far as Turnstile goes. Just to be extra sure, I logged out of a bunch of sites to test logging in with Turnstile via this plugin, and all worked fine/as expected. Turnstile itself is fairly simple underneath it all. It basically comes down to a value being passed with the form, so if something is blocking/filtering that value (or causing it to never be generated), it would be an issue.

Are you running anything that could be blocking it within your browser (for example privacy/ad blockers)?

A couple thoughts I had this morning…

Excluding the specific paths shouldn’t be necessary. The Cache Rule just makes requests “eligible” (it’s not a forced cache situation). There’s still server-side code/logic in the plugin that still makes the actual decision to cache. The admin pages don’t even run the logic code since they should never be cached (something is only cached if the logic runs and decides it should be cached). Additionally, a “page” is only cached if it has a content type of “text/html”, so that makes the json endpoint not cacheable by default as well.

Also, the next version of this plugin has a WordPress filter that allows third-party plugins to alter the caching criteria when it builds the Cache Rule.

public function pageCachingCriteria()
{
	return apply_filters ('cloudflare_guest_page_cacheable', [
		'not http.cookie contains "wp-"',
		'not http.cookie contains "wordpress_"',
		'not http.cookie contains "comment_"',
		'not http.cookie contains "woocommerce_"',
		'not http.request.uri.path contains "/wp-login.php"',
	]);
}

While that was done to allow third-party plugins to add whatever custom cookies they might use, there’s nothing preventing you could leveraging the upcoming cloudflare_guest_page_cacheable filter to make changes to the criteria automatically (depending on how technical you are). That’s going to be the better approach in the end because the server-side/plugin logic also uses that.

Maybe… I don’t see anything from skimming the code, but I didn’t go so far as to install it. Either way, the underlying issue does seem to only be an issue with some combination of multiple other plugins installed. One is making all notices dismissible, and the other is then hiding dismissible notices.