Collaboration: Replace post meta storage with dedicated database table

[josephfusco]

The real-time collaboration sync layer currently stores messages as post meta, which creates side effects at scale. This moves it to a single dedicated wp_collaboration table purpose-built for the workload.

Table Definition

CREATE TABLE wp_collaboration (
    collaboration_id bigint(20) unsigned NOT NULL auto_increment,
    room varchar(191) NOT NULL default '',
    type varchar(32) NOT NULL default '',
    client_id varchar(32) NOT NULL default '',
    user_id bigint(20) unsigned NOT NULL default '0',
    data longtext NOT NULL,
    date_gmt datetime NOT NULL default '0000-00-00 00:00:00',
    PRIMARY KEY  (collaboration_id),
    KEY type_client_id (type, client_id),
    KEY room (room, collaboration_id),
    KEY room_type_date (room, type, date_gmt),
    KEY date_gmt (date_gmt)
);

Testing

npm run env:cli -- core update-db
npm run test:php -- --filter WP_Test_REST_Collaboration_Server
npm run test:e2e -- tests/e2e/specs/collaboration/

References

Trac ticket: https://core.trac.wordpress.org/ticket/64696
PR with prior work and feedback (2 table approach): #11068

Use of AI Tools

Co-authored with Claude Code (Opus 4.6), used to synthesize discussion across related tickets and PRs into a single implementation. All code was reviewed and tested before submission.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props joefusco, peterwilsoncc, czarate, paulkevan, mindctrl, mukesh27, dmonad.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[josephfusco]

Carrying over props from original PR:

Props joefusco, peterwilsoncc, mindctrl, westonruter, paulkevan, dd32, czarate.

[peterwilsoncc]

A few notes from my first pass are inline. There will probably be more passes as I continuing reviewing the code and testing the functionality.

/* 
 * For multi-line comments the WordPress Coding Standard
 * is to write them like this rather than with consecutive lines
 * beginning with a `//`.
 *
 * This applies in a few places so I haven't dropped an inline comment.
 */

[peterwilsoncc]

I've added a few notes inline.

For the test suite (I've only noted it once inline but it applies elsewhere), I recommend using the pre_option_{$option} filter whenever possible to ensure that it gets reset by the test suite. The filter requires the use of __return_zero as returning false doesn't work for WP reasons.

I took the liberty of pushing the required changes to tests/qunit/fixtures/wp-api-generated.js to get the tests passing.

[peterwilsoncc]

Oh, forgot to mention: for the cron job specific tests, I'd recommend moving them to a separate file rather than keep them in the REST endpoints file.

[peterwilsoncc]

@josephfusco I've pushed an update to your PR to rename the ID column to collaboration_id as Matt wants it to have a prefix per other tables.

[josephfusco]

Apologies for the late replies on a couple of threads:

Client ID reactivation after 60s:

Can the same client ID be reactivated after 60 seconds? The situation I'm thinking of is someone locking their computer and returning to the browser tab later.

Yes — the awareness row expires via the TTL filter, and the next poll re-inserts it. Covered by test_collaboration_awareness_client_reactivates_after_expiry.

Separate awareness DELETE (60s cleanup):

As awareness should have been deleted by seven days, we might be able to leave it out anyway so the SQL query can simply hit the date index.

Technically true, but without the 60-second cleanup, awareness rows from abandoned sessions linger for 7 days. Keeping the separate DELETE bounds the table.