wp_get_presence, wp_set_presence, wp-presence/v1, or high-frequency ephemeral-state work. Do not confuse this experimental plugin with WordPress 7.1 core.\nlicense: GPLv2-or-later\nmetadata:\nwp-skills-author: \"Soczó Kristóf\"\nwp-skills-contact: \"mailto:lonsdale201@hotmail.com\"\nwp-skills-plugin: \"presence-api\"\nwp-skills-plugin-version-tested: \"0.1.23\"\nwp-skills-wp-version-tested: \"7.1\"\nwp-skills-php-min: \"7.4\"\nwp-skills-last-updated: \"2026-08-20\"Integrate with Presence API 0.1.23 as an experimental feature plugin, not as a\nWordPress 7.1 core API. It supplies awareness of active users and editors using\na dedicated per-site table, a 60-second TTL, Heartbeat, REST, admin surfaces,\nand a small public PHP API. Pin and feature-detect the plugin; its 0.1.x\ncontract may still change.
wp_get_presence(), wp_set_presence(), wp_presence_post_room(),\npresence-ping, wp_presence_editor_state, or /wp-presence/v1 code.Feature-detect a public function and avoid loading plugin internals yourself:
\nif ( ! function_exists( 'wp_get_presence' ) ) {\n return;\n}\nPresence API 0.1.23 requires WordPress 7.0+ and PHP 7.4+. WordPress 7.1 does\nnot provide these functions or the wp_presence table by itself. Do not test\nonly version_compare( get_bloginfo( 'version' ), '7.1', '>=' ).
Treat an experimental-plugin version constraint as a deliberate product\ndecision. Fail softly when it is absent, and verify the installed source again\nbefore relying on signatures in a later 0.1.x release.
The source explicitly marks these as its public contract:
\n| Function | \nContract | \n
|---|---|
wp_get_presence( $room, $timeout ) | \nReturn active entry objects for one room. | \n
wp_set_presence( $room, $client_id, $state, $user_id ) | \nAtomically upsert one (room, client_id) row. | \n
wp_remove_presence( $room, $client_id ) | \nRemove one client entry. | \n
wp_remove_user_presence( $user_id ) | \nRemove a user's entries across all rooms. | \n
wp_can_access_presence_room( $room, $user_id ) | \nCheck the plugin's room access policy. | \n
wp_presence_post_room( $post ) | \nReturn the canonical post room or false. | \n
wp_presence_admin_room() | \nReturn the canonical admin/online room. | \n
Everything after the public section in includes/functions.php is marked\nprivate even when it has a global wp_* function name. Do not depend on\nwp_get_active_rooms(), wp_get_presence_summary(), table/provisioning\nhelpers, or cleanup internals.
The direct PHP write/remove functions are trusted server-side primitives. They\ndo not reproduce the REST controller's room-length, payload, ownership, entry\nlimit, or capability checks. Validate and authorize before calling them from\nany request handler.
\nCore post types post and page opt in automatically. Add support to a custom\npost type during registration or afterwards:
register_post_type(\n 'book',\n array(\n 'show_ui' => true,\n 'supports' => array( 'title', 'editor', 'presence' ),\n )\n);\n\n$room = wp_presence_post_room( $book_id ); // postType/book:123 or false.\npostType/{post_type}:{id} rooms require edit_post for that object. Other\nroom strings, including admin/online, require only edit_posts. Therefore a\ncustom room name is not a custom authorization boundary. Do not put data in a\ngeneric room when every user with edit_posts must not see it; enforce the\nnarrower capability in your own server handler or use an object-backed room.
Presence is awareness, not authorization. Never grant locks, saves, or content\naccess merely because a user has a presence entry.
\n$room = wp_presence_post_room( $post_id );\n$client_id = 'my-plugin-' . get_current_user_id();\n\nif ( $room && current_user_can( 'edit_post', $post_id ) ) {\n wp_set_presence(\n $room,\n $client_id,\n array( 'mode' => 'reviewing' ),\n get_current_user_id()\n );\n}\nUse stable, namespaced client IDs. Store only small UI state, never secrets,\ntokens, unpublished content bodies, or durable workflow state. Entries expire\nfrom reads after the TTL and are later removed in bounded cron batches. TTL is\nnot a delivery guarantee, logout is not guaranteed to run, and a crashed tab\ncan remain visible until expiry.
\nThe table is the correct architectural pattern for high-frequency awareness:\nit avoids repeatedly invalidating wp_options or object meta caches. It does\nnot make every custom ephemeral feature a reason to depend on this plugin;\nuse the public contract only when Presence API's room and capability model fit.
Authenticated endpoints are:
\n| Method | \nRoute | \nPurpose | \n
|---|---|---|
GET | \n/wp-presence/v1/presence | \nPaginated entries for room. | \n
POST | \n/wp-presence/v1/presence | \nUpsert room, client_id, and data. | \n
DELETE | \n/wp-presence/v1/presence | \nDelete an owned entry; manage_options can delete any. | \n
GET | \n/wp-presence/v1/presence/rooms | \nPaginated, access-filtered active rooms. | \n
POST | \n/wp-presence/v1/presence/screen-revisions/stale | \nBump an authorized screen revision. | \n
Use wp.apiFetch in WordPress admin/editor JavaScript so the REST nonce and\nroot middleware are applied. Respect pagination headers and request _fields\nwhen only user identity is needed. Responses use Cache-Control: no-store.
The 0.1.23 controller bounds room/client IDs to 191 characters, REST state to\n10 KiB and three nested array levels, list pages to 100 rows, and active\nentries to 50 per user. It rejects an active client_id owned by a different\nuser and restricts delete-by-client ownership. Do not clone these values into\na competing endpoint; use the plugin route or implement an independently\nreviewed contract.
Read references/api-and-runtime.md before adding a REST client, custom room,\nscreen-revision integration, or multisite dependency.
The plugin enqueues WordPress Heartbeat and writes initial presence on eligible\nadmin/front-end requests, then refreshes state through Heartbeat. The block\neditor can run Heartbeat faster than its normal 60-second interval for post\nlocks. Do not add a second timer that posts the same state independently.
\nThe shipped usePresenceUsers() React hook performs one REST read initially\nand on Heartbeat ticks, deduplicates by user ID, supports _fields, and can\nexclude the current user. In 0.1.23 it is shipped as source, not as a registered\nWordPress package or script handle. Do not deep-import another installed\nplugin's filesystem path at runtime. If a build deliberately vendors that\nexperimental source, pin the plugin release and review license/update drift;\notherwise implement a small wp.apiFetch consumer around the REST contract.
wp_presence_editor_state can enrich editor state. The plugin also declares\nwp_presence_collaboration_started and wp_presence_collaboration_ended.\nDo not use the latter actions for billing, durable workflow transitions, or\nexact participant lifecycle: in 0.1.23 threshold memory is a request-local\nstatic variable, so it does not persist a transition state across separate\nHeartbeat requests. Recompute current membership from the room for decisions\nand verify this implementation again after upgrading.
false.edit_posts user._fields, and Cache-Control: no-store.false instead of causing SQL errors.edit_posts.wp-rest-api when implementing a separate custom endpoint.wp-plugin-options-storage for the custom-table decision.wp-plugin-cron for cleanup reliability and multisite scheduling.references/api-and-runtime.md for exact response fields, limits,\nprovisioning, stale-screen, and hook details.v0.1.23:\npresence-api.phpincludes/functions.phpincludes/class-wp-rest-presence-controller.phpincludes/heartbeat.phpincludes/screen-revisions.phpincludes/cron.phpsrc/hooks/use-presence-users.js