ACPT v2.0.67 WordPress Plugin

What’s New (Changelog) in ACPT v2.0.67

## [2.0.67] - 2026-08-18

### Changed

#### Performance

- **License, plugin-version and ID-field-backfill options queried on every request** - These three tracking options were stored with `autoload=no`, forcing WordPress to issue a dedicated `SELECT` for each on literally every front-end and admin request instead of folding into its single bulk options query. Now stored autoloaded, with a one-time migration that fixes the flag on sites already storing these from an earlier version.
- **Settings table queried on every request without ever hitting the plugin's cache** - Reading the settings table happens during the plugin's own bootstrap, before its file-based query cache has been initialized, so this specific read could never benefit from it no matter how warm the cache was elsewhere. It now has its own lightweight cache, invalidated whenever a setting is saved.
- **`wp_enqueue_media()` running on every wp-admin screen** - ACPT called WordPress's media-library bootstrap function unconditionally on every `admin_enqueue_scripts`, triggering a `wp_posts` query on every wp-admin page for every plugin - not just ACPT's own screens. It's now only called on screens where ACPT actually registered assets.
- **Media library "date filter" dropdown query re-run on every `wp_enqueue_media()` call** - Hooked WordPress core's `media_library_months_with_files` filter (provided by core specifically to avoid this cost, see `core.trac.wordpress.org` ticket #31071) to cache the dropdown's month/year data instead of recomputing it with an uncached `wp_posts` scan every time.

### Fixed

#### Security

- **REST API authentication** - `ACPT_Api_Auth::authenticate()` only verified that Basic Auth credentials or an API key belonged to *some* valid WordPress user, without checking any capability - any authenticated user (including a Subscriber) could call every "secured" REST v1 route. Now requires `manage_options`, matching the plugin's own AJAX proxy. Reported by Patchstack.
- **SQL injection** - WooCommerce product-data field cleanup built its `DELETE` queries by string-concatenating client-supplied IDs into a `NOT IN (...)` clause with no escaping; a crafted ID could delete every row of the field table, not just orphans. Rebuilt with prepared-statement placeholders. Reported by Patchstack.
- **Privilege escalation** - A public form submission could set a client-controlled `acpt_form_user_id`/`_post_id`/`_term_id` field to update an *existing* WordPress user/post/term instead of creating a new one, with no ownership or capability check - an anonymous "create new user" form submission could overwrite an administrator account. Added `current_user_can()` checks before any update.
- **PHP Object Injection** - Hardened all 30 `unserialize()`/`maybe_unserialize()` call sites across the plugin (form metadata, relation-field sync, box/field-rename sync, form/block/permission builders, WooCommerce and WP All Import integrations) to reject embedded objects, closing a gadget-chain risk originally reported by Patchstack against 2 of these sites.
- **Stored XSS** - The meta-field sanitizer's allowed-tags list admitted ``, so `wp_kses`-based sanitization never actually stripped it from rich-text field output.

#### Meta Fields

- **Site-wide crash from an invalid `save-meta-group` operator** - A `belongs` rule with a missing/empty operator could be persisted with an empty value and then crash *every* subsequent read of that structure (admin, front-end, REST, every Ability) as soon as it was re-hydrated from the database. The operator is now validated and invalid rules are rejected gracefully, both when saving and when reading a pre-existing row (Ticket #1182).
- **"Autoincrement" ID field never got a value outside wp-admin** - An ID-type meta field only ever generated its value inside the wp-admin edit-screen form; a post created via REST, the Abilities API, an import, or `wp_insert_post()` directly permanently had no value for that field. The value is now generated automatically on save regardless of how the post was created, and a one-time migration backfills every already-existing post on update (Ticket #1181).
- **`get_acpt_fields()` cross-box field collisions** - Fetching every field across a whole meta group (no specific box - the call ACPT's native Etch integration uses for `{options.acpt}`) could silently drop entire boxes' worth of data: fields were keyed by their position *within* their own box, which resets to 0 for every box, so a later box's fields overwrote an earlier box's fields at the same position (Ticket #1174).
- **Gallery field losing images on drag-reorder** - Dragging to reorder a Gallery field's images in wp-admin could silently drop entries: the preview only rendered a thumbnail for attachments that still resolved (e.g. not deleted from the media library since being selected), and reordering rebuilt the field's saved value from only the *rendered* thumbnails, discarding anything without one - occasionally emptying the field entirely. A Gallery field nested inside a Repeater/Flexible block had a second, more reliable trigger: reordering located the wrong field's hidden input as soon as a page had more than one gallery or rows were added/removed. Also fixed "hide unless this field has a value" conditional rules never correctly detecting an empty Gallery/Audio (multiple)/Video (multiple)/Image Slider field on the initial page render, only on later live updates. (Reported on Facebook)

#### Abilities API

- **`ability_invalid_output` on `rest_base`** - `list-post-types`/`list-taxonomies`/`get-taxonomy` could fail output validation for any taxonomy or post type registered without an explicit REST base (e.g. WP core's `link_category`/`post_format`), since `WP_Taxonomy`/`WP_Post_Type::$rest_base` defaults to the literal boolean `false`, not `string|null` as declared. Fixed at the read layer so already-stored data self-heals, not just new syncs.
- **`acpt/save-post-type` defaulting `capability_type` to the post slug** - A settings payload that omitted `capability_type` explicitly (rather than omitting `settings` entirely) defaulted it to the post type's own slug, generating meta capabilities never assigned to any role - the resulting CPT was registered but invisible in wp-admin and rejected edits for every role, including administrator. Default is now `post`, matching WP core (Ticket #1170).

#### Integrations

- **GenerateBlocks Dynamic Data for multi-value media fields** - Video (multiple), Gallery, Image Slider, and Audio (multiple) fields had no Dynamic Tag provider and never appeared as usable dynamic data; only their single-value counterparts were supported (Ticket #1175).
- **Windows image URLs** - Image/media field URL-building used `DIRECTORY_SEPARATOR` (a backslash on Windows) to join URL segments instead of a forward slash, silently breaking meta box saves on Windows hosts (Ticket #1173).