Integrating Participants Database Into Anti Christ - Source Excerpt 01 - Integrating Participants Database into anti-christ.org

Back to Integrating Participants Database Into Anti Christ

Summary

This source excerpt begins near Integrating Participants Database into anti-christ.org 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

# Integrating Participants Database into anti-christ.org

## Executive summary

The best-fit architecture for **anti-christ.org** is not to replace its existing account system with Participants Database, but to **keep WordPress users as the authoritative identity and authentication layer** and use **Participants Database as the extended participant/profile/intake data layer**. That recommendation follows directly from two facts visible in the public materials: the site already has a front-end membership portal with **Create an Account**, **Member Sign In**, and **Reset Access** flows; those accounts are described as **“standard site members”** and the page says the workflows are currently **managed by the theme**. Meanwhile, the base Participants Database plugin stores its data **separately from WordPress users** and its native self-management model is based on **private links** rather than WordPress login sessions. citeturn15view0turn5view0turn10view3turn5view1

For a “complete integration enabling user self-management,” the strongest design is a **hybrid**: preserve the site’s existing front-end registration, login, password-reset, and protected-content behavior with WordPress accounts; create or link **one Participants Database record per member** for richer profile/intake/program data; and expose profile editing through either the **official Participants Database WordPress User Profile add-on** or a small custom bridge plugin. The official add-on is the fastest path if premium add-ons are acceptable because it can connect a Participants Database record to a WordPress user, synchronize key fields, create WP users from signup or approval flows, and provide a frontend profile page via `[pdb_user_profile]`. citeturn10view0turn15view0

The report’s practical conclusion is therefore:

- **Authentication and authorization**: keep **WP users** as the source of truth.
- **Extended data**: store program/profile/intake fields in **Participants Database**.
- **Record linking**: use an authoritative **`wp_user_id`** link, not email alone, for durable synchronization.
- **Self-management UX**: keep the existing front-end account portal; add a linked profile editor and member dashboard integration.
- **Security**: do **not** use the Participant Login add-on as the site’s primary member authentication, because it is **not** a WordPress login and is explicitly **incompatible** with the official WP-user-linking add-on. citeturn10view1turn10view2turn10view0

## Current site context and assumptions

Publicly visible pages on **anti-christ.org** show that the site already has a **Membership Portal** with front-end forms for account creation, sign-in, and reset-link requests. The same page says accounts are created as **“standard site members,”** that visitors who hit protected pages are redirected back after login, and that the design/workflows are handled by the current theme. The site also separately offers a “Signals Briefing” signup where **no dashboard account is required**, which suggests there are at least **two distinct user populations**: site members with accounts and non-member briefing/intake subscribers. citeturn15view0turn14view0

Because there is no admin access in this research, the report assumes a **single-site WordPress installation**, no confirmed multisite requirement, no confirmed commercial-plugin prohibition, and no confirmed dependency on a specific membership plugin beyond the theme-driven front-end membership UX visible on the public pages. Where implementation details depend on the installed theme or hidden plugins, they are called out as assumptions rather than treated as verified facts. citeturn15view0turn14view0

## What Participants Database can and cannot do

Participants Database is a **highly configurable record system** built for storing people-oriented or directory-style data inside WordPress. Official plugin materials show that it supports configurable fields and groups, frontend signup via `[pdb_signup]`, frontend record editing via `[pdb_record]`, list and single-record views via `[pdb_list]` and `[pdb_single]`, standalone search, email notifications, CSV import/export, template customization, and a developer/API layer for deeper extension. Its field system includes text, textarea, rich text, date, checkbox, radio, dropdown, multiselect, link, image/file upload, hidden, numeric/decimal/currency, password, CAPTCHA, calculation, and shortcode fields. citeturn4view0turn5view2turn5view1turn5view4turn16view0

The plugin’s core data model is **separate from WordPress users**. Official documentation states that Participants Database uses the same MySQL database as WordPress but adds **its own tables** for plugin data, and migration documentation identifies configuration tables named `wp_participants_database_fields` and `wp_participants_database_groups`, with plugin settings in the `participants-database_options` option. A separate tutorial identifies the main records table as `wp_participants_database`. That separation is useful for flexible records and exports, but it also means the plugin is **not automatically your membership/authentication system**. citeturn5view0turn18view0turn20view0

The plugin’s default end-user self-management pattern is **not WordPress SSO**. The base plugin lets users edit their own record through a **private link** sent by email, and the developer documentation describes that link as a coded URL containing a record-specific access code. The Participant Login add-on adds username/password access to a Participants Database record, but its own documentation is explicit that this login is **not a WordPress user login** and that it is **not compatible** with the official WordPress User Profile add-on, which is the add-on intended to connect Participants Database records to WordPress accounts. For a site like anti-christ.org, which already has protected member content and theme-managed account flows, this distinction is decisive. citeturn5view1turn23view2turn10view1turn10view2turn10view3

There are several operational limitations to plan around. The plugin page currently lists **WordPress 5.0+**, **PHP 7.4+**, and testing through **WordPress 6.8.5**, while changelog entries note compatibility work for PHP 8.1 and 8.2. The plugin writes uploads under `wp-content/uploads/participants-database/` by default, requires that path to be writable, and warns against insecure permission fixes such as `777`. Its documentation also notes that **page/object/database caching** can interfere with dynamic form behavior and with background CSV imports, and that background imports can silently fail if the site cannot post to `admin-ajax.php`. citeturn21view1turn4view0turn22view0turn22view2turn22view3turn22view4

A final important limitation is that advanced API and write operations shift responsibility to the integrator. The REST API documentation states that POST routes can add, update, or delete records, but also warns that **validation is not performed** on record-add and record-update API writes, so the client or custom integration code must validate inputs before writing. Similarly, the public `Participants_Db::write_participant()` method can create records directly, but official API docs note that when records are created this way, values are **not validated** and duplicate prevention is also up to your code. citeturn30view5turn16view0

## Integration options and recommendation

The most realistic options for anti-christ.org are shown below. The comparison is based on the site’s existing front-end account portal and on official Participants Database documentation for private-link editing, WP-user integration, and the Participant Login add-on. citeturn15view0turn10view0turn10view1turn10view3