WordPress 5.0

WordPress 5.0 made the block editor, commonly called Gutenberg, the default editing experience for posts and pages, replacing the former single-editor workflow for most users. Content is composed from individual blocks for paragraphs, headings, images, galleries, embeds, and other elements; existing content can be handled in a Classic block. The cycle also introduced the Twenty Nineteen default theme and included the Classic Editor plugin as a way to retain the prior editor while teams adapted. This was a consequential change for custom editor integrations, metaboxes, shortcodes, page-builder workflows, and staff publishing procedures. 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.0 has reached end of life. Remaining on it leaves the site without fixes delivered in later WordPress releases, including security fixes, reliability corrections, and compatibility work for current server software, themes, and plugins. The practical risk is not limited to the editor: an old core version can prevent a team from safely updating extensions, while leaving old extensions in place increases exposure to known vulnerabilities and operational defects. Sites with custom metaboxes, editor plugins, or WooCommerce customizations may also have accumulated upgrade debt because later WordPress versions changed and expanded editor, REST API, block, and compatibility behavior. For stores, this can affect checkout, administration, payment extensions, tax and shipping integrations, and the ability to run supported WooCommerce releases.

Plan an upgrade to a currently supported WordPress release rather than treating 5.0 as a stable long-term baseline. First, take verified backups of files and the database, document the hosting PHP and database versions, and inventory the active theme, plugins, must-use plugins, custom code, integrations, and scheduled tasks. Build a staging copy using production-like data and test the target WordPress version with compatible PHP, updated plugins, and an updated or supported theme. Check publishing workflows in the block editor, custom metaboxes, shortcodes, forms, search, caching, user roles, media handling, and any front-end templates. If editors need a temporary transition path, test the Classic Editor plugin deliberately, but do not use it as a substitute for updating core. For WooCommerce sites, test catalog display, cart, checkout, account pages, transactional emails, payment and shipping methods, tax behavior, webhooks, subscriptions or bookings where used, and order administration. Schedule the production change with a rollback plan, monitor logs and key transactions afterward, and establish routine updates and backup restoration testing.