The release is still in development
As of October 15, the official WordPress 7.2 schedule lists Beta 1 for October 20 at 15:00 UTC and a final release planned for December 8. That is the project’s current target, not a guarantee that dates or scope cannot change. The release team says 7.2 is intended to be the final major WordPress release of 2026 and that a new default theme is planned alongside it.
This timing places site owners in preparation mode, not production-upgrade mode. Before Beta 1, contributors are still developing and testing. During beta and release-candidate stages, the project asks the community to test and report problems; those builds are for staging and evaluation, not ordinary live sites. Follow the release page and dev notes because the final release is where the stable upgrade decision can be made.
A confirmed database compatibility change
One 7.2 developer note already describes a concrete change: WordPress will treat the MySQL `NO_BACKSLASH_ESCAPES` SQL mode as unsupported and remove it from the session modes when WordPress connects. The documented reason is that WordPress uses backslashes to escape special characters in SQL; with this mode enabled, the database interprets them differently. The change is session-level, not a rewrite of the server’s global configuration.
The Core team says most sites should not notice a difference, while warning that WordPress may not work correctly if the mode remains enabled. A site that deliberately depends on it needs a developer review; the documented compatibility filter must be configured early enough, because the database connection is established before ordinary plugins load. This is a targeted compatibility note, not a reason for every site to edit database settings.
Do not mistake Gutenberg releases for core commitments
Gutenberg continues to ship on its own release cadence, and its latest release notes can include work that may or may not be included in a particular WordPress core release. The 7.2 roadmap identifies a new default theme and says features will be considered when reasonably ready, but it is not a frozen list of all editor changes. Beta-stage developer notes and the eventual field guide are the more reliable references for changes affecting themes and plugins.
For an agency, the practical question is not “what is in Gutenberg today?” but “what code is in the 7.2 beta and final build?” Compare the release candidate against the exact plugins, theme, editor extensions, custom blocks, PHP version and hosting stack each client uses. Check whether dependencies have declared compatibility and test the actual site behavior instead of relying on a plugin badge alone.
A safe preparation checklist
Create a staging copy with current backups and a repeatable restore path. Record WordPress, PHP, database and plugin versions; note custom code that changes SQL behavior or registers editor interfaces. When Beta 1 is available, test a representative site rather than a blank installation: publish and edit content, preview templates, run scheduled tasks, submit forms, check payment or membership flows, and inspect logs for warnings.
Keep production on the supported stable release until WordPress publishes 7.2 as final and your own checks pass. During beta, report reproducible bugs with environment details and a minimal test case. After release, update staging first, confirm backups and rollback procedures, then schedule production updates according to each site’s risk and maintenance plan. Do not promise compatibility before testing.
Sources & further reading
Have a factual correction or a source to suggest? Contact the editorial desk.
