A repeating WordPress Database Update Required screen means the application still believes its database state needs an upgrade. Do not hide the prompt by manually changing a version number in the database. First confirm that the browser, deployed files and database connection refer to the same installation.
Distinguish a normal prompt from a loop
One prompt after a core upgrade can be expected. Record whether the update completes, reports an error or returns immediately to the same screen. Note the domain and path, especially when WordPress lives in a subdirectory or a host has moved the document root.
Stop repeated clicks if errors mention database permissions, unavailable tables or an interrupted migration. Capture the exact message and timestamp. Repetition does not repair the underlying condition and can obscure which attempt produced a log entry.
Compare versions without starting another update
With authorized shell access, run these commands from the confirmed WordPress directory:
wp core version
wp core update-db --dry-run
The WP-CLI reference says the dry-run option compares database versions without performing the update. This is a core database check, not a promise that every plugin's migrations are complete.
Record the results, but never paste database credentials or the contents of wp-config.php into a public support thread. Ask the host to compare the browser's application path and database target privately if the CLI and browser disagree.
Target: Correct site and directory. Consistency: Serving nodes use matching files. Upgrade: Supported procedure completes. Recheck: New session no longer loops. Explanatory checklist, not a customer test result.
Work through the mismatch
| Evidence |
Investigation |
| CLI sees older files than the host dashboard |
Wrong directory or incomplete deployment |
| Different nodes report different versions |
Mixed application artifacts behind the load balancer |
| Upgrade reports a database error |
Database access, privileges or the specific failed operation |
| CLI reports current but browser keeps prompting |
Different target, persistent cache or stale serving process |
| Issue began after a restore |
Files and database may come from different checkpoints |
Cache is a hypothesis, not an automatic fix. Have the operator confirm the cache namespace and installation before clearing persistent data. A shared cache flush can affect other sites. Likewise, verify application deployment consistency before restarting services at random.
Apply the supported database update once
Before a real update, preserve a usable backup and confirm the intended environment. Use the dashboard or the host's supported WP-CLI process. A network-wide update has wider scope than a single-site action; do not add the network flag simply because the first command did not solve the problem.
For a restore-related incident, the database and file rollback rehearsal explains why replacing only files cannot undo database changes. Its beta scenario is a testing example, not a recommendation to install a beta on production.
Prove the prompt stays gone
Open a new administrator session and revisit Dashboard and Updates. Save a harmless draft, inspect the relevant error log and repeat the read-only comparison. On multi-node hosting, include the host's confirmation that each serving instance is consistent.
If the prompt returns, HandL WP can trace the code-to-database mismatch. Provide the installation paths checked and redacted command results. Never use a direct SQL version-marker edit as a substitute for a migration that has not completed.
References reviewed October 7, 2026. Examples are explanatory, not customer test results.