wpdev
e57dd5bd15
- 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
122 lines
4.8 KiB
Markdown
122 lines
4.8 KiB
Markdown
# 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.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 timeout
|
||
entry when it records, a value after at most a week (`MAX_CACHE_TTL`;
|
||
HivePress writes the value before its timeout, and a miss only makes it
|
||
rebuild). Entries of deleted posts no longer pile up. (PR-099)
|
||
|
||
### 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
|
||
```
|
||
|
||
dev36: 3,013,352 keys in 45 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`.
|