WordPress 7.0 is bringing architectural shifts that most people will ignore until their site breaks. The Presence API feature plugin is the one worth watching now. It is an experimental layer that gives the admin system-wide awareness: who is logged in, which screens they are on, and what they are editing at that moment.
We have all hacked a version of this together with transients or custom options, and it usually ended in “ghost” editors and race conditions. This plugin formalizes that “neighborhood” feel inside the dashboard instead, without the decade of technical debt we normally pay for it.
The scalability problem the Presence API feature plugin solves
In the WP 7.0 planning sessions, the core team pinned down a real bottleneck. High-frequency ephemeral data stored in shared tables such as wp_options invalidates the persistent cache site-wide. Put 40 editors in the admin, have every move they make trigger an update, and your object cache turns into a revolving door of expired keys. Same concern I raised in my longer piece on object caching under fire.
The Presence API feature plugin gets around that with a dedicated ephemeral data table on a 60-second time to live (TTL). The Heartbeat API keeps the data moving without dragging the server down, and that is the groundwork real-time collaboration needs before it can hold up at scale.
What ships with it
- Who’s online widgets, so the dashboard tells you at a glance.
- Avatar stacks in the admin bar showing who else is on your screen.
- Post list indicators, so you see the editor already in a post before you click into it and hit a “Post Lock” surprise.
- REST endpoints and WP-CLI commands for pulling presence data into your own workflows.
To see how it holds up under density, clone the official GitHub repository or fire up a 40-user blueprint in WordPress Playground. That is the cheapest way to stress test the UI before any of this lands in core.
Integrating with the Presence API
The interesting part for developers is the data, not the UI. Presence state is queryable through standard REST endpoints, which makes it a usable source of truth for an agency dashboard or a custom editorial workflow. You can ask which users are active on a given post ID without going anywhere near post meta.
// Example: Checking for active presence on a post via PHP
function bbioon_check_post_presence( $post_id ) {
if ( ! function_exists( 'get_presence_for_post' ) ) {
return false;
}
$active_users = get_presence_for_post( $post_id );
foreach ( $active_users as $user ) {
error_log( 'User ' . $user->display_name . ' is currently viewing this.' );
}
}There is a catch, and it is that this is still experimental. Early versions got confused when a user dropped off the internet before the TTL expired, which left them sitting there as present. Do not treat the “online” status as gospel yet.
If the Presence API feature plugin is eating your dev hours, I can take it off your plate. I have been wrestling with WordPress since the 4.x days.
Where this leaves multi-user sites
Post locking on its own stopped being enough a long time ago. Moving ephemeral data out of the core tables is what makes the “neighborhood” feel Matt Mullenweg described affordable, because you no longer pay for it in TTFB. The work is happening in #feature-presence-api on Slack, which is where to look if you care about the direction WordPress collaboration takes next.
