Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Guarding against encoding/collation mismatches
Had a weird one today. A client site suddenly started throwing this:
Uncaught mysqli_sql_exception: Invalid character set was provided in /path/to/textpattern/lib/txplib_db.php:259
Stack trace: #0 /path/to/textpattern/lib/txplib_db.php(259): mysqli_set_charset()
#1 /path/to/textpattern/lib/txplib_db.php(288): DB->__construct()
#2 /path/to/textpattern/index.php(65): include('...')
#3 {main} thrown in /path/to/textpattern/lib/txplib_db.php on line 259Front- and back-end the same. The charset in config.php was $txpcfg['dbcharset'] = 'utf8mb3'; which matches the encoding and collation of the tables (utf8mb3 / utf8mb3_general_ci, respectively). The site was running fine until today so presumably the hosting company upgraded something and it broke.
MySQL 8.0.4 is now running. I know that they’ve deprecated utf8mb3 from MySQL 8.4+ onwards, but that shouldn’t affect an older version, surely?
Anyway, the “fix” was to use $txpcfg['dbcharset'] = 'utf8mb4'; in config.php – for how long this works I don’t know.
But it got me thinking. Is there any way we can defensively code against this situation by catching the exception (and other similar connection-based ones) and issuing something more friendly than a “your site is mashed, mate” PHP splurge? We shouldn’t be leaking directory path errors like this, imo, on a live site.
EDIT: while still issuing an error message that helps diagnose this problem. I don’t really want to throw die(db_down()); as that is thrown earlier to indicate more of a connection issue (which smacks of credentials) rather than character set/collation. Don’t want to lead people down the wrong diagnostic path.
Last edited by Bloke (Yesterday 08:54:44)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline