- MAX_CACHE_TTL: a week -> a day (HivePress's own default); a timeout still
outlives its value by a minute
- dev36 (1.3M listings): 4.7M entries / 1 GB in the shared Redis at a week,
evicting other sites' keys
- Verify: composer test (148), integration (53), phpcs clean on the file
- PR: PR-120
- hp_listing_core declares (hp_price, post_id), (hp_rating, post_id) and
(hp_hourly_rate, post_id): with core 1.4.0 a flat-first price, rating or
hourly-rate sort reads them in order instead of sorting every match
(dev36 stage 3: the price-range + price-sort search was the slowest routed
page, 2.9 s at 1.3M listings); core 1.3.0 ignores indexes ending with post_id
- the pinned schema hash is unchanged (indexes are not part of it)
- Verify: HivePressEntityGroupsTest, unit 148, integration 53, phpcs;
dev36 front-end sorts
- PR: PR-119
- review F5: a timeout entry expired before its value (a day vs a week), and
HivePress reads a missing timeout as "never expires", serving the stale
value for up to six more days. The timeout now expires a minute after the
later of MAX_CACHE_TTL and its own time, so HivePress sees it expire first
- review F7: site attributes accept only types with a plain index (json and
binary would fail the CREATE TABLE)
- review F8: the hp_listing_attrs group is registered on the run after
after_setup_theme (init:1), so a filter added in a theme counts and the
group has one definition per request; only keys of other groups are skipped
- Verify: TTL test, attribute group tests, unit 148, integration 53, phpcs
- PR: PR-115 (2.3 acceptance correctness review)
- the tmdo_hp_listing_attribute_fields filter (hp_ key => type) registers a
site's HivePress listing attributes, such as a "Warranty" number attribute
(hp_warranty, 901k rows on dev36), in their own hp_listing_attrs group: a
new table with each column indexed at creation; hp_listing_core and its
pinned hash are unchanged
- keys another group manages, keys without the hp_ prefix and unknown types
are ignored
- Verify: HivePressEntityGroupsTest (opt-in, filtering, pinned hashes), unit
147, integration 53, phpcs; dev36 hp_warranty backfill and queries
- PR: PR-109
- with an external object cache, a HivePress timeout entry expires when it
records; the value (written before its timeout) after at most a week — a
miss only makes HivePress rebuild it. Entries of deleted posts no longer
accumulate without end
- Verify: HivepressTransientFilterTest TTL test, integration 53, unit 145;
dev36 Redis TTL on tmdo_hp_transient keys
- PR: PR-099
- hp_listing_core declares indexes on hp_hourly_rate and hp_rating_count; core
adds them in place (WP-CLI / WP-Cron), the pinned schema hash is unchanged
- Verify: unit 145, integration 52, phpcs; dev36 902k listings (SHOW INDEX, EXPLAIN)
- PR: PR-090
- 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
- With a persistent object cache (wp_using_ext_object_cache(), Redis on the HivePress sites) the transient filter stores HivePress's per-post transient pairs in the tmdo_hp_transient cache group instead of wp_options, where they piled up (1.15 M rows on dev36). Reads fall back to wp_options for values written before; deletes clear both. Without an object cache nothing changes.
- Verify: HivepressTransientFilterTest object-cache cases (RED before); dev36 with Redis: update/get/delete_post_meta on an HP transient key leaves 0 rows in wp_options and postmeta.
- PR: PR-081
- 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
- ADR-003 step 4 (AddOn side): core, requests, bookings, memberships and
marketplace adapters no longer register zone=hot fields or contribute
hot_* FSM modules; their keys live in TMDO_HivePress_Entity_Groups.
Cold/warm registrations are unchanged.
- Hot-table doctor probes go with them (trait defaults apply). The
hot-clause query rewrite and cron optimizer are now inert and are left
for the ADR step-5 removal together with core's hot path.
- New NoHotZoneRegistrationTest pins the invariant across all 13 adapters;
per-adapter hot assertions removed.
- Verify: HP unit 142 / integration 49 green, phpcs clean (WordPress)
- PR: PR-037
- New scoped post groups for fields only the Hot zone covered (ADR-003):
hp_draft_flags (hp_listing, hp_request: hp_drafted), hp_booking_core,
hp_membership_plan_core, hp_membership_core. hp_drafted lives in one group
spanning both post types, so it adds no shared key.
- New groups register before the existing ones: the legacy (unscoped)
owner of hp_expired_time stays hp_request_core; existing hashes unchanged.
- Reconciler now also plans hp_membership rows of hp_expired_time out of
hp_request_core. dev20-22 hold 0 native rows for these keys.
- Verify: HP unit 151 / integration 49 green, phpcs clean
- PR: PR-036
- TMDO_HivePress_Entity_Groups hooks tmdo_rest_default_post_type so GET /wpdo/v1/listings keeps defaulting to hp_listing now that core defaults to 'post' (PR-020e)
- Test: TMDO_Post_Group_Reconciler::plan() over the AddOn's groups yields the 8 misrouted HivePress keys (coverage moved out of core in PR-020b)
- Verify: HP unit 148 / integration 49 OK, bootstrap smoke OK
- PR: PR-020f
- Delete the HPCT importer (no caller left after core dropped HPCT in PR-020c) and its bootstrap/alias/test-bootstrap entries
- Conflict guard notice, log line and HivePress admin tab no longer point to the never-existing `wp wpdo hivepress migrate-from-hpct`; they say to deactivate the legacy plugins (their own tables are not imported)
- Verify: ConflictGuardTest guard; HP unit 146 / integration 49 OK, bootstrap smoke OK
- PR: PR-020d
- hp_listing_core / hp_request_core / hp_vendor_core declare hp_listing / hp_request / hp_vendor, matching core (PR-033), so the AddOn keeps scoped routing once core stops registering them (PR-020b)
- Test: with tmdo_post_scoped_routing on, every key of each group resolves to its own post type's group; legacy owner and hash pins unchanged
- Verify: HP unit 145 / integration 49 OK
- PR: PR-033b
- HivePressEntityGroupsTest no longer loads core TMDO_Post_Fields / TMDO_Member_Fields, so it survives core dropping them (PR-020b)
- Pin the 4 groups to their wpdo_registry_meta hashes and the current owner of the 8 shared post keys (documented as existing behaviour, not intent)
- Verify: HP unit 144 OK; mutating one field type fails the hash test
- PR: PR-020a
- Delete 7 interceptors + 5 query rewriters that read/write hpct_* tables no site has (only an empty hpct_latepoint_idx exists)
- Drop their loading/registration in TMDO_HP_Bootstrap, back-compat aliases, integration bootstrap, and ListingMetaInterceptorTest
- Verify: unit 141 OK, integration 49 OK, bootstrap smoke OK; phpcs 34E/40W → 25E/28W
- PR: PR-014
- hivepress-marketplace stores its filterable, sortable listing price as
hp_price; hp_purchase_price never existed (dev34: 588 hp_price rows)
- Drop hp_purchase_count: the addon keeps no per-listing sales counter
- Remove the stale docblock note about the legacy core registration path
Verify: vendor/bin/phpunit --filter test_on_register_fields_registers_hot_hp_price;
addon unit 156 OK, integration 57 OK
PR: PR-011
- hivepress-social-links stores each link as hp_{name} (hp_facebook, not
hp_facebook_url) and lets admins enable links separately for listings
and vendors; the hardcoded 7 *_url vendor keys never matched real meta
- Read hp_listing_social_links / hp_vendor_social_links and register each
enabled link on its own post type, so custom links (e.g. line_oa) work
- dev34 check: meta holds hp_instagram / hp_website, and zero *_url keys
Verify: vendor/bin/phpunit --filter HivePressSocialLinksAdapterTest;
addon unit 156 OK, integration 57 OK
PR: PR-010
- hivepress-bookings has no guests field; the places booked are stored as
hp_quantity (only when "Allow multiple places" is enabled)
- Verified against hivepress-bookings 1.5.5: start_time / end_time were
already correct and stay unchanged
Verify: vendor/bin/phpunit --filter test_on_register_fields_uses_real_booking_meta_keys;
addon unit 155 OK, integration 57 OK
PR: PR-009
wpdev