IBSE Website Plan Using Participants Database for Membership

Full report

On this page

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.

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.

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.

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.
• 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.

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.

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.

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.

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.

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.

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.

Membership workflow fit

The shortest path to value is an application-first workflow with explicit approval, followed by a member portal backed by WordPress users if and when IBSE needs authenticated member-only areas. That keeps the first release tractable while leaving a clean upgrade path.

The following lifecycle is the recommended baseline:

flowchart TD
    A[Visitor opens Join page] --> B[Short application via pdb_signup]
    B --> C[Record created in Participants Database]
    C --> D[Automated checks: required fields, anti-spam, duplicate scan]
    D --> E[Membership review queue]
    E -->|Approved| F[Status = applicant approved]
    E -->|Needs changes| G[Send correction request]
    F --> H{Portal mode}
    H -->|Lightweight MVP| I[Send private link to complete profile]
    H -->|Full member portal| J[Create WordPress user and send activation email]
    I --> K[Complete profile via pdb_record]
    J --> L[Frontend member profile page]
    K --> M[Payment or manual activation]
    L --> M
    M --> N[Member status = active]
    N --> O[Renewal reminders]
    O --> P[Renewal payment / staff renewal]
    P --> N

This flow aligns with the plugin’s documented signup, editable record, approval, email, and WordPress-user-linking capabilities, while keeping payment handling outside the unstable PayPal-only path for new builds.

Recommended WordPress architecture and UX

The recommended architecture is a single-site WordPress build with a public content layer for pages, posts, resources, and chapters, and a membership application layer built around Participants Database. Keep “people” in Participants Database; keep “content” such as Resources, Chapters, Statements, News, and landing pages in normal WordPress content types. That matches both the existing site direction and the plugin’s own “people records in separate plugin tables” model.

A multisite network is only justified if IBSE later wants semi-autonomous local chapter websites with their own editors, settings, and independent content operations. Even then, it should not be the default for a unified membership database because WordPress multisite uses separate content tables per site and Participants Database on multisite gives each site its own field configuration and its own database. For central membership coordination, a single site is simpler and safer.

Logical architecture

flowchart LR
    V[Visitors and applicants] --> W[Public WordPress pages]
    W --> X[Join / Renew / Profile pages]
    X --> Y[Participants Database forms and templates]
    Y --> Z[PDb member record tables]

    A[Editors and membership staff] --> B[WP Admin]
    B --> C[PDb admin list, fields, approvals, exports]
    C --> Z

    D[WordPress users and roles] <--> E[WP User Profile add-on]
    E <--> Z

    F[Custom IBSE Membership plugin] <--> Z
    F <--> D
    F --> G[Payment gateway webhooks]
    F --> H[Transactional email / SMTP]
    F --> I[ESP / marketing sync]
    F --> J[Custom reports and privacy tools]

    K[Resources CPT] --> W
    L[Chapters CPT] --> W

This design uses the plugin’s strengths without forcing it to become a CMS, identity system, payment processor, and privacy framework all at once. It also leaves room for later integrations through its REST API and WordPress custom routes.

Recommended theme and content model

IBSE’s public pages should stay visually lightweight and editorially simple. The reviewed site already behaves like a brand-forward homepage with section-based messaging, posts for updates, and archive-style content types for Chapters and Resources. The best fit is therefore a lightweight, standards-based WordPress theme with a child theme or site-specific customizations, not a complex membership mega-theme. That matters because Participants Database templates are starting points rather than finished designs, and the plugin’s own docs say its built-in templates usually need custom CSS to match a site’s layout and mobile behavior.

Recommended content model:

Recommended field groups and custom fields

Participants Database stores user-defined fields and groups them for different display modes. IBSE should lean heavily on this instead of changing core plugin schema. Use custom tables only for transactional or relational data that should not live as one long member record.

Two practical additions are especially useful because the plugin natively supports them: hidden fields for source tracking, locale, and referrals, and explicit grouped visibility controls so public, private, and admin data do not leak into the wrong templates.

REST and integration pattern

Participants Database already provides a REST API for reading, adding, updating, and deleting records, and the plugin docs specify route patterns such as:

• /wp-json/participants-database/v1/record/{id}
• /wp-json/participants-database/v1/list?...
• /wp-json/participants-database/v1/record/add
• /wp-json/participants-database/v1/record/update/{id}

For server-to-server access, the plugin expects a WordPress Application Password, and the WordPress docs say application passwords are revocable per-application credentials meant for API access rather than interactive login. Custom endpoints should be registered with register_rest_route() on rest_api_init.

Recommended custom endpoints in an ibse-membership/v1 namespace:

For browser-based admin/member operations, use normal WordPress auth plus nonces; WordPress’s security guidance is explicit that custom actions should use nonce protection, capability checks, input sanitization, validation, and escaping on output.

Payments, email, and SSO recommendation

Payments. Because the reviewed Member Payments sources are PayPal-specific and the maintainer warns that PayPal Buy Now buttons are being phased out, IBSE should use a custom gateway integration for any new recurring or card-based dues flow. Participants Database should store billing summary fields; detailed transactions should live in a dedicated custom table. If IBSE were already committed to PayPal and already had access to the add-on, Member Payments could still serve as a short-term bridge, but it should not be the strategic default for a new build.

Email. Use Participants Database’s core email for basic transactional messages, but route delivery through SMTP because the plugin docs recommend it for reliability and testing. Use Email Expansion Kit for approval-based or low-volume custom messaging. For newsletters and broader campaigns, use an external ESP. If Mailchimp is selected, the MailChimp Integration add-on supports API-key configuration, list mapping, opt-in fields, CSV synchronization, two-way webhook sync, merge-field mapping, and double opt-in.

SSO. No SSO requirement is visible on the public site today, so SSO should be treated as deferred unless IBSE already operates protected member systems. If SSO becomes necessary later, IBSE should standardize on WordPress-user-backed membership, not Participant Login, because Participant Login is only for secure record access to a PDb record and explicitly is not a WordPress login.

Key pages, components, and wireframe descriptions

Sample shortcode patterns that fit this architecture are shown below. These are examples, not drop-in production templates. The choices reflect documented PDb shortcode behavior, field/group targeting, and the WP User Profile add-on’s frontend profile capability.

Join page
[pdb_signup groups="identity,membership,consent" action="application-next-steps"]

Profile completion page
[pdb_record groups="identity,professional,chapter,privacy"]

Frontend member profile page
[pdb_user_profile]

Member directory
[pdb_search]
[pdb_list filter="approved=yes,directory_opt_in=yes" template="bootstrap"]

Lost link page
[pdb_request_link]

Implementation roadmap and migration

The right delivery strategy is phased, because IBSE’s public site and membership operations are clearly not finished yet, and because Participants Database is flexible enough that a rushed field model will create long-term friction. The plugin’s own quick-start guidance emphasizes planning how the plugin should work, what information must be collected, and the user experience before building.

Phases and effort

A realistic total for a solid first production release is therefore about 230–410 hours. The lower end assumes no authenticated member portal, no live payment gateway in phase one, and relatively clean source data. The higher end assumes WordPress-user-backed membership, custom payment integration, chapter-lead dashboards, and messy legacy data. That range is consistent with the complexity evident in the plugin’s custom fields, templates, add-ons, approvals, APIs, and privacy work needed around separate plugin tables.

Testing plan

Testing should be explicit and gated, not ad hoc. The Member Payments docs, for example, strongly emphasize complete testing before accepting payments; that same caution should apply to any IBSE build even if it uses a different gateway.

Migration plan

Because the current membership data format is unspecified, the migration plan should support CSV, XML, and direct database export pathways. The core principle is the same in every case: do not import raw source data directly into production. Normalize into a staging model first. Participants Database supports CSV import/export, background processing for large imports, update-on-match behavior, and API-based record creation/update for more controlled migrations.

Recommended migration sequence:

Three migration-specific cautions come directly from the reviewed plugin docs and are important for IBSE. First, CSV headers must match field names and be UTF-8. Second, blank values do not overwrite existing values unless explicitly allowed. Third, background imports can fail if object/database caching interferes, so import jobs need to be run on staging under production-like cache settings before launch.

Rollback strategy

Rollback should be prepared at four levels:

Because Participants Database stores data in its own tables separate from core WordPress data, a rollback plan that restores only posts or users is incomplete. Backup scope must include plugin tables and any custom tables added for payments or audit events.

Security, privacy, and compliance

IBSE’s current public site does not yet present enough evidence of mature privacy/compliance pages in the reviewed navigation, and its only visible post still has default comments enabled. That is normal for a new site, but once the site begins collecting membership data, the security and compliance posture has to rise quickly.

The plugin itself provides several useful controls: explicit field groups, record editing via private links, CAPTCHA/reCAPTCHA options, export/import, backend access control, a configurable external API, private-ID link options, and cache/session settings intended to keep dynamic form behavior working correctly. WordPress core adds role/capability APIs, REST auth patterns, privacy exporters/erasers, nonces, validation, sanitization, and escaping guidance. The missing piece is the IBSE-specific glue.

Security and privacy checklist

One subtle but important point from the reviewed settings docs: Participants Database can use the private ID in frontend single-record links to make records harder to enumerate, but the same private ID also opens editable record pages, so careless configuration can blur the line between “view” and “edit” access. For IBSE, public directory and self-edit flows should therefore be separated by design, not merely by clever URL settings.

Risks, costs, and open questions

Key risks and mitigations

Cost estimates

These are planning estimates, not quotes. “Low / medium / high” is the most defensible format given the current public information.

Open questions and limitations

A few items remain genuinely unspecified from public sources and should be confirmed before implementation begins:

The strongest overall recommendation is therefore straightforward: launch IBSE membership on a single WordPress site, use Participants Database as the structured membership database, adopt WordPress-user-backed membership if protected member experiences are expected, defer or custom-build modern payments instead of relying on the sunset-risk PayPal path, and add a small site-specific plugin to handle the approval/billing/privacy/reporting glue that Participants Database does not provide out of the box. That approach is the best fit with IBSE’s current site state, the plugin’s documented capabilities, and the operational realities visible in the reviewed sources.