- 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)
- add_flat_rows (wp_insert_post, after transition_post_status) inserts the
copies with the empty row: a NULL copy turned the copy route off for the
whole group until the next sync
- wp tmdo post-status-sync bumps the routed count version (not on dry runs)
- Test bootstrap: minimal WP_Post stub
- Found in the 2.4 correctness review (residual risks)
- Verify: 2 new integration tests; integration 606, unit 704, phpcs 0, stan OK
- PR: PR-133
- pre_get_posts clears wpdo_post_clauses / _sort / _copy_route / _count_sql
before anything else: new WP_Query( array( … ) ) could preset them
- posts_orderby whitelists the copy route's direction
- Found in the 2.4 security review (Low L2; not reachable from URLs)
- Verify: PostQueryRouterCopyTest (1 new); integration 604, unit 704, phpcs 0
- PR: PR-132
- flat_first and the copy route share ties_on_post_id(): a posts.ID term
alone (optionally with a direction) reads the flat post_id; posts.ID inside
an expression a plugin added (FIELD(), IN) is left alone — inserting a
direction there made the SQL invalid and the page empty
- PCRE failures return the text given instead of '' (the query kept its
shape rather than becoming an empty request)
- Found in the 2.4 correctness review (Medium) and security review (Low L1)
- Verify: 2 new integration tests (the flat-first one runs the SQL), router suites 69 OK
- PR: PR-131
- meta_key is routed as EXISTS only when no orderby entry names meta_value,
meta_value_num or the key (several orderings or an array included);
clearing it made WordPress drop the price ordering
- A sort group is dropped as unused only when orderby names neither it,
meta_value(_num) nor its key (it is then the primary clause)
- meta_compare_key other than '=' keeps meta_key native (LIKE matches other keys)
- Found in the 2.4 correctness review (regressions from PR-122)
- Verify: PostQueryRouterTest (3 new), router suites 67 OK
- PR: PR-130
- Replace the index only on tables listed in tmdo_post_status_columns
(ALTER ADD idx_post_status_date_id / DROP idx_post_status_date)
- Warn that `wp tmdo post-status-sync` also adds and backfills copy
columns on every other post group (large ALTER + UPDATE)
- Found in the 2.4 rollout (dev21: aeav_only, over ten million posts)
- migrate_entity (drift-check --fix), migrate_group and migrate_group_batch
write flat rows outside the Hook Bus: bump the routed count version
(once per call / batch; not on dry runs; post rows only)
- dev36: a vendor search kept counting 21515 of 21522 matches after a fix
- Verify: composer test (704), test:integration (598), phpcs, stan
- PR: PR-129
- Copy route: drop WordPress's GROUP BY when the flat row is the only join,
and read posts.ID tie-breaks as the flat post_id (own direction, once)
- Post status sync: index (post_status, post_date, post_id) replaces the
two-column idx_post_status_date (added / dropped by post-status-sync)
- dev36, 235k of 1.3M listings in a price range: main query 1.7 s -> 3 ms
- Verify: composer test (704), test:integration (597), phpcs, stan
- PR: PR-128
- migrate_entity() (drift-check --fix, per-row backfill) REPLACEs the whole
flat row and left out the post_status / post_date copies, so a rebuilt row
had NULL status. One such row turns the status/date copy route off for the
whole group: on dev36 a single row rebuilt by the stage-3 drift fix made the
date-ordered price search 1.47 s instead of driving from the flat index
- post rows now carry TMDO_Post_Status_Sync::insert_columns(); the bulk pivot
backfill (ON DUPLICATE KEY UPDATE) was not affected
- Verify: PostStatusSyncTest (existing and new rows keep their copies),
integration 593, unit 704, phpcs, stan; dev36 post-status-sync + front-end
- PR: PR-127 (found in 2.4 profiling)
- HivePress runs it on every listing search page from its own
pre_get_posts: get_posts() with the search's meta query (still unrouted,
including its sort group), meta_key hp_featured and orderby rand. The
router declined both shapes, so the lookup stayed native: 2.26–2.38 s of a
2.5 s page at 1.3M listings on dev36
- a sort group (key NOT EXISTS OR key EXISTS) that no orderby uses matches
every post and is dropped; meta_key without meta_value and without a
meta_value sort routes as EXISTS (WP_Query turns it into that clause)
- Verify: PostQueryRouterTest (featured lookup routed, meta_key with a value
untouched), integration 592, unit 704, phpcs, stan; dev36 front-end
- PR: PR-122 (follow-up)
- WP_Meta_Query adds a value condition only when 'value' is set, so a clause
like array( 'key' => 'hp_featured' ) only tests that the key exists. The
router read it as "= ''", declined it, and kept the whole query native
- HivePress runs such a query on every listing search page (featured-listing
lookup in Attribute::set_search_query(): hp_featured plus the search's own
filters, ORDER BY RAND()); at 1.3M listings on dev36 it took 2.26 s of a
2.5 s page, routed or not
- Verify: PostQueryRouterTest (key-only clause routes as IS NOT NULL),
integration 590, unit 704, phpcs, stan; dev36 front-end
- PR: PR-122
- a group index may end with the entity ID column (post_id, ...)
- flat-first rewrites the posts.ID tie-breaks once, in the sort's direction:
with a (column, post_id) index MySQL returns rows in order instead of
sorting the whole match. dev36 (1.3M listings), price range sorted by price:
850 ms filesort -> 2 ms. Ties are ordered by ID the same way as the column
(natively ID DESC); pagination stays stable, result sets are unchanged
- Verify: EntityRegistryIndexesTest, PostQueryRouterFoundRowsTest (ASC
tie-break, single tie-break), unit 704, integration 589, phpcs, stan;
dev36 with the HivePress indexes (PR-119)
- PR: PR-118
- mut.php called wp_cache_flush() after each write and qbench.php
wp_cache_flush_group() before each run; with Redis Object Cache's selective
flush both are one server-side Lua scan over the site's keys, which blocked
the shared Redis for 5–20 s on dev36 (3 M keys) and broke other sites'
requests (BUSY / read errors)
- mut.php clears the touched post or user caches plus the runtime cache;
qbench.php bumps the routed count version (posts' last_changed before 1.3.0)
- tests/ is not packaged; plugin code does not flush
- cached counts followed posts' last_changed, which WordPress moves on any
post meta write; themes write meta on page views (on dev36 Blocksy saved a
dynamic-CSS descriptor for each listing a crawler visited), so the cache
was invalidated every few seconds and keyword/filter searches recounted
- counts now follow their own last_changed group (tmdo_posts), bumped on
clean_post_cache (post saved or deleted; hooked in every mode) and on flat
writes through the Hook Bus, plus terms' last_changed; a routed search reads
no unmanaged meta
- Verify: PostQueryRouterFoundRowsTest (unrelated meta write keeps the count,
save or flat write recounts), integration 588, unit 703, phpcs, stan;
dev36 front-end
- PR: PR-117 (2.3 acceptance)
- keyword searches carry wpdb's placeholder escape for "%" ({<hash>}), which
is new in every request, so md5(count SQL) never matched across requests
and every keyword search recounted (the 2.2 "keyword + filter routed slower
than native" finding). The key now uses remove_placeholder_escape()
- found in the 2.3 acceptance: dev36 keyword + price routed 6.2 s vs native
4.9 s; PR-091's in-process check reused one process, one escape
- Verify: PostQueryRouterFoundRowsTest (two escapes, one COUNT), integration
588, unit 703, phpcs, stan; dev36 front-end
- PR: PR-116 (2.3 acceptance)
- a deferred group whose stored definition matches again (reverted, or
upgraded by another process) goes through end_deferral() instead of staying
native for good (review F2)
- the tmdo_ensure_group_indexes handler upgrades deferred tables itself: with
ALTERNATE_WP_CRON the event runs after init in a visitor's request (F3)
- a new group table created while the entity writes to flat stays native
until the drift fix has filled it from native meta; an opted-in HivePress
attribute no longer routes searches to an empty table (F6)
- direct_read() returns native values for a deferred group (F10); the Hook
Bus ignores deferral in aeav_only, as the router does
- dbDelta failures: the definition is recorded only when every column exists
(schema.upgrade_failed otherwise), so a failed ALTER is retried and the
group is not released onto missing columns
- test bootstrap: get_metadata() reads the real meta table
- Verify: SchemaUpgradeDeferralTest (6), Hook Bus direct read, integration
587, unit 703, phpcs, stan
- PR: PR-114 (2.3 acceptance correctness review)
- TMDO_Logger::notice() is always written to the error log (it had no
callers); bridge_mode_changed and snapshot_deleted use it. Since PR-095
info() is silent without WP_DEBUG_LOG, which left no record of who switched
a mode or deleted a snapshot (security review L1)
- Verify: LoggerTest (notice always logged, info gated), unit 703,
integration 585, phpcs, stan
- PR: PR-113 (2.3 acceptance security review)
- security review H1: anonymous /wp-cron.php requests pass ddl_allowed(),
and dbDelta on an existing table had no lock, so concurrent requests each
ran the ALTER on a large table. The upgrade now runs under the same MySQL
GET_LOCK as the index DDL (skipped when another process holds it) and
re-checks the stored hash once locked; this covers aeav_only too. The table
build moves unchanged to write_table(); lock()/unlock() are shared
- security review M1: after a deferred upgrade the group stays native until
tmdo_drift_resync has rebuilt the rows written meanwhile
(TMDO_Schema_Manager::resynced() from run_scheduled_fix()); with no flat
writes (disabled) it is released at once
- Verify: SchemaUpgradeDeferralTest (lock held elsewhere, resync release),
integration 585, unit 702, phpcs, stan
- PR: PR-111 (2.3 acceptance security review)
- Changed: deferred table upgrades (PR-107), index lock on the primary
(PR-108), cold cache flush by version (PR-110); Fixed: dropped tables in
post status sync (PR-106)
- Verify: composer test
- PR: PR-101 (follow-up)
- TMDO_Cache_Layer::flush_group() bumps the post type's cold cache version
(option wpdo_cold_cache_version) instead of wp_cache_flush_group(), which
Redis Object Cache runs as one server-side scan that blocks Redis on a large
group; entries under older keys expire by their TTL
- TMDO_Zone_Cold::cache_key() builds every cold blob key; version 0 keeps the
current keys, so upgrading invalidates nothing
- Verify: CacheLayerTest (new keys, no scan, other post types untouched),
unit 702, integration 583, phpcs, stan
- PR: PR-110
- when $wpdb has send_reads_to_masters() (HyperDB, LudicrousDB), it is called
before SELECT GET_LOCK, which a replica would take without locking out the
ALTER on the primary
- Verify: GroupCompositeIndexTest (call order through a wpdb proxy),
integration 583, unit 701, phpcs, stan
- PR: PR-108
- a changed group definition no longer runs dbDelta on an existing table
inside a web request (seconds to minutes on a large table, and every
concurrent request tried it): the group is recorded in tmdo_schema_deferred
and tmdo_ensure_group_indexes is scheduled, whose request upgrades it
- meanwhile the group stays native: Hook Bus field lookups return no field and
the router treats it as drifting; afterwards a drift fix
(tmdo_drift_resync) rebuilds the writes that skipped the flat table
- new tables are still created at once; aeav_only upgrades at once (the flat
table is the only copy); doctor lists deferred groups
- Verify: SchemaUpgradeDeferralTest, Hook Bus and router tests, integration
582, unit 701, phpcs, stan; dev36 live cycle in the 2.3 acceptance
- PR: PR-107
- on_transition() skips a recorded group whose table no longer exists and
removes it from tmdo_post_status_columns; every post status change used to
UPDATE the missing table and print a database error (seen on dev36 after a
throwaway group's table was dropped)
- Verify: PostStatusSyncTest (dropped table), integration 578, unit 701, phpcs, stan
- PR: PR-106
- version 1.3.0; CHANGELOG and readme.txt for PR-090a, 091, 093 (verified,
no change), 094–098, with the post-upgrade steps (first CLI / cron run adds
the HivePress indexes; INFO lines need WP_DEBUG_LOG)
- Verify: composer test (701)
- PR: PR-101
- $bootstrap_files, $bootstrap_ok, $f, $result, $snapshot_id and $dir become
$wpdo_* like the file's other globals (WordPress.org Plugin Check)
- Verify: PrefixAllGlobals sniff 0, phpcs, UninstallGuardTest and
InstallerCleanupTest, unit 701
- PR: PR-098
- the main page's form handlers move unchanged from render_page() to
handle_post(), hooked on load-{page}: inside render_page() the admin
header was already sent, so their wp_safe_redirect() calls could not work
- the setup wizard's step 4 snapshot post moves to handle_snapshot_post() on
its load hook; a failure redirects with snap_failed=1 for the notice
- Verify: unit 701, integration 577, phpcs, stan; dev36 load hook handles a
posted reset and redirects before output
- PR: PR-097
- rest_exposable() also withholds keys named like an email, phone, address or
IP, even when a field declares show_in_rest (defence in depth)
- Verify: RestApiTest (private and look-alike public keys), unit 701,
integration 577, phpcs, stan; dev36 live rest suite
- PR: PR-096
- TMDO_Logger::info()/notice() write to the PHP error log only with
WP_DEBUG_LOG (filter tmdo_log_info); every CLI run and production request
printed [WPDO][INFO] lines
- debug() keeps its WP_DEBUG gate; warning() and error() are unchanged
- Verify: LoggerTest (2 new), unit 700, integration 577, phpcs, stan
- PR: PR-095
- blocked POST /listings/{id}/view requests update wpdo_rl_stats 1 in 10,
each sample adding 10: anonymous traffic no longer turns 1:1 into DB writes,
and the admin top list stays representative (unbiased estimate)
- Verify: RestApiTest counts option writes (about 20 for 200 blocked requests),
unit 698, integration 577, phpcs, stan
- PR: PR-094
- a routed search with post__not_in (HivePress sends a random set per page)
caches the COUNT without the exclusion and subtracts a live primary-key
count of the excluded posts that match; the total stays exact
- the excluded count drops STRAIGHT_JOIN so MySQL starts from posts.ID
- Verify: PostQueryRouterFoundRowsTest, unit 698, integration 577, phpcs, stan;
dev36 live router suite and keyword + price search
- PR: PR-091
- ensure_group_indexes() runs the ALTER only under WP-CLI or WP-Cron (filter
tmdo_schema_ddl_allowed); web requests, including /wp-admin/ before
auth_redirect() and admin-post.php, schedule tmdo_ensure_group_indexes instead
- MySQL GET_LOCK keeps it to one process (add_option() is INSERT ... ON
DUPLICATE KEY UPDATE and cannot serve as a lock); released by MySQL if the
process dies
- the applied signature is recorded only when every ALTER succeeds; failures
log schema.index_failed and stay in pending_indexes(), which doctor reports
- new tables get their declared cidx_ indexes in CREATE TABLE
- test stub wpdb::query()/insert() return false on SQL errors like wpdb
- Verify: GroupCompositeIndexTest 7/7, unit 698, integration 576, phpcs, stan
- PR: PR-090a
- The PR-079 live router cases ran the HivePress rating sort on the whole site with an unqualified DECIMAL: native rounds 4.5 to 5 and orders its many ties by chance, so the id order passed or failed with the query plan. They now send DECIMAL(10,1), as the HivePress Rating field does, and compare each position's native sort key and found_posts; the flat-first / GROUP BY assertions stay.
- Verify: live router 18/18 twice; all suites 56/56
- PR: PR-089b
- A group's last drift record outlived its registration (wc_product and user hot on dev36, any add-on deactivated): doctor counted it and could warn forever with a --fix hint that cannot reach it. Only records of backfillable groups are read; the router and clean_since already go by the registry.
- Verify: DoctorTest (RED before); dev36 doctor user 9 → 8 groups
- PR: PR-089a
- `wp tmdo cleanup-hp-transients --options [--dry-run|--confirm] [--batch=<n>]` removes the rows the HivePress AddOn wrote to wp_options (`_transient_wpdo_hp_pm_*` and their timeouts) before AddOn 0.3.0 kept them in the object cache, deleting in batches (default 5000). It works without the AddOn active; the namespace is repeated in core for that.
- Verify: CleanupHpTransientsTest (RED before; only the AddOn's rows go, look-alike names stay); dev36 --dry-run counts 2,314,750 rows in 3.2 s. The --confirm run belongs after the AddOn change is deployed.
- PR: PR-080
- A sort-only search (HivePress _sort, no routed filter) LEFT JOINs the flat table to keep posts without a row; it now drives from the flat table (STRAIGHT_JOIN, INNER JOIN) when every post of the type has a flat row. The router gives a new post of a type with its own groups an empty row (wp_insert_post); coverage is one anti-join per group, cached 15 min and per post-mode change (forget_coverage()).
- A flat-first search drops the GROUP BY posts.ID WordPress adds for any tax query when the flat row is the only join (WooCommerce's product_visibility NOT IN on searches is a subquery); a joining tax query keeps it.
- Verify: live router suite (5 new cases, RED before); dev36 rating__desc page, ids identical: native ~3.3 s, 2.1 routing ~1.5–1.9 s, now ~0.51–0.85 s (main query 440 → 46 ms, COUNT 400 → 160 ms). p50 ≤ 300 ms is still not met: page rendering and HivePress's own get_posts() in pre_get_posts (suppress_filters, ~100 ms) remain.
- PR: PR-079
wpdev