If WordPress keeps sending you to /wp-admin/upgrade.php—or alternates between “Database Update Required” and “No update required, your WordPress database is already up to date”—treat it as a version-consistency problem, not as a prompt to edit the database by hand. Run the normal upgrade once, clear every relevant cache, temporarily bypass the persistent object cache and plugins, then verify that the active WordPress files, database connection and database write permissions belong to the same site. Only consider database repair after you have a verified backup.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
The usual screen is expected once after a core update. A loop means the version comparison is not staying consistent between requests, the migration did not persist, or a cache or deployment layer is serving an old value.
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
What the loop actually means
WordPress stores the installed database schema level in the db_version option. The loaded WordPress core files contain the schema version they expect. During the normal upgrade flow, /wp-admin/upgrade.php compares those values and, when they differ, runs WordPress’s upgrade routine, wp_upgrade().
After a successful migration, the comparison should agree and the upgrade screen should disappear. WordPress core describes the final step this way: “WordPress has been updated! Next and final step is to update your database to the newest version.” It also cautions that “The database update process may take a little while, so please be patient.” Seeing the prompt once is normal; seeing it again after completion is not.
A loop generally has one of four explanations:
- A stale cache is returning an old
db_versionvalue. An external object cache is the strongest documented explanation when the update reports success but the prompt returns. - A page, CDN or plugin cache is replaying an old admin response or interfering with the upgrade request.
- The code and database do not belong to the same deployment. Different web nodes, staging and production settings, or an incorrect
wp-config.phpconnection can make two requests disagree. - The migration cannot be written durably. Database permissions, a repair problem or another server-side error can leave the expected version unchanged.
Do not “fix” the message by changing db_version directly. That can hide an incomplete migration while leaving the schema mismatched with the code that will execute against it.
Before changing anything: make the recovery reversible
Take a current, restorable backup before database repair, file changes or any operation that writes to the database. Keep a copy outside the affected hosting account if possible. Also record the current WordPress version, the time the loop began and any error text shown by the host or browser.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Use an incognito or private browser window for each test. This prevents a browser cookie or locally cached response from making a successful fix look unsuccessful. If another administrator is logged in, ask them to stop testing while you work so that two upgrade requests do not overlap.
- Have access to the hosting file manager or FTP/SFTP account.
- Know which installation directory contains
wp-admin,wp-includesandwp-content. - Know which database the site is supposed to use, including its table prefix.
- Be able to restore a renamed file or directory immediately.
Use this fix sequence, in order
The order matters. Start with the least invasive and most reversible action. Do not skip ahead to database edits because the screen looks urgent.
1. Run the normal database update once
- Open
/wp-admin/upgrade.phpfor the affected site. - Click the page’s database-update button once.
- Wait for the completion message. Do not refresh repeatedly, close the tab or submit the form a second time while it is working.
- Open a new private-window session and test
/wp-admin/.
The process may take a little while, especially when a core release includes several schema changes. If the update completes and the dashboard opens, continue to the cache-clearing step before declaring the incident closed.
2. Clear presentation and application caches
A successful migration can be hidden by a stale response. Purge every cache layer you control, then test again:
Free tools Windows power users keep installed
One-click scans. No signup required.
- Browser cache and cookies: use a private window first; clear the normal browser cache only if the private test differs.
- CDN or reverse-proxy cache: purge the site or the affected admin response according to that service’s controls.
- Page-cache plugin: use its purge or clear-all action, if the dashboard is available.
- Host-level cache: clear it through the hosting control panel or ask support to purge it.
Do not cache authenticated administration pages. If the prompt appears only on one network, browser or web node, compare those paths before changing files. A response that changes after a purge points to presentation or application caching rather than a missing schema migration.
3. Temporarily bypass object-cache.php
Persistent object caching can preserve an old option value even after the database has changed. SiteGround’s knowledge-base guidance, updated August 29, 2025, specifically recommends finding object-cache.php in wp-content and renaming or deleting it when this symptom prevents access.
- Open the site’s
wp-contentdirectory in the host file manager or an FTP/SFTP client. - If
object-cache.phpexists, make a backup copy first. - Rename the active file to a clearly identifiable temporary name such as
object-cache.php.disabled. Renaming is preferable to deleting because it is easy to reverse. - Open a private browser window and revisit
/wp-admin/upgrade.php, then the dashboard.
Renaming this file changes runtime behavior: it disables the persistent object-cache integration, including Memcached functionality, until the cache is re-enabled. That is a diagnostic step, not a permanent performance recommendation. If the loop stops, leave the file disabled while you complete the checks below and identify the cache component that supplied the stale value.
4. Disable plugins temporarily
A plugin can cache an admin response, hook the upgrade request or fail while WordPress is updating. If you can reach the Plugins screen, deactivate all plugins. If you cannot, use the file system:
Rank #3
- In the WordPress installation directory, locate
wp-content/plugins. - Rename the directory to a temporary name such as
plugins.disabled. - Retry
/wp-admin/upgrade.phpand then the dashboard in a private window. - When access returns, rename the directory back to
plugins. - Reactivate plugins in small groups, testing the upgrade screen after each group. The group that brings the loop back contains the likely conflict; narrow it down one plugin at a time.
Renaming the directory is reversible, but it changes the site’s runtime. Expect plugin-provided features to be unavailable during the test. Do not leave the directory under its temporary name after recovery unless you intentionally want all plugins disabled.
5. Verify that the loaded code and database are paired
If cache and plugin tests do not resolve the loop, confirm that every request is using the same installation and database. This is especially important after a deployment, migration or hosting change.
- WordPress files: Confirm that the web server is loading the directory you just inspected, rather than a second copy of WordPress.
- Database name and host: Check the
DB_NAMEandDB_HOSTvalues inwp-config.phpagainst the database intended for this environment. - Table prefix: Verify that
$table_prefixpoints to the tables belonging to this site. A correct database with the wrong prefix can look like an empty or un-updated installation. - Environment separation: Make sure staging credentials were not deployed to production, or vice versa. A load-balanced site must send requests to nodes running the same code and configuration.
- Write access: Confirm that the database user can update the WordPress tables and options. Check the host’s database error log for denied writes, timeouts or connection failures.
A deployment mismatch can produce contradictory messages: one request reads the updated value while another reaches an older database, node or cache. Fix the configuration or deployment consistency before attempting another migration.
6. Consider database repair only after the checks above
Database repair is a later branch, not the first response. Use the repair procedure documented for your WordPress installation or host only after you have a verified backup and have ruled out stale caches, plugins and configuration mismatches.
- Follow the repair procedure exactly and monitor the result rather than refreshing repeatedly.
- Keep the repair endpoint or temporary repair setting protected while it is enabled.
- Remove the temporary repair setting immediately after the operation, whether or not it appears to help.
- Return to
/wp-admin/upgrade.phpand run the normal update once after repair.
If repair reports errors, stop and preserve the messages for your host or database administrator. Do not respond by manually replacing db_version; the option is a version marker, not a substitute for the schema changes that the migration performs.
7. Restore caching deliberately and verify
Once the dashboard remains available and the upgrade prompt no longer returns in a private window, restore the runtime components you disabled:
- Rename the backed-up object-cache file back to exactly
object-cache.php, or re-enable the cache plugin using its documented method. - Re-enable plugins in the groups you tested, stopping when the symptom returns.
- Purge CDN, page-cache, host and object-cache layers again so no old response survives the restoration.
- Test from a private window and, if the site uses more than one web node, test through each node or route available to you.
- Keep the backup and the temporary filenames until the site has passed a second login and dashboard test.
If restoring one cache component immediately recreates the loop, disable that component again and treat it as the confirmed source. Update or reconfigure it before putting it back into production.
Choose the remedy by risk and reversibility
| Action | What it tests | Reversibility | Main risk |
|---|---|---|---|
Run /wp-admin/upgrade.php once and wait |
Whether the standard migration can complete | Normal WordPress operation | Submitting repeatedly can create confusion while the first request is still running |
| Purge browser, CDN, page and host caches | Whether an old response is being replayed | Low risk | Temporary cache misses and slower responses |
Rename wp-content/object-cache.php |
Whether persistent object caching serves an old option | High; restore the original filename | Memcached or another object-cache integration is disabled until restored |
| Rename the plugins directory | Whether a plugin hooks the request or serves stale data | High; restore the directory name | Plugin features are unavailable during the test |
Verify wp-config.php, deployment and permissions |
Whether requests use the same code, database and writable account | Depends on the configuration change | Changing production credentials incorrectly can take the site offline |
| Run database repair | Whether table or index damage prevents persistence | Backup-dependent | Data changes require a verified rollback path |
Edit db_version manually |
Nothing reliable; it only changes the marker | Not a safe remedy | Can conceal an incomplete migration and create a deeper mismatch |
Symptoms and the next diagnostic branch
The button says the update succeeded, then the prompt returns
Start with cache invalidation, then bypass object-cache.php. This pattern most strongly indicates that a stale object or external cache is returning the previous db_version. If disabling object caching works, restore it only after purging it and confirming that its backend is connected to the intended site.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallYou see “No update required” and are sent back to the prompt
This contradiction means different requests are seeing different state. Test privately, purge all layers, and compare the active code and database settings across deployment nodes. Do not assume that either message is the definitive state until the same request path produces the same result repeatedly.
You cannot reach the dashboard at all
Use the host file manager or FTP/SFTP to rename object-cache.php first, then the plugins directory if necessary. These changes do not require dashboard access and can be reversed. Once the dashboard opens, identify which component caused the conflict before re-enabling it.
The screen hangs or reports a database error
Wait for the first request to finish, then inspect the hosting and database error logs. Confirm database write permissions and connection settings. If the error persists after caches and plugins are bypassed, stop before repair and preserve the exact error for the person responsible for the database.
The loop returns only after caching is restored
That isolates the fault to the restored cache layer or its backend. Disable it again, purge every related cache, and verify that it is configured for the current production database and code. Re-enable it only after a clean upgrade test.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsWhat not to do
- Do not repeatedly click the update button while a migration is running.
- Do not delete
object-cache.phpwithout first keeping a copy when renaming is sufficient. - Do not leave all plugins disabled as a permanent “fix” without finding the conflicting component.
- Do not assume a successful message proves every web node and cache has refreshed.
- Do not edit
db_versionmerely to remove the notice. - Do not run repair without a verified backup, and do not leave a temporary repair setting enabled.
When to hand the incident to your host or developer
Escalate with the exact URL, timestamps, WordPress version, completion message, cache components tested, renamed files, database error text and confirmation of your backup. Ask the host to verify which web node handled each request, whether the database user can write to the WordPress tables and whether an external object cache is returning an old option value.
Escalation is appropriate when the database user cannot be granted the required write access, the environment alternates between staging and production, a repair reports corruption, or the loop returns even with object caching and plugins disabled. Those conditions point beyond a browser refresh and require server or database-level inspection.
Quick Recap
Recovery checklist
- The normal upgrade was run once and allowed to finish.
- Private-window testing no longer shows contradictory messages.
- Browser, CDN, page-cache and host-cache layers were purged.
object-cache.phpwas tested and either safely restored or intentionally replaced.- Plugins were re-enabled in groups, with the conflicting component identified if the loop returned.
wp-config.php, table prefix, deployment nodes and database permissions all point to the intended site.- Any repair was performed from a verified backup, and its temporary setting was removed.
- A final purge and dashboard login succeeded after caching was restored.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
