Fix PHP error from a failed database connection

[jdarwood007]

PHP 8.1+ will generate the following error upon a failed database connection:

PHP Fatal error:  Uncaught TypeError: mysqli_error(): Argument #1 ($mysql) must be of type mysqli, null given in /Sources/Errors.php:464

To fix this, I built a wrapper to check to ensure that the we don't have a null argument going into the related function. Instead if its null and the primary connection is null, it returns a empty string, which is what the code seems to expect.

@albertlast I don't have PG setup anymore to test. But I believe it will suffer the same problem according to the PHP docs. Have you seen that?

[albertlast]

when i turn off my pg instance i get this error message:

php 8.1.1

[sbulen]

I am not sure this helps anything?

If db_connection is null that means the connection failed (or was somehow bypassed, which shouldn't happen).

If we return an empty string, I believe all we will see in these circumstances is a blank error message in smf_error_log. I think that is actually less helpful than 'argument is of type null'.

It would be more helpful to find out why the db connection was lost, if available. Or put a proper "db connection lost" error of some type.

[albertlast]

updated env to 8.2.8 same behavior like 8.1.1 mention before

[jdarwood007]

I am seeing the fatal php error in a MySQL 8.0 and PHP 8.1 env.
The error isn't being displayed to users, but PHP is logging that fatal error.

[jdarwood007]

Here is the full PHP error given.

PHP Fatal error:  Uncaught TypeError: mysqli_error(): Argument #1 ($mysql) must be of type mysqli, null given in /Sources/Errors.php:457
Stack trace:
#0 /Sources/Errors.php(457): mysqli_error(NULL)
#1 /Sources/Subs-Db-mysql.php(101): display_db_error()
#2 /Sources/Load.php(3706): smf_db_initiate('**********', '**********', '*********', '*********', '**********', Array)
#3 /SSI.php(92): loadDatabase()

We could also fix this in Errrors.php by checking that we are not about to use a null, but the wrapper returns a empty string. Which Errors.php will check for. Because its a loose type check, our code would basically make null == ''. So no changes here except we handle the error gracefully.

[jdarwood007]

As well: https://php.watch/versions/8.1/internal-func-non-nullable-null-deprecation

[live627]

env

before fix

after fix

[live627]

Suggested change

	if (is_null($connection) && is_null($db_connection))
	if (is_null($connection) || is_null($db_connection))

[live627]

nvm

[jdarwood007]

So do I need to make the changes?

[live627]

Yes; thinking this over again, it is correct imo because it should check the provided connection before the global one. Also could we explicitly check? Another stupid suggestion, but matches everywhere else; also, I dislike superfluous function calls.

Suggested change

	if (is_null($connection) && is_null($db_connection))
	if ($connection !== null || $db_connection !== null)

[jdarwood007]

I changed it, but it needs to be and, not or. If either one is not null, it has a db connection and would just return a empty string if no error has occurred.

[live627]

oh oh did I really get those backwards? 😮 I accidentally inverted your logic, sorryyy.

[Sesquipedalian]

It happens to the best of us.

[live627]

looks like the inverted logic is in the commit

[jdarwood007]

env

before fix

after fix

Basically what I am seeing in the logs. Luckily nothing is being sent to output, because if it was, the PHP error would be exposing the mysql credentials.

[live627]

@sbulen is the provided proof satisfactory

[Sesquipedalian]

c98729c should be reverted.

[jdarwood007]

Inverted the logic. I don't care whether is_null is used or === null. I doubt any speed differences can be found.