Support

We had to include the legacy PHPmailer files instead of using their modern versions because a certain third party plugin was badly written and these people were falsely blaming us for "breaking their plugin" when it was, in fact, their own incompetence (they were relying in PHP's require_once to not include the same class twice instead of using class_exists). The downside is, of course, that WordPress emits a user warning message when these old files are included by a plugin.

This is normally not an issue on a properly configured production server. Anything below a stop error (E_ERROR) is not reported in the browser output, and actual stop errors are caught by WordPress itself. The user warnings are simply not output; they are only logged.

It is a problem in a server configuration like yours where the PHP error reporting level is set unnecessarily high. The correct thing to do on a production site is to set the PHP error reporting level to E_ERROR only. You do not want warnings, notices, and deprecation notices to be output. You can ask your host on how to do that. Usually, it's something you can set up in the hosting control panel.

As a mid-term solution I have made a modification in that code to suppress the browser output of WordPress' warnings. I will be releasing a new version of Akeeba Backup for WordPress this upcoming week.

I believe your answer implies I don't need to worry about them

Correct. These messages are not errors, they are user warnings.

They are not coming from a programming error that needs fixing, they are WordPress issuing a warning about using the legacy PHPmailer path instead of the modern one. I am aware of the change, but I have to still use the legacy path because of a third party plugin which breaks if I don't. Even though I am using the legacy path, I already have code in place to use the modern PHPmailer inclusion path in WordPress when WordPress removes the legacy path without me having to do anything else 😀

I can see that you have quite the balancing act of producing ONE version Akeeba Backup each release, that works in so many different WordPress configurations. 

And that's before you start considering the differences between PHP versions, MySQL vs MariaDB, and the different MySQL and MariaDB versions.

I think you're saying I don't need to be concerned about the PHP warnings, notices, and deprecation notices I see output at my development websites, when I leave error reporting enabled (debug mode).

Correct. As an end user you can't do anything about them. These are for us developers to see. Deprecation notices and notices give us a heads up about behavior in PHP which will or might change in the future. Warnings tell us that something didn't outright break, but it may cause side-effects or might break in the future. There's a LOT of nuance understanding what these mean, what we can do about them, and when to do something about them. If you run WordPress on PHP 8.4 you will get tonnes of deprecation notices. WordPress cannot address them properly before dropping support for PHP version older than 7.4. There's a reason they increase the minimum recommended PHP version every release and why they are dropping support for older PHP versions. They don't do it to annoy you, they do it to make sure you will have an upgrade path in 2-3 years' time.

I realize that if a website crashes, I do need to know what happened, and the E_ERROR level message displayed if I've configured my WordPress (development) website to show me errors, will be helpful.

About E_ERROR in particular, in PHP 7 and later versions it is thrown as an ErrorException which extends Throwable. Moreover, PHP does have a mechanism to intercept E_ERROR to run some code before it crashes out. WordPress has a default exception handler and an error handler which catch those errors to display a nice page informing the visitor something broke, and send you an email with the details of the error. This is MUCH more preferable than throwing an error to the browser. An error to the browser may contain privileged information which might leak information valuable to a potential attacker.

You can always extend the functionality of WordPress' error handler by handling the wp_php_error_message filter. You could write an mu-plugin to log extended debug information, or send that to a log management service like DataDog, a self-hosted Graylog image etc. You could even send you a conditional push notification if you're trying to troubleshoot an intermittent issue. I am using that trick to create a very detailed crash report during development.

It tells me if a plugin hasn't been tested with the latest version of WordPress (according to the developer); and it tells me when a plugin hasn't been updated in the last two-three years.

Sometimes a plugin is just too simple to warrant an update. This should also be a factor in your decision-making.