📌 Tracking: Presence API path to Core #550

Presence API is headed for a core proposal, with post locks as its first consumer. This page says what just happened and what comes next.

Next

• Release 0.8.0 (chore(main): release 0.8.0 #547)
• Move post locks out of post meta in the plugin (An open editor makes every cached post query stale on each Heartbeat tick #548)
• Release 0.11.0 (chore(main): release 0.11.0 #635)
• Make the Presence API gutenberg-sync-engines' awareness store (feat: require the Presence API plugin gutenberg-sync-engines#120)
• Label agent rows once Agent Users lands (An agent can edit a post you have open, and neither of you knows #549)
• Release 0.15.0 (chore(main): release 0.15.0 #718)
• Release 0.18.0 (chore(main): release 0.18.0 #803)
• List it in the plugin directory's Beta Testing tab, raised at devchat on 2026-10-14; Make/Core's features page lists it already
• Firefox and WebKit end-to-end runs for the tab coordination code (End-to-end tests run in Chromium only #808, test: run the cross-tab, visibility and admin bar contrast specs in Firefox and WebKit #838)
• Step each piece aside once core's patch exists (The whole plugin stops loading if core registers the presence table #859); when core adopts a feature, a release removes its registration and files, as Gutenberg does
• Review the Trac proposal draft with Deepak, then publish once readiness gate is met

Feature plugin merge criteria

Each item from the Core Handbook's Features as Plugins, in its order and wording, with where this plugin stands.

Merge criteria

• A plugin exists in the official WordPress plugin repository, is updated regularly, and is used/tested by the community. presence-api on WordPress.org, 0.18.2 shipped 2026-10-16.
• Weekly chats are taking place on Slack, and the feature lead is attending the weekly core dev chat. The meeting in #feature-presence-api runs every other Monday at 15:00 UTC.
• A kickoff post and regular update posts are published publicly, tracking the progress and major decisions. Kickoff and What's new on Make/Core.
• The feature works in all of the browsers that WordPress officially supports. The specs for code that can differ between engines also run in Firefox and WebKit, and a manual pass covers Safari, Chrome, Firefox and Edge (test: run the cross-tab, visibility and admin bar contrast specs in Firefox and WebKit #838).
• Touch devices can use the entire feature with no hindrance, with visual records for major flows. The admin bar shows on phones and spells out names that were hover-only (fix: show the admin bar presence node on phones and spell out hover-only names on touch #830), and every other screen works by tap on phones and tablets, with visual records (Screens haven't been checked on touch devices and small screens #833).
• Visual records comparing old flow with new flow are provided for any feature that changes or replaces existing interfaces. Nothing replaces an existing interface; post locks look the same and only move where they are stored (An open editor makes every cached post query stale on each Heartbeat tick #548).
• The code conforms to the WordPress coding standards. PHPCS (the full WordPress ruleset, with the rules that don't fit tests turned off, as core does), Stylelint and ESLint cover the source and tests.
• The code is well-tested, and has unit tests. PHPUnit on single site, multisite and SQLite, Playwright end-to-end tests, and about 97% coverage.
• The code is well-documented. The README covers the PHP API, REST, WP-CLI and every hook, and each function has a docblock.
• The code follows the plugin security best practices, and has undergone a security audit. No audit yet (The plugin hasn't had a security audit #834).
• The user interface/experience has been tested through user testing, and appropriate feedback was incorporated. Not yet (The plugin hasn't been through user testing #835).
• The design is fully responsive, displaying properly on any mobile device, and using graphics that are ready for hi-dpi/retina displays. Avatars are fetched at twice their display size, and no screen scrolls sideways on a phone or tablet (fix: show the admin bar presence node on phones and spell out hover-only names on touch #830, Screens haven't been checked on touch devices and small screens #833).
• HTML validates to the proper doctype. The plugin's fragments pass as the server sends them, and the stale-screen notice, which JavaScript adds, as the browser builds it (test: validate the plugin's markup in e2e #852, The markup check validates the browser's repaired markup, not the HTML the plugin sends #855).
• The code has all of the proper hooks in place for localization. Strings use the presence-api text domain, which PHPCS enforces, and each release regenerates the translation template.
• WordPress continues to function, and the feature is still usable, with JavaScript turned off. Every screen works, since each admin page load records presence on the server (test: check the plugin's screens with JavaScript turned off #857).
• The feature can be used with just a keyboard. Fixed for the admin bar and widgets in Admin bar flyout: non-link items unreachable by keyboard #264 and Heartbeat swap drops focus to <body> in dashboard widgets #265, and for the screens added since in fix: make the presence screens readable with only a keyboard #841.
• Any required accessibility support has been added, including (but not limited to) off-screen text, ARIA, and JS-assisted. Accessibility audit for dashboard widgets and admin bar node #138, Missing alt text on Who's Online widget avatar #142, Admin bar flyout: non-link items unreachable by keyboard #264, Heartbeat swap drops focus to <body> in dashboard widgets #265 and Admin bar flyout text fails contrast in the Light color scheme #266.
• A merge proposal has been published on the Make/Core blog once the plugin is ready. After the Trac ticket.

Merge checklist

• Make sure the feature plugin noops once the feature is merged. This means the plugin won't break with a Fatal Error after code is merged from the plugin to core. If core registers the presence table, the plugin shows a notice and loads nothing, and feat: let core's copy of a presence function or class win when it already exists #805 and Six files would fatal with "cannot redeclare" if core ships their functions #860 let core's copy of each function win. The whole plugin stops loading if core registers the presence table #859 holds the rest for core's patch.
• If code from another plugin is used, make sure there are no clashes with that plugin once the feature merges. gutenberg-sync-engines calls the presence functions but declares none of its own.

Readiness gate

The proposal goes to core when all of these hold, since core weighs real-world use of the API over install counts.

• Three plugins outside this repository build on the API. One so far: gutenberg-sync-engines, as its awareness store.
• A host runs it on production sites, reaching persistent object caches and multisite at scale.
• Two or more large sites measure the post query cache before and after post locks moved out of post meta (An open editor makes every cached post query stale on each Heartbeat tick #548). One small site and one synthetic large site have run it so far (The post query cache hasn't been measured before and after post locks left post meta #836).
• Eight weeks with no breaking change to the API and no high-severity bug, counted from the release that ships the $args signatures (feat: take an $args array in the presence functions #789): 0.17.0 on 2026-10-08, so 2026-12-03 at the earliest.
• 1,000+ active installs on WordPress.org. 10 today.

Recently

How it fits

flowchart LR
  E[Block editor] --> G[gutenberg-sync-engines<br/>edits]
  G -->|who is here| P[Presence API<br/>wp_presence]
  H[Heartbeat in wp-admin] --> P
  L[Post locks] --> P
  A[AI agents] --> P

Each of these asks who is here right now, and today each answers it separately: post meta for locks, a serialized array for editor awareness, nothing for agents. One row per client per room answers it once. RTC ships as a feature plugin on two primitives, gutenberg-sync-engines for edits and this plugin for who is in the room, with core adopting what holds up. The cost evidence is in #444 and the work left outside this repo in #647, and what Gutenberg needs to host an RTC plugin is in WordPress/gutenberg#83165. Discussed at the Presence API meeting, every other Monday at 15:00 UTC in #feature-presence-api.

Where Gutenberg sync and presence overlap

Detecting a second editor. The client must poll the endpoint to learn whether it needed to poll it.

• Gutenberg sets hasCollaborators from the poll response (polling-manager.ts#L731) and selects the interval from it (#L778, #L804).
• Presence fires wp_presence_collaboration_started and _ended on the 1 to 2+ and 2+ to 1 transitions (heartbeat.php#L414-L457). Shipped in #290; the edge was made to hold across requests in #380. Ten tests in test-heartbeat.php. Since #503 and #511 the same two edges fire JavaScript events, presence-api.collaborationStarted and presence-api.collaborationEnded, alongside presence-api.watchingRoom, so the editor can listen instead of polling.

Cross-tab coalescing. The other half of section 3, on the client side.

• Gutenberg has none. No BroadcastChannel or navigator.locks anywhere in packages/sync/src.
• Presence elects one poller per room with Web Locks and distributes the result over BroadcastChannel, with a per-tab fallback (presence-poll-coordinator.js), from #300. Six tests in presence-poll-coordinator.test.js.

Idle backoff. Visibility is not idleness, so an open untouched editor keeps paying the fast rate.

• Gutenberg keys off document.visibilityState only. A focused tab left untouched keeps polling at 4s.
• Presence backs off on inactivity, widening to idleInterval after idleTicks unchanged ticks, from #307, closing #267. The widened interval is capped below the TTL, so an idle-but-open tab cannot drop out of its own room (presence-ping.js#L49-L50).

Both Presence values are filterable with no clamp. Gutenberg's sync.pollingManager.pollingInterval runs through Math.min( filteredInterval, defaultInterval ) (config.ts#L62), so a host can lower the interval but not raise it. That is intentional, from WordPress/gutenberg#78811: a host slowing the interval far enough makes active collaboration feel broken. The clamp protects the two-editor case at the cost of the solo one.

Unchanged payloads. N writes per poll for state that usually has not changed.

• Gutenberg calls set_awareness_state() on every poll without comparing state.
• Presence hashes room state and has the client echo its last hash; on a match the response omits the payload, skipping cache_users(), per-user get_userdata() and get_avatar_url(), label building and most of the JSON (#288).

Identity hydration. Fields that almost never change ride every request.

• Gutenberg does it client-side. Each client puts its own name, slug, avatar_urls and browserType into awareness state and sends it on every poll (utils.ts#L146).
• Presence does it server-side and batched, through wp_presence_hydrate_room_users() (functions.php#L1218), paginated in #297.

Already aligned. Room naming, post lock and room membership need no work.

Room identifiers match (postType/{type}:{id}). Both read _edit_lock, for different purposes: Gutenberg suppresses the lock modal and adjusts post-list UI, Presence keeps the lock itself in the room's _lock row and flags the holder's editor- entry. Room membership lands in the same wp_presence table under the same room string. sync-storage did it with a sync- client id prefix; gutenberg-sync-engines does it with gse-, through an awareness backend of its own rather than __unstable_wp_sync_storage (WordPress/gutenberg-sync-engines#102). It needs no configuring: where the Presence API is active, recording and has its table, a collaborator in the editor is a row in wp_presence and shows up in the admin bar and the post list. Where it is not, the plugin keeps its own store.