Client Lockbox Membership documentation

WordPress plugin client-lockbox-membership 1.0.8 · Author 007AJ · Works with any WordPress theme

Install

This package is the Client Lockbox Membership plugin (client-lockbox-membership-1.0.8.zip). It works with any WordPress theme. Requirements: WordPress 6.3+ and PHP 7.4+. Upload the ZIP file as it is (do not unzip it).

1. In wp-admin go to Plugins > Add New Plugin > Upload Plugin.
2. Choose client-lockbox-membership-1.0.8.zip and click Install Now.
3. Click Activate Plugin. Activate it per site; multisite network activation is not supported.
4. Open Client Lockbox in the wp-admin menu to configure levels, Stripe, portal, signals, downloads and starter sites.

WP-CLI: wp plugin install client-lockbox-membership-1.0.8.zip --activate.

Updating: upload the new ZIP the same way and choose Replace current with uploaded. Member data and stored files are kept.

First-time setup guide

Do this once after activating the plugin. The same steps, with live ticks and buttons, are in Client Lockbox → Setup guide in your WordPress admin.

Step 1 — Create a membership level

1. Go to Client Lockbox → Levels.
2. Under Add level, enter a Name (for example Gold Plan), a Price (0 = free) and an Interval (once, day, week, month or year). Optional: trial days, download cap, admin approval.
3. Leave Level is available ticked and click Save level.

Step 2 — Find the level ID and the signup shortcode

The level ID is created from the name when you save it (for example Gold Plan → goldplan). The Levels list shows it in the ID column, next to a ready-to-copy Signup shortcode. The name slug (gold-plan) is accepted too.

• [clbm_signup] — no level needed. It uses the Default signup level from Settings if you set one; otherwise the only active level; otherwise visitors choose from all active levels on the form. If no level exists yet, visitors see “Signup is not available yet” and administrators see a link to create a level.
• [clbm_signup level="ID-or-slug"] — signup for one specific level, e.g. [clbm_signup level="goldplan"].
• Block editor: add the Membership signup block and pick a level from the Membership level dropdown in the block sidebar, or keep Let visitor choose.

Step 3 — Create or assign the Signup, Account and Portal pages

Easiest: on Client Lockbox → Setup guide (or Settings) click Create pages for me. It creates the missing pages with the right shortcode and assigns them.

Or assign existing pages in Client Lockbox → Settings. An assigned page works automatically: if its content does not contain the shortcode, the plugin adds it when the page is shown. Settings shows the status of each page. The shortcodes are:

Step 4 — Connect Stripe (paid levels only)

In Settings, paste your Stripe secret key (sk_test_… to test), add the webhook URL shown there in Stripe → Developers → Webhooks, and paste its signing secret (whsec_…). Free levels work without Stripe. See Stripe.

Step 5 — Test a signup

Open the Signup page in a private browser window, create a test account, then check Client Lockbox → Members and the Account page.

Modules

• Core — levels, members, restriction, drip, approvals, emails, reports.
• Portal — [clbm_portal]; files kept in the private storage folder (see Private file storage).
• Signals — CPT + [clbm_signals] / [clbm_signals_pnl]; optional Telegram/Discord. Signals are members-only: not in the REST API, search, sitemaps, feeds or archives; neutral addresses such as /signal/signal-123/.
• Downloads — [clbm_downloads]; files kept in the private storage folder; per-level caps; optional buyer product keys. Only administrators can create Downloads and upload their files.
• Starters — import/rollback five page sets from Client Lockbox > Starter sites.

Shortcodes and blocks

• [clbm_signup] or [clbm_signup level="ID-or-slug"] — signup form (see First-time setup); also available as the Membership signup block with a level dropdown.
• [clbm_checkout level=""] — checkout form for a level (optional coupon code) that continues to Stripe hosted Checkout.
• [clbm_account] — the signed-in member's level, status, invoices and a button that opens the Stripe Customer Portal.
• [clbm_portal] — client portal.
• [clbm_signals limit="50" status=""] and [clbm_signals_pnl limit="100"] — signal history and P&L table.
• [clbm_downloads] — protected downloads list.
• Restricted content block — shows its content only to members of the level ids you enter, with optional drip days.

Output uses your active theme's styles.

Stripe

Use Stripe hosted Checkout only. Save the secret key and webhook signing secret under Settings. Card numbers never touch your WordPress server. Prices, currency and trial length always come from the level saved on your site, never from the browser.

Webhook events to send (Stripe → Developers → Webhooks): checkout.session.completed, customer.subscription.updated, customer.subscription.deleted, invoice.paid, invoice.payment_failed, charge.refunded, customer.deleted.

Paid levels, plan changes and approvals

• Paid levels need Stripe. A level with a price above 0 is only ever activated after Stripe confirms payment. If Stripe is not configured (or cannot be reached), the signup page shows “Online payment is not available right now” and nothing is created or activated; administrators see a notice listing the affected levels and the last blocked attempt.
• Changing to another paid level. Starting a new Checkout does not change the current membership. The new purchase is remembered separately and applied only when Stripe confirms it; the previous subscription is then canceled automatically. An abandoned Checkout leaves everything as it was.
• Paid → free. When a paying member joins a free level, the Stripe subscription is canceled first (immediately). Only after Stripe confirms is the membership switched; if Stripe fails, nothing changes and the member sees an error.
• Levels that require approval. For a paid level with “Require admin approval”, the member pays at Checkout and waits as pending_approval without access. Approve grants access. Deny cancels the Stripe subscription immediately, so no further charges are made. Refunds of the first payment are not automatic: issue them in your Stripe Dashboard if your policy offers one. If Stripe cannot confirm the cancellation, the member is set to denied_pending_cancel (no access) and the subscription goes into the reconciliation queue (see Subscription cleanup).
• Roles. A level's role is added while the membership is active. On a level change the previous level's role is removed before the new one is added. The plugin only removes roles it added itself; roles you assign by hand stay.
• One membership per user. Each user has exactly one membership row (unique database index). Duplicates from older versions are merged on update, and no extra subscription is left billing. Before a duplicate row is removed, each of its subscriptions is checked in Stripe. The row whose subscription is active is kept (if several are: the one active on your site, then the highest-priced level, then the newest). The other live subscriptions are canceled in Stripe immediately; Stripe does not prorate or refund an immediate cancellation. Already-canceled ones are skipped. Merged rows are kept in an archive table and their invoices move to the kept row. If Stripe is not connected or a cancellation fails, the subscription goes into the reconciliation queue (see Subscription cleanup). The merge runs under a database lock, is safe to repeat and never cancels a subscription twice. Stripe confirmations for the same member are processed one at a time under a database lock with a conditional update: if two Checkouts complete at the same moment, the last confirmed one is kept and the other subscription is canceled in Stripe (queued on failure).
• Paid signup. The Stripe Checkout Session is created before anything is sent. If it cannot be created, the account made in that request is removed again, no email is sent, and the visitor sees “Your account was not created. Please try again” and can retry. The welcome email for a paid signup is sent when Stripe confirms the purchase (checkout.session.completed); for a free signup it is sent immediately.
• Trials. A level's trial is given once per user account; a second Checkout by the same account starts without a trial. A new account with a different email can get a new trial.
• Buying rules. Free levels are joined without Stripe, and a level the member already holds cannot be bought again. The success page after Checkout never grants access by itself; only the verified webhook does.
• Coupons. Only active coupons from Client Lockbox → Coupons are accepted; unknown or inactive codes are refused and never sent to Stripe (raw Stripe coupon IDs are not accepted). Coupons created before Stripe was connected are created in Stripe when you save the Stripe settings, or at checkout. Deactivating deletes the coupon in Stripe so it cannot be redeemed again (discounts already running continue, as in Stripe); if Stripe fails, an admin notice appears with a Retry button and the deletion is retried hourly. Reactivating creates it in Stripe again.
• Status, failed payments and refunds. Access follows the Stripe subscription: active and trialing have access; past_due, unpaid, canceled and expired do not. A refund of a subscription payment does not cancel the subscription; cancel it in the Stripe Dashboard if access should end. A full refund of a one-time purchase ends that membership; partial refunds are only recorded on the invoice. Disputes are not handled automatically.
• Deleted customers and users. If the customer is deleted in Stripe, the stored reference is cleared so the member can check out again. Deleting a WordPress user ends all of their Stripe subscriptions on this site; see Deleting a user.
• Expiry. The hourly WP-Cron check expires memberships without a Stripe subscription when their end date has passed. Stripe-billed memberships are never expired locally; the plugin re-reads the subscription from Stripe instead.
• Approvals. Only memberships waiting for approval can be approved; only waiting or pending ones can be denied.
• Roles. A level's role may not include administrative or publishing capabilities (for example manage_options, edit_users, publish_posts, upload_files, unfiltered_html); such roles are refused.
• Portal. Every upload, download, delete and folder action re-checks the current membership, so an old link stops working as soon as access ends.

Webhooks only tell the site which subscription changed; the plugin then reads the subscription from Stripe and stores its status and dates. Events can therefore arrive in any order (for example customer.subscription.created before or after checkout.session.completed), and trial or period dates are never cleared by an incomplete event. Member records are updated field by field, so unrelated fields are never reset.

Webhooks are signature-checked, then each event is claimed as processing, handled, and marked processed only after it succeeded. If handling fails, the event is marked failed and the site answers with an error so Stripe retries it. A claim left by a crashed request expires after 5 minutes. Only successfully processed events are skipped as duplicates.

Subscription cleanup and admin notices

Whenever the plugin has to end a Stripe subscription (a duplicate membership merged on update, a WordPress user deleted, an approval denied, a second subscription replaced, or the plugin uninstalled with data deletion), it asks Stripe first. Any subscription Stripe does not report as canceled or incomplete_expired (for example active, trialing, past_due, unpaid, incomplete, paused) is canceled immediately; Stripe does not prorate or refund an immediate cancellation. A subscription that is already canceled is skipped. A subscription is never canceled twice.

Updating from older versions: duplicate memberships

Versions before 1.0.5 could leave a user with more than one membership row. On update the rows are merged so each user has exactly one. Before any row is removed, the plugin reads the status of every subscription on those rows from Stripe. It keeps the row whose subscription is active (if several are: the one active on your site, then the highest-priced level, then the newest), cancels the other live subscriptions and skips canceled ones. Every removed row is copied to an archive table first, and its invoices are moved to the kept row. The merge runs under a database lock and can safely run again (for example after an interrupted update). If Stripe is not connected yet during the update, nothing is canceled blindly: the extra subscriptions go into the reconciliation queue and are canceled once Stripe is connected.

The reconciliation queue and its retry schedule

A cancellation that cannot be done right away (Stripe not connected, an API error, a timeout) is stored in one reconciliation queue, together with the user, the Stripe customer, the reason and, for a deleted user, their email address and name. The queue is processed by the hourly WP-Cron event. The first retry is one hour after the item was queued; after that each failed attempt doubles the wait (1, 2, 4, 8, 16 hours), then once a day until it succeeds. Before each attempt the plugin reads the subscription from Stripe again, so a subscription you canceled yourself is simply marked done. An item leaves the queue only when Stripe confirms the subscription is canceled or you click I handled it in Stripe; it is never dropped. Items queued by version 1.0.6 or earlier are moved into this queue on update.

When the database cannot be written

Every caller that ends a subscription (user deletion, duplicate merge, denial, a replaced subscription after a new Checkout, the webhook for a deleted user, uninstall and the hourly check) follows one rule: nothing is deleted or marked done unless Stripe confirmed the cancellation or the item was durably recorded. “Queued” means the queue row was written and read back. If the queue table cannot be written (a database error, a full disk), the item goes into a separate fallback store (the non-autoloaded option clbm_reconcile_fallback), with its own admin notice and one email; the hourly check moves it into the queue once writes work again. If neither can be written, the destructive step is skipped: when a user is deleted, the membership row, archived rows and pending Checkouts are kept and flagged, and the hourly check finishes the job later. A per-customer sweep (all of this site’s subscriptions for a deleted user’s Stripe customer) is closed only when every subscription was canceled, skipped or queued; otherwise it stays in the queue with backoff. Stripe lists are read page by page to the end; a failed page counts as a failure, never as a shorter list.

If WP-Cron is disabled on your server (DISABLE_WP_CRON), make sure a real cron job calls wp-cron.php, or run wp cron event run --due-now regularly; otherwise use Retry now.

What each admin notice means

Manual recovery

1. Open the Stripe Dashboard → Billing → Subscriptions and search for the subscription id shown in the notice (or the customer email).
2. If it is still active, choose Cancel subscription → Immediately. Issue a refund there if your policy offers one; the plugin never refunds.
3. Back in WordPress, click I handled it in Stripe next to that line. The item is marked handled and leaves the notice.
4. If you would rather let the plugin do it, fix the Stripe connection and click Retry now; it re-reads every queued subscription and cancels the live ones.

Deleting a user

Deleting a WordPress user (Users → Delete, bulk delete, or removing a user from a site on multisite) ends every Stripe subscription that belongs to that user on this site, whatever the local membership status says. The plugin collects:

• the subscription on the membership row;
• subscriptions on rows archived by the duplicate merge;
• Checkouts the user started that were not confirmed yet: an open Checkout Session is expired so it can no longer be paid; a completed one has its subscription canceled;
• the subscriptions Stripe lists for the user's customer that were created by this site for this user (each subscription carries a per-site key, so other sites sharing the Stripe account are never touched).

Each one is canceled if live, skipped if already canceled, or queued with the user's email and name if Stripe cannot be reached. The membership row is copied to the archive table before it is deleted; if even the queue cannot be written, the row is kept so no subscription id is lost. A Checkout paid after the user was deleted is canceled when its webhook arrives. Membership rows whose user disappeared without the normal delete (for example a direct database change, or a deletion on another network site while this plugin was not loaded) are found and handled by the hourly check. Invoices do not store a subscription id; their subscriptions are covered through the customer listing.

Levels, deactivation and uninstall

• Deleting a level is refused while any membership row uses it; untick Active instead.
• Deactivating the plugin never cancels subscriptions and keeps all data.
• Deleting the plugin removes nothing unless Delete all plugin data on uninstall is ticked. With it ticked, live member subscriptions are canceled first. Checkouts that were paid but not yet confirmed by their webhook are looked up in Stripe and their subscriptions canceled; open Checkouts are expired. Anything that cannot be handled is emailed to the site email address and kept in the reconciliation table, which is then the only table left. If that table cannot be written, nothing is deleted and the site email address is told that the data was kept.
• Privacy erasure keeps a membership row whose Stripe subscription is live or cannot be checked, while a Checkout is still open or paid but not yet processed, or while an item waits in the fallback store; cancel it first. Archived rows and reconciliation records are erased only when the queue can be read and nothing is pending.

Private file storage

Portal and download files are never public media. They are delivered only through the plugin after a permission check (the signed-in owner or an administrator, or a valid signed link you created).

• Default: on activation the plugin creates a randomly named folder outside the web root (next to the WordPress folder, e.g. clbm-private-1a2b3c4d5e6f7a8b/) when that location is writable and not publicly served.
• Fallback: otherwise it uses a randomly named folder inside uploads (wp-content/uploads/clbm-vault-…/) with .htaccess, web.config and index.php guards.
• Self-test: the plugin writes a random test file, requests it once over HTTP from your own site and deletes it. If it can be downloaded (common on Nginx, which ignores .htaccess), administrators see a persistent warning and a critical Site Health result with the exact rule to add. See Client Lockbox > Settings > Private file storage (with a Check again button).

Nginx rule (use the folder name shown in your warning), then nginx -t && systemctl reload nginx:

location ^~ /wp-content/uploads/clbm-vault-xxxxxxxxxxxxxxxxxxxxxxxx/ {
    deny all;
}

To choose the folder yourself, add define( 'CLBM_STORAGE_DIR', '/full/path/outside/web/root/clbm-files' ); to wp-config.php. CLBM_PORTAL_DIR and CLBM_DOWNLOADS_DIR still set each area separately.

Content restriction

Tick Restrict this content in the Client Lockbox access box of a post or page and enter the required level ids (empty = any active member) and optional drip days. A restricted post is protected wherever WordPress can show it: the single view, archives and the home page, search results, RSS/Atom feeds, the REST API (posts, pages, search and comments endpoints), oEmbed embeds and comments. Visitors without access see the title and the members-only message instead of the text and excerpt; its comments are hidden and closed for them, and it is left out of their searches. The search check (front-end search, the search feed, REST /wp/v2/search and REST post/page lists with ?search=) runs inside the search query against a lookup table that the plugin keeps in step with each post's access settings. It has no size limit and costs the same number of queries however many restricted posts the site has. Administrators and anyone who can edit the post always see it. Signals follow the same rules and also hide their title.

The search lookup table

The table {prefix}clbm_post_levels holds one row per restricted post and level (* = any active member) with its drip days. It is updated when you save a post, when the access settings change in any other way (for example by code or import) and when a post is deleted. Updates fail closed:

• While a post's rows change, a marker row hides it from everyone except editors; the level rows are swapped inside a database transaction and the marker is removed in the same commit.
• A post that has restriction settings but no rows is hidden from search, so a lost write can never make it public.
• If a write fails, the change is rolled back, the post stays hidden, the error is logged (in debug.log when WP_DEBUG_LOG is on), and a resync is scheduled with WP-Cron. If it keeps failing, the “search access table” notice appears with Retry now.
• Removing a restriction clears the setting first and only then deletes the rows.

After updating: the backfill

When you update from 1.0.5 or earlier, existing restricted posts are added to the table in batches of 500 (on activation and then every minute through WP-Cron; about a second per 6,000 posts). Until a post is reached, it is hidden from search for everyone except editors; the single view, archives and REST access checks are not affected. If restricted posts still do not appear in members' searches some minutes after the update, WP-Cron is probably not running: run wp cron event run clbm_post_levels_backfill (each run works for up to 20 seconds and schedules the next one if posts are left), or set up a real cron job for wp-cron.php. Running the backfill again is harmless.

Starter sites

Open Client Lockbox > Starter sites to import one of five page sets: client portal, signals club, download club, course and community. Import one starter at a time. Pages are built from core WordPress blocks and take their look from your active theme. Rollback removes pages/menu created by that import and restores the previous front-page settings. Levels added by a starter are kept (additive).

External Services

By default, with no payment or chat credentials saved, this plugin does not call outside hosts. When an administrator saves Stripe credentials, the site contacts Stripe for hosted Checkout, the Stripe Customer Portal and inbound webhooks. Card details are entered on Stripe's pages and never reach your site. Telegram (api.telegram.org) and Discord (discord.com webhooks) are contacted only when Signals push is enabled with your own bot token or webhook. The storage self-test makes one HTTP request from your site to its own address (never to another host) to confirm private files cannot be downloaded directly. Nothing is sent to 007aj.com for product unlock checks. This plugin has no License tab and does not gate features behind a product key.

Privacy

Client Lockbox Membership stores membership levels, member–level associations, order and invoice records (amounts, currency, status, payment-provider references — never card numbers), content-restriction and drip settings, email template settings, report aggregates, and (if you use those modules) portal file metadata, signal posts you create, download logs, and optional product keys you issue for your downloadable products, and records of Stripe subscriptions the plugin had to cancel (with the email address and name of a deleted user until that cancellation is resolved), in your site's database. Members can request an export or erasure through Tools → Export Personal Data / Erase Personal Data: the export covers the membership, rows archived when duplicates were merged, reconciliation records, invoices, download log, portal file list and portal activity, and it is exported in pages so every record is included; erasure removes the membership row (unless its Stripe subscription is still live or cannot be checked), archived merge rows (unless a subscription is still waiting in the reconciliation queue), the plugin's user meta and IP addresses in logs, and keeps invoices and portal files for your records. Portal and download file bytes are stored in a private folder outside the web root when the server allows it (otherwise in a randomly named folder inside uploads that the plugin tests for direct access) and are delivered only through the plugin after a permission check. The plugin sets no marketing cookies. It does not claim to make your site HIPAA- or GDPR-compliant; you remain responsible for your own policies, lawful basis and server security. When you delete the plugin, nothing is removed unless you tick "Delete all plugin data on uninstall" first. With it ticked, the plugin's tables, options, transients, scheduled events, Signals and Downloads posts, plugin post meta, plugin user meta (single site only; user meta is shared on multisite) and the private file folders are removed; live member subscriptions are canceled first, and any that cannot be are emailed to the site email address and kept in the reconciliation table. WordPress roles are never deleted.

FAQ

Are files safe on Nginx?

Yes. By default they are stored outside the web root, so there is no URL to download them from. If your host only allows the uploads fallback, the self-test detects direct access and shows the exact Nginx rule to add until the files are blocked.

Can a signed link or product key be used more times than allowed?

No. Each use is counted with one atomic database update that only succeeds while uses remain, so parallel requests cannot exceed the limit. Per-member download caps are enforced the same way.

What happens if a Stripe webhook fails part-way?

The event is marked failed and the site returns an error, so Stripe retries it. It is treated as a duplicate only after it was processed successfully.

Is a paid membership ever activated without payment?

No. Paid levels are only activated after Stripe confirms the payment or subscription. Without a working Stripe connection, paid signups are refused with a clear message.

What happens to billing when I deny an approval?

The Stripe subscription is canceled immediately. Refunds are up to you and are made in the Stripe Dashboard. If the cancellation fails, the member has no access and the subscription goes into the reconciliation queue (see Subscription cleanup).

What happens to billing when I delete a user?

All of the user's subscriptions on this site are canceled, or queued if Stripe cannot be reached. See Deleting a user.

Can I delete a level that has members?

No. Untick Active to stop new signups instead.

Is multisite supported?

Activate the plugin on each site; network activation is blocked. Each site keeps its own levels, members and files. User accounts and user meta (Stripe customer reference, trial used) are shared across the network by WordPress.

Can a member end up with two active subscriptions?

No. See One membership per user under Stripe.

Do I need a product key?

No. All included features work when the plugin is active. There is no License tab or activation screen.

Changelog

1.0.8

• Billing: every cancel helper returns one result (cancelled, skipped, queued or failed); “queued” is only reported after the queue row is read back. One durability rule for every caller: queue table, else a fallback store with its own notice and email, else the destructive step is not done.
• Billing: deleting a user keeps the membership row, archived rows and pending Checkouts (flagged) when a queue write fails; the hourly check finishes later. The customer sweep stays pending until every subscription is canceled, skipped or queued, and Stripe lists are read to the last page.
• Billing: a replaced subscription is recorded before the membership switches to the new one; if it cannot be recorded, the webhook fails so Stripe retries it.
• Uninstall: paid Checkouts whose webhook had not arrived are canceled, open ones expired; items Stripe cannot confirm are kept; if they cannot be saved, nothing is deleted. Privacy: erasure keeps the membership while a Checkout is open or unprocessed or an item waits in the fallback store.

1.0.7

• Billing: deleting a WordPress user (single, bulk, or removal from a multisite site) ends every Stripe subscription tied to the user, whatever the local status: the membership row, archived merge rows, unconfirmed Checkouts (open sessions are expired) and this site's subscriptions for the user's customer. Live ones are canceled, canceled ones skipped, the rest queued with the user's email and name. The membership row is archived before deletion.
• Billing: one reconciliation queue for every cancellation (merge, user deletion, denial, replaced subscription, uninstall) with hourly retries and backoff, Retry now and I handled it in Stripe, and one email. The earlier retry list is moved into it on update.
• Billing: subscriptions carry a per-site key so a site only cancels its own; a Checkout paid after its user was deleted is canceled by the webhook; membership rows whose user disappeared are handled by the hourly check.
• Restriction: the search lookup table is updated fail-closed (marker row + transaction; posts with restriction settings but no rows stay hidden). Failed writes are rolled back, logged, resynced by WP-Cron and shown in an admin notice with Retry now if they persist. Unrestricting deletes rows only after the setting is cleared.
• Levels: a level with members cannot be deleted. Privacy: erasure keeps a membership whose subscription is live or cannot be checked. Uninstall with data deletion cancels live subscriptions first and keeps any it could not cancel.

1.0.6

• Members: merging duplicate membership rows cancels the extra live Stripe subscriptions (immediately, no proration), skips already-canceled ones, keeps the row with the active subscription, archives instead of deleting, and re-links invoices.
• Members: reconciliation queue when Stripe is not connected or a cancellation fails. Hourly retry with backoff, an admin notice with Retry now and I handled it in Stripe, and one email. The merge is lock-protected and safe to repeat.
• Restriction: search filtering moved into the search query with a lookup table. There is no 5,000-post limit and no per-post checks. It covers front-end search, the search feed, REST /wp/v2/search and REST lists with ?search=. A batched backfill runs on update and hides posts from search until it reaches them.
• Performance: membership lookups for access checks are cached per request.
• Privacy: paged exporter with no row limits, which includes archived merge rows and reconciliation records.
• Uninstall: pending reconciliation items are emailed before the tables are removed.

1.0.5

• Restriction: restricted posts, pages and Signals no longer leak through the REST API, feeds, excerpts, search, archives, oEmbed or comments.
• Signals: removed from REST, search, sitemaps, feeds and archives; title gated; neutral permalinks.
• Billing: concurrent Stripe confirmations for one member leave exactly one active subscription (database lock + conditional update).
• Members: unique membership row per user with automatic merge of old duplicates; atomic first insert; unique invoice rows.
• Coupons: only active local codes reach Stripe; deactivation deletes the Stripe coupon (notice + retry); reactivation recreates it; pre-Stripe coupons are synced on settings save and at checkout.
• Signup: Checkout is created first; on failure the new account is removed, no email is sent and a clear error is shown. Paid welcome email is sent after Stripe confirms.
• Billing: one trial per account; free or already-held levels cannot be bought; Stripe errors are logged, not shown; stale customer ids recovered; charge.refunded and customer.deleted handled; deleting a user cancels their subscription.
• Expiry: Stripe-billed members are re-synced, never expired locally while the subscription is live.
• Approvals: only pending memberships can be approved or denied.
• Downloads: administrators only. Roles: dangerous capabilities refused.
• Privacy exporter and eraser; fuller uninstall (posts, meta, cron, transients; multisite per site).
• Portal and Downloads: fixed error messages; signed links no longer shown in the address bar. Uppercase currency accepted; translatable email templates.

1.0.4

• Billing: paid levels always fail closed when Stripe is unavailable, with a visitor message and an admin notice.
• Billing: a new Checkout no longer changes the existing membership until Stripe confirms it; the replaced subscription is then canceled.
• Billing: paid → free cancels the Stripe subscription first; nothing changes if Stripe fails.
• Approvals: deny cancels the Stripe subscription; failures become denied_pending_cancel with admin email, notice and hourly retry.
• Members: partial updates; webhooks read the subscription from Stripe, so event order does not matter and dates are kept.
• Portal: download and delete re-check membership at request time.
• Roles: previous synced role removed on level change; manually assigned roles kept.

1.0.3

• Setup: new Setup guide screen; assigned Signup, Account and Portal pages work without the shortcode; Create pages for me button and page status on Settings.
• Signup: [clbm_signup] without a level uses the default level, the only level, or a level chooser; level accepts an ID or slug; block level dropdown; Default signup level setting; Levels list shows ID and shortcode.
• PHP 8.5: removed deprecated finfo_close() calls.
• Storage: changing the storage folder (e.g. adding CLBM_STORAGE_DIR) now moves files from every earlier location, including the clbm-vault-… uploads folder, with verification, resumable batches, an admin notice on failure and removal of the empty old folder.

1.0.2

• Wording: the plugin is described as a standalone membership plugin that works with any WordPress theme.
• Starter sites: Join pages link to their own membership level; headings use the active theme's colours.

1.0.1

• Private files now default to a randomly named folder outside the web root; uploads fallback uses a random folder name with guard files.
• New HTTP storage self-test with admin warning, Site Health check and Nginx deny rule.
• Existing files are moved safely on update (copy, SHA-256 check, then remove).
• Signed-link uses, product-key uses and per-member download caps are counted atomically.
• Stripe webhooks are retry-safe: failed events return an error and are processed again on retry.

1.0.0

• First WPBay release.

Support

Purchase includes 6 months of support. Use continues on 1 domain after support ends. Sold on WPBay and 007aj.com only. Contact admin@007aj.com.