benecaster_registered_token_types
Registers a token type, so Benecaster treats an add-on’s listeners correctly everywhere without knowing what the add-on is. There is no setting for this in the podcaster’s admin: it is a developer surface only.
Each entry is keyed by a slug and declares two things: a label (what the listener is called on the Supporter Wall, in badges and on the account page) and behaves_as, the built-in the type inherits every behavioural answer from. behaves_as accepts subscriber or follower only. purchaser is a built-in but not a base, so a descriptor naming it is rejected. There are no per-behaviour overrides: feed resolution, the license gate, email audiences, promotion and front-end classification all follow the base.
Slugs must be vendor-prefixed (lowercase letters, digits, _ and -, up to 100 characters), which leaves Benecaster the whole unprefixed namespace. The filter is add-only. Benecaster re-applies its built-ins afterwards, so a callback can add a type but can never remove or redefine subscriber, follower or purchaser, and a return that is not an array is discarded. Tampering with a built-in, or registering a refused slug, raises _doing_it_wrong() naming the slug so the mistake explains itself.
Counting is not yours to change. A descriptor has no is_paying or exempt field, and the exemption lists are Benecaster’s with no filter. A registered type therefore counts toward the plan’s subscriber limit whenever its tier is paid, whatever it behaves like. A follower-like type is non-paying because its tier is free, not because of its base.
Two add-ons registering the same slug cannot be detected. The filter passes an array keyed by slug, so a second callback assigning the same key overwrites the first and Benecaster sees one entry. The vendor prefix is the only protection, so choose one that is yours.
A listener whose type is no longer registered, because the add-on was deactivated, is treated as a subscriber and keeps resolving by tier. A slug that matches one of your tier slugs is allowed and is the intended pattern.
Parameters
| Name | Type | Default | Description |
|---|---|---|---|
$types |
array |
— | Registered types, keyed by vendor-prefixed slug, each `[ 'label' => string, 'behaves_as' => 'subscriber'|'follower' ]`. Starts empty: Benecaster's built-ins are added after the filter runs. |
Returns:
array
Example
add_filter( 'benecaster_registered_token_types', function ( array $types ): array {
$types['transcription-service_patron'] = [
'label' => __( 'Patron', 'my-addon' ),
'behaves_as' => 'subscriber',
];
return $types;
} );
Notes
Register during benecaster_boot. The type is stored in benecaster_tokens.token_type, which is 100 characters wide, so a descriptive vendor prefix fits.
Affects
- Token\TokenTypeRegistry
Need this built rather than just documented? See our services →