Release v2.0.67
ACPT v2.0.67
Latest versionWhat's new in v2.0.67
ACPT v2.0.67 was released on . Trusted by more than 2000 customers Custom post types. See the full changelog below and compare with the complete version history.
Release details
Released
7.8 MB
File available
Changelog
Improved
- #### 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
Compatibility
- Requires WordPress
- 6.5