BlogProLabels
Corex\Config\Blog\BlogProLabels · class · Config layer
Blog Pro’s state vocabulary, in words (spec 075, FR-2/FR-3). The screen used to print ready_for_review and publish at people — raw slugs on an otherwise translated screen, and the same defect Spec 074 removed from Data Models and Notifications. The mapping lives on the server rather than in JavaScript on purpose. The states are the workflow service’s vocabulary; a second copy in the client is a second thing to update when a state is added, and the two would drift the way the drawer and the screen drifted before DECISIONS #157. The client is handed { key, label } and renders the label. An unrecognised key returns the key itself. A slug is bad, but an empty cell where a state should be is worse: it reads as “no state” rather than “a state CoreX has no word for yet”.
Public API
Section titled “Public API”editorialStates(): array
Section titled “editorialStates(): array”The CoreX editorial states, in the order a post moves through them.
editorialState(string $state): string
Section titled “editorialState(string $state): string”nativeStatus(string $status): string
Section titled “nativeStatus(string $status): string”The native WordPress status, shown beside the CoreX state. The workflow service maps between the two, so a divergence — approved in CoreX, still a draft in WordPress — is worth being able to see rather than having to infer.
commentState(string $state): string
Section titled “commentState(string $state): string”commentActions(): array
Section titled “commentActions(): array”The moderation actions this screen offers, keyed by the action the service accepts. Three, not five. CommentModerationService::queue() returns only comments held for review, so there is nothing for an “unapprove” to act on, and the service’s edit and reply are excluded by spec 075 §10 — this screen moderates, it does not author.