flush_views_to_postmeta() adds warm-zone views back with a direct UPDATE,
which the Hook Bus never sees: under dual_write/shadow_read the
hp_listing_core.hp_view_count column drifted after every hourly batch and
the (Redis) object cache kept the old count. After the UPDATE, drop the
post's meta cache and, while native is still the source of truth, rebuild
the entity's flat row with migrate_entity().
- version 0.4.0; CHANGELOG for PR-090, 090b and 099 with dev36 numbers
- Upgrading: deploy with core 1.3.0; give 0.3.0 Redis entries a TTL with
redis-cli --scan | EXPIRE ... NX | --pipe (tested on dev36: 3.0 M keys,
45 s, latency max 2 ms), never flush-group
- Verify: composer test (145)
- PR: PR-102
- On a cache miss the filter fell back to get_option(): with the values now written to the cache, the option is absent, so WordPress added its name to `notoptions` for good (dev36: +1,000 entries for 1,000 posts, one array loaded on every miss); a hit kept the old row in the options cache group with no expiry, which slowed the selective Redis flush (8.9 s, BUSY). The cache is now the only store for reads and deletes; old rows wait for cleanup-hp-transients --options. Without an object cache nothing changes.
- Verify: HivepressTransientFilterTest (2 RED before); dev36 notoptions 210 → 210 over 1,000 posts (was 128 → 1,128)
- PR: PR-089c
- Do not bind optimize_query / optimize_search on hivepress/v1/models/{listing,vendor}/{query,search} while core's TMDO_Post_Query_Router is active: core now routes HivePress searches (filters and _sort) to the entity flat tables, and two routers would claim the same clauses
- Version 0.2.0 (released with core 1.1.0); CHANGELOG
- Verify: composer test (144, +2 binding tests); integration 49; dev36 fe.sh 9 URLs ids == native (except known flat drift)
- PR: PR-063
wpdev