DataModelsScreen

Corex\Config\DataModels\DataModelsScreen · class · Config layer

The single home for data: models, records, import, export, and migrations. Records used to live here AND on a separate “Data” screen that rendered the identical explorer from an identical config — two menu entries for one screen. The Data screen is gone and its address redirects here. That consolidation forces the permissions to be honest. MANAGE_DATA and MANAGE_DATA_MODELS are independent (CorexAbilityCatalog: neither implies the other; only MANAGE_ADMIN implies both), and this screen gated on MANAGE_DATA_MODELS while the records explorer inside it reads sources gated on MANAGE_DATA. So a models-only user already got an explorer that could read nothing, and gating the survivor on models alone would have cut off data-only users entirely. The screen therefore admits either ability and each tab asks for the one it actually needs — the same either-ability rule DataRestGateway and DataManagementController already apply to the REST side.

Public API

__construct(AdminGuard $guard, AdminPage $page, DataSourceService $sources, FlowFilterOptions $flows, CapabilityFacts $facts)

register(): void

menu(): void

render(): void

The shell is echoed directly, as every other CoreX screen does. It used to pass through wp_kses_post(), which silently deleted every inline <svg> in the chrome — svg is not in the allowed post tags. This screen alone lost the CoreX brand mark, the rail icons and the notification bell’s glyph, leaving an empty bell button that read as a missing icon. AdminPage escapes each dynamic value at the point it interpolates it (esc_attr/esc_html/esc_url), so the markup it returns is trusted CoreX chrome and filtering it again removes correct output rather than adding safety.

maybeEnqueue(string $hook): void