On 8th December 2026, WordPress 7.2 arrives: a new version of the software that runs most of the world’s websites. This is not something to worry about. It is a date in the diary, and the genuinely interesting part is not the day itself but the eight weeks that come before it, where a quiet, public, oddly methodical process decides what that update will contain.
WordPress 7.2 is the next major version, and the core team published its full timetable on 6th October. Here it is, start to finish.
The calendar
- Beta 1: 20th October 2026
- Beta 2: 27th October 2026
- Beta 3: 3rd November 2026
- Beta 4: 10th November 2026
- Release Candidate 1: 17th November 2026
- Release Candidate 2: 24th November 2026
- Release Candidate 3: 1st December 2026
- Dry run and 24-hour freeze: 7th December 2026
- General release: 8th December 2026
Four betas and three release candidates, a week apart, then a day on which nothing is allowed to change, and then the release.[1] What that list shows, more than any description could, is that this is an engineered process rather than a software company pushing a button one morning.
What a beta is, and why there are four
A beta is a version released early and on purpose, so that people can find what does not work while there is still time to fix it. It is not finished, and it is not meant to be. Anyone can install it, try their site on it, and report anything odd.
Four of them, a week apart, in the open. Each beta gathers what the last one’s testers found, folds in the fixes, and asks the same question again: what else is broken? A large number of people around the world do exactly this for free, which is one of the quiet strengths of software this widely used.
What a release candidate is, and why there are three
A release candidate is the team saying, in effect, “we think it is finished.” It is the version they would ship, offered up one more time for the world to prove them wrong.
There are three of them. That is worth a second’s thought. Scheduling three release candidates is the team planning, in advance, to be told twice that it is not quite done yet. That is not a lack of confidence. It is the opposite: it is how you build something dependable, by assuming you have missed something and leaving time to be shown what.
The day nothing happens
The detail most likely to stay with you is 7th December. The day before release, nothing is allowed to change. A full day set aside for deliberately not touching anything, so that what ships on the 8th is exactly what was tested on the 6th, with no last-minute cleverness slipped in behind it.
Most small businesses have no equivalent of that, and most would be better for one. There is a lot of wisdom in a rule that says the safest thing to do, right before something important, is nothing at all.
One real change, and why it makes the point
On 9th October the core team published a note about one confirmed change in 7.2, and it is a lovely example of what all this testing is actually for. WordPress is changing a small detail of how it talks to its database, a setting with the unlovely name NO_BACKSLASH_ESCAPES, which it will now switch off on its own database connections.[2]
Almost nobody reading this needs to understand that, and that is precisely the point. For very nearly every website, the change will make no visible difference at all. For a small number, with an unusual database setup or a plugin that leaned on the old behaviour, it could. The core team’s own note says most sites will not notice.[2]
So the shape of it is this: a change that is invisible on 99 sites out of 100, and quietly consequential on the hundredth. No site owner is ever going to find that sentence in the release notes, work out what it means, and check their own site against it. Somebody has to, and that somebody is whoever looks after the website.
How would you know if you were the hundredth?
Honestly, you would not. Not from reading about it, and not on the day. The only way to know which group your site is in is for someone to take the new version for a run against a copy of your site, before December, and look at what happens.
That is the whole job, and it is less mysterious than it sounds. You take a copy of the site, never the live one. You install the beta on the copy. You then use the pages that actually matter: the contact form, the checkout, the booking calendar, the member login, the things that would genuinely cost you something if they stopped working. You check the plugins you depend on against what has changed. Anything that goes wrong, you find in October and sort out in October, instead of a customer finding it for you in December.
And if you would rather do it yourself
Some readers can do exactly that, and should. If you are comfortable taking a staging copy of your site and trying the beta on it, please do, and test the things that earn you money rather than the homepage. It is good practice and it costs nothing but an afternoon. Being able to do it yourself is a perfectly good reason not to pay anyone to do it for you.
Where we come in
Here is our part, and it is deliberately undramatic. Keeping up with WordPress as it changes is simply part of what managed hosting is, and a dated, public, eight-week release like this one is the easy kind to plan for. If you are already with us and you would just like to know that December is somebody’s job rather than yours, it is, and you are welcome to ask what that looks like for your particular site. If you are not a customer and you would rather be sure before the day, we can do it as a single, self-contained piece of work: take a copy of your site, install the 7.2 beta on the copy, exercise the pages that actually matter to you, and send you a short written note of what we found. One job, one result, nothing ongoing. Whichever applies to you, there is nothing you need to do today, and saying so now rather than in December is rather the point of this article.
Because if all of this is done properly, 8th December will be a day on which nothing happens to your website at all. No outage, no broken checkout, no surprise. Success here looks exactly like an ordinary Tuesday, which is a strange thing to take pride in, and we do.
Related reading
- What actually stops your neighbour on shared hosting reaching your website
- Uptime and monitoring explained, or the work you only notice when it stops
Sources
- WordPress 7.2 release schedule, Make WordPress Core, published 6th October 2026.
- NO_BACKSLASH_ESCAPES SQL mode is now turned off by default in WordPress 7.2, Make WordPress Core, 9th October 2026.
