WordPress 7.2 Beta 1 came out on 20 October, and the final release is scheduled for 8 December 2026. That gives you seven weeks to find out what it does to the 40 sites you look after, and it lands two and a half weeks before Christmas, which is exactly when nobody wants to be restoring a client's checkout page. Here is how I'd run it.
What is confirmed, and what is still a beta
The dates come from the official schedule on make.wordpress.org/core/7-2/ (checked 21 October 2026): Beta 1 on 20 October, Beta 2 on 27 October, Beta 3 on 3 November, Beta 4 on 10 November, Release Candidate 1 on 17 November (that is the hard string freeze and the point where the branch is created), RC2 on 24 November, RC3 on 1 December, a dry run with a 24-hour code freeze on 7 December, and the release itself on 8 December. WordPress release dates do slip, and the "Help test 7.2" post on the test team's blog says 9 December, so treat the week of 8 December as the target rather than the day.
What is in the beta, per the Beta 1 announcement and the test team's call: admin scripts and stylesheets now load as individual files instead of concatenated bundles (the old load-scripts.php and load-styles.php paths are retired), a prefetching mechanism that loads assets for the admin screen you are likely to open next, client-side media processing that resizes uploads in the browser before they hit the server, Dashicons in the admin bar and menu replaced with SVG icons, a new Secrets API for credential storage, a new post settings sidebar built on DataForms, collaboration Notes improvements, text shadow and responsive design controls, a new default theme called Ipsum, and an "On This Day" dashboard widget.
Two things the announcement does not state: a change to the minimum PHP version, and a list of breaking changes. Until the Field Guide is published at RC1 on 17 November, treat the feature list as "likely" and the dates as "planned". I am not going to tell you what 7.2 requires until the people shipping it do.
The five changes most likely to touch a client site
Most of 7.2 is editor and admin work that a client who logs in once a month will never notice. Five items deserve a line in your test plan.
The removal of script concatenation matters if anything on the site references those two retired paths. Security hardening snippets and some host-level rules block or rewrite load-scripts.php; those rules stop doing anything, which is harmless, but a plugin that assumed the bundled path existed is worth a look. The Dashicons-to-SVG swap in the admin menu will change how custom admin menus look if a plugin or your own white-label code styles them by icon class. Client-side media processing changes the upload path, so test an upload from a client's laptop on every site where you have a plugin hooking into image generation, and on every site where the client uploads 8 MB photos straight from a phone. The new post settings sidebar means the "Publish" panel your clients were trained on looks different, which is a support question, not a bug, but you will get it ten times if you do not warn them. And Ipsum is a new default theme, which on a major update gets added to the themes list of existing sites: an inactive theme is still code on the server, so either delete it or keep it patched.
A staged rollout for 40 sites
Do not update 40 sites on 8 December. Here is the sequence I use, with the arithmetic.
Start with staging copies of your three most complex sites (WooCommerce, a membership plugin, a page builder) the week RC1 lands, 17 November. If you do not run staging for everything, that is fine; the earlier post on which care-plan sites need staging still holds, and the ones that do are the ones you test first. Then on release day, update the five lowest-risk production sites: brochure sites, a block theme, no e-commerce. Wait 48 hours. Then do the next 15 in two batches, and finally the 20 that take payments or logins, one batch per day. That is 40 sites across roughly a working week, and if the first five break, you have broken five.
Before every single update, the non-negotiables are:
- A restore point taken immediately before the update, not the nightly backup from eleven hours ago.
- A screenshot of the home page, the contact page, and the one page that makes the client money, taken before and after, and compared.
- Someone checking the result within the same day, so a rollback happens before the client notices.
Check your auto-update settings now. Minor releases update themselves by default; major releases do not, unless someone has clicked "Enable automatic updates for all new versions of WordPress" on a site. On a portfolio of 40, somebody has. Those sites will take 7.2 on 8 December whether you tested or not, so either switch them back to minor-only until you have run your first batches, or accept that they are your canaries.
Plugins, themes, and the PHP question
Compatibility work starts with the plugins that touch the admin, media, or the editor, because that is where 7.2 changed things. Run the plugin list on your three test sites against the "Tested up to" line in each plugin's readme during the RC period; vendors that care will have bumped it to 7.2 by the end of November. For a plugin that has not been updated in a year and has not been tested past 6.x, the update is not the risk, the plugin is.
Page builders and premium themes are the usual suspects: the new responsive style controls and the DataForms sidebar touch exactly the parts of the editor that Elementor, Divi and Bricks replace or extend. Test those sites in staging before anything else.
Then PHP. WordPress 7.2 has not announced a new PHP minimum, but PHP 8.2 stops receiving security patches on 31 December 2026, 23 days after 7.2 ships. If you are already planning an update window for 7.2, you are already planning the one for PHP 8.3 or 8.4; the PHP 8.2 end-of-life audit for your client portfolio walks through how to do both in one pass, and doing the PHP move first on the test sites means your 7.2 testing covers the stack you will actually be running in January.
What to tell clients, and when
Clients do not need the feature list. They need three sentences, in the second half of November: WordPress has a major release in early December, we will update your site in a planned window between date X and date Y, and the editing screen will look slightly different afterwards; here is a 60-second screenshot walkthrough. Send it once, before you start, and then one line in the monthly report confirming it is done. If you charge for a care plan, this is the moment the client sees what they are paying for; do not do it silently.
Where this changes the ticket queue is the post settings sidebar. A client who publishes a blog post every week will notice the different panel on their first login after the update, and "where did the publish button go" costs ten minutes a time. The walkthrough prevents the ticket.
Where this leaves you
Seven weeks is enough to do this properly: test three staging sites at RC1, update five low-risk sites on 8 December, finish the rest by the following week, and never once update without a restore point and a before-and-after screenshot. If you want a dashboard that takes the restore point, runs the screenshot diff and holds the rollback button for every site in one place, WPClientHub does exactly that, free for 3 sites, paid plans from $19/month. You can set up the first batch at app.wpclienthub.com before Beta 2 lands next Tuesday.