wpdev/2meet-data-optimizer-hivepress-addon
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
18 Commits 8 Branches 0 Tags
69c8bf2a88c641dd2b3a97e6a1309ae360994913
Commit Graph

3 Commits

Author SHA1 Message Date
wpdev 69c8bf2a88 feat(2meet-data-optimizer-hivepress-addon): provide HivePress defaults to core via filters 
- 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
 2026-09-26 00:24:43 +08:00
wpdev 3c57fb0ee6 fix(2meet-data-optimizer-hivepress-addon): declare post_type scopes on HivePress post groups 
- 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
 2026-09-25 23:57:52 +08:00
wpdev 19add5fc16 refactor(2meet-data-optimizer-hivepress-addon): take ownership of hp_* entity groups 
- Add TMDO_HivePress_Entity_Groups registering hp_listing_core / hp_request_core / hp_vendor_core / hp_user, copied verbatim from core (same order; schema hashes match the persisted wpdo_registry_meta rows)
- Drop the core adapter's conflicting hp_user definition (hp_verified / hp_avatar_id — keys HivePress never writes)
- Verify: HivePressEntityGroupsTest (identical to core, same shared-key resolution, no collisions); HP unit 144 / integration 49 OK; hashes = dev20 registry_meta
- PR: PR-019
 2026-09-25 23:43:40 +08:00