IBSE Website Plan Using Participants Database For Membership

IBSE’s public site is currently a very early-stage WordPress launch site: the homepage presents the organization’s mission, pledge, membership pitch, chapters, resources, and contact details; the site also exposes emp...

Metadata

Field	Value
Source site	aiwikis.org
Source URL	https://aiwikis.org/
Canonical AIWikis URL	https://aiwikis.org/aiwikis/files/raw-system-archives-ibse-agent-file-handoff-retired-source-archive-2026-d2cb1417/
Source reference	raw/system-archives/ibse/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-09/IBSE Website Plan Using Participants Database for Membership.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-05-10T03:34:10.9184133Z
Content hash	sha256:d2cb141748a047a834b70968c2e0eb449799dbc1e169c64c8ca03a1eb59fb594
Import status	unchanged
Raw source layer	data/sources/aiwikis/raw-system-archives-ibse-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-09-ibse-we-d2cb141748a0.md
Normalized source layer	data/normalized/aiwikis/raw-system-archives-ibse-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-09-ibse-we-d2cb141748a0.txt

Current File Content

Structure Preview

• IBSE Website Plan Using Participants Database for Membership
• Executive summary
• Current-state audit
• Workflow mapping to Participants Database
• Membership workflow fit
• Recommended WordPress architecture and UX
• Logical architecture
• Recommended theme and content model
• Recommended field groups and custom fields
• REST and integration pattern
• Payments, email, and SSO recommendation
• Key pages, components, and wireframe descriptions
• Implementation roadmap and migration
• Phases and effort
• Testing plan
• Migration plan
• Rollback strategy
• Security, privacy, and compliance
• Security and privacy checklist
• Risks, costs, and open questions
• Key risks and mitigations
• Cost estimates
• Open questions and limitations

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 43189
• Preview characters: 11500

# IBSE Website Plan Using Participants Database for Membership

## Executive summary

IBSE’s public site is currently a very early-stage WordPress launch site: the homepage presents the organization’s mission, pledge, membership pitch, chapters, resources, and contact details; the site also exposes empty archive pages for “Resources” and “Chapters,” and its only visible post is the default “Hello world!” post with comments enabled. In the pages reviewed, there is no visible member login, account dashboard, renewal flow, payment flow, searchable public directory, privacy-policy link, or standalone application workflow. WordPress is explicit, but the exact theme, hosting stack, and any current membership back office are not publicly specified. citeturn3view0turn18view0turn18view1turn5view1

Participants Database is a strong fit for IBSE **as the membership data layer and intake/profile workflow engine**, not as a full turnkey association-management system. Its strengths are exactly where IBSE needs them first: configurable custom fields, grouped forms, frontend signup, editable member records, email notifications, list/search/filter/export, CSV import/export, a developer API, and a REST API. It was explicitly built for organizations managing people-centric records such as members, supporters, volunteers, and similar constituencies. citeturn10view1turn33search0turn10view0

The central architectural recommendation is therefore: **keep IBSE on a single WordPress site, use Participants Database as the canonical membership record, use WordPress users only where authenticated experiences are needed, and add a small custom “IBSE Membership” plugin to bridge approvals, roles, payment events, reporting, privacy requests, and external integrations.** A multisite network is not the right default because WordPress multisite separates content tables per site, and Participants Database likewise gives each site in the network its own fields and database; that is the opposite of what IBSE wants if it needs one cross-chapter membership database. citeturn27view0turn13view2

For identity, IBSE should choose **one of two modes**:

- If the first release only needs application intake and self-service profile editing, Participants Database’s native signup plus private-link editing can work. citeturn10view1turn13view0turn13view3
- If IBSE needs member-only pages, chapter-lead dashboards, forums, or future SSO, it should use **Participants Database WordPress User Profile** so a Participants Database record is linked to a real WordPress account and a frontend profile page. In that model, Participants Database remains the structured member database, while WordPress handles authentication and authorization. citeturn24view0turn10view2

For payments, a greenfield IBSE build should **not** rely on the reviewed “Member Payments” add-on as the primary long-term strategy. Although its product page still describes dues, pay-to-join, reminders, and payment logs, the maintainer’s current support page says it depends on PayPal “Buy Now” buttons, that PayPal is phasing those out, and that the author has stopped selling the add-on to new customers. The safer plan is a custom integration to a modern payment gateway, with payment events written back into Participants Database via custom code and, where useful, the plugin’s REST API. citeturn24view2turn35view0turn20view1

The estimated implementation effort for a solid first release is **roughly 230 to 410 hours**, depending on whether IBSE chooses simple private-link editing or a full WordPress-account member portal, whether payments are deferred or fully integrated, and how clean the legacy member data is. That scope includes discovery, data modeling, UX, build, migration, QA, launch, and rollback readiness. Those effort estimates are implementation estimates, not vendor quotes. Supporting evidence for scope complexity includes the plugin’s separate data tables, add-on ecosystem, custom templating system, access-control model, import/export tooling, and the need for custom privacy/export integrations if IBSE wants GDPR-grade handling in WordPress admin. citeturn33search0turn12view5turn12view3turn23view1turn27view2turn28search0

This report prioritizes four primary source groups, in this order: Participants Database documentation and add-on pages, WordPress developer documentation, and IBSE’s own public pages. All substantive claims below are tied back to those sources. citeturn10view0turn29search10turn3view0

## Current-state audit

The highest-confidence reading of ibse.org is that it is a **new WordPress marketing site with partially configured content architecture and no public-facing membership operations yet**. The homepage navigation points to Mission, Pledge, Membership, Chapters, Resources, and Contact. The homepage copy promises member forums, chapter playbooks, templates, and coordinated action, which implies a future need for member identity, permissions, chapter affiliation, and private/member-only content. Yet the currently visible site behavior is still pre-launch-level: empty archives for Chapters and Resources, a default post, and default comments still enabled. citeturn3view0turn18view0turn18view1turn5view1

| Audit area | What is publicly visible now | Assessment |
|---|---|---|
| Site structure | Homepage sections for mission, pledge, membership, chapters, resources, and contact; footer repeats key navigation. citeturn3view0 | Clear top-level IA, but still brochure-oriented. |
| Content types | Homepage explicitly says resources can be published “using the Resources content type included in this theme”; archive pages for Resources and Chapters exist. citeturn3view0turn18view0turn18view1 | Suggests custom post types already exist or were scaffolded. |
| Current content population | Resources archive shows “Nothing found”; Chapters archive shows “Nothing found”; only visible post is “Hello world!” dated May 9, 2026. citeturn18view0turn18view1turn5view1 | Content architecture exists, but editorial population is largely unfinished. |
| Membership features | Homepage promises membership benefits and has a “Start an application” CTA, but the reviewed pages did not expose a public application form, account area, pricing, renewals, payment page, or login. citeturn3view0turn19view0 | Public membership operations appear not yet implemented. |
| Community features | Homepage promises “member forums,” mentoring, chapter playbooks, and chapter coordination. citeturn3view0 | This future state strongly favors real user identities over private-link-only workflows. |
| Tech stack | Footer states the site is “Built for IBSE.org on WordPress.” The reviewed post page behaves like a default WordPress post template with comments, recent posts, archives, and categories. citeturn3view0turn5view1 | WordPress confirmed; exact theme name, builder, and hosting are unspecified. |
| Governance and policy pages | In the reviewed navigation/footer, no privacy policy, cookie policy, terms, or accessibility links were visible. citeturn3view0turn18view0turn18view1 | Add before collecting member data. |
| Operational readiness | Default post/comment content is still present. citeturn5view1 | Indicates launch hygiene and hardening are incomplete. |

The plugin chosen for this plan is mature enough for production use but needs disciplined maintenance. On WordPress.org, Participants Database is listed at version 2.7.8.1, with 7,000+ active installations, tested up to WordPress 6.8.5 and PHP 7.4+. Its changelog also shows recent fixes for security issues, including XSS and code-injection vulnerabilities in earlier releases, which is a good reminder that IBSE will need routine patching and staging-based update testing. citeturn32view0turn32view3

## Workflow mapping to Participants Database

Participants Database is naturally good at **collecting, storing, validating, editing, listing, and exporting structured member records**. It is less naturally good at **opinionated membership lifecycle management**, especially where you need authenticated member portals, chapter-scoped permissions, recurring card billing, or built-in GDPR export/erase tooling inside WordPress admin. The correct design is therefore to use the plugin for what it does best, then add the missing pieces intentionally. citeturn10view1turn33search0turn12view5turn27view2turn28search0

### Membership workflow fit

| Workflow | Participants Database core fit | Add-on or custom work required | Recommendation |
|---|---|---|---|
| Registration and application intake | Strong. Core `[pdb_signup]` supports configurable signup fields, thank-you flow, receipt email, hidden fields, and CAPTCHA. The full record can then be completed later. citeturn11view0turn10view1 | Add an approval/status model and, if the application is long, split it into multi-page steps using the `action` attribute and `[pdb_record]`. citeturn13view2 | Use core signup for intake. |
| Profile completion and self-service editing | Strong. Core `[pdb_record]` allows frontend editing via a private link; lost-link recovery is supported via `[pdb_request_link]`. citeturn13view0turn13view3 | If IBSE wants standard login/account behavior instead of emailed private links, move to WordPress-backed user accounts. citeturn24view0turn24view1 | Fine for a lightweight MVP; not ideal for a full portal. |
| Member authentication | Weak in core. Core editing depends on private links, not true user login. citeturn10view1turn33search0 | Either use **Participant Login** for PDb-record login only, or use **Participants Database WordPress User Profile** for real WordPress-account login. These two patterns are different, and Participant Login is not compatible with the WP User Profile add-on. citeturn24view1turn24view0 | Prefer WP User Profile if member-only content or SSO is in scope. |
| Approval and activation | Strong enough with configuration. Core docs show an “approved” admin field used to filter public display; Email Expansion Kit can send a welcome email on approval; WP User Profile can create the WP account on approval. citeturn13view1turn24view3turn24view0 | Minor custom workflow plugin for status transitions and audit logs. | Good fit. |
| Renewals | Partial. Core has records and email triggers, but not a full subscription engine. Member Payments can track dues and reminders, but reviewed sources show PayPal-only limitations and sunset risk. citeturn24view2turn35view0 | Custom renewal scheduler and payment integration strongly recommended. | Customizable, but not turnkey. |
| Payments | Weak for greenfield unless PayPal-only is acceptable. Reviewed Member Payments sources are PayPal-centric and depend on Buy Now buttons. citeturn24view2turn35view0 | Custom Stripe or alternative gateway integration is the safer default. Use webhook-driven updates into PDb and optionally the PDb REST API. citeturn20view1turn27view1turn27view3 | Build custom payments. |
| Roles and permissions | Partial. WordPress roles/capabilities exist; PDb adds action-level backend access controls mapped to WP roles. citeturn10view2turn12view3 | Chapter-scoped or finance-scoped row-level permissions are not documented in the reviewed PDb access controls, so custom dashboards or filtered admin tools will be needed. citeturn12view3 | Use WP roles + custom capability checks. |

Why This File Exists

This is a memory-system evidence file from aiwikis.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: IBSE Website Plan Using Participants Database for Membership; Executive summary; Current-state audit; Workflow mapping to Participants Database; Membership workflow fit; Recommended WordPress architecture and UX; Logical architecture; Recommended theme and content model. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-1023 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "IBSE Website Plan Using Participants Database For Membership",
    "source_site":  "aiwikis.org",
    "source_url":  "https://aiwikis.org/",
    "canonical_url":  "https://aiwikis.org/aiwikis/files/raw-system-archives-ibse-agent-file-handoff-retired-source-archive-2026-d2cb1417/",
    "source_reference":  "raw/system-archives/ibse/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-09/IBSE Website Plan Using Participants Database for Membership.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:d2cb141748a047a834b70968c2e0eb449799dbc1e169c64c8ca03a1eb59fb594",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-05-10T03:34:10.9184133Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-1023",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}