The Presence API is a WordPress feature plugin that shows who is logged in, which admin screen they are on and which posts they are editing. It is not real-time co-editing, it is not part of WordPress core, and nothing I read says it is headed for WordPress 7.2. I read the core team’s two announcements, the plugin directory listing and the related collaboration posts on 7 October 2026, so the details below are current to that day, and I flag every place where the sources disagree or go quiet.
The Short Answer
- What it is: an experimental awareness layer for the admin. It records who is online, where they are, and which posts they have open, and it shows that in the admin bar, the post list and a few dashboard widgets.
- Where it lives: a plugin in the WordPress.org directory, listed as developed by the WordPress.org team. Version 0.15.0 was the current release when I checked, it needs WordPress 7.0 and PHP 7.4, and it showed 10+ active installations.
- Is it in WordPress 7.2? I found no sign of it. The Roadmap to 7.2 does not mention it, and the plugin describes itself as an exploration for some future release, with no version named.
- Does it replace real-time collaboration? No. Presence tells you who is around. It does not merge anyone’s edits.
- Should you install it? On a staging site if you run a team, yes, and read the privacy section first. On a production site that matters to you, wait.
What The Presence API Actually Is
The core team announced the plugin on 27 April 2026 and described it as an experimental feature plugin that provides a system-wide awareness layer. The announcement lists three gaps it targets. There is currently no way to see who else is logged in to the admin. A post that someone is editing is only surfaced when a lock collision happens, by which point work may already overlap. And the post list gives no hint of which posts have active editors until you try to open one.
The background explains why it is a separate plugin rather than a core patch. During WordPress 7.0 development, a discussion on ticket #64696 concluded that storing high-frequency throwaway data in shared tables invalidates persistent caches across the whole site. The plugin was built to test that workload on its own, using a dedicated table for short-lived rows. The data flows through the existing Heartbeat API. According to the announcement, the plugin was presented at a core dev chat, moved to the WordPress GitHub organization and submitted to the plugin directory on 6 April 2026.
That design choice is the interesting part. Presence data is noisy by nature, since every logged-in user generates a regular ping. The directory listing says the plugin keeps it in a dedicated wp_presence table and avoids writing to wp_postmeta, which means no post-cache invalidation on every heartbeat.
What The Plugin Does Today
The directory listing names five visible features, and the April and October announcements add detail to each one.
- Admin bar indicator: an avatar stack and an “online” count. Open the menu and you see who shares your screen first, then everyone else grouped by the post or screen they are on.
- Active Posts dashboard widget: posts and pages grouped by who is editing them.
- Editors column in the post list: faces next to each post, plus a lock icon and a note such as “Quinn Roberts is currently editing” on locked posts.
- Online filter in the Users list: a view that shows only people who are online right now.
- Agent labels: AI agents get a badge in the admin bar, the widget and the Editors column once another plugin marks them as agents. More on that below.
Underneath those screens there are REST endpoints and WP-CLI commands, and on multisite the Network Admin gets its own view. The listing says a network-activated install adds a Who’s Online widget listing the busiest sites, an Online column in the Sites list, and an Online view, filter and column in the Users list. Those network views need the manage_network capability, which on a default network means super admins.
Is Presence API Coming To WordPress 7.2?
This is the question people will search, so I checked it from the sources rather than guessing. The short answer is that I could not find any commitment to put it in 7.2, and the sources I read still describe it as a feature plugin.
- The plugin directory calls it a feature plugin sponsored by the WordPress Core team, “exploring what system-wide presence could look like for a future WordPress release”. That wording does not name a version.
- The April announcement calls it experimental and asks for feedback on whether the screens are useful. It does not mention a merge proposal.
- The Roadmap to 7.2, published on 18 September, does not mention Presence API anywhere. It adds the usual caution that what it lists is being actively pursued but does not necessarily mean each item will make the final release.
- The roadmap’s Collaboration section says collaborative editing is intentionally not on the roadmap for 7.2, because more time is needed for a number of architectural decisions.
Absence from a roadmap is not proof. The roadmap post itself says it describes work being pursued, and a feature plugin can still be proposed for merge later. What I can say is that the plugin is the only place you can get Presence API today, and that the dates around 7.2 give it little room to appear unannounced. The release schedule post says WordPress 7.2 is due on 8 December 2026, with Beta 1 on 20 October and Release Candidate 1 on 17 November. If you want the full feature list for that release, our guide to WordPress 7.2 and its roadmap tracks it.
| Date (2026) | Milestone | Source |
|---|---|---|
| 6 April | Submitted to the WordPress.org plugin directory | April announcement |
| 27 April | Feature plugin announced | April announcement |
| 18 September | Roadmap to 7.2 published, no mention of Presence API | Roadmap to 7.2 |
| 2 October | Update post, version 0.14.0 listed as current | Presence API: What’s New |
| 20 October | WordPress 7.2 Beta 1 | Release party schedule |
| 17 November | WordPress 7.2 Release Candidate 1 | Release party schedule |
| 8 December | WordPress 7.2 general release | Release party schedule |
How Presence Differs From Real-Time Collaboration
People mix these up because both live under the “real-time” banner, and the plugin’s own tags include real-time. They solve different problems.
| Question | Presence API | Real-Time Collaboration |
|---|---|---|
| What does it answer? | Who is here, and where are they? | How do two people edit one post together? |
| Does it touch post content? | No, it stores short-lived awareness rows | Yes, it merges edits between collaborators |
| Where does it run today? | Feature plugin, needs WordPress 7.0 | Experiment in the Gutenberg plugin, removed from WordPress 7.0 |
| Transport | Heartbeat API | Still being decided, with several server-aware engines under test |
| Core status | Feature plugin, no merge commitment found | Not on the 7.2 roadmap |
The September collaboration post shows why the second column is still unsettled. It says real-time collaboration was removed from WordPress 7.0 earlier this year. Its authors argue that merging edits only in the browser leaves the server unable to say who wrote what, unable to take part when a script or the REST API changes a post, and unable to mediate when two editors drift apart. Their proposal is a server-aware approach where every update goes through WordPress. The post says the exploration is early and not ready for Core inclusion, and that the team has built three candidate sync engines in a separate repository: a PHP implementation of Yjs, a three-way merge called Distributed Editing, and an operational transform engine called Intent log.
I covered the practical side of that proposal in our earlier post on WordPress real-time collaboration and the server-aware approach. The short version for this post: collaboration is the hard, slow part, and presence is the small, shippable part. A site can get value from knowing who is around long before anyone solves merging.
Where The Two Projects Already Touch
They are separate, but not strangers. The October update says the Gutenberg Sync Engines plugin, which is the exploratory tool for server-aware collaboration, keeps who is in the editor in the presence table when Presence API is active. The post suggests opening the debugger in the RTC Playground, where those rows start with gse-. That tells you where the core team thinks awareness data should live, and nothing more.
What Changed Between April And October
The October update lists what shipped since April. The directory changelog adds the newest release. A few items matter more than the rest.
| Version | What changed | Source |
|---|---|---|
| 0.12.2 | Each presence query is read once per request until the table changes; one visible tab per site sends the Heartbeat ping | Directory changelog, update post |
| 0.13.0 | An AI agent gets a presence row when it saves a post, with an Agent badge | Directory changelog, update post |
| 0.14.0 | REST entries no longer include color; the block editor’s color is used instead | Directory changelog, update post |
| 0.15.0 | Actions fire when a presence row is set or removed; sites can switch off pieces such as post locks; switches move to a plugin page under Settings | Directory changelog |
One discrepancy is worth stating plainly. The 2 October update post says the current version is 0.14.0. The directory listing I opened on 7 October says 0.15.0 and shows it as updated one day earlier. That is not an error on anyone’s part. It means the plugin is moving fast, and the 0.15.0 items above appear only in the directory changelog, not in the update post.
Privacy, Roles, And Who Can See What
A plugin that records where every logged-in user is deserves a close read of its privacy behaviour, and the update post is direct about it. Recording is on by default. You can switch it off for one site on Settings, General, or for every site in a network from Network Admin, Settings. If either switch is off, recording is off. Post locks keep working either way. From WP-CLI, the command is wp presence recording set off, with --network for the whole network. The post also says a privacy policy section, an exporter and an eraser cover presence data.
Visibility is separate from recording. Everyone online still appears in the admin bar, but where they are now sits behind the view_presence_location capability, which maps to list_users by default. Everyone can always see their own location. In practice that means administrators see which post each person has open, while an editor sees only who is online. The April announcement says all features were gated on the edit_posts capability, and the October post adds that roles who can edit only pages or a custom post type now get presence too.
Before enabling it on a client site, decide whether to leave recording on and restrict who sees location, or turn recording off and keep only post locks. The plugin gives you both options.
AI Agents In The Presence List
This is the part I find most useful for sites that use automation. An AI agent editing over REST or MCP sends no Heartbeat, so it would not show up on its own. Since 0.13.0, each save writes a presence row for the agent in that post’s room, and the row expires about 75 seconds after its last save by default. The row appears in the admin bar and the Editors column with an Agent badge.
The plugin does not decide who counts as an agent. It asks the Agent Users plugin through wpai_is_agent_user() when that is loaded, and any plugin can answer through the wp_presence_is_agent_user filter. With neither in place, nobody is labelled. So the badge is only as good as whatever identifies your agents. If you are comparing the tools that connect agents to WordPress, our comparison of WordPress MCP plugins covers the options, and none of that changes how this badge works.
Performance And Heartbeat Costs
The honest worry with any presence feature is load. The update post gives some numbers. In 0.12.2, each presence query is read once per request until the table changes, which took a Users screen heartbeat from six presence reads to two. The plugin stopped checking its tables on every admin page, and only one visible tab per site sends the Heartbeat ping, while background tabs stop sending presence and idle screens back off automatically. Site Health now tells you when Heartbeat cannot keep presence current.
What I cannot give you is a benchmark. I did not measure database load, Heartbeat traffic or admin responsiveness with the plugin active, and the update post does not publish site-level numbers beyond the six-to-two read count. If you run a large editorial team on modest hosting, test it on a staging copy with realistic editor counts before you decide.
What I Saw When I Ran The Demo
The plugin’s announcements link to WordPress Playground blueprints with seeded editors, so I opened one on 7 October 2026 and went to the Posts screen. It took roughly a minute to boot. The admin bar showed “101 online”, and four posts carried lock icons with notes naming who was editing, alongside an Editors column of overlapping avatars.
Two caveats. The April announcement describes a 5-user blueprint and a 40-user blueprint, yet the one I opened showed 101 people online, so the seeded data has evidently changed since April. I did not work out which blueprint file produces which count. And Playground is a seeded demo in a browser tab. It shows what the screens look like when populated, not how they behave with real people on real hosting.
Should You Install It?
My rule of thumb is based on the plugin’s own label. It calls itself experimental, and the version number is 0.15.0. That is a good reason to try it and a bad reason to depend on it.
Try It On Staging If
- You run a multi-author site and have collided on posts before.
- You manage agents or automations that write to posts and want them visible in the admin.
- You want to give feedback to the core team, who ask for it in the #feature-presence-api channel on WordPress Slack and in GitHub Issues.
Wait If
- You are a solo site owner. The plugin will have little to show you.
- Your hosting is already tight on Heartbeat or admin-ajax load, and you have no staging site to measure on.
- You cannot document a new category of stored user activity for your own privacy policy.
Before any of that, keep the basics current. The plugin lists “tested up to” 7.1.3, which is newer than the point releases we covered in our WordPress 7.1.1 and 7.1.2 security releases write-up, so update core first and test the plugin on top of it. For the editor side of the same month, our write-up of Gutenberg 24.1 covers what the editor itself gained that cycle.
Where Nexter Fits
I work on the Nexter side, so weigh this section with that in mind. Nexter Blocks and Nexter Extension do not depend on the Presence API, and neither adds presence or collaboration features. They are block and site-building tools, not an awareness layer. I have not tested either one running alongside the Presence API plugin, so I will not claim compatibility or conflicts. If you try the combination on staging, it is a short test: install the plugin, open a page built with Nexter blocks in two browsers and watch the Editors column.
What This Doesn’t Cover
I did not install Presence API on a real WordPress site. My only hands-on contact was one run of the plugin’s Playground blueprint, which is a seeded browser demo. I have no performance measurements, no database comparison and no view of how the plugin behaves on shared hosting, behind a page cache or with a persistent object cache. I did not read the GitHub repository, the issue tracker or the full changelog history, so anything about 0.15.0 comes only from the four changelog lines in the directory listing. I did not test the Agent Users integration, the multisite views or the WP-CLI commands. I also did not verify the plugin’s privacy exporter and eraser, and I am relying on the update post for that.
Everything else comes from five pages read on 7 October 2026: the 2 October update, the 27 April announcement, the plugin directory listing, the 18 September collaboration post and the 6 October release schedule, plus the Roadmap to 7.2 that the collaboration post links to. Install counts on WordPress.org are bucketed, so “10+” is a floor, not an exact figure, and all of this will change as the plugin ships updates.
The Bottom Line
Presence API is a small, sensible idea with careful engineering behind it: track who is where, keep that data out of post meta, and show it in the places editors already look. It is not real-time collaboration, it is not in WordPress core, and I found nothing that puts it in 7.2. Treat it as a feature plugin to try on staging, read the privacy controls before turning it on, and check the directory page again after the 7.2 betas start on 20 October.
Suggested Reading
- WordPress Real-Time Collaboration: What The New Server-Aware Approach Means For Your Site
- WordPress 7.2: Release Date, Ipsum Theme, And Every Feature On The Roadmap
- Gutenberg 24.1: Design Tools Now Reach Almost Every Core Block (What You Still Need A Block Plugin For)
- Best WordPress MCP Plugins Compared
