Automattic / Automattic/cortext

Spike: confirm WP 7.0 sync behavior on Cortext CPTs

Open
#164 0 comments 0 reactions 0 assignees View on GitHub
area: collaboration
Dominant language
JavaScript
Stars
51
Forks
2
Avg merge
3h 12m
Merged PRs (30d)
8

Description

We made several guesses about how core auto-applies sync to non-block CPTs. Answer them on a running 7.0 build before writing the per-surface sync issues.

## Depends on

* #162 (shim fix; loading `@wordpress/sync` against the current shim would trigger a namespace collision)

## Blocks

* #165 (page sync)
* #166 (entry sync)
* #167 (schema sync)

## Goal

Replace the guesses with answers we can point to in code.

## Scope

Pin wp-env to WP 7.0 trunk now (revalidate on RC3 May 8 and GA May 20). Then confirm:

* What does the auto-applied post-type sync config actually do for `crtxt_page`, `crtxt_collection`, `crtxt_field`, and dynamic entry CPTs? The config is built around block-tree sync; what happens on CPTs that don't support `editor`?
* Does core's default meta merge preserve concurrent reorder, add, and remove on multi-value post meta (`'single' => false`)? This decides whether `crtxt_collection.meta.fields` needs a custom wrapper.
* Is `_crdt_document` registered automatically for all post-type entities, or only those with `editor` support?
* Does core's `wp_collaboration_inject_setting()` run on Cortext's custom React shell screen, or do we need to plug into the injection point ourselves so `window._wpCollaborationEnabled` lands on the page?
* If we need to override the auto-applied config for a CPT, what's the path: filter, custom entity registration, different `kind`?
* Smoke-test `POST /wp-sync/v1/updates` against our custom CPT addressing.

## Acceptance

* A short Serena memory or repo doc records the answers with code references against the pinned build.
* The follow-up sync issues (pages, entries, schemas) have their scope confirmed or revised in the same session.

## Notes

Polling endpoint URL is settled (`POST /wp-sync/v1/updates` per `WP_HTTP_Polling_Sync_Server`); the smoke-test bullet just verifies our CPT addressing works.

---

*This issue is the result of a guided back and forth between Opus 4.7 and GPT 5.5.*

Contributor guide

Open the contributing guide

Research direction

Pin wp-env to WP 7.0 trunk and inspect the core sync behavior for the listed CPTs, including wp_collaboration_inject_setting() and WP_HTTP_Polling_Sync_Server. Smoke-test POST /wp-sync/v1/updates with custom CPT addressing, then record code-referenced answers in a Serena memory or repo document and confirm or revise issues #165–#167.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, react
Domain
api, backend, databases, frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.