BulkEnrollmentProcessor
\Benecaster\Membership\BulkEnrollmentProcessor
The synchronous core of bulk enrollment: it takes a list of email addresses and adds each one to a show, without going through Stripe (no payment, no Stripe customer, no Stripe subscription). It can be called directly from custom code such as WP-CLI, a scheduled job or your own REST endpoint. The admin’s Subscribers → Bulk enroll screen reaches it through a background job runner instead, so a long list does not block a request.
A batch is either subscribers or followers. A subscriber batch (the default) enrolls each address on a tier of a show running the built-in membership: it finds or creates the WordPress user, and unless that person already has an active subscription on the show, creates the subscription with the source admin_enrolled, which mints the feed token and queues the welcome email. A follower batch adds each address as a free follower, with no tier and no subscription: an address that already holds any token on the show, including a paying subscription, is left untouched and reported as already enrolled, the unlicensed follower cap applies, and double opt-in is honoured.
A subscriber batch on a show whose active bridge is not the built-in membership (including a show with no bridge) is refused before any row is processed, by throwing BulkEnrollBridgeNotBuiltin, because the enrollment writes a native subscription the show’s real membership plugin would never see. A follower batch works under every bridge.
The class puts no limit on the number of addresses. The REST endpoint caps a request at 1,000, and a large batch run inline is still subject to the PHP time limit. One bad row never stops the batch: a row that throws is reported as an error and processing continues.
Constructor Dependencies
| Type | Description |
|---|---|
\Benecaster\Membership\NativeSubscriptionManager |
Creates the subscription for each address in a subscriber batch, which starts the token and welcome-email chain. |
\Benecaster\Membership\SubscriptionRepository |
Checks whether an address already has an active subscription on the show before enrolling it. |
?\Benecaster\Token\FollowerSignup |
Optional, but required for a follower batch. enroll() throws LogicException if a follower batch is attempted without it. |
?\Benecaster\Bridge\BridgeManager |
Optional, but required for a subscriber batch. Used to check that the show runs the built-in membership. enroll() throws LogicException if a subscriber batch is attempted without it; a missing manager never skips the check. |
Methods
| Method | Visibility | Since | Description |
|---|---|---|---|
enroll( array $addresses, int $show_id, string $tier_slug, string $billing_interval = 'monthly', ?callable $progress = null, string $token_type = 'subscriber' ): array |
Public | — | Enrolls each address and returns a reconciliation report. Addresses are trimmed and empty entries dropped. $token_type is 'subscriber' or 'follower'; anything else throws InvalidArgumentException. $tier_slug must already exist on the show (the caller checks); it is ignored for followers, who carry the show's follower slug instead. $billing_interval is informational only, since nothing bills; it fills a required column. For each address the outcome is created, already_enrolled, skipped (invalid email, with message invalid_email, or the follower cap, with follower_cap_reached) or error (user creation failed, or an exception message). A follower who was sent a double opt-in confirmation counts as created with message confirmation_sent and has no token until they click. $progress, when given, is called with the partial report after every row. After the last row it fires benecaster_bulk_enrollment_complete and returns { enrolled, already_enrolled, skipped, errors, rows }, where rows is a list of { email, outcome, message? }. Throws BulkEnrollBridgeNotBuiltin for a subscriber batch on a show not running the built-in membership, before anything is created and without firing the action, and LogicException when the dependency the batch needs was not supplied. |
Constants
| Name | Value | Description |
|---|---|---|
IMPORTABLE_TOKEN_TYPES |
[ 'subscriber', 'follower' ] |
The token types an import may write. The list is deliberately shorter than the set of token types that exist, because the type drives paying-subscriber counts, tier analytics, the Supporter Wall and email audiences, and an import may only write a value all of them understand. |
Hooks Fired
Notes
On the benecaster_bulk_enrollment_complete action, the skipped count is the report's skipped plus already_enrolled, so a listener sees one "did nothing, no failure" figure; the returned report keeps them separate. A new WordPress account is created with a random password nobody chose, and benecaster_subscriber_account_provisioned fires only for accounts this call created, never for an existing user, so adding someone who already has a login does not email them a password reset. The REST endpoint also checks the bridge itself so a client gets a clean 409 (bridge_not_builtin) instead of a caught exception. Subscriber enrollment also fires the hooks of the activation chain (benecaster_subscription_activated and the token and welcome-email hooks after it), and follower enrollment fires benecaster_follower_signed_up, from the classes that do the work rather than from this one.