Llewen

In answer to your earlier question, all my plugins are up to date with the latest available from WP.

That’s the basic issue, I’m using PHP 8.1, not PHP 8.0. I foolishly assumed there would be nothing major code breaking between PHP 8.0 and PHP 8.1. But it would appear that there is. So the thread isn’t named properly, it should be PHP 8.1, not PHP 8…

I don’t know, but imagick is a required plugin for WordPress, and it is missing, so I’m guessing that is the issue. If not then it is an SQL syntax error that 8.1 is catching that 8.0 didn’t.

I’m going to try php8.0. The imagick plugins is available for php8.0.

Getting a little frustrated. My apologies. The problem is that Debian support, even on Debian Testing, isn’t full featured for PHP 8.1. The imagick module for PHP 8.1 hasn’t yet been released.

This is clearly an error with this plugin. The only question is why you aren’t seeing it.

The error is in the mysqli syntax. mysqli is the PHP MySQL module, which should be compatible with both MySQL and MariaDB.

I was able to figure out what the issue was that was causing serious problems with my WordPress installation. I had changed the server signature as a joke using Mod Security, however, the joke backfired. I didn’t realize that the WordPress “$is_apache” variable, and who knows what else, uses the server signature to allow plugins to make accommodations for different webserver software.

So I’ve fixed that, but the problem that I reported in this thread remains. I re-enabled PHP 8.1 and encountered the same error.

Ya, that was it. Thanks for your help. I’m not sure why disabling modsecurity didn’t also disable that, but it didn’t. That was also the reason for a lot of the other issues I’ve been having with WordPress. Lesson learned.

I think I figured it out. My little joke backfired on me. Changing the server string messed up the contents of the “$is_apache” variable. That might well be why a bunch of other things that I’ve never been able to figure out are broken in my WordPress. I’ll post back when I know for sure.

I double checked the documentation. That function doesn’t appear have any specific scope, so it should run on any page, and it returned false no matter what page I ran it on, no matter what data I fed it.

I’m not really good with WordPress or with PHP, so this was a bit of fun, but as far as I can see, unless I am running into permissions issues, apache_mod_loaded always returns FALSE.

I ran this code on various bits of the admin page, using different mod names and just a random string, and it always returned FALSE. But perhaps I was just plugging it into the wrong place. I’m a hack when it comes to scripting. I’m not really skilled.

<div>
<?php
if ( apache_mod_loaded( 'mod_rewrite' ) ) {
    echo "TRUE";
} else {
    echo "FALSE";
}
?>
</div>

Just to be double sure, I disabled modsecurity entirely, and encountered the same error.

On the off chance that you think Mod Security is the issue, I have attempted to disable it, to no effect.

The “Microsoft IIS 5.0” is my little joke on hackers attempting to hack the website…