WordPress 5.4

WordPress 5.4 expanded the block editor substantially compared with earlier WordPress releases. It added the Social Icons and Buttons blocks, introduced gradient backgrounds for blocks, improved block color controls and reusable-block workflows, and added a welcome guide and a more streamlined editor interface. The editor also gained a default full-screen editing mode, while retaining a way to switch modes. Other changes included a Site Health Status widget on the dashboard, additional privacy-export information, updates to theme and plugin developer APIs, and general accessibility and performance work. These changes mattered most to sites using the block editor: custom themes, custom blocks, editor integrations, and documented authoring procedures may have needed adjustment. WooCommerce is a plugin that runs on WordPress, so a WooCommerce store is a WordPress site and its WordPress version matters to it just as much as its WooCommerce version does.

WordPress 5.4 has reached end of life and no longer receives security or maintenance fixes for that release line. Remaining on it leaves newly discovered core issues uncorrected and makes it harder to maintain a defensible patch-management position. The larger operational risk is dependency drift: current plugins, themes, WooCommerce extensions, payment gateways, hosting stacks, browsers, and supported PHP versions increasingly target newer WordPress APIs and behavior. A site can appear to work while still carrying unsupported components, then fail during a routine plugin, PHP, database, or infrastructure change. For WooCommerce sites, this can affect checkout, payment callbacks, order administration, tax and shipping integrations, customer accounts, and the block-based editing experience. Delaying the move generally increases the number of WordPress versions, database changes, plugin updates, and compatibility assumptions that must be validated in one project.

Plan an upgrade to a currently supported WordPress release rather than treating 5.4 as a stable long-term baseline. First, create tested backups of both the database and all site files, including uploads, themes, plugins, configuration, and any must-use plugins. Build a staging copy on the target hosting and PHP version, inventory every active and inactive plugin, theme, child theme, custom block, integration, scheduled task, and external API dependency, and replace or remove unsupported components before the production move. Upgrade WordPress and its dependencies in staging, then test public pages, login and role permissions, the block editor, media handling, forms, search, redirects, REST or webhook integrations, caching, and error logs. For a WooCommerce site, test catalog display, cart, checkout, payment authorization and callbacks, order emails, refunds, taxes, shipping, subscriptions or memberships, and background jobs using representative test transactions. Review custom code for deprecated WordPress APIs and assumptions about editor markup or block behavior. After a documented rollback plan and maintenance window are in place, deploy the validated upgrade, monitor logs and business-critical flows, and establish an ongoing process for core, plugin, theme, PHP, and extension updates.