=== MetaBench ===
Contributors: silver222
Tags: custom fields, post meta, term meta, metadata, developer
Requires at least: 6.0
Tested up to: 7.0
Requires PHP: 7.4
Stable tag: 1.0.1
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

A workbench for metadata. Search, filter, sort and edit custom fields for posts and terms from one fast panel.

== Description ==

MetaBench replaces the cramped core Custom Fields box with a panel built for
sites that actually have a lot of metadata.

* **Search** across both keys and values, with matches highlighted as you type.
* **Filter** by value type — text, number, long text, array, JSON or empty.
* **Sort** by key, by value size, or by raw database order.
* **Edit in place**, with a textarea for long values and JSON editing for
  serialised arrays.
* **Rename, create and delete** fields, each independently switchable.
* Works on **posts and terms**, on whichever post types and taxonomies you
  enable.
* Works in the **block editor and the classic editor** with no duplicated UI.

= Permissions =

For ordinary meta keys, every read and write goes through the per-key
capabilities that core derives from `register_meta()` auth callbacks. A user who
cannot edit such a field through core cannot edit it through MetaBench either.

Protected keys — those beginning with an underscore, where ACF, SEO plugins and
WooCommerce keep their data — work differently, and the difference is worth
understanding.

`map_meta_cap()` denies `edit_post_meta` on a protected key for *every* role,
including administrators, unless a plugin has registered an `auth_..._meta_...`
filter for that specific key. That blanket denial is aimed at untrusted REST and
XML-RPC callers, and it makes the core capability unusable as a gate for a
deliberate administrative tool.

MetaBench therefore gates protected keys separately. They are listed and
editable only when **both**:

1. "Show protected fields" is switched on in the settings, and
2. the user holds `manage_options` (filterable via
   `metabench_protected_capability`).

This is an intentional step past the core denial, kept as narrow and explicit as
possible. If you do not want that behaviour on your site, leave the setting off
— which is the default — and MetaBench will never touch a protected key.

= Translations =

MetaBench ships translated into German, Spanish, French, Italian, Japanese,
Dutch, Polish, Brazilian Portuguese, Russian, Ukrainian and Simplified Chinese,
covering all 119 translatable strings.

Every string the JavaScript panel displays is defined in PHP and handed to the
browser through `wp_localize_script()`, so the whole interface translates from a
single `.po` file with no JavaScript build step and no separate JSON language
packs.

To retranslate or add a locale, edit the `.po` file in `languages/` with Poedit
or any gettext editor, then recompile:

    wp i18n make-mo languages/ languages/
    wp i18n make-php languages/

After changing translatable strings in the source, regenerate the template with
`wp i18n make-pot . languages/metabench.pot --domain=metabench`.

= For developers =

Filters:

* `metabench_settings` — the effective settings array.
* `metabench_required_capability` — the capability gating the panel.
* `metabench_protected_capability` — the capability gating protected keys.
* `metabench_available_post_types` / `metabench_available_taxonomies` — the
  choices offered on the settings screen.
* `metabench_get_items` — the rows returned for an object.
* `metabench_validate_key` — return a `WP_Error` to block a write.

REST routes, all under `metabench/v1`:

* `GET    /fields/<object_type>/<object_id>`
* `POST   /fields/<object_type>/<object_id>`
* `POST   /fields/<object_type>/<object_id>/<meta_id>`
* `DELETE /fields/<object_type>/<object_id>/<meta_id>`

== Installation ==

1. Upload the `metabench` folder to `/wp-content/plugins/`.
2. Activate the plugin through the Plugins screen.
3. Visit **Settings → MetaBench** and enable the post types and taxonomies you
   want the panel on.

== Frequently Asked Questions ==

= Do changes save when I update the post? =

No. Each field saves immediately over the REST API, independently of the post.
That means you can fix one meta value without publishing unrelated draft edits,
but it also means there is no undo — the panel says so beneath the table.

= Why can I not see my ACF fields? =

ACF stores its values in protected keys beginning with an underscore. Enable
"Show protected fields" under Settings → MetaBench, and note that only users
with `manage_options` will see them. Editing those by hand can desynchronise
ACF's own field references, so change them only when you know what a key does.

= Why is one of my fields read only? =

Either you lack the capability for that key, or the stored value is a
serialised PHP object. Objects cannot round-trip through the JSON editor
without risking data loss, so MetaBench shows them but refuses to write them.

= Does it handle duplicate meta keys? =

Yes. Rows are addressed by `meta_id`, so several rows sharing one key are
listed and edited individually rather than collapsed into one.

== Changelog ==

= 1.0.1 =
* Hardened deserialization of stored meta values so a protected-key payload
  can no longer instantiate arbitrary PHP objects on read.
* Corrected a docblock that claimed object-cache caching the code doesn't do.

= 1.0.0 =
* Initial release.
