benecaster_boot
The add-on bootstrap point. Fires at the end of Plugin::boot() once Benecaster services are registered and the upgrader has run, passing the dependency injection container. This is where every Benecaster add-on hooks its own initialization — registering services, shortcodes, REST routes, and filter callbacks.
Hook here rather than on WordPress’s plugins_loaded or init. At benecaster_boot the container is populated and Benecaster services are resolvable; earlier than this they are not.
Registries that add-ons contribute to are applied immediately after this action fires, so a callback registered inside your benecaster_boot handler is in place before the registry is read. Registering later — on init, for example — is too late for those registries and the contribution is silently ignored.
Check whether a Benecaster add-on is available for a show
Use this when your code extends one of Benecaster’s add-ons — adding a section to the Analytics Dashboard’s digest, contributing rows to a Sponsor Manager export, reading transcripts the Transcription Service produced. You need to know whether that add-on is actually available on the show in front of you, so you can extend it when it is and stay out of the way when it is not.
⚠ This does not gate your own plugin. benecaster_addon_is_active() answers only about add-ons in Benecaster’s own catalogue — it compares against the entitlement list the licence server publishes, so a slug that is not one of theirs can never match and will always return false. If you sell your own plugin, license it your own way; use this to detect theirs.
The question has two halves, and one grant can give three answers. An add-on is available on a show when the licence grants it and the podcaster has left it switched on for that show. A Multi-Show customer can run the same add-on on shows A and B and switch it off for C. So code that resolves the question once and caches the answer gets show C wrong for the rest of the request.
The shape that follows: register unconditionally at boot, check at the point of use, where a show is actually in hand.
⚠⚠ Do not substitute benecaster_addon_is_active_for_any_show() for the per-show call to save a lookup. “Some show on this install has it” is not an answer to “may this show use it”. On a site running two shows on two different licences, that substitution shows one customer’s paid feature to another customer’s show.
The show context is a show post ID or the show’s _benecaster_show_uuid — both resolve identically, so pass whichever you already hold rather than looking the other one up.
<?php
add_action( 'benecaster_boot', function ( \Benecaster\Container $container ): void {
// Nothing here knows which show is being rendered yet, so this is the
// one place the install-wide question is the right one: is it worth
// wiring up at all on this install?
if ( ! benecaster_addon_is_active_for_any_show( 'analytics-dashboard' ) ) {
return;
}
$container->make( \MyPlugin\DigestSection::class )->register();
} );
// ...and check per show, where the show is known.
add_filter( 'benecaster_analytics_digest_sections', function ( array $sections, string $type, int $show_id, array $data ): array {
if ( ! benecaster_addon_is_active( 'analytics-dashboard', $show_id ) ) {
return $sections;
}
$sections[] = my_plugin_build_section( $show_id, $data );
return $sections;
}, 10, 4 );Register an Add-on Bootstrap With Core's Entitlement Gate
benecaster_register_addon() replaces the manual any_show_addon_is_active() check add-ons previously wrote inline in their own benecaster_boot handler. Call it once, passing your slug and a bootstrap callback — core invokes the callback with the plugin Container, and only when your slug is entitled on at least one connected show. An unregistered slug, or one registered but not currently entitled, is silently skipped: your bootstrap never runs, so none of your filters, actions, or REST routes register.
Registration and invocation happen at two different moments: register() only records the callback. Nothing runs until core’s own late plugins_loaded pass (priority 20 — after benecaster_boot and after any add-on’s own plugins_loaded registration) walks every registered slug. Don’t rely on side effects from your bootstrap having happened by the time benecaster_boot itself returns.
A third, optional argument, $requires_core, declares a compatibility requirement — version (checked with version_compare( BENECASTER_VERSION, ..., '>=' )) and/or capabilities (function or class names checked with function_exists()/class_exists()). Both keys are independent and optional; declare only what you actually depend on. When an entitled add-on’s requirement isn’t met, core shows an admin notice naming your add-on and what it needs, and skips your bootstrap — never a fatal error, never a silent no-op. This is a compatibility check, not a tamper check: it answers “is the thing I need here?”, never “has core been modified?” — do not use it to detect or react to core file changes.
<?php
add_action( 'benecaster_boot', function ( \Benecaster\Container $container ) {
benecaster_register_addon(
'benecaster-addon-guest-manager',
function ( \Benecaster\Container $container ) {
// This only runs when 'benecaster-addon-guest-manager' is
// entitled on at least one connected show — no
// any_show_addon_is_active() check needed here.
$container->make( \GuestManager\GuestManagerPlugin::class )->register();
},
[
'version' => '1.60.0', // minimum Benecaster core version
'capabilities' => [ 'benecaster_addon_is_active' ], // function/class names that must exist
]
);
} );Parameters
| Name | Type | Default | Description |
|---|---|---|---|
$container |
object |
— | The Benecaster DI container; use `make()` to resolve Benecaster services. |
Examples
Boot an add-on
add_action( 'benecaster_boot', function ( $container ): void {
( new My_Addon\Plugin( $container ) )->register();
} );Notes
Add-ons that check license entitlement should do so inside this callback rather than at file load time — the license services are not resolvable before the container is built.