If your Drupal 7 site throws SQLSTATE[42000] errors about NO_AUTO_CREATE_USER after a MySQL upgrade, you are dealing with a known compatibility problem, not a mysterious one-off. The original patch thread that circulated in 2020 was useful at the time, but it is no longer the best default advice. Drupal 7 gained official MySQL 8 support in core in 7.76, followed by a hotfix in 7.77. That means the first question in 2026 is not "which patch do I apply?" but "why is this site still below the core fix, or why is the environment still forcing an old sql_mode?"
For business owners, operations leads, and agency teams, the practical goal is to stabilize the site without pretending the underlying risk has disappeared. As of April 27, 2026, Drupal 7 has already been end-of-life for more than a year. So yes, you can usually remove this MySQL 8 blocker, but you should treat it as legacy-platform triage and pair it with a clear plan for support, migration, or both.
Why this happens
Older Drupal 7 database code sets a MySQL sql_mode string that includes NO_AUTO_CREATE_USER. According to the MySQL 8 reference manual, that mode was removed in MySQL 8.0.11. When Drupal tries to set it anyway, the connection fails and you see the SQLSTATE[42000] error.
There is a second compatibility wrinkle as well: MySQL 8 is stricter about identifiers and reserved words. Drupal's MySQL 8 support work backported identifier quoting so tables such as system do not break queries. That is why the durable fix is broader than deleting one mode flag from one query.
What to check first
- Before you change anything, take a fresh database backup and make sure code and database rollback are both real, not assumed.
- Confirm the Drupal core version. If the site is older than Drupal 7.76, upgrade core before you go hunting for one-off patches. If you are on 7.76, at least review 7.77, because it shipped as a hotfix for a bug introduced in 7.76.
- Confirm the real database version at the server, not just what the hosting control panel says. Run
SELECT VERSION();andSELECT @@sql_mode;in MySQL so you know what Drupal is actually connecting to. - Check whether the bad mode is being injected somewhere outside Drupal too. MySQL's own upgrade notes say
NO_AUTO_CREATE_USERshould be removed fromsql_modesettings and older dump definitions. In practice, teams often fix the application side and still get blocked by inherited server config, bootstrap SQL, or an old restore script. - Treat the historical issue thread as reference material, not your default deployment plan. It is still useful for edge cases, but the official core work landed years ago and is the safer starting point today.
When a settings.php override makes sense
If you are already on a Drupal 7 release with MySQL 8 support and the site still fails, the next suspect is environment detection. Drupal's own change record notes that some managed MySQL services and proxies can report the server version incorrectly. When that happens, Drupal may still build the wrong sql_mode string.
In that case, forcing the mode explicitly in sites/default/settings.php is a reasonable operational workaround:
$databases['default']['default']['init_commands'] = array(
'sql_mode' => 'SET sql_mode="REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO"'
);Test that in staging first, then confirm the site can bootstrap, clear caches, run cron, log users in, and save content. This is the kind of fix that looks done after the homepage loads but still breaks routine admin paths if nobody validates them.
There is also a Drupal setting for identifier quoting: $conf['mysql_identifier_quote_character'] = '';. That can help on older MySQL versions or unusual edge cases, but it is not a blanket recommendation for MySQL 8. On MySQL 8, identifier quoting is part of the compatibility work, so disabling it casually can create new problems instead of removing them.
What this means for owners and agency teams
The important decision is not whether Drupal 7 can talk to MySQL 8. It can, provided the site is on the right core changes and the environment is sane. The important decision is whether you want to keep spending time on emergency compatibility fixes for an unsupported platform.
Drupal 7 reached end of life on January 5, 2025. That means no new community core releases, no ongoing community security coverage, and no guarantee that future infrastructure changes will be smoothed out for you. From an operations perspective, MySQL 8 compatibility is a stopgap, not a strategy.
If the site is business-critical, the sensible path is usually to stabilize the current environment, document the exact workaround in settings.php or deployment notes, reduce the number of moving parts around the legacy site, and plan either extended support or a migration to a supported modern Drupal release.
A pragmatic next step
If you just need the site back online, start with the core version and the sql_mode check. If you are responsible for the longer-term platform decision, use this incident as a forcing function: fix the immediate blocker, then decide how much longer Drupal 7 should stay in the business.
If you want a second pair of eyes on a Drupal 7 estate, a MySQL 8 upgrade path, or the shape of a migration plan, Greg can help you separate the urgent fix from the strategic work.
Need help with this kind of work?
Need help separating the urgent Drupal 7/MySQL 8 fix from the longer migration plan? Greg can review the stack, de-risk the change, and map the next step. Get in touch with Greg.