Editing content

With content write abilities exposed, an assistant can fill in and fix content: set field values on posts, terms and users, create and update posts and terms, publish or unpublish, and delete.

Values go through the same validation as the editor, and every change is recorded with a way to undo it.

Good practice for bulk changes

A change across many entries is where an assistant saves the most time, and where a mistake costs the most. A careful run:

1. Counts first: "this touches 212 Books".
2. Tries one entry as a dry run, and shows you the result.
3. Works in batches under one task name, so the whole run can be reviewed and reversed together.

The vx-migrate-values prompt walks the assistant through exactly this.

What to know before exposing content writes

• An empty value clears a field. Only the fields the assistant sends change, but sending an empty value deletes what was there. Expose the matching read abilities too, so the assistant sees current values before writing.
• Some deletes can't be undone. Deleting a post moves it to the trash, which can be reversed. Deleting a post permanently, or deleting a term (WordPress has no trash for terms), can't be undone.
• Assistants don't check post locks. If someone has a post open in the editor while an assistant changes it, the editor doesn't warn either of them, and whoever saves last wins. Assistants can guard against changes they didn't see, but a person with the post open won't see the assistant's change until they reload.
• Assistants act with administrator rights. Content changes by an assistant aren't limited by the per-post permissions WordPress applies to other roles, because the connected account is an administrator.
• User accounts are out of scope. An assistant can set users' field values, but can't create or delete accounts, or change roles, passwords or email addresses.

Posts and their fields are separate changes

A post's own properties (title, content, excerpt, slug, status, author, date, parent, menu order and featured image) are changed separately from its VX field values. A task that needs both is two steps of one task.

Option pages

An assistant reads and writes an option page's settings by the page's key. A key the page has no field for is refused, and nothing is written.

Technical details for LLMs

• Writes: vx-framework/set-post-values (patch; id or ids), vx-framework/create-post (draft by default; core props + initial values; template assigns a page template the active theme offers for the post type, default for none), vx-framework/update-post (core props only; ids allowed only for status, author, date, parent, menu_order, featured_image, template), vx-framework/set-post-status (id / ids), vx-framework/delete-post (trash; force: true permanent; id / ids); vx-framework/set-term-values, vx-framework/create-term, vx-framework/update-term (name, slug, description, parent; no ids), vx-framework/delete-term (permanent); vx-framework/set-user-values (values only).
• Option page writes: vx-framework/set-option-page-values (patch; unknown keys refused; multi-fieldset writes may return partial: true + written_keys).
• Controls: dry_run, batch_id, strict: true (warnings become errors), if_match (hash over stored values and core properties; refused together with ids). Writing a field value doesn't change post_modified; use the hash to detect concurrent edits.
• Undo: restore_values descriptors carry the previous values of exactly the fields written (or none when too large). create-post → delete-post (trash); update-post / update-term → same ability with previous props; set-post-status / trash → previous status; force delete and delete-term → none; create-term → delete-term (permanent).
• Permissions: the only check is manage_options; no edit_post / publish_posts per object and no post-lock check. Count first with vx-framework/count-posts / vx-framework/count-terms / vx-framework/count-users.
• Different values per post: one vx-framework/set-post-values step per post inside vx-framework/apply-changes (≤ 25 steps).