feat: register cms-framework post + page core-data entities (#399 Phase B)

[ViewFromTheBox]

Description

2 of 3 PRs closing #399 (G3 editor entity adapter). Phase A shipped the backend REST surface (WP-shape /visual-editor/api/{posts,pages}/{id}); this phase wires the JS-side entity registration so core/post-* blocks can resolve postType:post / postType:page through the core-data shim. Phase C will add the editor's EntityProvider wrapping + inspector-sidebar enhancements that surface the integration to the user.

Refs: #399 (closes when Phase C also merges)

Type of Change

• New feature (adds new functionality)

Related Issue

Issue: #399 (Phase B of 3)

Motivation and Context

G3 from plan 12 §4.4 — "the shim's editor bootstrap registers two new entities: postType:post → /visual-editor/api/posts and postType:page → /visual-editor/api/pages". Builds on Phase A's REST surface (merged) and the resource-bridge filter from #397 (merged). With these entities registered, downstream Phase C (editor EntityProvider wrapping + inspector sidebar) plus existing core/post-* blocks resolve their data automatically.

Changes Made

The shim already defaults apiBase to /visual-editor/api, so the only seam needed is DEFAULT_ENTITIES:

• postType:post → /posts (resolves to /visual-editor/api/posts/{id} from Phase A)
• postType:page → /pages (resolves to /visual-editor/api/pages/{id} from Phase A)

Unconditional declaration: the entities are registered regardless of whether cms-framework is installed. When the package isn't present, the matching endpoints are unrouted and the resolver returns null — the same shape any unseeded entity returns. No runtime detection seam needed in JS.

How Has This Been Tested?

Testing Environment:

• Operating System: macOS (Darwin 25.4.0)
• Node: vitest 2.x
• Project Version: 1.0.0 (release/1.0)

Tests Performed:

1. Full vitest suite — 944 passed (1 pre-existing skip)
2. Updated strict-equality registry test in core-data-shim.test.tsx to include the new G3 entries
3. New dedicated test (the G3 post + page entities resolve to /posts and /pages baseURLs) asserts the full shape of both entries

Manual smoke notes: Phase B's user-visible value depends on Phase C wiring an EntityProvider around the editor canvas — without that context, blocks like core/post-title have no entity to resolve and render placeholders. Phase B in isolation is verified by the unit tests + the Phase A REST endpoints (proven via tinker on the Phase A PR). End-to-end network-call verification will land naturally during Phase C's manual smoke.

Accessibility Tests Run

N/A — no UI surface in this phase.

• Keyboard navigation tested
• Screen reader tested
• Color contrast verified
• ARIA labels checked

Details: Pure entity-registry change. UI work lands in Phase C.

Tests Added

• Unit tests added/updated
• Integration tests added/updated
• All tests passing

Test details:

• Updated core-data-shim entity registry > registers the V1 site-editor + G3 cms-framework entities by default to expect 7 entries instead of 5
• Updated exposes default entities via getEntities after reset to include the two new entries in the arrayContaining set
• New the G3 post + page entities resolve to /posts and /pages baseURLs test asserts each entity's full shape — will catch any future rename of baseURL / key / label / plural

Documentation

• Inline code documentation added
• README updated (no host-facing surface change yet — Phase C adds the integration touchpoints)
• Wiki updated
• API documentation updated

Documentation details:

• Inline comment on the new entries pointing to plan 12 §4.4 and explaining the unconditional-declaration semantics + null-resolution behavior when cms-framework isn't installed.

Pre-Submission Checklist

• Followed contributing guidelines
• Checked for other open PRs for same update
• Code passes all tests
• Code has been linted (no .php-cs-fixer.dist.php / pint binary in this package; tests are the gate)
• Accessibility tests completed (N/A)
• Code follows project style guide
• Self-review completed
• Comments added for complex code
• No new warnings generated

Summary by CodeRabbit

Release Notes

• New Features

  • Expanded entity registry to include post and page types as default configurable entities, enabling proper resolution of post-related data queries through their REST endpoints and improving consistency in core data handling.

• Tests

  • Updated test suite to verify correct configuration and resolution behavior for newly supported entity types.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: d8712961-238f-4ad1-864d-319cb306b449

📥 Commits

Reviewing files that changed from the base of the PR and between 51c2406 and 0f5f6c4.

📒 Files selected for processing (2)

• resources/js/visual-editor/vendor/__tests__/core-data-shim.test.tsx
• resources/js/visual-editor/vendor/core-data-shim.ts

---

📝 Walkthrough

Walkthrough

The core-data-shim's default entity registry is expanded to include post and page as postType entities with REST endpoints (/posts and /pages). Corresponding test assertions are updated to validate these new defaults and their configuration properties.

Changes

Cohort / File(s)	Summary
Core-data-shim entity registry resources/js/visual-editor/vendor/core-data-shim.ts	Added post and page as default postType entities with REST endpoint paths, id as the key, and associated metadata (label, plural).
Test assertions resources/js/visual-editor/vendor/__tests__/core-data-shim.test.tsx	Updated DEFAULT_ENTITIES and getEntities() assertions to reflect new post-type entities; added test verifying baseURL resolution and entity metadata configuration.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• #328: Introduced the core-data-shim module that this PR extends with new default entities.
• #355: Previously expanded the core-data-shim entity registry surface using the same registration patterns applied here.

Poem

🐰 Posts and pages now take their place,
In the shim's registry with grace,
REST endpoints mapped with care so true,
The entity resolver knows what to do! 📑✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and specifically describes the main change: registering two core-data entities (post and page) in the cms-framework, with clear reference to the feature scope and phase.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/399-add-entities-bootstrap

---

_{Review rate limit: 4/5 reviews remaining, refill in 12 minutes.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}