By Greg Nowak. Last updated 2026-07-15.
A Drupal 7 site that fails after a move to MySQL 8 can produce an intimidating SQLSTATE[42000] message about NO_AUTO_CREATE_USER. The immediate cause is usually straightforward: Drupal is asking MySQL to enable an SQL mode that the database no longer recognises.
The technical fix can be small. The operational decision is larger. In 2026, Drupal 7 is no longer community supported, so this incident should produce two outcomes: a controlled recovery now and a documented decision about how long the platform should remain in service.
What the error actually means
MySQL removed NO_AUTO_CREATE_USER in version 8.0.11. Its upgrade documentation advises removing the value from server configuration and older dump files as well as application-generated settings.
Drupal addressed this as part of its wider MySQL 8 compatibility work in Drupal 7.76. That work also added quoting for identifiers such as the system table, whose name conflicts with MySQL 8 syntax. This is why deleting one string from a patched core file is an incomplete solution: later Drupal 7 releases contain related compatibility changes that a one-line edit does not provide.
Diagnose before changing production
Start by confirming the versions that are actually running. Do not rely only on a hosting dashboard or an old handover document. Check the deployed code and query the database connection used by the application.
grep "define('VERSION'" includes/bootstrap.incSELECT VERSION();
SELECT @@SESSION.sql_mode;
SELECT @@GLOBAL.sql_mode;Before deploying a change, take a fresh database backup, retain the current code release and confirm that somebody can perform the rollback. A backup that has never been restored is reassurance, not yet a recovery plan.
| What you find | Likely explanation | Practical next action |
|---|---|---|
| Drupal is older than 7.76 | Core predates Drupal’s MySQL 8 compatibility work | Test an update using the final community release or the baseline supplied by your extended-support provider |
| Drupal is exactly 7.76 | It includes MySQL 8 support but also introduced a table-prefix regression | Do not stop at 7.76; review the 7.77 hotfix and move to an appropriate later baseline |
| Current legacy core still sends the removed mode | A proxy or managed service may be reporting the server version incorrectly | Confirm the reported version, then consider a targeted connection override |
| The failure occurs during server startup or database restore | An option file, deployment script or older dump may still contain the mode | Remove the obsolete value at its source rather than changing Drupal alone |
Use the final community release as the minimum reference point
Drupal 7.76 introduced MySQL 8 support, and 7.77 immediately followed with a hotfix for table prefixes containing dots. The final community release was Drupal 7.103, published in December 2024.
That does not make 7.103 supported today. It makes it a more credible starting point than a much older release with an isolated community patch. If the site has commercial extended support, follow that provider’s maintained distribution and update process instead. In either case, compare custom core modifications before replacing files; old Drupal estates often contain undocumented edits.
When the settings.php override is justified
If the deployed core already contains the MySQL 8 work but Drupal still builds the wrong mode, investigate how the server version reaches PHP. Drupal’s change record notes reports involving managed services and proxies that returned misleading version information.
After confirming that situation, a per-connection override in settings.php is a reasonable containment measure:
$databases['default']['default']['init_commands']['sql_mode'] =
'SET SESSION 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"';Adding the named command avoids replacing unrelated entries if init_commands already exists. Keep the override in version-controlled configuration, comment on why it is necessary and record which infrastructure behaviour it compensates for. If the provider later corrects its version reporting, reassess the workaround instead of letting it become permanent folklore.
Do not disable MySQL identifier quoting as a routine MySQL 8 fix. Quoting was part of Drupal’s compatibility work. The old empty-string workaround documented by Drupal was intended for particular problems on older MySQL installations, not as a default setting for MySQL 8.
Test the business paths, not just the homepage
A successful homepage request proves only that Drupal can bootstrap. The release should also cover login, content editing, cache clearing, cron, search and file handling. Add the site’s revenue or service-critical journeys: checkout, lead forms, account creation, API synchronisation and scheduled exports.
Capture the deployed core version, database version, effective session mode, configuration change, test results and rollback location in the incident record. That gives the next engineer something better than an error screenshot and prevents the same investigation from being repeated.
Treat recovery and migration as separate workstreams
Drupal 7 reached end of life on January 5, 2025. Community releases, security coverage and compatibility updates have ended. A stable MySQL connection therefore solves today’s outage, but it does not restore an ongoing support path.
Once service is stable, decide who owns the legacy risk, whether extended support is required and when migration discovery will begin. That discovery should inventory custom modules, integrations, content types, editorial workflows and data-retention requirements before anyone estimates a rebuild.
If you need a second pair of eyes, Greg can help separate the immediate Drupal recovery from the migration decision and turn both into a workable delivery plan. Talk to Greg about the next step.
Related on GrN.dk
- NGINX 1.30 changed upstream connection reuse by default: what to check before you upgrade
- Fix the HTTPRL Network Configuration Error in Drupal 7
- MariaDB 10.6 EOL: quiet CMS hosting debt needs a real upgrade plan before July 2026
Need help with this kind of work?
Discuss your Drupal recovery plan Get in touch with Greg.
