WordPress 7.0: What it brings to higher education

WordPress 7.0 releases on 20th May. It has been delayed a couple of times because the core team found performance problems in the real-time collaboration features after entering the release candidate phase, which is unusually late to be reworking foundations, and they decided to fix it properly rather than release and patch later. That’s a good signal about the overall quality bar for this release.

The WPCampus and Human Made “State of WordPress in Higher Education” survey, published last year and covering over 100 HE professionals, found that WordPress is genuinely thriving in the sector, but that confidence in its direction is mixed, with 62% of respondents reporting internal discussions about whether to continue using the platform. The top concerns weren’t features; they were editorial workflows, accessibility, governance, and under-resourced teams. Seventy percent of respondents said WordPress meets or exceeds their expectations. But 69% reported insufficient headcount, and nearly a third identified training gaps as a material problem.

WordPress 7.0 addresses several of those concerns directly, and does so in ways that are particularly relevant to how universities actually operate.

The defining feature of 7.0 is real-time collaboration. Multiple users can edit the same post or page simultaneously.

With live presence indicators, and changes syncing automatically when a user reconnects after going offline, 7.0 is bringing that Google Docs editing experience to WordPress. The Notes feature which provides threaded, block-level comments introduced in 6.9gains real-time syncing in 7.0, and email notifications now send when a note is added to a post you authored, keeping asynchronous review cycles moving even when contributors aren’t simultaneously online.

This matters to universities because the editorial workflow problem in HE is not simply one of too many people editing; it’s one of too many handoffs across too many roles with too much distance between them. A piece of content might move between a departmental author, a faculty web editor, a central communications team, and a legal or accessibility reviewer. Currently that round-trip happens partly in WordPress and partly in email or Slack or a shared Google Doc, which fragments the record of what was decided and why.

7.0 doesn’t fully solve that because it’s the beginning of Phase 3 and not the end but it brings the conversation into the same place as the content. For institutions that need an audit trail of editorial decisions (and many do, for FOIA, accessibility compliance, or institutional governance reasons), that consolidation has real value.

An admin that reflects how teams actually work

The WordPress admin has looked essentially the same since 2008. 7.0 replaces the legacy WP List Tables with DataViews which are a modern interface for browsing posts, pages, and media. The new interface supports customisable grid, list, and table layouts with browser-side filtering and sorting. No full page reloads and a cleaner visual language that aligns the classic admin with the block editor.

For a content administrator managing several hundred pages across a complex university site, the old list table was genuinely slow and frustrating to work with. DataViews makes content management feel more like a modern application and less like an aging spreadsheet.

Visual “Revisions” also lands in 7.0: a proper inline, block-level differential view that lets editors compare versions of content visually rather than wading through raw code comparisons. For institutions where multiple contributors have touched a page over several years, this is a meaningful improvement in editorial safety.

Consistency becomes easier to enforce

Many Universities run large and distributed WordPress estates. A single multisite installation might serve hundreds of faculty sites, student publications, research project microsites, and the main institutional site. Those each have different editors, different levels of WordPress experience, and different interpretations of brand guidelines.

7.0 continues the work on design system enforcement that’s been building across recent releases. Patterns are easier to treat as genuinely governed components rather than flexible starting points. Templates are clearer about what can and cannot be modified. Block-level controls behave more consistently across contexts. The effect is that brand and accessibility standards get reinforced by the platform rather than depending on editors remembering to follow documentation.

The new ‘iframed’ editor contributes here too. Styles are properly isolated which means that what editors see in the editor matches what renders on the front end, without bleed from admin styles or theme quirks. That gap between preview and published output has been a persistent source of small errors in large WordPress installations, and closing it removes a category of problem rather than fixing individual instances of it.

AI foundations

7.0 introduces a Web Client AI API and a Connectors UI: a provider-agnostic, standardised interface that lets plugins connect to external AI services, with a single management screen in the dashboard where site administrators can add, test, and remove those connections. No AI model is bundled in core; the platform provides the integration point and the governance layer, and AI capability comes from registered providers.

The Abilities API, which landed on the backend side in 6.9, now has its JavaScript counterpart. This creates a machine-readable registry of capabilities that AI tools such as browser agents and MCP integrations.

For universities, this is an interesting architecture. Higher education has significant concerns around AI governance (e.g. data residency, vendor lock-in, accessibility of AI-generated content, and compliance with institutional and regulatory policies). A standardised integration layer in core that doesn’t prescribe a specific provider is a more sensible foundation for institutions that need to make deliberate, auditable decisions about which AI tools they deploy and under what conditions. The alternative of each team installing their own AI plugin with its own data-handling model is already happening, and it’s a governance problem.

What to look at before 20th May

If you’re running WordPress in higher education, this is a release worth preparing for rather than just applying when the notification arrives.

The iframed editor is the most likely source of compatibility issues. Anything that touches the editor DOM directly such as custom editor tooling, certain page builder integrations and some older plugins may need updating. Test in a staging environment first.

The DataViews admin overhaul is the second area of risk. Plugins that modify the Posts, Pages, or Media list views are the most exposed. Check release notes and changelogs and if a plugin hasn’t issued a 7.0 compatibility statement then test it before going live.

PHP 7.4 is the new minimum (previously 7.2). Sites on older PHP versions won’t be able to update at all. PHP 8.3 is recommended for performance so if your hosting environment hasn’t been reviewed recently then do that before the release date.

None of this is unusual complexity for a major release. But 7.0 touches more of the stack than recent releases have: the editor architecture, the admin interface, the permission model, and the developer APIs are all moving at once.

The longer picture

The WPCampus survey found that 62% of HE institutions are in “wait and see” mode on WordPress. They’re not planning to leave, but watching to see whether the platform’s direction matches what they need and the concerns that put them in that position such as workflow support, governance tooling, accessibility, platform stability are the problems 7.0 is aiming to address.

It won’t resolve everything. Accessibility-related plugin quality remains patchy. Full Site Editing is still not widely adopted in HE, with the survey finding 62% not using it at all. Under-resourced teams don’t become better resourced because the platform releases a new version.

But the trajectory is the right one. The platform is pulling governance, consistency, and workflow support into core rather than requiring institutions to solve those problems themselves through accumulated plugin layers. For universities that have been running WordPress at scale for a long time, this is a strong positive direction and 7.0 is a meaningful step along it.