WordPress 7.0 development is introducing some architectural shifts that most folks will ignore until their site breaks. However, the Presence API feature plugin is something you need to watch. It is an experimental layer designed to provide system-wide awareness—basically, knowing who is logged in, which admin screens they are on, and what they are editing in real-time.
In the past, we tried to hack this together with transients or custom options. Consequently, we often ended up with a mess of “ghost” editors and race conditions. This new approach aims to formalize that “neighborhood” feel within the admin dashboard without the technical debt we’ve carried for the last decade.
Why the Presence API Feature Plugin Matters for Scalability
During the planning sessions for WP 7.0, the core team identified a massive bottleneck. Storing high-frequency ephemeral data in shared tables (like wp_options) causes persistent cache invalidation site-wide. If you have 40 editors moving around the admin, and every move triggers an update, your object cache becomes a revolving door of expired keys. This mirrors the concerns I raised in my deep dive on object caching under fire.
The Presence API feature plugin solves this by using a dedicated ephemeral data table with a 60-second Time-To-Live (TTL). It leverages the Heartbeat API to keep data flowing without nuking your server’s performance. Furthermore, it provides the foundation for real-time collaboration that actually works at scale.
What’s Inside the Box?
- Who’s Online Widgets: Immediate visibility on the dashboard.
- Avatar Stacks: Seeing who is on the same screen as you via the admin bar.
- Post List Indicators: No more “Post Lock” surprises; you see the editor before you click.
- REST Endpoints & WP-CLI: Hardcore data access for custom workflows.
If you want to see how this handles density, I recommend checking out the official GitHub repository or firing up a 40-user blueprint in WordPress Playground. It’s a great way to stress test the UI before this hits core.
Integrating with the Presence API
For developers, the beauty isn’t just in the UI—it’s in the data. You can query the presence state through standard REST endpoints. If you’re building an agency dashboard or a custom editorial workflow, this is your new source of truth. Specifically, you can fetch who is currently active on a specific post ID without touching the 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.' );
}
}Wait, there is a catch. This is still experimental. I’ve seen early versions throw some weirdness when a user loses internet connectivity but the TTL hasn’t expired yet. Therefore, don’t treat the “online” status as 100% infallible just yet.
Look, if this Presence API feature plugin stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
The Senior Takeaway
The Presence API is a necessary evolution. We’ve outgrown the era where “Post Locking” was enough. By moving ephemeral data out of the core tables, we’re finally getting the “neighborhood” feel Matt Mullenweg talked about without sacrificing our TTFB. Keep an eye on #feature-presence-api on Slack—this is where the next decade of WordPress collaboration is being built.
” queries:null},excerpt:{raw:
