Memory Wiki

I'll begin the independent audit now — starting with listing all plugins and all database tables.

Excellent. I have the full inventory. Now let me describe every non-WordPress-core table to understand the data columns.

Now let me examine the FluentCRM/Marketing Automation tables, PMPro tables, and other plugin-specific tables.

Now let me check the Profe module migration files and the profe_user_meta schema.

Let me also check some sample data and look at what the BWF contact table's `wpid` field references, plus check the PMPro membership users data relationship.

Let me check the BP xprofile fields configuration and Youzify's relationship to BuddyPress.

Now I have enough data to write the independent audit report. Let me do a couple more quick data checks for completeness.

I now have all the data needed. Let me compile the independent audit report.

Let me verify the report was written correctly.

Independent audit complete. Here's a summary of what was done and found. --- ## Summary **What I did:** Performed a completely independent audit of all 86 non-core WordPress database tables across 7 active plugin groups on the staging site. Examined every table schema via `DESCRIBE`, traced FK relationships, and mapped data ownership without referring to any prior analysis. **Key findings documented in `/root/profe-gs-independent-audit.md` (390 lines, 27KB):** 1. **Plugin Inventory & Table Map** — Every plugin's tables inventoried with column-level analysis. 86 tables across BuddyPress (18), FluentCRM (29), PMPro (19), Youzify (7), GamiPress (4), FV Player (3), FileBird (2), Fluent SMTP (1), and Profe Profile Tracker (1). 2. **7 Critical Issues Identified:** - **Schema mismatch**: Profe module tables FK to `profe_users.(id|uuid)` but the chassis creates `profe_user_meta` — constraints will fail. - **BP XProfile blind spot**: `profe_user_meta` plans to sync from `wp_usermeta` only — but BuddyPress stores bio/location/language/employer in `bp_xprofile_data`, not `wp_usermeta`. These will be **missing** from the canonical record. - **PMPro internal duplication**: Two parallel subscription systems (`pmpro_subscriptions` + `pms_member_subscriptions`) — any sync must pick one. - **Quadruplicated address/phone**: PMPro billing, Youzify social login, FluentCRM, and wp_usermeta all store overlapping contact data with no sync. - **Dual CRM systems**: FluentCRM is active NOW with 29 tables; Profe's CRM module is planned. Running both = unresolvable tag/contact divergence. - **Profile Tracker stores flags, not values**: It knows a field is complete but can't serve data — adds dependency without sovereignty. - **Youzify Social Login = full identity duplicate**: Stores a complete second copy of name, email, phone, address from OAuth providers. 3. **Recommended Architecture** — Data flow diagrams for each domain assigning: - **Write-authority** stays with native plugin tables - **profe_user_meta** as the aggregated read-source via JOINs and custom syncs - Specific hook/cron mechanisms for each data domain (profile_update hooks, cron for membership level, custom BP XProfile sync) 4. **7 Immediate Action Items** — Concrete next steps including the `profe_users` vs `profe_user_meta` naming fix, BP XProfile sync implementation, PMPro→Profe level mapping, CRM/community strategy decisions, PII exclusion, and hook-based propagation.