Files
wpdev 9803f8379d
Tests / PHP Lint (pull_request) Successful in 7s
Tests / Unit Tests (pull_request) Successful in 56s
Tests / Integration Tests (pull_request) Successful in 1m22s
chore(2meet-data-optimizer-hivepress-addon): 0.5.1 repackage (no functional change)
Version bump for a re-release packaged alongside the WP-MVB v8 hub (dev39)
acceptance; code is identical to the previous release.
2026-10-02 17:23:21 +08:00

164 lines
6.8 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Changelog
All notable changes to this AddOn will be documented here.
Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
Versioning follows [Semantic Versioning](https://semver.org/).
---
## [Unreleased]
---
## [0.5.1] — 2026-10-02 — 重新打包
### Changed
- 重新打包(無功能變更):與 WP-MVB v8 樞紐站(dev39)一同驗收後發版;程式碼與前一版相同。
---
## [0.5.0] — 2026-09-28
Released with 2meet-data-optimizer 1.4.0 (hardening 2.4).
### Changed
- `hp_listing_core` declares `(hp_price, post_id)`, `(hp_rating, post_id)` and
`(hp_hourly_rate, post_id)` indexes for the listing sorts HivePress offers:
with core 1.4.0 reading the ID tie-break from the flat `post_id`, a sort walks
the index and stops at the page instead of sorting every match (dev36, 1.3M
listings: price sort 14 s native → 0.37 s routed, hourly rate 11.5 s → 0.35 s,
rating 43 s → 0.51 s). Core 1.3.0 ignores indexes ending with `post_id`, so
nothing changes there. The pinned schema hash is unchanged. (PR-119)
- Transient entries in a persistent object cache live a day (`MAX_CACHE_TTL`,
HivePress's own default) instead of a week; a timeout still outlives its value
by a minute. At a week dev36 kept 4.7M entries (1 GB) in the shared Redis and
pushed other sites' keys out. Entries already cached keep their week. (PR-120)
---
## [0.4.0] — 2026-09-27
Released with 2meet-data-optimizer 1.3.0 (hardening 2.3).
### Changed
- `hp_listing_core` declares indexes on `hp_hourly_rate` and `hp_rating_count`
(HivePress filters and sorts on both). They are declared through the group's
`indexes`, not `searchable`, so the pinned schema hash is unchanged and the
table is not rebuilt; core 1.3.0 adds them in place from WP-CLI / WP-Cron.
dev36 (902k listings): two indexes in about 4.7 s; routed `rating_count IN`
2.1 s → 0.36 s, `rating_count !=` 2.1 s → 0.76 s, hourly rate + price sort
2.1 s → 0.65 s. (PR-090)
- With a persistent object cache, transient entries now expire: a value after
a week (`MAX_CACHE_TTL`; HivePress writes it before its timeout, and a miss
only makes it rebuild), its timeout a minute after the later of that and its
own time — HivePress reads a missing timeout as "never expires", so the
timeout must go last. Entries of deleted posts no longer pile up. (PR-099,
PR-115)
### Added
- Opt-in flattening of a site's own listing attributes: the
`tmdo_hp_listing_attribute_fields` filter (`'hp_warranty' => 'integer'`)
registers them in an `hp_listing_attrs` group — a new table, each column
indexed at creation — leaving `hp_listing_core` unchanged. Types: text,
textarea, integer, decimal, boolean, date, datetime, timestamp, enum. The
group is registered once themes load, so the filter may live in a theme;
core 1.3.0 keeps it native until a drift fix has filled it. (PR-109, PR-115)
### Upgrading
- Deploy with core 1.3.0: on an older core the AddOn declares no index at all
(core 1.2.0 would run the ALTER inside a web request). (PR-090b)
- Redis: entries written by 0.3.0 have no TTL (dev36 had 3.0 M). Give them one
with non-blocking commands — never `wp cache flush-group`, which the Redis
Object Cache drop-in runs as one server-side script and which blocked Redis
on a large group. `NX` leaves entries written by 0.4.0 alone:
```
redis-cli --scan --pattern '<WP_CACHE_KEY_SALT>wp:tmdo_hp_transient:*' \
| awk '{printf "EXPIRE %s 604800 NX\r\n", $0}' | redis-cli --pipe
redis-cli --scan --pattern '<WP_CACHE_KEY_SALT>wp:tmdo_hp_transient:_transient_timeout_*' \
| awk '{printf "EXPIRE %s 608400 GT\r\n", $0}' | redis-cli --pipe
```
The second pass makes timeouts outlive their values. dev36: 3,013,352 keys
in 45 s and 1,867,569 timeouts in 32 s, 0 errors, Redis latency max 2 ms. The pattern
follows the drop-in's key layout (`<salt><blog prefix>:<group>:<key>`);
check it with `redis-cli --scan --pattern '<salt>*tmdo_hp_transient*' | head`
first. redis-cli 7 has no `--count` with `--scan`.
---
## [0.3.0] — 2026-09-27
Released with 2meet-data-optimizer 1.2.0 (hardening 2.2).
### Changed
- With a persistent object cache (`wp_using_ext_object_cache()`), the
transient filter keeps HivePress's per-post transient pairs in the
`tmdo_hp_transient` cache group instead of `wp_options`, where they piled
up (1.15 M pairs on dev36). The cache is then the only store: rows written
before are neither read nor deleted (HivePress rebuilds those caches once),
because a `get_option()` miss adds the name to WordPress's `notoptions` for
good and a hit keeps the old row in the `options` cache group with no expiry.
Without an object cache nothing changes. After upgrading, remove the rows
left behind with core's `wp tmdo cleanup-hp-transients --options --confirm`.
### Fixed
- The detected / bound status cells of the HivePress admin table go through
`esc_html()` (2.1 audit); output unchanged.
### Docs
- `docs/REGISTERED-KEYS.md`: the six registered keys HivePress never writes
as meta, because its models alias them to core columns (listing
`hp_vendor` → `post_parent`, `hp_status` → `post_status`; request
`hp_status`, `hp_user`; vendor `hp_user`; review `hp_rating` →
`comment_karma`). The schema stays; their flat columns are always NULL.
- `docs/HIVEPRESS-COVERAGE.md`: dev36 inventory of the meta each HivePress
post type holds, where the extensions keep their data and the query shapes
the front end produces. Attribute auto-registration is not needed now:
every meta key HivePress queries is registered.
---
## [0.2.0] — 2026-09-26
Released with 2meet-data-optimizer 1.1.0 (hardening 2.1, search-index mode).
### Changed
- HivePress model query / search hooks (`optimize_query`, `optimize_search`)
are no longer bound while core's post router is active
(`TMDO_Post_Query_Router::is_router_active()`): core routes HivePress
searches, including `_sort`, to the entity flat tables, and two routers
would claim the same clauses.
### Added
- `tests/integration/`:bootstrap(複用核心的 integration bootstrap,連真實
MariaDB)+ `phpunit-integration.xml` + CI job,移植 5 個測試檔
(`HivepressIntegrationTest`、`HivepressTermCommentFieldsTest`、
`HivepressTransientFilterTest`、`ListingMetaInterceptorTest`、
`TermCommentBackfillTest`),共 57 tests。
- `tests/unit/ListingStatsTest.php`(9 tests)。unit bootstrap 先 define
`TMDO_TEST_SKIP_LISTING_STATS_STUB`,核心 bootstrap 便會跳過它的
`TMDO_Listing_Stats` stub,改載入本 AddOn 的真實實作。145 → 154 tests。
- Phase 3 implementation in progress.
---
## [0.1.0] — TBD
### Added (initial release, scaffold)
- Plugin scaffold from `wp-data-optimizer v2.16.0` extraction plan.
- Plugin Header + bootstrap stub + 7 MD + composer.json.
- Requires Plugins: `2meet-data-optimizer`, `hivepress`.