My hoster screwed up by updating MySQL and now I’m faced with the following warning which prevents me from working with InvoicePlane: Message: mysqli::real_connect(): Headers and client library minor version mismatch. Headers:100337 Library:100427
Is there a way to bypass this temporarily?
I’m also getting some complaints PDF files can’t be opened by clients. I don’t seem to have this problem. Maybe this is related?
Hi @vespinonl thanks for opening the issue in this community. I’ve personally never had to deal with this specific error, but the results given by google seem to suggest this is more a hosting related problem. This Stackoverflow post explains (in the solution) quite well the problem: php - Headers and client library minor version mismatch - Stack Overflow
Yes, I also found that topic and also pointed my hoster to it (or I think they pointed me to it come to think about it), but I’m not able to make changes to the hosting environment.
Mmmh I really think this should be solved by your hosting provider. As a temporary solution you might try to set IP to use the mysql driver instead of mysqli. This is done by navigating to application/config/database.php and on line 83 setting the following variable 'dbdriver' => 'mysql'. I’m not sure this will do the trick. As I understand it, the issue is by your hosting provider (especially if it is a managed hosting in a shared enviroment) and not you nor InvoicePlane.
You could try to suppress the warnings at the connection of the database. (I’ve not tested it) You should be able to do it by adding an @ in at row 211 of the file \vendor\codeigniter\framework\system\database\drivers\mysqli to make it result like this if (@$this->_mysqli->real_connect($hostname, $this->username, $this->password, $this->database, $port, $socket, $client_flags)). Does it work?
I will investigate this some more, but PDF are sent via mail but first generated by IP. Firefox doesn’t show any errors, it’s my default viewer, I believe my clients mostly use Adobe viewer.
@vespinonl mmh actually PHP8 and above still has the error/warning suppression operator @. AFAIK the change in PHP8 is that the @ control operator does not suppress fatal errors, which should not be your case.
im hosted at Green Geeks - – i contaced them - - and i dont know what they did, but it fixed now. They didnt sayanything - - just “The issue should be corrected now.” now im back up an running . . weirddd