SdkContext is the current WordPress-host compatibility bag. The durable portable contracts live in @meteorack/modules-sdk-core/services.
Today the host surface spans these service families:
| Family | Examples |
|---|---|
| Core runtime services | settings, events, cache, http, logger, storage |
| Identity and trust | auth, secrets, rate limits, feature flags |
| Content and data | content, data |
| Async and delivery | scheduler, queue, email, webhooks, uploads |
| Search and realtime | search, channel |
| Platform controls | licensing, design tokens, observability |
Usage pattern
Use SdkContext inside onSdkReady() for boot wiring, and use module helper traits when they make the call sites simpler.
public function onSdkReady(SdkContext $ctx): void
{
parent::onSdkReady($ctx);
$ctx->logger()->info('billing.boot', []);
$enabled = $ctx->settings()?->get('enabled', false);
if ($enabled) {
$ctx->scheduler()?->schedule('billing_refresh', time() + 60, 'hourly');
}
}Important caveat
Many services are nullable by contract. Module code should handle missing services explicitly instead of assuming every runtime exposes every implementation.
The portable rule is:
- modules depend on service contracts
- runtimes decide which concrete services they expose
- WordPress-specific helpers remain compatibility glue, not the permanent module API