The standard advice after a major WordPress release is to wait a few weeks and update quietly. I keep the waiting part. What I skip is treating release week as dead time, because this is when the field guide and dev notes land, and an hour of reading now is cheaper than an emergency later. Amy Kamala posted the May 27 dev chat agenda on Make WordPress Core, and it sums up the week: 7.0 is out, three dev notes landed, and the WordPress 7.1 release cycle opened the same week.
I run the same small triage on every agenda like this one. It takes four passes and roughly an hour, and by the end I know which sites need what before anything auto-updates.
What the agenda contains
- WordPress 7.0 “Armstrong” shipped, with the release post on WordPress.org.
- New dev notes: the 7.0 accessibility improvements, removing title attributes in author link functions, and the 7.0 Field Guide.
- Operation WP 7.1 opened the next cycle, followed by a call for volunteers.
- General items: a call for testing the Media Editor modal, a PHP support clarification, unicode support in email addresses, usernames and slugs, and Gutenberg 23.2.
The field guide counts more than 419 Trac tickets, over 76 of them enhancements, and more than 300 bug fixes. I don’t read all of it. I read the sections that touch what each site runs, which for most of my clients means the editor, media handling, and users.
The four passes, in order
- Read the dev notes before the release post. The release post tells you what’s being promoted, and the dev notes tell you what changed under your code. This week the title attribute removal in author links is the one I care about, because every classic theme I’ve inherited has markup assumptions somewhere, and a missing attribute breaks anything that was string-matching it.
- Match the quiet items to the stack. The PHP support clarification matters because 7.0 raised the minimum to PHP 7.4, and hosts move at different speeds. Before I tell a client when to update, I check what PHP their box runs and read the clarification post once.
- Answer the testing calls that fit the site. The Media Editor modal call for testing is aimed at media-heavy installs, and product galleries qualify. Thirty minutes on staging beats finding the rough edges during a busy product upload.
- Mark the 7.1 dates, then pick your 7.0 window. The cycle opened May 20, so two cycles overlap for a while. I’d rather push clients through 7.0 before the 7.1 betas start competing for attention.
The email item is the one that reaches checkout
Unicode support for email addresses sounds niche until a store sells outside ASCII-only markets. WooCommerce checkout, account creation and order confirmations all run on email. The failure mode sits downstream of core: newsletter plugins, CRM connectors and SMTP relays that run their own validation, or choke on addresses core now accepts. An order that places cleanly and never gets its confirmation email is a delayed support ticket.
So before assuming anything, run this on a staging copy of a 7.0 site and see what comes back:
wp eval 'var_dump( is_email( "josé@exämple.test" ) ); var_dump( sanitize_email( "josé@exämple.test" ) );'
If core returns the address, the next hop is the real test: push the same address through checkout, the order email, and whatever connector hands addresses to your email provider. (I haven’t seen that combination break yet, so it gets tested rather than assumed.)
The WordPress 7.1 release clock is already running
Operation WP 7.1 formally opened the cycle on May 20, with the call for volunteers a day later. Gutenberg 23.2 shipped as a plugin, which means editor behavior can shift under a site between major releases even when core itself hasn’t changed. And 7.0 has already had one hotfix round delivered as plugin updates, so I’m not treating it as settled yet.
If you’d rather hand this off, it’s the kind of work I do regularly: I read the notes, test the risky parts on staging, and tell you which week each site should update. Send me your stack and I’ll point out where the risk sits.
Either way, start with one search: grep your active theme and child theme folders for the_author_posts_link and for filters hooked onto the author link, because the 7.0 title attribute removal stays invisible until a theme that quietly parsed its own markup meets it.