- Archive sweep waits until idx_original_meta exists (a plugin update does
not run dbDelta; without the index NOT EXISTS scans the archive per row)
- Duplicate archive cleanup runs from WP-CLI only, never in a web activation
- Uninstall keeps the LatePoint add-on's tmdo_latepoint_db_version
- AJAX save errors stay on screen instead of fading after 2.5 s
- Verify: 2 new integration tests; unit 711, integration 612, phpcs 0, stan OK
- PR: PR-141 (2.4.2 correctness review)
- Version 1.4.2 (header, TMDO_VERSION, readme Stable tag and changelog)
- CHANGELOG lists PR-135..139; after upgrade run wp tmdo install once per
site for the archive index and duplicate cleanup
- PR: PR-140
- The refused-uninstall notice said no tool writes the data back to native
tables; wp tmdo bridge-restore-native does.
- The post stress tester no longer maps product to the retired wc_product table.
- Verify: unit 711, integration 611, phpcs 0
- PR: PR-139 (manual F-7, F-8)
- Backfill batches are scheduled with (entity, group) args; the health
panel looked for (entity) alone, never saw one and kept offering to start
a backfill, which resets the group's checkpoint
- is_backfill_active() checks every group of the entity
- Unit bootstrap: wp_next_scheduled() stub honours hook + args
- Verify: EntityHealthBackfillTest (2 new); unit 711, phpcs 0, stan OK
- PR: PR-137 (manual F-11)
- sweep() skips meta rows already in wpdo_archive (NOT EXISTS on
original_meta_id): it copied the same trashed meta again every day and
wpdo_archive has no unique key (dev20: 300 rows for 150 meta rows)
- TMDO_Zone_Archive::remove_duplicates() keeps the first copy per
original_meta_id (rows without one are left alone); install() runs it,
so `wp tmdo install` cleans existing sites
- wpdo_archive gets KEY idx_original_meta for the lookup (new installs;
existing sites via `wp tmdo install`). SCHEMA_VERSION is not bumped, so
no web request runs dbDelta
- Verify: ZoneArchiveIntegrationTest (2 new); dev20 read-only check: 150 of
300 rows would be removed; unit 709, integration 608, phpcs 0, stan OK
- PR: PR-136 (manual F-6)
- The settings form and the AJAX section save both went through
TMDO_Mode_Manager::set() and dropped its WP_Error: an unsafe jump or a
Promotion Guard refusal still said "saved" while the mode stayed put
- TMDO_Admin::apply_bridge_modes() returns the refusals; the full form keeps
them in a per-user transient and shows them after the redirect, the AJAX
save returns them as the error message (the settings JS shows it)
- Verify: AdminBridgeModeSaveTest (5 new); unit 709, integration 606, phpcs 0, stan OK
- PR: PR-135 (manual F-2)
wpdev