Integrating Participants Database Into Anti Christ - Source Excerpt 02 - Recommended target architecture

Back to Integrating Participants Database Into Anti Christ

Summary

This source excerpt begins near Recommended target architecture and preserves the surrounding evidence from Anti-Christ.org/agent-file-handoff/Archive/2026-05-10-improvement-and-content/Improvement/Integrating Participants Database into anti-christ.org.md.

**Source path:** Anti-Christ.org/agent-file-handoff/Archive/2026-05-10-improvement-and-content/Improvement/Integrating Participants Database into anti-christ.org.md

| Option | Identity and auth model | Strengths | Weaknesses | Complexity | Estimated effort |
|---|---|---|---|---|---|
| **Participants only** | No WP account required; user edits via private link | Fastest to stand up for simple public intake, directories, or surveys | Poor fit for protected-member workflows; no real WP SSO; weaker UX for ongoing members | Low | 1–2 days |
| **Participants with Participant Login add-on** | Username/password to a PDb record, but **not** a WP login | Familiar login form for record editing; brute-force protection documented | Still not WP auth; incompatible with PDb WordPress User Profile; not suitable as the main anti-christ member portal | Low–medium | 2–4 days |
| **Hybrid custom sync** | WP user is authoritative; custom code syncs mapped fields to/from PDb | Best control; no premium add-on dependency; can fit current theme exactly | More engineering and testing; you own long-term maintenance | Medium–high | 5–10 days |
| **Hybrid with official PDb WordPress User Profile add-on** | WP user is authoritative; official add-on links record and user | Fastest full integration path; official field mapping; frontend profile page; can create WP users from PDb flows | Premium add-on dependency; still needs project-specific testing and privacy/export glue | Medium | 3–6 days |

For **anti-christ.org**, the recommended choice is:

### Recommended target architecture

Use a **hybrid WP-authoritative model** with **Participants Database as an extended profile/intake layer**, not the primary identity provider. If premium add-ons are acceptable, use the **official Participants Database WordPress User Profile add-on** for the profile-linking and frontend profile UI. If premium add-ons are not acceptable, implement the same architecture with a lightweight custom bridge plugin. citeturn10view0turn15view0

That recommendation is reinforced by the site’s current public behavior. The Membership page already promises front-end join, sign-in, reset-link, protected redirects, and a dashboard path. Replacing that with private-link-based record editing would be a regression. Participants Database is a strong fit for **extended participant metadata**, intake pipelines, exportable non-member records, staff/admin operations, and user-editable extended profiles; it is a weaker fit as the site’s primary auth layer. citeturn15view0turn5view1

## Data model, identity, and access design

### Recommended entity model

' ' ' mermaid
erDiagram
    WP_USERS ||--o| PDB_RECORD : linked_by_wp_user_id
    WP_USERS {
        bigint ID PK
        varchar user_login
        varchar user_email
        varchar display_name
        datetime user_registered
    }
    PDB_RECORD {
        bigint id PK
        bigint wp_user_id
        varchar wp_user_login
        varchar email
        varchar first_name
        varchar last_name
        varchar public_alias
        varchar intake_lane
        varchar briefing_opt_in
        varchar consent_version
        datetime consent_timestamp
        varchar consent_ip
        datetime date_recorded
        datetime date_updated
        varchar private_id
    }
' ' ' 

Participants Database fields are user-defined and grouped, with group **view modes** controlling exposure: **public**, **private**, and **admin**. This maps well to anti-christ.org’s needs because member-visible profile fields, staff-only administrative notes, and selectively public profile/intake attributes can all live in the same record model while remaining separately controlled. citeturn32view1turn32view7

### Canonical identifiers

For this site, the authoritative identifier should be:

- **Primary identity key**: `wp_users.ID`
- **Primary link key inside Participants Database**: custom hidden/read-only field `wp_user_id`
- **Secondary readable links**: `wp_user_login`, `email`
- **Plugin-native record keys**: `id` and `private_id` remain plugin/internal keys, not business identifiers. The developer docs explicitly say you cannot repurpose the internal PDb `id` for your own identifier scheme and should instead create a separate field for a custom identifier. citeturn16view0turn10view0

That leads to the following mapping pattern:

| WordPress user field | Participants Database field | Direction | Recommended rule |
|---|---|---|---|
| `ID` | `wp_user_id` | WP → PDb | **Canonical one-to-one link** |
| `user_login` | `wp_user_login` | WP → PDb | Read-only, operationally useful |
| `user_email` | `email` | Bidirectional with WP canonical | Sync to WP only after validation/conflict checks |
| `first_name` | `first_name` | Bidirectional | WP canonical for account forms; PDb allowed on profile page |
| `last_name` | `last_name` | Bidirectional | Same as above |
| `display_name` | `public_alias` or derived field | Site-specific | Keep separate if public alias differs from account name |
| `user_registered` | `registered_at` | WP → PDb | Optional audit field |
| role/capabilities | `program_role`, `intake_lane`, `member_status` | Mostly WP → PDb / admin-managed | Do not use PDb to authorize protected WP content |

For anti-christ.org specifically, I would add these PDb-only fields early in the design:

- `public_alias`
- `primary_interest`
- `intake_lane`
- `cohort_interest`
- `briefing_opt_in`
- `consent_privacy`
- `consent_terms`
- `consent_version`
- `consent_timestamp`
- `consent_ip`
- `member_status`
- `staff_notes`
- `review_state`

These fit the visible site language around cohorts, advisory lanes, program intake, signals/briefing preferences, and member workflow. The site’s public structure strongly suggests that intake, cohorting, and briefing interest are first-class concepts worth modeling directly. citeturn14view0turn15view0

### Synchronization strategy

The safest synchronization policy is:

- **WP account is authoritative for identity/authentication fields**
- **PDb record is authoritative for extended participant/program fields**
- **Mapped overlap fields** (`email`, `first_name`, `last_name`) can sync bidirectionally, but with WordPress as the conflict arbiter for account integrity
- **Never link by email alone after initial migration**
- **Always persist a `wp_user_id` link once the user-account relationship exists**

That design avoids the common failure mode where multiple records share an email or where a user changes their email later. Official PDb materials show several mechanisms based on matching a single field, using the current user login, or custom record matching. Those capabilities are useful, but for durable member-linking on a protected portal you want an **immutable numeric account linkage** once the association is made. citeturn11view4turn16view0turn23view3

### Role and capability mapping

For WordPress itself, use the least-privilege model described in the WordPress roles/capabilities docs: keep normal members on a low-privilege role and create custom roles only where needed. Use `current_user_can()` checks in custom code and define explicit custom capabilities for site-specific staff paths. citeturn25view4turn25view5

For Participants Database backend access, the official access-control page shows that plugin functions are already separated into **editor-level** and **admin-level** operations. Editors can access the plugin menu, list records, edit records, and add records; admins can manage fields/settings, upload CSVs, export CSVs, delete records, and access admin field groups. The plugin exposes the `pdb-access_capability` filter for capability remapping. Ordinary members should not receive any backend PDb access at all; give them only front-end profile/self-management functionality. citeturn24view0turn16view0turn7view0

A practical anti-christ.org mapping would look like this:

- **Subscriber / fftac_member**: protected content, own account, no backend PDb access
- **fftac_cohort_lead**: no general WP editorial powers; only custom member-management screens if needed
- **fftac_participant_manager**: can view/edit participant records, but not plugin settings/import/export
- **Administrator**: full plugin and site control

## User journeys and implementation blueprint

### Recommended user flow

' ' ' mermaid
flowchart TD
    A[Visitor opens Membership Portal] --> B{Has WordPress account?}
    B -- No --> C[Theme registration form]
    C --> D[Create WP user]
    D --> E[Bridge creates or links PDb record]
    E --> F[Redirect to member dashboard/profile]
    B -- Yes --> G[Theme login form]
    G --> F
    F --> H[Frontend profile page]
    H --> I[Update mapped WP fields and PDb fields]
    I --> J[Sync changes]
    J --> K[Protected essays, cohort paths, program routing]
' ' ' 

This matches the site’s publicly visible current posture: front-end join, login, password reset, redirect to the intended protected area, and ongoing member workflow from the front end. citeturn15view0

### Registration, login, reset, and profile-edit flows

#### Registration