SiteLifecycleSubscriber
Corex\Multisite\SiteLifecycleSubscriber · class · Core layer
Joins CoreX schema work to WordPress’s site lifecycle without leaking WP_Site objects into framework events. HookRegistry uses add_filter for this seam because WordPress actions are filters with ignored return values (spec 100 FR-036–FR-040).
Public API
Section titled “Public API”__construct(SiteMigrationRunner $runner, SchemaMigrator $migrator, SchemaRegistry $schemas, EventDispatcher $events)
Section titled “__construct(SiteMigrationRunner $runner, SchemaMigrator $migrator, SchemaRegistry $schemas, EventDispatcher $events)”hooks(): array
Section titled “hooks(): array”onSiteInitialized(WP_Site $site, array $args): void
Section titled “onSiteInitialized(WP_Site $site, array $args): void”Priority 20 runs after WordPress’s priority-10 default, which creates the core tables and options for the new site and then puts the current blog back: wp_initialize_site() ends with if ($switch) { restore_current_blog(); }. So the current site here is the one that requested the creation, not the new one — every schema call below must stay inside SiteScope::run(), which performs the real switch. Do not “optimise” that wrapper away.
onSiteDeleted(WP_Site $site): void
Section titled “onSiteDeleted(WP_Site $site): void”filterDropTables(array $tables, int $siteId): array
Section titled “filterDropTables(array $tables, int $siteId): array”WordPress owns the actual drops, their order, and their error handling. CoreX only contributes its site-prefixed names to the filter, preserving every incoming table and avoiding duplicate entries (spec 100 FR-037).