benecaster_activate_template()
benecaster_activate_template( string $slug ): true|WP_ErrorActivates a design template by slug — either a built-in (default-light, default-dark) or one installed from a zip by benecaster_install_template().
Installing and activating are separate on purpose: a freshly installed template appears in the list and changes nothing until someone selects it. This is the selecting half.
Parameters
| Name | Type | Default | Required | Description |
|---|---|---|---|---|
$slug |
string |
— | Yes | Slug of a built-in or installed template — default-light, default-dark, or a slug returned by benecaster_install_template(). |
Return Value
Type:
true|WP_Error
true once the template is active, or a WP_Error with code benecaster_template_activate_failed when no built-in or installed template carries that slug.
Example
$activated = benecaster_activate_template( 'my-addon-template' );
if ( is_wp_error( $activated ) ) {
error_log( 'Template activation failed: ' . $activated->get_error_message() );
return;
}
Notes
It answers with WP_Error rather than throwing. The only failure is that no template carries the slug, and it arrives with code benecaster_template_activate_failed. Check is_wp_error() rather than wrapping the call in try/catch. That matters most on benecaster_boot, where an uncaught throw takes down every request on the site.
A failed activation leaves the previously active template in place. It does not clear the setting on the way out, so a site keeps rendering what it was already rendering.
Authorisation is the caller's job. This writes a site-wide option and performs no capability check, because a CLI command or a background installer has no current user to check. If anything a web request can reach calls it, do the capability and nonce checks yourself first — see benecaster_rest_permission_admin().
Need this built rather than just documented? See our services →