Skip to content
wiki.fftac.org

Integrating Participants Database Into Anti Christ - Source Excerpt 05 - Testing checklist and deployment steps

Back to Integrating Participants Database Into Anti Christ

Summary

This source excerpt begins near Testing checklist and deployment steps and preserves the surrounding evidence from Wiki.FFTAC.org/raw/system-archives/anti-christ.org/file-intake/2026-05-10-improvement-and-content/Improvement/Integrating Participants Database into anti-christ.org.md.

**Source path:** Wiki.FFTAC.org/raw/system-archives/anti-christ.org/file-intake/2026-05-10-improvement-and-content/Improvement/Integrating Participants Database into anti-christ.org.md

**Keep the PDb external API disabled unless you actually need it.** If enabled, prefer no public GET access for personally identifying data, use WordPress Application Passwords, and restrict API callers to tightly controlled admin/editor service accounts. citeturn29view4turn5view11

**Disable or carefully scope caching on dynamic member pages.** Exclude registration, login, password reset, profile-edit, intake, and request-link pages from full-page cache. The PDb docs explicitly warn that caching can break dynamic submissions and background imports. citeturn22view1turn22view2

**Lock down uploads.** Use the default upload path unless you have a non-standard install, keep file extensions limited at the field level, and do not “solve” upload issues with `777` permissions. The field-level “allowed” attribute is helpful for UX but is **not** described as a complete security control, so server-level MIME/extension and executable-file protections still matter. citeturn22view0turn22view3turn32view2

**Turn debugging off in production.** The PDb settings help notes say the debugging log should be left off unless actively debugging, for performance and security reasons. citeturn22view2

### Testing checklist and deployment steps

#### Testing checklist

- **Environment**
  - Staging clone available
  - Backups verified
  - Cache exclusions in place for account/profile/intake pages

- **Account lifecycle**
  - Registration creates WP user
  - Registration creates or links exactly one PDb record
  - Login redirects correctly to protected content
  - Password reset email arrives and reset succeeds
  - Deactivated/unapproved users cannot access protected content

- **Profile lifecycle**
  - Front-end profile page loads for logged-in user
  - Mapped fields sync WP → PDb
  - Allowed fields sync PDb → WP
  - Read-only/admin-only fields cannot be edited by ordinary members
  - Multiple browser/device sessions do not produce duplicate PDb records

- **Privacy/compliance**
  - Consent fields save with timestamp/version
  - Export request includes PDb data
  - Erasure/deactivation workflow behaves according to retention policy
  - Non-member briefing subscribers are not accidentally force-converted into member accounts

- **Security**
  - No PDb password fields used for member auth
  - API disabled or restricted
  - Upload path writable and not over-permissioned
  - Debug log off in production
  - Public pages do not leak admin/private field groups

- **Migration**
  - Dry-run produces expected match/create/link counts
  - Ambiguous email matches go to manual review
  - Rollback restore tested from backup

These checks are grounded in the plugin’s documented behavior around field visibility, access control, validation, caching, uploads, API authorization, and account-linking patterns. citeturn32view1turn24view0turn22view0turn22view1turn22view2turn29view4turn10view0

#### Deployment sequence

1. Install PDb on staging.
2. Define field groups and fields.
3. Activate the official WP User Profile add-on **or** deploy the custom bridge plugin.
4. Run migration in dry-run mode.
5. Resolve ambiguous matches.
6. Enable frontend profile page and member dashboard links.
7. Run full staging acceptance tests.
8. Take production backup/restore point.
9. Deploy plugin(s), field config, and bridge code.
10. Run migration in production.
11. Monitor logs and member account creation/edit flows closely for the first release window.

## Open questions and limitations

This report could verify the **public** membership behavior of anti-christ.org, but not the hidden implementation details of the current theme, plugins, caching layer, WAF, or hosting panel. That matters because the current member portal is already theme-managed, and the exact “best” integration point depends on whether those forms are custom theme templates, a membership plugin, or a bespoke WP-user workflow. citeturn15view0

Two additional items remain implementation-time questions rather than research-verified facts:

- whether premium Participants Database add-ons are acceptable for this project
- whether the installed Participants Database version already includes any privacy exporter/eraser registration in the target environment, or whether you should assume custom WP privacy hooks are required

Given the verified public account portal and the official plugin documentation, however, the architectural recommendation remains high-confidence: **keep WordPress users for identity and session management, and integrate Participants Database as the extended participant/profile/intake layer linked by `wp_user_id`.** citeturn15view0turn10view0turn5view0
Website health report