- The detected / bound status cells of the HivePress admin table echo their literal marks through esc_html() (2.1 audit, Info 1, AddOn part); the output is unchanged.
- PR: PR-084
- docs/HIVEPRESS-COVERAGE.md: read-only inventory on dev36 of the hp_* meta each post type holds (registered or not, queried or not), where the extensions keep their data (comments, taxonomies, user meta) and the query shapes a front-end crawl produced.
- Conclusion for plan D04: attribute auto-registration is not needed now — every meta key HivePress queries is registered, select attributes are taxonomies, and the unregistered keys written (hp_due_date, hp_availability, hp_warranty) are never queried; revisit for sites that add filterable or sortable number / date attributes. README links it.
- PR: PR-083
- docs/REGISTERED-KEYS.md lists the six registered keys that are aliases of core columns in the HivePress models (listing hp_vendor → post_parent, hp_status → post_status; request hp_status, hp_user → post_author; vendor hp_user; review hp_rating → comment_karma), with the dev36 evidence (0 meta rows each) and why the schema stays (plan D03). README links it.
- PR: PR-082
- 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