Roadmap

Eleven phases, built in order. Phases 1 and 2 already make a complete free or hand-granted members site (plans, access rules, the member area and emails); phase 3 adds selling; phase 4 joins it to the CRM; every later phase is a module on the same plans, membership records and access engine.

65 of 65 tasks completeextension v1.0.16

Verified against the extension source on 2026-10-14.

Phase 1 · Plans, memberships and the access engineDone

14/14

The core every later phase stands on: plans, the membership record that says who holds which plan and in what state, and one access engine that answers "may this person see this?" for every page, post, archive, element and menu. A site can already run a free or manually granted members area at the end of this phase.

• ✓
  Extension scaffold — Done

  The membership extension: manifest, main class, settings, thumbnail and its entry in the Extensions catalogue. Ships inactive; nothing loads until it is switched on.

• ✓
  Tables and migrations — Done

  Its own tables from the first release: plans, prices, memberships, membership history, access rules, payments and the event log, indexed for the screens that read them. A versioned installer with numbered migrations; tables are never dropped on deactivation, only by the explicit "Remove all data" action.

• ✓
  Module switches — Done

  One Modules screen. The core is always on; every other module (payments, drip, groups, courses…) is switched on there, and a module that is off loads no code and adds no menus.

• ✓
  Plans and prices — Done

  Unlimited plans, each with any number of prices (free, one-time, monthly, yearly, custom interval, fixed-date renewal, lifetime), a trial, a setup fee, a duration or expiry date, a sign-up limit, a priority so the highest plan wins when someone holds several, and inheritance (Gold includes everything Silver unlocks). A plan can also give a WordPress role or grant or deny capabilities while it is active, applied on the fly and never written into the role, so switching the extension off leaves nothing behind.

• ✓
  Membership records — Done

  A membership is a real record (person × plan) with a status, start, renewal and end dates, the source that granted it (manual, payment, WooCommerce, group seat, gift, import) and a full history. Several memberships per person are allowed.

• ✓
  Status rules and events — Done

  One service owns every status change (pending, trialing, active, past due, paused, cancelled with access to period end, expired, refunded) and fires one documented event per change, so emails, the CRM, automations and add-ons all listen to one stream.

• ✓
  Access rules — Done

  A rule says what is protected (reusing the Theme Builder's location vocabulary: entire site, post types, single items, terms, archives, child pages, URL patterns), who may see it (plans, any / all / none; logged-in state; roles; later CRM tags, lists and segments, course progress) and when (immediately, after N days, from a date). Each post type has a default (open or protected) and any single post can override it: protect, open, or hide from lists. Rule targets are stored as indexed rows and looked up from the page’s context (its ID, terms, author, post type, template), so one query answers any page however many rules exist, and "except" groups handle "all of this category but this post".

• ✓
  Access engine — Done

  One resolver, fw_membership()->can( $user, $object ), used by every gate below, cached per request, with a filter for custom checks. Admins and editors always pass; a "view as member of…" toggle in the admin bar previews the site as any plan, and an emailed, time-limited rescue link restores an administrator who has locked themselves out.

• ✓
  Leak-proof content gating — Done

  Protection applies everywhere the content can surface, not only the single page: archives and loops, search, RSS feeds, the REST API, comments, sitemaps, attachments of protected posts and adjacent-post links. Most membership leaks come from the places nobody tested.

• ✓
  What a non-member sees — Done

  One clear order when access is denied, shown in the interface: a teaser (excerpt or the first N blocks) with an upgrade prompt, a login form, the pricing table, a redirect, or "not found". Per rule, with a site default. A Paywall prompt element lets designers build the upgrade box in the page builder.

• ✓
  Visibility on every element — Done

  Every page-builder element, section and column gains a Membership tab (next to Advanced, only while the extension is on): everyone, members, people without a plan, members of chosen plans, everyone except them, logged-in or logged-out people, and what everyone else gets instead (nothing, or the members prompt). The same choices are on every menu item, and the [member_content] shortcode covers text written outside the builder.

• ✓
  Menus per plan — Done

  Each menu item can be shown to everyone, logged-in users, logged-out users or chosen plans; members can also get their own menu location.

• ✓
  Caching that never shows the wrong page — Done

  Protected responses are marked uncacheable and a member cookie lets page caches vary, with notes for common caches and hosts, so a cached member page is never served to a visitor.

• ✓
  Membership app in wp-admin — Done

  A Membership screen in the same app style as the CRM: Home, Members, Plans, Access rules, Payments, Reports, Emails, Modules and Settings. Members can be granted, extended, changed or revoked by hand, with notes and the full history.

Phase 2 · Accounts and the member areaDone

9/9

People can join, log in and look after their own account without leaving the site's design. Everything a member sees is a page-builder element, so the member area is designed like any other page.

• ✓
  Registration through Forms — Done

  A Register member form action (next to the CRM's Add to the CRM action) creates the WordPress user, grants a free plan or sends them to checkout, and records consent. New username and password fields join the form builder.

• ✓
  Login, logout and password reset — Done

  A Member Login element styled by the theme (with "forgot your password" and a sign-up link) that logs in through WordPress's own login, so the Security extension's throttling and two-factor login always apply, and per-plan pages after login and logout (members never land in wp-admin). Password reset uses WordPress's own screen.

• ✓
  Email verification and approval — Done

  Optional email verification before access starts, and an optional approval queue for plans that need a human yes.

• ✓
  Account page — Done

  A Member account element with tabs for profile, memberships, payments and invoices, payment method, and security (password, sessions). Members cancel, change plan or update their card here.

• ✓
  Profile fields — Done

  Extra profile fields chosen per plan, stored on the user, or on the CRM contact when the CRM is on, so there is one place for a person's details.

• ✓
  Member emails — Done

  Every lifecycle email (welcome, verification, receipt, renewal reminder, payment failed, card expiring, cancelled, expired, plan changed) editable with placeholders, sent through wp_mail() so the Mailer's transport applies. When the CRM is on, they use its email builder and templates.

• ✓
  Visibility on editor blocks — Done

  The same Membership choices on WordPress's own blocks in the block editor (a panel in the block sidebar, applied when the block renders), for content written without the page builder.

• ✓
  Privacy — Done

  Personal-data export and erasure for memberships, payments and profile fields; payment records are anonymised, not deleted, so accounts stay correct.

• ✓
  REST API and AI connector tools — Done

  REST endpoints for plans, members, memberships and rules with proper capability checks and real HTTP error codes, and AI Assistant abilities to set up plans, rules and pages. No ability reads or exports members' personal data.

Phase 3 · Payments and checkoutDone

8/8

Selling plans directly, with the site owner's own payment accounts and no transaction fee from Unyson+. Billing runs on the payment service's own subscriptions wherever possible, so renewals do not depend on WordPress's scheduler.

• ✓
  Payment gateway layer — Done

  One gateway interface (start a payment, confirm the return, cancel, refund, billing portal, signed webhook) so new gateways are add-ons, and every payment, refund and renewal lands in one payments table.

• ✓
  Card payments and wallets — Done

  The first gateway: cards, Apple Pay, Google Pay and saved-card checkout, subscriptions billed by the payment service, strong customer authentication, signed webhooks with replay protection, and a test mode.

• ✓
  PayPal and offline payments — Done

  PayPal subscriptions, and bank transfer or cash with manual approval.

• ✓
  Checkout and pricing elements — Done

  A Pricing plans element (monthly / yearly toggle, highlighted plan) and a one-page Checkout element that creates the account and takes payment in one step, with an order summary and an optional terms checkbox.

• ✓
  Upgrades, downgrades and proration — Done

  Members switch plans themselves; the price difference is prorated or applied at renewal, per plan.

• ✓
  Coupons — Done

  Percentage or fixed, first payment or forever, per plan, with usage limits, expiry and bulk generation.

• ✓
  Receipts and invoices — Done

  Numbered invoices with the business and buyer details, downloadable as PDF from the account page.

• ✓
  Tax — Done

  Tax rates by country and region, EU VAT with VAT-number validation and reverse charge, or automatic tax calculation by the payment service.

Phase 4 · Connected to the CRMDone

7/7

With both extensions on, every member is a CRM contact, memberships show on the contact's page and timeline, access rules can use CRM tags, lists and segments, and membership events drive CRM automations and campaigns. Built on the CRM's extension API and events (already in the CRM), never its tables.

• ✓
  CRM bridge — Done

  Turns on by itself when the CRM is active. Registers Membership as a CRM integration and degrades cleanly when the CRM is off.

• ✓
  One person, one contact — Done

  Registration finds or creates the CRM contact by email and links it to the WordPress user; email changes stay in sync both ways, and duplicates are never created.

• ✓
  Plans mirrored to tags — Done

  Each plan maps to a CRM tag (and optionally a list) that is added and removed as the membership changes, plus a nightly reconcile. The membership stays the source of truth; tags are a mirror, so they never drift.

• ✓
  CRM conditions in access rules — Done

  Access rules and element visibility can use CRM tags (any / all / none), lists, segments, lifecycle stage and contact fields, through the CRM's filter engine, so the rule language is the same in both extensions.

• ✓
  Timeline and contact page — Done

  Joined, renewed, payment failed, plan changed, cancelled and expired land on the contact's timeline, and the contact page gets a Membership panel (plans, payments, grant or extend).

• ✓
  Automation triggers and actions — Done

  Triggers: member joined, trial ending, renewal due, payment failed, cancelled, expired, drip unlocked, inactive for N days. Actions: grant, extend, pause or revoke a plan, and send a coupon.

• ✓
  Member value on the contact — Done

  Plan, status, member since, monthly revenue and lifetime value kept as the contact's membership summary, usable in segments (for example "Gold members past due"), and a Members card on the CRM home.

Phase 5 · Content toolsDone

4/4

The ways publishers and course creators actually release content: on a schedule, a few free articles at a time, as downloads, or one item at a time.

• ✓
  Drip content — Done

  Release content N days after someone joins, on a fixed date, or in a sequence, with an "unlocks in 3 days" notice and an email when it opens.

• ✓
  Metered paywall and registration wall — Done

  Let visitors read N items per period before asking them to register (free) or subscribe, counted per visitor and per account.

• ✓
  Protected downloads — Done

  Files in a protected folder served only through an access check (no guessable URLs), with download limits and logs, and a Downloads element.

• ✓
  Pay per item — Done

  Sell access to one post, page or file without a plan.

Phase 6 · Keeping membersDone

5/5

The tools that keep revenue: recover failed payments, offer a pause instead of a cancellation, ask why people leave, and win them back.

• ✓
  Failed payment recovery — Done

  Retries on a schedule, a grace period with access kept, card-update links in emails, and card-expiring reminders. On by default.

• ✓
  Pause instead of cancel — Done

  Members pause for one to three months; billing and access resume by themselves.

• ✓
  Cancellation flow — Done

  A short survey on why, then a save offer (discount, pause or cheaper plan) before the cancellation is confirmed; answers are reported.

• ✓
  Reminders and win-back — Done

  Renewal and trial-ending reminders, and a win-back coupon after expiry.

• ✓
  Gift memberships — Done

  Buy a plan for someone else; they redeem it with a code or link.

Phase 7 · Groups and communityDone

3/3

Memberships for teams and organisations, and the people-facing pieces of a community site.

• ✓
  Group and team memberships — Done

  One buyer pays for N seats and invites people by email, link or domain; seats can be added, removed and reassigned, and the group owner gets a team page.

• ✓
  Member directory and profiles — Done

  A searchable, filterable directory element and public profile pages, each field with its own privacy setting.

• ✓
  Membership cards — Done

  A printable or wallet-style digital card with a QR code for check-in at events or venues.

Phase 8 · Store integrationDone

2/2

For sites that already sell through WooCommerce: a product can grant a plan, members get member prices, and the store's own subscriptions can drive memberships instead of Membership's checkout.

• ✓
  Products that grant plans — Done

  Buying a product grants a plan; a refund or cancelled subscription ends it.

• ✓
  Member prices and restricted products — Done

  Member discounts and free shipping per plan, and products hidden from or unbuyable by non-members.

Phase 9 · ReportsDone

2/2

The numbers a membership business runs on, inside WordPress.

• ✓
  Revenue and member reports — Done

  Monthly recurring revenue, new, upgraded, downgraded and lost members, churn, lifetime value, trial conversion and failed-payment recovery, by plan and period.

• ✓
  Cohorts and content — Done

  Retention by joining month and by source, and which protected content members actually read (with Visitor Insights when it is on).

Phase 10 · Security and operationsDone

7/7

Stop account sharing, make login easier without making it weaker, and make the extension easy to move to and to run.

• ✓
  Account sharing limits — Done

  A limit on simultaneous sessions or devices per plan, with members able to sign out other devices.

• ✓
  One-click login links — Done

  Login links in emails that are signed, single-use and expire, never a shared code.

• ✓
  Passkeys — Done

  Sign in with a passkey (fingerprint, face or device PIN), alongside the Security extension's two-factor login.

• ✓
  Scheduler status — Done

  A health card showing whether scheduled jobs (reminders, expiries, drip, reconcile) run on time, with the exact cron line to add on shared hosting.

• ✓
  Importers — Done

  Import members, plans and active subscriptions from a CSV file or from other membership plugins, keeping payment-service subscription IDs so renewals continue.

• ✓
  Login and access log — Done

  Logins, failed logins, denied access and plan changes per member, for support and for spotting shared accounts.

• ✓
  Command line — Done

  WP-CLI commands to list, grant, expire and reconcile memberships.

Phase 11 · CoursesDone

4/4

A course module on the same access engine, so a course is just protected content with order and progress, not a second membership system. Built from scratch: it replaces the old Learning extension, which is no longer offered (its lessons had no progress tracking, enrolment or working access control).

• ✓
  Courses and lessons — Done

  Courses with modules and lessons in order, enrolment by plan or single purchase, and drip per lesson.

• ✓
  Progress and completion — Done

  Mark complete, resume where you left off, progress bars and a course outline element.

• ✓
  Quizzes — Done

  Quizzes that can gate the next lesson, with the common question types and a pass mark.

• ✓
  Certificates — Done

  A certificate designed in the builder (or a built-in design), issued and emailed on completion, printable or saved as PDF, with a verification link.

Order of work

1. Plans, membership records and the access engine. The tables, the status rules and the one resolver every gate uses, including element and menu visibility and leak-proof gating.
2. Accounts and the member area. Registration through Forms, login, the account page, emails and the REST API.
3. Payments. The gateway layer, card payments and wallets, PayPal, checkout, coupons, invoices and tax.
4. The CRM connection, built on the CRM's extension API (contact links, tag and segment checks, managed tags and fields, contact panels), which the CRM already provides. See Membership and the CRM.
5. Content tools: drip, the metered paywall, protected downloads and pay per item.
6. Retention: failed-payment recovery, pause, the cancellation flow, reminders and gifts.
7. Groups and community: team plans, the directory and membership cards.
8. Store integration for WooCommerce sites.
9. Reports.
10. Security and operations: session limits, login links, passkeys, the scheduler status card, importers and the command line.
11. Courses, on the same access engine.

How this page stays current

Status is not ticked by hand. src/data/membership-roadmap.json lists every task with a detect block naming the files (and, where needed, code symbols) that make it real, and scripts/gen-roadmap.mjs checks them against the extension's source tree:

Result	Status
Every file and symbol found	Done
Some found, some missing	In progress
None found	Planned

npm run roadmap:membership            # scan and rewrite the JSON
npm run roadmap:membership -- --dry   # report only, write nothing
npm run roadmap:membership -- --check # exit 1 if stale

The detect paths double as the extension's agreed file layout, decided before the code is written: core classes in includes/, each switchable module in modules/<module>/ (not loaded unless the module is on), and page-builder elements in shortcodes/<name>/.