As of June 13, 2026, WordPress 7.0 Armstrong has been live since May 20, 2026. The release delay from April 9 to May 20 matters more than the calendar shift itself. WordPress paused the cycle to finish collaboration architecture work, scheduled a host-testing checkpoint on April 24, and asked teams to treat the May 8 release candidate more like a fresh beta. For business owners, operations leads, and agency teams, that is the useful signal: WordPress 7.0 is not just a maintenance update. It changes how editorial workflows, custom fields, and hosting assumptions behave when more than one person is editing.
The practical mistake is to ask only whether the site upgrades cleanly. The better question is which content types can handle shared editing without slowing down publishing. On many sites, the platform update itself is manageable. What stalls the rollout is discovering too late that collaboration disappears on key post types, custom sidebars drift out of sync, or long editor sessions expose infrastructure weaknesses. The safest approach is to separate the platform decision from the collaboration decision and test both deliberately.
Start with the blockers that change the business outcome
| Signal on staging | Why it matters in 7.0 | What to do next |
|---|---|---|
| Classic meta boxes appear on priority post types | WordPress disables collaboration on posts where those boxes are detected. | Map each box to modern post meta, a sidebar UI, or a documented fallback before promising shared editing. |
| Critical custom fields are not REST-aware | Shared editor features cannot reliably read and sync those values. | Move toward register_post_meta() or register_meta() with show_in_rest => true. |
| Long editor sessions feel slow or cache behavior becomes odd | Collaboration adds workload patterns that can expose hosting and caching assumptions. | Run realistic multi-editor staging tests before a broad rollout. |
Custom sidebars rely on local React state or defaultValue |
Editors can see stale values after another collaborator changes the same data. | Read from the WordPress data store and use controlled inputs. |
| Servers still run PHP 7.2 or 7.3 | WordPress 7.0 raises the floor to PHP 7.4. | Upgrade PHP first; WordPress recommends 8.2+ for current environments. |
Legacy meta boxes are still the first audit item
If a key content type still depends on add_meta_box(), treat collaboration as suspect until staging proves otherwise. WordPress has been explicit: classic meta boxes are not synchronized, so collaboration is turned off to avoid data loss. That means a site can upgrade to 7.0 and still fail the business test that matters most: the editors who publish revenue-driving content cannot use the workflow they expected.
The migration direction is clear. Move important fields toward register_post_meta() or register_meta(), expose them with show_in_rest => true, and consider revisions_enabled => true when those values belong in editorial history. Also check that the post type supports custom-fields, otherwise registered meta will not be available through REST the way the editor expects. In practice, the risky dependencies are rarely glamorous: SEO panels, campaign tags, legal sign-off fields, review checklists, or old client-specific controls that nobody touched because they still worked.
Hosting is no longer a background detail
WordPress chose HTTP polling as the default sync transport for broad hosting compatibility, and developers can replace or extend that layer with the sync.providers filter if a platform genuinely needs something like WebSockets. The point is not that every host should rush into custom transport. The point is that collaboration creates workload patterns that deserve staging tests, not assumptions.
During the April 2026 release pause, WordPress said the collaboration storage model was using post_meta on an internal wp_sync_storage post type and that this disabled persistent post query caches while an editor session was open. For operations teams, that translates into concrete checks: multiple concurrent editors on staging, object-cache behavior, autosaves, publish flows, long sessions, and the effect of SSO, security plugins, or edge caching around admin traffic. If your business runs scheduled publishing windows or high-volume editorial days, this is where confidence is won or lost.
Custom editor UI can quietly break shared workflows
Even after meta has been registered correctly, plugin UI patterns still matter. WordPress recommends reading shared values directly from the editor data store and using controlled inputs. If a sidebar copies shared meta into local React state, one editor can keep looking at stale data after another collaborator changes it. Nothing crashes, but the team experiences the upgrade as flaky.
The same goes for custom blocks with side effects on insertion. In collaborative sessions, inserted block content syncs immediately, so side effects can fire for every connected editor. If a block auto-opens a modal, triggers a remote fetch, or starts a workflow the moment it is inserted, that behavior needs redesign before rollout. These are small implementation details with large trust costs once real editors hit them under deadline.
How to green-light the upgrade
A sensible 7.0 rollout is usually phased, not binary. Green-light the core upgrade when PHP, plugin, and staging checks are clean. Green-light collaboration only on the post types that pass workflow testing. That lets you move forward without forcing every legacy control to be rewritten at once.
- No classic meta boxes on the post types where teams need shared editing.
- Critical custom fields are REST-aware, revision-friendly where needed, and tested in real editor sessions.
- Staging stays responsive with two or three people editing the same content over realistic session lengths.
- PHP is at least 7.4, and ideally aligned with WordPress's 8.2+ recommendation for current environments.
If those conditions are not true yet, do not present the upgrade internally as finished. Treat it as a staged workflow program instead. If you want an outside view, Greg can audit the post types your team actually uses, trace meta-box and hosting dependencies, and turn that into a rollout plan editors can trust. Start the conversation here.
Need help with this kind of work?
Talk to Greg about a WordPress 7.0 readiness audit Get in touch with Greg.