Memory Wiki

Now let me do a targeted search for any remaining COMMITs in the file and verify the full function structure of `profe_crm_process_tags`:

Now I have all the data needed. Let me verify one final thing — check the `AUTO_INCREMENT` of profe_crm confirms the test row was deleted: The `AUTO_INCREMENT=2` confirms a row was inserted (id=1) and then deleted. That matches the cleanup story: the invalid "test_membership" row is gone. --- ## Final Read-Only Review Report: `profe-sync.php` ### ✅ What Was Fixed — Verified Clean **1. Orphaned COMMITs — ALL REMOVED** Searched the live file on disk via `docker exec`. Zero occurrences of `COMMIT` or `ROLLBACK` in profe-sync.php. The 5 orphaned COMMIT statements (including the crash bugs in `profe_schedule_crons()` and `profe_sync_on_register()`) are gone. Verified by grep against the local repo copy as well — COMMITs only exist in the archived SQL backup, not in the active PHP. **2. Test Row Cleanup — profe_crm TABLE EMPTY** `SELECT COUNT(*) FROM profe_main.profe_crm` returns **0 rows**. The row with invalid tag "test_membership" has been deleted. The AUTO_INCREMENT = 2 confirms id=1 was consumed and removed. ### ✅ What's Correct **3. Transaction Order is Sound** `START TRANSACTION` precedes `SELECT ... FOR UPDATE SKIP LOCKED` in `profe_crm_process_tags()`. This is the correct ordering — the transaction must be started before the locking SELECT. **4. Unique Index on profe_crm** UNIQUE KEY `idx_user_tag_unique` on `(user_id, tag)` exists. The `INSERT IGNORE` + `rows_affected === 0` fallback-to-UPDATE logic in `profe_crm_log_membership()` is correct for resetting `processed=0` on re-apply. **5. End-to-End Flow is Sound** - PMPro checkout → `pmpro_after_change_membership_level` fires - `profe_sync_pmp_level` (priority 10): updates `profe_users.membership_level` - `profe_crm_log_membership` (priority 20): inserts tag row into `profe_crm` - `profe_crm_process_tags` (on `init`, priority 100): reads unprocessed rows, detaches old membership tags, attaches new one **6. No Undefined Variables** All functions properly initialize their variables (`$profe_db` via `profe_get_db()`, `$uuid` via `profe_get_uuid_for_user()` or `profe_ensure_user_row()`). No obvious undefined variable warnings. **7. 14-Level Membership Mapping Complete** `profe_mem_levels` has all 14 rows properly mapped. `profe_map_membership_slug()` covers direct lookup and substring fallback. ### ⚠️ Critical Issue Found: Missing COMMIT in `profe_crm_process_tags()` **Location:** `/var/www/html/wp-content/mu-plugins/profe-sync.php`, function `profe_crm_process_tags()`, lines ~250-280. **Problem:** `START TRANSACTION` is issued but there is **no matching `COMMIT`** (or `ROLLBACK`) anywhere in the function. ```php $profe_db->query("START TRANSACTION"); $rows = $profe_db->get_results("SELECT * FROM profe_crm WHERE processed = 0 ORDER BY id ASC LIMIT 50 FOR UPDATE SKIP LOCKED"); if (empty($rows)) { // <-- returns here without ROLLBACK return; } foreach ($rows as $row) { // ... FluentCRM operations ... $profe_db->query($profe_db->prepare( "UPDATE profe_crm SET processed = 1 WHERE id = %d", $row->id )); } // <-- function ends without COMMIT ``` **Impact:** 1. **No-rows path:** `START TRANSACTION` is opened, `SELECT ... FOR UPDATE` returns empty, function returns. Transaction stays open until PHP script ends — wasted transaction resources on every page load. 2. **Success path:** The `UPDATE profe_crm SET processed = 1` runs inside the transaction, but MySQL **auto-rolls back** uncommitted transactions when the connection closes. Since PHP closes the MySQL connection at script end, the UPDATE is **rolled back**, meaning `processed` stays 0. The same rows would be reprocessed on every page load — FluentCRM tags would be re-applied each time (which is idempotent since it's detach + attach, but wasteful and the `profe_crm` table never makes progress). ### ⚠️ Minor Issue: Test User Still Exists `profe_users` and `wp_users` both contain a test user: - **user_id=2**, login=`testsync`, email=`tester@test.com` - `membership_level = NULL` (no PMP level) This is leftover test data that should be removed before production deploy. The deleted "test_membership" row from profe_crm likely belonged to this user. ### Summary | Check | Status | |---|---| | Orphaned COMMITs removed | ✅ Pass | | profe_crm test data clean | ✅ Pass (0 rows) | | START TRANSACTION before SELECT...FOR UPDATE | ✅ Pass | | No undefined variables | ✅ Pass | | Full flow makes sense | ✅ Pass | | Unique index on (user_id, tag) | ✅ Pass | | 14 membership levels populated | ✅ Pass | | Missing COMMIT after START TRANSACTION | ⚠️ **FAIL — Critical** | | Test user "testsync" still in DB | ⚠️ Needs pre-deploy cleanup | **Recommendation:** Fix the missing COMMIT in `profe_crm_process_tags()` before production deploy. Add `$profe_db->query("COMMIT");` after the foreach loop, and `$profe_db->query("ROLLBACK");` in the empty-rows early return path. Also remove the testsync test user from both `wp_users` and `profe_users`.