- 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
- 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)
- 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
- 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
wpdev