# GHL-WP Membership: researched expansion backlog

Research checked **6 November 2026, Asia/Dhaka**. Baseline: plugin **0.5.0**, source and prior Lab evidence. This is a development backlog, not a completed-feature declaration. Implementation and runtime evidence must be recorded separately for each release.

## Assessment

The existing plugin proves an important access lifecycle, but the user's assessment is correct: it is a single-contact Lab prototype, not yet a complete membership product. Its menus are scattered, plans do not yet drive the complete experience, and ordinary operators lack a member directory, rule management, onboarding, member portal and diagnostics. Private downloads and reliable revocation are valuable foundations; they do not substitute for the daily administration experience.

Current official documentation was checked for six products. Vendor pages establish documented features, not independent security/performance proof. Memberium's HighLevel edition must be assessed separately from its older Keap/ActiveCampaign editions. Its current setup guide still explicitly describes beta/staging use. No competitor was purchased, installed or runtime-tested during this re-check. A feature not established here is not necessarily absent.

Our strongest direction is **a simple GHL-led membership product with local access decisions, independent access sources and useful operational explanations**. The differentiator should be the complete experience and verified correctness, rather than a claim that tags, retries or logs are new.

## Current comparison

Legend: **D** = documented in current vendor source; **A** = adapter/add-on or higher edition; **NE** = not established by this re-check. These are broad categories, not interchangeable implementation guarantees.

| Capability | Memberium HighLevel | Connector Wizard | WP Fusion | Syncly | MemberPress | PMPro | Our 0.5.0 |
|---|---|---|---|---|---|---|---|
| Own membership/content gating | D | D | D | D | D | D | Single Lab grant |
| GHL tags/contact integration | D | D | D | D | NE directly | NE directly | One allowlisted contact/tag |
| Multiple member levels | D | D | A | A | D | D | Plan type exists; incomplete |
| Posts and pages | D | D | D | D | D | D | Pages |
| Partial-content conditions | D | D | D | D | D | D | Basic shortcode only |
| Per-member dates/drip | NE for own date engine | NE | Tag-driven | NE for own date engine | D | A | Missing UI/model |
| Conditional navigation | NE | NE | D | A | NE | D | Missing |
| Login/passwordless convenience | D | D | Personalization session | D | Login/account | Login/account | Core WP recovery |
| Private files | D | NE | Integration-dependent | NE | A | A | Private store + guarded route |
| Source-safe grants | NE | NE | Adapter-dependent | A | NE | NE | Single source only |
| Billing/self-service | NE financial semantics | Woo integrations | A | A | D | D | Payments disabled |
| Member portal/profile | Login/fields | Portal tools | A | A | D | D | Missing |
| Logs/health tools | D | Some documented | D | D | Reports | Reports | Queue status only |
| LMS/community/team features | Edition-specific | LearnDash/associations | A | A | A | A | Missing |

Sources for this table and their limits:

- **Memberium HighLevel:** [setup and memberships](https://highlevel.memberium.com/getting-started-with-memberium/) document local/remote tags, level inheritance, modifier tags, redirects and page/post protection. [Shortcodes](https://highlevel.memberium.com/documentation/shortcodes/) cover conditional sections and contact/custom values. [Reports](https://highlevel.memberium.com/reports-module/) cover authentication, webhook/backend events, views and secure downloads. [Login links](https://highlevel.memberium.com/shortcodes/memb_request_magic_link/) are requested by existing members and single-use. Do not import every Keap feature into the HighLevel column.
- **Connector Wizard:** [official product](https://connectorwizard.app/) documents built-in membership/tag access, CRM fields, shortcodes, WooCommerce automation and LearnDash-oriented integration. Its generic role-update marketing should be checked against the specific current operation: [role workflow documentation](https://connectorwizard.app/docs/connector-wizard/wp-to-crm-data-communication/add-remove-wp-user-role-from-workflow/) previously said it was disabled. We have not runtime-confirmed that operation in this re-check. Do not turn an advertised upcoming feature into a current capability.
- **WP Fusion:** [access controls](https://wpfusion.com/documentation/other/access-control/) document any/all/negative tag logic, redirects and access testing. [Documentation index](https://wpfusion.com/documentation/) describes membership, LMS and commerce adapters, field/tag synchronization, menus and logs. [Auto Login](https://wpfusion.com/documentation/tutorials/auto-login-links/) describes a personalization session, not universal authenticated WP login. Prior research established Woo subscription overlap/paid-through behavior; its detailed page returned 403 during this refresh, so that detail is retained as earlier research, not newly verified.
- **Syncly:** [features](https://synclyforgohighlevel.com/features/) document OAuth, user/field/tag synchronization, queues, retries, rules/preview, conditional content/navigation, logs, health and configuration import/export, plus Woo/LearnDash/BuddyBoss/family integrations. [Woo grant rules](https://synclyforgohighlevel.com/documentation/gohighlevel-woocommerce-integration/woocommerce-memberships-grant-plans-automatically-from-a-ghl-tag-pro/) expressly preserve paid/manual memberships when an automation-owned tag grant is removed. This is important counterevidence to claiming source-safe revocation is unique. Edition descriptions should be checked against the chosen installed build.
- **MemberPress:** [feature catalog](https://memberpress.com/features/) presents rules, drip/expiry, downloads, coupons, subscriptions, self-service billing, courses, corporate seats, gifting and invoices, with some delivered as add-ons/products. These establish the broader membership-product benchmark; they do not establish a native direct GHL integration.
- **Paid Memberships Pro:** [features](https://www.paidmembershipspro.com/features/) documents multiple concurrent levels, content restrictions, drip, account/profile tools, pricing/trials, reports, groups and imports. [Level Groups](https://www.paidmembershipspro.com/documentation/membership-levels/level-groups/) clarifies multiple levels. [Admin documentation](https://www.paidmembershipspro.com/documentation/admin/) separates subscriptions/payment agreements from membership/access. [Dashboard](https://www.paidmembershipspro.com/documentation/admin/membership-dashboard/) demonstrates centralized management with members, orders, subscriptions, reports and settings.

## Dedicated WordPress menu

Use **GHL-WP Membership** as the single top-level entry. Reuse WordPress admin controls and list tables instead of loading an application framework on every admin page. Keep advanced settings in tabs within relevant screens.

| Submenu | What belongs here |
|---|---|
| Dashboard | Setup checklist, local member counts, pending/failed jobs, last confirmed sync, essential warnings |
| Members | Search/filter users, plans/dates, source history, grant/revoke controls, access explanation |
| Membership Plans | Names, tag mappings, suspension tags, term policy, member destination |
| Content Rules | Protected pages/posts/types, any/all plan requirements, drip/expiry, deny behavior |
| Private Downloads | Upload/migration, required plans, protected URL, status, storage checks |
| GHL Connection | Exact location, credential status, scope test, tag mapping, webhook setup |
| Sync & Activity | Queue, retry history, audit log, targeted reconciliation and previewed repairs |
| Member Experience | Dashboard/login pages, messages, navigation and onboarding settings |
| Tools & Health | Diagnostics, previewed imports/exports, migrations, backup instructions |
| Settings & Help | General behavior, privacy/retention, documented limits, developer/authorship links |

Do not display nonfunctional buttons or imply a pending integration exists. Initially combine Sync & Activity and Tools & Health if it keeps the navigation smaller. Old admin URLs can redirect to their new screens to preserve bookmarks.

## Prioritized feature list

Each numbered item is a proposed implementation requirement. **P0** is necessary for a usable first product; **P1** expands real membership workflows; **P2** needs separate integration/payment validation; **P3** is an optional product module. The list is comprehensive for our intended GHL-led product, not a promise to replicate every competitor product.

### P0 — complete the membership core

| ID | Feature to implement | Minimum acceptance evidence |
|---|---|---|
| 01 | Dedicated top-level menu/submenus | All screens reachable in one place; subscribers cannot open admin screens |
| 02 | Dashboard/setup checklist | Real configuration and database state, no fake success badges |
| 03 | Multiple membership plans | Two plans grant different content to two synthetic members |
| 04 | Multiple contacts per configured GHL location | No single-contact hardcoding; cross-location request denied |
| 05 | Local plan-tag mapping | Current verified CRM state controls only the mapped grant |
| 06 | Any/all required plans | Truth-table tests for no/one/all required plans |
| 07 | Cancellation/suspension tags | Blocked state reversible without deleting users or resetting passwords |
| 08 | Independent access sources | Revoking a CRM source preserves a still-valid manual source |
| 09 | Fixed start/end and lifetime access | Expiry enforced at request time even with cron disabled |
| 10 | Administrator manual grants/revokes | Capability, nonce, source ID and actor/reason audit |
| 11 | Member search/filter directory | Bounded pagination, correct active/expired filtering |
| 12 | Member access explanation | Shows matching source/date/rule and plain-language denied reason |
| 13 | Page/post protection | Guest, inactive and wrong-plan requests denied via HTML/core REST/feed/search |
| 14 | Per-file plan requirements | Copied URL denied for wrong-plan member, including HEAD/range |
| 15 | Member dashboard shortcode | Only current user's plans, dates and approved resource links |
| 16 | Login/logout/recovery navigation | Safe same-origin redirects; no shared login secret |
| 17 | Friendly no-access message | Generic safe output; no private title/content leak |
| 18 | Audit event history | Immutable event records for changes; bounded retention; no credentials/raw payloads |
| 19 | Queue operations | Retry/backoff/dead-letter visibility, targeted requeue, generation-safe duplicates |
| 20 | Connection/environment health | Exact location, token configured flag, cron/storage/schema checks; no token display |
| 21 | Upgrade/migration safety | Existing 0.5 grants/pages/files retain their intended protection |
| 22 | Local access performance | Zero CRM calls on member pages/downloads; bounded queries and indexed lookups |

### P1 — stronger member and operator experience

| ID | Feature to implement | Minimum acceptance evidence |
|---|---|---|
| 23 | Relative content drip | Days since specified plan activation; explicitly define rejoin/reset behavior |
| 24 | Fixed-date content releases | Site timezone converted consistently; exact boundary tests |
| 25 | Content expiration windows | Denied after window; no stale cache makes content public |
| 26 | Conditional content shortcode | Shared authorization engine, escaped safe fallback |
| 27 | Gutenberg protection block | Server render uses same rule engine; editor preview isolated |
| 28 | Conditional navigation | Hidden links improve experience; destinations remain independently protected |
| 29 | Category/custom-post-type rules | Explicit supported types, conflict resolution and REST coverage |
| 30 | Plan-specific post-login destination | Same-origin allowlist and deterministic priority for multiple plans |
| 31 | Frontend account profile | Allowlisted profile fields, CSRF protection and verified-email change process |
| 32 | Secure one-time login links | Hashed tokens, short expiry, atomic single use, enumeration/rate limits |
| 33 | Welcome/setup notification | Send only after actual provision, retry separately, no duplicate messages |
| 34 | Scheduled reconciliation | Bounded batches reread authoritative state and recover dropped webhooks |
| 35 | Reconciliation preview/repair | Show intended changes before applying; per-source audit receipt |
| 36 | Login/last-seen reporting | Minimal data and retention; opt-in for behavioral tracking |
| 37 | Membership reports | Real active/expired totals and changes by plan; no inferred revenue |
| 38 | CSV member export | Capability/nonce, formula neutralization and explicit field selection |
| 39 | Previewed CSV import | Validation, duplicate policy, chunked writes, resumable progress |
| 40 | Settings export/import | Exclude credentials/member data; schema validation and preview |
| 41 | Delegated membership-manager role | Dedicated capabilities; cannot manage tokens, plugins or administrators |
| 42 | Privacy export/erase hooks | Explain retention; preserve protection consistency when identity is erased |
| 43 | Storage/backup diagnostics | Flag public aliases/cache risks; verify restore procedure |
| 44 | Staging mode | Suppress outbound automation/email unless explicitly enabled for tests |
| 45 | Accessibility/localization | Keyboard and screen-reader checks, translation functions, timezone handling |

### P2 — GHL lifecycle and tested adapters

| ID | Feature to implement | Minimum acceptance evidence |
|---|---|---|
| 46 | OAuth onboarding for distribution | State validation, least scopes, token rotation/refresh races, uninstall handling |
| 47 | Product/price → plan mapping | Verified paid-event contract; never infer payment from a tag alone |
| 48 | Subscription lifecycle | Renew, cancel-at-term, failure/grace/recover/expire with authoritative paid-through dates |
| 49 | Refund/dispute policy | Source-specific action; partial refunds and unrelated purchases preserved |
| 50 | Billing portal links | Provider-authorized member-scoped destinations; no card data stored in WP |
| 51 | Native GHL Grant Membership action | Authenticated site/location/plan/source inputs and accurate pending/applied result |
| 52 | Native Revoke This Grant action | Revoke source only; idempotent repeats; report remaining effective access |
| 53 | Native Access Status action | No unsafe repair side effect; clear reason/valid-until response |
| 54 | Grant Applied/Access Changed events | Emitted after commit; durable outbox, signed delivery, stable event IDs |
| 55 | GHL field mapping | Allowlist fields/directions, validation and loop suppression; no arbitrary role writes |
| 56 | LearnDash adapter | Own only plugin-created enrollments; enrollment/progress/completion verified with LMS |
| 57 | WooCommerce adapter | Orders/subscriptions stay separate from local grants; cancelled overlap retained |
| 58 | BuddyBoss adapter | Source-owned group join/leave, permissions and private-group tests |
| 59 | Elementor conditions | Server-side enforcement and correct cache partitioning |
| 60 | Forms integration | Consent-aware field mapping, authenticated callbacks, spam/rate safeguards |
| 61 | External private object storage | Private bucket, short signed access URLs, expiry and revocation limitations documented |
| 62 | Membership migration adapters | Dry run, identity/grant mapping, backup and rollback per supported competitor |

Native Marketplace blocks require a registered GHL app and its action/event contract. A WordPress REST endpoint alone is not a native canvas action. Payment milestones need a named GHL test product/subscription and payment sandbox; current tag-only Lab proof cannot satisfy these checks.

### P3 — optional expansion after demand and core validation

63. Corporate/family accounts, seats, invitations, ownership transfers and source-aware inherited access.
64. Gifts, invitation grants and promotional access codes with expiry/redemption limits.
65. Member directory and private profile visibility settings.
66. Cohorts and group reporting.
67. Course catalog/progress presentation through a supported LMS.
68. Quizzes, certificates and gamification through adapters.
69. Coupons, upgrade/proration and dunning through the actual billing provider.
70. Agency multisite presets, separate location isolation and fleet health.
71. Audited developer API, CLI and documented extension hooks.
72. Opt-in engagement events and inactivity automations.
73. Member device/session management and compatible 2FA integration.
74. Private video delivery through a supported provider; do not promise that an authorized viewer cannot record video.
75. Scheduled report exports and operator alerts with explicit recipients/retention.
76. White-label member-facing templates and email presentation.
77. Mobile app/API compatibility after the access contract is stable.
78. License/update service whose expiry never turns protected content public.

## Build sequence and release gates

1. **Usable local membership release:** menu, plans, source-aware grants/dates, member list, rule selection, per-plan files, portal and audit/health screens. Keep the current tag Lab route compatible. Run upgrades and direct-access tests before sharing its ZIP.
2. **Reliable multi-member synchronization:** generalize the verified identity boundary to the selected location; jobs per contact/source; reprocess rule changes; reconcile. Test several contacts and concurrent/duplicate/stale events in the named Lab.
3. **Member experience:** drip, blocks, navigation, profile/login conveniences, welcome messages, migration preview and privacy controls. Validate unauthorized REST and cached-response paths for every new protected surface.
4. **GHL sales lifecycle:** OAuth/distribution, one payment provider, native workflow actions/events, self-service billing. This remains incomplete until sandbox financial events and paid-through semantics are actually tested.
5. **Adapters and teams:** enable optional modules individually so a simple site does not load every integration. Each must have its own dependency versions and acceptance evidence.

Do not describe this catalog as fully built because screens, database fields or placeholder hooks exist. Track each item as **planned → implemented → automated tests passed → Lab verified → released**. A packaged local ZIP is not the public website download until its hosted bytes are checked. Benchmark comparisons need matched datasets/hosting; no “fastest” or “most secure” claim is justified by this research.

## Non-negotiable engineering decisions

Keep grants separate from users, CRM contact tags, subscriptions and payments. Store UTC date boundaries; evaluate current access on read. Every member content surface should use one authorization service. Avoid global frontend assets, remote API calls and unbounded queries. Use capabilities, nonces, prepared SQL and escaped output everywhere relevant. Store scoped credentials outside served files; exclude them from exports, logs and release ZIPs. Default webhook/user creation must never promote an existing account or overwrite an unrelated identity. Preserve current deny behavior on upgrade or license failure. Maintain synthetic Lab tests for overlapping grants, denied direct files, stale events, outages, wrong locations and cache isolation.

Earlier detailed research remains preserved in `research/2026-11-01/membership-competitor-deep-dive/`; the 2026-10-26 marketplace research is untouched.