fix(2meet-data-optimizer-hivepress-addon): 0.5.3 view-count flush keeps flat row and meta cache in sync
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().
This commit is contained in:
@@ -11,6 +11,20 @@ Versioning follows [Semantic Versioning](https://semver.org/).
|
||||
|
||||
---
|
||||
|
||||
## [0.5.3] — 2026-10-07 — 瀏覽數 flush 不再造成漂移
|
||||
|
||||
### Fixed
|
||||
|
||||
- **`TMDO_Listing_Stats::flush_views_to_postmeta()` 寫完後同步扁平表與快取**:每小時把 warm zone 的瀏覽數
|
||||
用原子 `UPDATE … meta_value + N` 加回 `hp_view_count`,繞過了 meta API:Hook Bus 看不到這次寫入,
|
||||
dual_write/shadow_read 下 `hp_listing_core.hp_view_count` 每批落後一次(夜間 drift-check 每晚 diff),
|
||||
物件快取(Redis 下跨請求)也一直是舊值。現在 UPDATE 之後清掉該篇的 `post_meta` 快取,
|
||||
並在原生仍是真相時(同時寫原生與扁平)用 `TMDO_Entity_Migration_Engine::migrate_entity()` 重建那一列。
|
||||
`hp_view_count` 同時在 `hp_listing_core` 與 `hp_request_core`:只重建含這個 key、而且適用該篇 post type 的群組
|
||||
(不帶 post type 的 `get_field()` 只回最後登記的那組)。aeav_only 不動(扁平才是真相)。
|
||||
|
||||
---
|
||||
|
||||
## [0.5.2] — 2026-10-05 — attribute bridge 的 meta key
|
||||
|
||||
### Fixed
|
||||
|
||||
Reference in New Issue
Block a user