What Broke When I Upgraded 70+ Sites to WordPress 7.0

WordPress 7.0 "Armstrong" landed on 20 May 2026. Within a week, I needed every site I manage on the new version — or at least verified as safe to update. That meant auditing 70+ WordPress installations across eight servers, identifying what would break before it broke, and handling the three issues that no amount of reading the Field Guide prepared me for.

The Audit: What Are We Working With?

Before touching a single Update button, I needed a snapshot of the entire fleet. WP-CLI made this a five-minute job:

for site in /var/www/*/; do
  echo "=== $(basename "$site") ==="
  wp --path="$site/htdocs" core version 2>/dev/null
  wp --path="$site/htdocs" db query "SELECT VERSION();" --skip-column-names 2>/dev/null
  wp --path="$site/htdocs" eval 'echo "PHP " . phpversion();' 2>/dev/null
  echo ""
done

The output told me three things per site: WordPress version, database server version, and PHP version. That is everything WordPress 7.0 cares about.

The requirements jump is significant. WordPress 7.0 needs PHP 7.4+ (up from 7.2), MySQL 8.0+ or MariaDB 10.6+ (up from MySQL 5.5.5), and drops support for PHP 7.2 and 7.3 entirely. Sites that do not meet these requirements will not be offered the auto-update — they silently stay on 6.9.

Issue 1: Twelve Sites Blocked by MariaDB 10.4

My audit revealed twelve sites across two servers still running MariaDB 10.4. These were older HestiaCP boxes provisioned in 2022. MariaDB 10.4 hit end of life in June 2024 — it was overdue for an upgrade regardless, but WordPress 7.0 forced the issue.

The auto-updater did not warn these sites. It simply did not offer WordPress 7.0 as an available update. If I had not run the audit, those twelve sites would have quietly fallen behind on security patches with no indication anything was wrong.

The fix: MariaDB 10.4 to 10.11

I took the direct upgrade path. On each server:

mysqldump --all-databases --routines --triggers --events \
  > /root/pre-upgrade-$(date +%Y%m%d).sql

mariadb --version

On the HestiaCP server, the upgrade was straightforward because HestiaCP packages MariaDB from the official repository:

curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \
  | bash -s -- --mariadb-server-version="mariadb-10.11"

systemctl stop mariadb
apt update && apt install -y mariadb-server
systemctl start mariadb
mariadb-upgrade

After the upgrade, I verified every site could still connect:

for site in /var/www/*/; do
  wp --path="$site/htdocs" db check --quiet 2>/dev/null \
    && echo "$(basename "$site"): OK" \
    || echo "$(basename "$site"): FAILED"
done

All twelve sites connected immediately. No socket path issues this time — I had learned that lesson from a previous MariaDB upgrade and ensured the socket path was symlinked before starting.

Two sites had tables still using the utf8mb3 charset. MariaDB 10.11 flags these with warnings during mariadb-upgrade. I converted them on the spot:

ALTER TABLE wp_postmeta CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Issue 2: DataViews Broke Admin Column Plugins

This was the issue I had been warned about, and it still caught me off guard on two sites.

WordPress 7.0 replaces the traditional WP_List_Table interface on the Posts, Pages, and Media screens with DataViews — a React-based component with client-side sorting, filtering, and layout options. The old PHP-rendered table is gone for these core screens.

The problem: any plugin that hooks into manage_posts_columns, manage_posts_custom_column, or bulk_actions-edit-post to add custom columns simply does not render. The hooks fire, but the DataViews UI renders independently and ignores them.

Two sites used Admin Columns Pro to display custom fields, word counts, and featured image thumbnails in the post list. After updating to WordPress 7.0, those columns vanished. No error, no warning — just missing.

The fix

Admin Columns Pro shipped a DataViews-compatible update (version 7.0) within days of WordPress 7.0 launching. Updating the plugin restored everything. But the pattern matters: any plugin that customises the Posts, Pages, or Media list screens needs a DataViews-aware update to work with WordPress 7.0.

To audit which plugins hook into the affected screens:

grep -rl "manage_posts_columns\|manage_posts_custom_column\|manage_pages_columns\|manage_media_columns\|bulk_actions-edit-post" \
  /var/www/example/htdocs/wp-content/plugins/

If a plugin appears in that list and has not been updated since May 2026, it is likely broken on WordPress 7.0's core screens. Custom post type screens are safe — they still use WP_List_Table in 7.0.

For sites where the plugin developer has not shipped a compatible update, the options are: wait for the update, switch to an alternative, or stay on WordPress 6.9.x until compatibility lands. I held two sites on 6.9 for a week until their bespoke admin plugin was patched.

Issue 3: WooCommerce Admin Order Styling

Seven WooCommerce stores displayed a broken orders screen after the WordPress 7.0 update. Column widths were wrong, status labels were misaligned, and the order preview modal had padding issues. Nothing was functionally broken — orders processed fine — but the admin was visually messy and confusing for store owners who work in it daily.

The fix

WooCommerce 10.6.2 shipped admin style fixes specifically for WordPress 7.0 compatibility. WooCommerce 10.8.0, released six days after WordPress 7.0, is the version I recommend as the minimum for any store running WordPress 7.0 — it includes full DataViews alignment and the admin styling fixes.

The upgrade order matters: update WooCommerce before updating WordPress to 7.0, not after. That way the styling fix is already in place when the DataViews interface loads.

wp --path=/var/www/store/htdocs plugin update woocommerce
wp --path=/var/www/store/htdocs core update
wp --path=/var/www/store/htdocs cache flush

After updating, I tested the full checkout flow on each store — cart, payment, confirmation email, admin order view — before moving to the next.

The Pre-Upgrade Checklist I Use Now

After this round of upgrades, I have formalised a checklist I run before every major WordPress version update:

# 1. Database version
wp db query "SELECT VERSION();" --skip-column-names

# 2. PHP version
wp eval 'echo phpversion();'

# 3. Plugin updates available
wp plugin list --fields=name,version,update --format=table

# 4. Plugins hooking into affected admin screens
grep -rl "manage_posts_columns\|manage_pages_columns\|manage_media_columns" \
  wp-content/plugins/

# 5. WooCommerce version (if present)
wp plugin get woocommerce --field=version 2>/dev/null

# 6. Full database backup
wp db export ~/backups/pre-upgrade-$(date +%Y%m%d).sql

The entire checklist runs in under a minute per site. For the fleet, I wrap it in the same for site in /var/www/*/ loop and pipe to a file for review.

The Takeaway

WordPress 7.0 is a solid release, but the infrastructure requirements jump — particularly the MariaDB 10.6 / MySQL 8.0 minimum — means you cannot just click Update and hope. If you manage WordPress servers that were provisioned more than two years ago, check the database version before anything else. And if you run WooCommerce, update it first — the order matters.

The sites that went smoothest were the ones where I had already upgraded MariaDB and kept plugins current. The ones that caused headaches were running stale infrastructure with plugins that had not been touched in months. Same pattern on every major release.

---

Stop Firefighting. Start Maintaining.

I manage 70+ WordPress sites for agencies and businesses. Whether you need ongoing maintenance, emergency support, or a one-off performance fix — I can help.

View Maintenance Plans → Get in Touch →