TierUpgradeManager
\Benecaster\License\TierUpgradeManager
Fires a one-per-month warning when a site reaches 80% of its plan’s paying-subscriber limit, and keeps two local subscriber-count history values. That is the whole of it.
The name is wider than the class. It does not upgrade anything, and it implements no plan-change logic at all. Plan changes are decided entirely by the licence server on its own 24-hour rolling windows, which the plugin cannot see — over_limit_since is not published on /validate. If you are looking for where an upgrade is triggered, it is not here.
Registered automatically on plugin boot — do not instantiate directly.
Constructor Dependencies
| Type | Description |
|---|---|
\Benecaster\License\CapChecker |
Supplies the current plan's paying-subscriber limit, from which the 80% threshold is derived. |
Methods
| Method | Visibility | Since | Description |
|---|---|---|---|
register(): void |
Public | — | Hooks on_license_validated() to the benecaster_license_validated action. |
on_license_validated( array $response ): void |
Public | — | Runs on each validation cycle: evaluates the 80% threshold and updates the two subscriber-count history options. |
Hooks Fired
Notes
The threshold is derived, never hardcoded. It is 80% of CapChecker::get_subscriber_limit(). A null limit means an unlimited plan and there is no threshold to reach. It previously used a literal 8-of-10 — the same number for Launch, but it froze a pricing-server value into the plugin. Plan limits are published by the licence server and can change without a plugin release, so a literal would have gone silently wrong on the first pricing change. If you are adding a similar threshold anywhere, derive it the same way.
The warning is a notice cadence, not a plan-change signal. At most once per calendar month, and unrelated to any rule that changes a plan. The licence server sends the customer-facing threshold_warning email; benecaster_license_free_threshold_warning exists so a podcaster can render their own in-plugin notice alongside it. Do not read it as "an upgrade is about to happen".
benecaster_subscriber_count_max and benecaster_subscriber_count_prev have no consumer today. They are written every cycle and read by nothing. The original documentation claimed they fed suspicious-drop detection and the zero-at-activation exception; both live on the licence server. These are kept as cheap local history — treat them as available rather than authoritative, and decide they are the right source before building on them.
A large amount was removed from this class on 2026-08-29, and it should not come back. The audit against the current /validate contract retired: the four calendar-month overage counters and the benecaster_license_overage_month_1 / _month_2 / _cleared hooks; the downgrade lock, including is_downgrade_locked(), both benecaster_free_downgrade_lock_* options and its two hooks; and a reader for an upgrade_required field deleted from /validate on 2026-08-25.
The overage counters were not merely redundant — they were a second, contradictory clock. The plugin counted consecutive calendar months over the limit while the licence server ran rolling 30-day windows for the same event, so an admin notice could fire on a calendar boundary while the server changed the plan on a rolling one. They also cannot be reimplemented faithfully: the window's start (over_limit_since) is not published on /validate, so the plugin cannot see it. The plugin implements no subscriber-count threshold logic beyond the notice above. Downgrade eligibility is likewise the server's downgrade_eligible_since window, published as downgrade_eligible.