The W series has covered what to check before a major upgrade, when to apply it, and what can go wrong. This fourth part covers the remaining question: how to actually run it. Once the preparation is in place and the timing is right, this is the command sequence to follow — one stage at a time, with a confirmation step at each boundary.
Why not use the admin dashboard Update button
The WordPress admin screen has an “Update All” button that runs core, plugin, and theme updates in a single operation. This is the approach to avoid for major upgrades.
The reason is loss of isolation. When core plus five plugins plus two themes update in one pass, any breakage afterward has multiple suspects and no clear way to narrow them down. The dashboard update also displays “Updated successfully” even when PHP warnings or non-fatal errors occurred during the process — making it easy to miss problems until they surface later.
WP-CLI lets you apply core, the DB migration, plugins (one at a time), and themes in separate steps, with a check between each one.
STEP 0 — Final checks before starting
Before touching anything, establish a baseline and take a backup.
# Confirm the current core version and what updates are available
wp core version
wp core check-update
# Export the database with compression
wp db export - | gzip > backup_$(date +%Y%m%d_%H%M%S).sql.gz
# See which plugins have updates pending
wp plugin list --update=available --format=table
# See which themes have updates pending
wp theme list --update=available --format=table
wp core check-update tells you what the upgrade will move to before you start. Running it first also gives you a record of the pre-upgrade state in your session log.
The database backup taken here is the recovery point for the entire upgrade. If core update fails or something breaks in the DB migration step, this is what you restore from. Take it immediately before starting, not hours earlier.
STEP 1 — Update core in version steps
Jumping directly from 6.4 to 6.7 means several DB migration passes run back-to-back, and if something breaks you’re left trying to figure out which intermediate version caused it. Applying one version at a time keeps the problem space smaller.
# Specify the target version explicitly — don’t rely on "latest"
wp core update --version=6.5
# Run the DB migration immediately after core update
wp core update-db
# Verify core file checksums against the WordPress.org reference
wp core verify-checksums
Omitting --version= updates to the latest available, which skips the intermediate-version approach. For major upgrades, name the version explicitly.
wp core update-db aligns the database schema version with the code. Without it, WordPress may run the migration automatically when the admin screen loads — which works, but runs without any visible confirmation that it completed cleanly. Running it from WP-CLI gives you a clear success or failure signal.
wp core verify-checksums compares core files against the WordPress.org checksums for that version. On servers where files were previously modified directly via FTP, this catches discrepancies before they become confusing later. Worth running both before and after core updates.
After the core step: confirm that the admin dashboard loads and that the front page returns a 200 before moving on.
STEP 2 — Update plugins one at a time
With core confirmed stable, move to plugins. One plugin per update, with a check after each one.
# List plugins that have updates available
wp plugin list --update=available --format=table
# Update one plugin at a time
wp plugin update contact-form-7
# ... check the site ...
wp plugin update woocommerce
# ... check checkout flow ...
wp plugin update yoast-seo
A useful order: start with plugins that have a narrow blast radius (SEO, debugging tools, admin utilities), and finish with the high-stakes ones (e-commerce, forms, page builders, authentication).
| Update earlier | Update later |
|---|---|
| SEO plugins, security scanners | WooCommerce, payment plugins |
| Admin utilities, debug tools | Page builders (Elementor, Beaver Builder) |
| Cache plugins | Authentication, multisite-related |
W3’s failure patterns 2 and 3 — JS library version jumps and PHP minimum requirement changes — are most likely to appear during plugin updates. After updating any plugin with heavy JavaScript dependencies, open the browser console and check for JS errors before calling the step done.
If WP-CLI itself starts throwing errors or crashing after a plugin update, the --skip-plugins --skip-themes rescue flag lets you restart WP-CLI without loading plugins — useful for investigating the problem or rolling back without getting stuck in a broken plugin load loop.
STEP 3 — Update themes
After plugins are confirmed stable, update themes.
# Check which themes have updates
wp theme list --update=available --format=table
# Update the theme
wp theme update twentytwentyfour
If a child theme is in use, the parent theme update doesn’t touch the child theme files — but parent theme hook changes can break child theme behavior if the child overrides hooks that were renamed or removed. After any parent theme update, walk through the pages that use customized template parts.
W3’s pattern 4 — Classic Theme child theme customizations breaking when switching to Block Themes — is most likely to appear here if theme updates involve moving from one theme architecture to another. That’s a case where the theme update decision needs to be treated separately from the core upgrade decision.
Rolling back when something goes wrong
Have these commands ready before starting. Running the upgrade without knowing the rollback path in advance is the kind of setup where panic sets in under pressure.
Roll back core
# Force-reinstall a specific prior version of core
wp core update --version=6.4 --force
# Restore the database from the backup taken in STEP 0
wp db import backup_20260615_090000.sql.gz
--force installs the specified version even if it’s already installed — necessary when rolling back to the previous version that’s already recorded as the current one.
Roll back a plugin
# Force-install a specific prior version of a plugin
wp plugin install contact-form-7 --version=5.8.3 --force
Plugin rollback is covered in detail in the WP-CLI pinpoint rollback post. The version number to restore to is in the version column of wp plugin list.
When core has been rolled back, the situation is the same as the halt-after-core-rollback design: continuing plugin updates on an unstable core adds another variable to an already unclear state. Stabilize core first, then resume.
Summary
| Command | When to use |
|---|---|
wp core check-update |
Baseline check before starting |
wp db export |
Immediately before core update (required) |
wp core update --version=X.X |
Core update with explicit version |
wp core update-db |
Immediately after core update (required) |
wp core verify-checksums |
Core file integrity check |
wp plugin update <name> |
One plugin at a time, check between each |
wp theme update <name> |
Theme update, visual check after |
wp core update --version=X.X --force |
Core rollback if needed |
wp plugin install <name> --version=X.X.X --force |
Plugin rollback if needed |
Where W1–W4 fit together:
| Post | Topic |
|---|---|
| W1 — What to check | Pre-upgrade checklist: 7 items |
| W2 — When to apply | The case for waiting for x.0.1 |
| W3 — What can go wrong | Five failure patterns from past majors |
| W4 — How to run it | Commands and checkpoints for each stage ← this post |
| W5 — Getting ready for 7.0 | Three things to check now: PHP, FSE, editor extensions |
| W6 — Verifying the result | 7-step post-upgrade checklist |
Running updates in stages isn’t a slower path — it’s the path that keeps each step reversible and each problem identifiable. When something breaks after a one-at-a-time update sequence, you know exactly which step caused it. That clarity is what makes the difference between a short investigation and a long one.