David Adams

For the benefit of others reading this thread, this issue turned out to be caused by a now confirmed bug with the Imagify plugin in that, when the ‘Resize to’ option is selected, Imagify is using the original image size to assess whether the file is <2MB (restriction of the Starter Plan) and not the actual file being converted to WebP i.e. the resized image.

This has been logged in their development system here: https://github.com/wp-media/imagify-plugin/issues/521

Until this bug is resolved, original image sizes must be <2MB irrespective of how big the actual image being converted is.

David.

Your last comment was a link to an article that CF7 supports spam modules, and this is not relevant because none of those modules are installed.

I have asked three times now if there any debugging features within for CF7.

David.

Neither Akismet, reCAPCHA or disallowed list are installed on this website, in fact it’s on my to-do list to install them.

This is clearly nothing obvious, otherwise you would know what is causing this. Does CF7 have a debugging feature?

David.

@sterndata Noted.

https://paragondrones.co.uk/contact-drone-services-kent/

[redacted]

David.

• This reply was modified 2 years, 8 months ago by Steven Stern (sterndata).
• This reply was modified 2 years, 8 months ago by Steven Stern (sterndata).

@diondesigns Might have found a workaround to implementing your solution. Flywheel allows its customers to create redirects via their admin portal/dashboard feature. So I should be able to use that to redirect ./feed/ to the homepage.

No WordPress needed here and, perhaps waaaay more importantly, no wp_die() either! ??

Thanks for your help, guys. Genuinely appreciated.

David.

@sterndata Yes, that’s exactly what I want, and exactly what I am not getting.

I think confusion is creeping in on exactly how $string is outputted – but we both agree that it should be, right? My understanding is that it is output in a HTML page like the one towards the bottom of the article you linked me to. All I’m getting is some knarley XML tree.

Are we now on the same page?

OK, well, I’m sorry to have bothered you, @sterndata . Looks like this one is just beyond my capability to understand. I’m not the brightest spark. Thank you for your input on this.

David.

@sterndata According to the WordPress developer reference (https://developer.www.ads-software.com/reference/functions/wp_die/), the difference between the die() and wp_die() functions is that the latter renders a HTML page with an error message and allows for a customisable response code prior to calling die().

I am not a developer, not even close, but it seems that WordPress is supposed to be doing one thing, but is actually doing something else. Can we agree on that?

David.

Agreed that the ‘404 solution’ (Method 1) is an option, and maybe even a better one.

I’m trying to follow a ‘minimal code’ principle with this website (cyber security is a big deal for this company) and adding a plugin with lots more code than I actually need is contrary to that principle. Method 2, therefore, was the preferred solution and in that very article towards the bottom it shows the pretty HTML page I’m supposed to get when using the wp_die() function … I’m just not getting that and have no idea why.

Has the wp_die() function changed recently? Am implementing it incorrectly?

I’m on v5.9.2 of WordPress.

David.

For the benefit of others reading this thread, in our offline correspondence we determined that in this case the index.php error is a red-herring and the root cause was because the original image file was >2MB, which, although not mentioned anywhere in your documentation, is a limitation of the free edition of your plugin, presumably in addition to the 20MB per month total processing cap.

Original images <2MB are processed correctly.

David.

@diondesigns A valid point and, as you say, would require fewer server resources, but unfortunately not all website hosting providers provide access to the root .htaccess file (e.g. Flywheel). Unfortunately, I’m stuck with WordPress functions.

But anyway, my query was more about why wp_die() wasn’t rendering the pretty HTML page I’ve seen on so many articles. I even tried creating a fresh Local site and received the same knarley XML tree page. Just feel like I’m missing something.

David.

@sterndata Interesting, I actually used that article as the basis for my code.

David.

Loanna,

Which index.php file does this error relate to? I have checked the directory the image file itself is contained in (./wp-content/uploads/2022/03/test1-scaled.jpg), and there is no index.php file in there. Traversing back, the first index.php I come across is in the ./wp-content directory and there is also one at the website root.

See screenshot: https://i.imgur.com/gjbT5UT.png

And just to your point, “so Imagify can write newly optimized images and backup images to their proper locations on your server“, the existence of test1-scaled.jpg and test.jpg in your backup folder proves that your application has the correct level of file system access. The only issue we seem to be having here is the creation of WebP format files, which is consistent with the single log failure.

David.

Loanna,

[redacted by moderator]

David.

• This reply was modified 2 years, 8 months ago by Steven Stern (sterndata).