If a Drupal 7 site starts throwing SQLSTATE[42000] errors about NO_AUTO_CREATE_USER after a database upgrade, the failure is usually predictable: older Drupal 7 code is trying to set a MySQL mode that no longer exists. This is fixable, but it is not a sign that the stack is healthy. For owners, operations leads, and agency teams, the right response is two-track: get the site stable, then decide how much more time you want to invest in a platform that reached community end of life on January 5, 2025.
The good news is that this stopped being a patch-hunt problem years ago. Drupal added MySQL 8 support in 7.76 via the official change record, and 7.77 followed with a hotfix for a regression introduced in that work. So in 2026 the first question is usually not which patch to apply. It is whether the site is still on outdated core, or whether the hosting layer is still forcing the wrong sql_mode.
What the error actually means
MySQL removed NO_AUTO_CREATE_USER in 8.0.11. Older Drupal 7 database code can still try to include it when setting the session sql_mode, which causes the connection to fail during bootstrap. The problem is bigger than one flag, though. MySQL 8 also tightened some identifier behaviour, which is why Drupal's compatibility work included quoting fixes for names such as system. Deleting one token from one query can get you past the first error, but it does not give you the full MySQL 8 compatibility work that later Drupal 7 core already carries.
Start with the fastest safe checks
Before changing anything, make sure rollback is real. Take a fresh database backup, confirm the exact code deployed, and know how you would reverse both if the site boots but later breaks in admin workflows.
- Check the Drupal core version first. If the site is below 7.76, MySQL 8 support is not complete in core. If you are already touching legacy core in 2026, use the latest Drupal 7 release listed on Drupal.org, 7.103 from December 4, 2024, as your baseline rather than cherry-picking one old fix.
- If the site is on 7.76, review 7.77 at minimum. Drupal.org published 7.77 as a hotfix for a table-name quoting bug introduced in 7.76.
- Check the database directly, not through a hosting dashboard. Run
SELECT VERSION();andSELECT @@sql_mode;so you know what Drupal is really connecting to. - Inspect server startup SQL, restore scripts, and managed-service configuration. MySQL's own release notes are clear that
NO_AUTO_CREATE_USERis gone. Teams often fix Drupal and then get blocked by an inheritedsql_modesetting elsewhere.
This is usually enough to separate a core-version problem from an environment problem.
When a settings.php override is reasonable
If the site is already on a Drupal 7 core release with MySQL 8 support and you still hit the same error, the next suspect is version detection. Drupal's change record notes that some providers and proxies can report the MySQL version incorrectly. In that case Drupal may build the wrong session settings even though the database is actually MySQL 8.
That is the point where a targeted settings.php override becomes a sensible 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"'
);Use it only after you confirm that core is current enough and the environment is the real problem. Then test more than the home page. A good verification pass includes login, cache clear, cron, content save, search, and any payment or integration path that matters to the business. Legacy Drupal failures often move from bootstrap to admin paths once the immediate error is masked.
Avoid blanket tweaks that fight core's MySQL 8 work. In particular, do not disable identifier quoting by default just because an old forum post suggests it. That setting had niche value for older MySQL versions, but on MySQL 8 the quoting changes are part of the official fix.
What this should trigger inside the business
On June 11, 2026, a Drupal 7/MySQL 8 incident is not just a database bug. It is a signal about operational risk. Drupal 7 has been out of community support since January 5, 2025. That means no new community core fixes, no ongoing community security coverage, and no promise that future platform changes will be smoothed out for you.
So the practical question is not whether Drupal 7 can be kept running. It usually can. The question is how much effort you want to spend keeping it running compared with migrating it. For most teams, the sensible path is to stabilise the current site with the smallest credible fix, document the exact workaround in deployment notes and settings.php comments, freeze unnecessary infrastructure change around the legacy stack, and decide whether you need extended support, a controlled rebuild, or a phased migration.
That turns an outage-driven fire drill into a managed decision instead of a repeating surprise.
A practical next step
If you only need the immediate fix, start with core version, MySQL version, and sql_mode. If you are responsible for delivery risk, use this incident to get clear on ownership, support horizon, and migration timing. The technical fix is short. The expensive part is staying ambiguous about the plan.
If you want an outside view on a Drupal 7 estate, a MySQL 8 upgrade path, or the shape of a migration plan, Greg can help separate the urgent production fix from the longer platform decision without turning it into a larger-than-needed project.
Need help with this kind of work?
Need help stabilising a legacy Drupal 7 stack while planning the next move? Get in touch with Greg.