GuideRegistry

Corex\Guides\GuideRegistry · class · Add-ons layer

Every registered guide, from Corex and from whatever site is built on it (spec 084, FR-001–FR-005). ## Why registerDeferred() is not optional This registry’s whole purpose is to accept contributions from plugins Corex has never heard of, and the ordering makes that hostile. Corex boots on plugins_loaded at priority 10; a site plugin following the generated starter (packages/cli/stubs/starter/plugin.stub) boots on plugins_loaded at priority 10 too. Whichever WordPress happens to load first wins, and it varies with the plugin’s directory name. So nothing is resolved until something reads the registry, which is an admin request — long after every plugin has loaded. This is the shape of Corex\Config\Data\DataRegistry, and it exists there because this exact bug was already shipped once: a registry built during boot froze before add-ons could declare their tables, and the newsletter table was invisible in wp-admin while being perfectly visible to WP-CLI, which resolves things later. Same trap, worse audience. ## Why the filter results are sieved corex_guides is the seam for callers with no container access. Anything that comes back and is not a Guide is dropped rather than rendered — the Cache\CacheRegistry precedent, and the reason there is the reason here: this screen is what somebody opens when they are already stuck, and a fatal on the help page is the worst possible moment for one.

Public API

register(Guide $guide): void

registerDeferred(callable $factory): void

Register guides that cannot be built yet, to be built the first time the registry is read. This is the method a site plugin should use. register() works too, but only if the caller can be certain it runs after Corex has bound the registry — and a plugin cannot be certain of that from plugins_loaded. Keep the factory cheap. Guides are value objects and building them costs nothing; a factory that queries the database or reads a file would put that cost on the request. If a guide’s content genuinely has to come from storage, cache it — the registry deliberately does not, because it cannot know how long somebody else’s data stays fresh. The registry is read when the Guides screen renders, and no longer on every admin page load: spec 084 also read it on current_screen to fill each screen’s contextual help tab, and spec 097 removed that surface.

all(): array

Every registered guide, in section then order then title sequence. Sections therefore come out alphabetically by key, which is the only lever a site has over where its own section appears and is not guessable from the API. Deliberately not a separate section-order registry: that would be a second thing to register, a second thing to get wrong, and a second thing for two plugins to disagree about. A site that wants its section first names the key accordingly.

available(): array

Every guide the current user should actually be offered (FR-009).

find(string $id): ?Guide

bySection(): array

Available guides grouped by section, sections in first-seen order.