Audit multisite behavior before core proposal

[josephfusco]

wp_can_access_presence_room() branches on user_can() for both post rooms and admin/online (includes/functions.php:199-214), and nothing exercises that across a site boundary yet. #212 added the first switch_to_blog() calls in tests/, in test-table-creation.php, which is the pattern to follow here.

• A user with edit_posts on site A but not site B is denied admin/online on site B.
• Presence entries written on site A aren't visible reading back from site B, confirming site-scoping rather than inferring it from the table prefix.

Split either into its own issue if it grows past a test.

[josephfusco]

This issue was identified as part of a peer review conducted by Claude Sonnet 4.6, facilitated by @josephfusco.

[josephfusco]

Refinement note, 2026-08-08.

The first section here, front-end and login writes reaching the table before it is created, is a confirmed defect rather than an open question. Verified against main at 0.1.14: wp_maybe_create_presence_table() is still hooked only to admin_init and cli_init (presence-api.php:170-171), while wp_presence_enqueue_heartbeat_ping() is registered on both admin_enqueue_scripts and wp_enqueue_scripts (presence-api.php:179-180).

Split to #203 so it can be picked up without waiting on the rest of this issue.

What stays here, and genuinely needs discussion:

• wp_can_access_presence_room() behavior when a user has edit_posts on one site but not another, particularly for admin/online (see Presence room authorization is not enforced per room #128)
• Confirming front-end presence is site-scoped with a test rather than inferring it from the table prefix

Removing Needs Discussion is not appropriate yet since both remaining items are still open questions. Flagging instead that the actionable part has left.

[josephfusco]

Correction to my previous comment: I cited #128 as an open reference, but it was closed by #158, which added the per-room authorization checks. wp_can_access_presence_room() now branches to user_can( $user_id, 'edit_post', $post_id ) for post rooms and user_can( $user_id, 'edit_posts' ) otherwise (includes/functions.php:162-177).

That narrows this issue further but does not empty it. user_can() is site-context-aware, and no test currently exercises it across a site boundary. Grepping tests/ turns up no switch_to_blog() anywhere, so the multisite job is running the single-site assertions against a converted network rather than testing cross-site behavior specifically.

Restating what is actually left here:

1. A test that a user with edit_posts on site A but not site B is denied admin/online on site B
2. A test that presence entries written on site A are not visible on site B, confirming site-scoping rather than inferring it from the table prefix

Both are test-writing tasks against defined behavior, not open design questions. Once #203 lands, Needs Discussion can come off and this becomes Needs Dev.

[josephfusco]

Refinement note, 2026-08-08. Trimmed the body to what is still open.

Removed the "front-end writes to a table nothing on the front end creates" section: it was split to #203 and fixed by #212, which provisions per site at activation and on wp_initialize_site and guards every read and write. Removed the See #128 reference, already corrected in a comment above but still sitting in the body.

Also correcting my earlier comment on this issue: "grepping tests/ turns up no switch_to_blog() anywhere" is no longer true. #212 added them in test-table-creation.php, which gives the remaining work a pattern to follow.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Assisting with investigation and drafting