Pods MCP for pods, field groups, fields and items

Defining a Pods relationship field that points at the right object

Most Pods MCP sessions that go wrong do so on relationship fields. A pick field needs three options before it is useful: pick_object and pick_val, which name what it points at (another pod, a post type, a taxonomy, users), and pick_format_type, which decides between a single value and multiple values. pods-get-field-type-schema lists those keys for the pick type, along with file_format_type for media fields and number_decimals for numbers, so the agent should call it before pods-create-field rather than guessing option names. The schema is a hint surface: Pods still accepts other option keys it recognises for a type.

When filling a relationship through pods-create-item or pods-edit-item, the value is an item id for a single pick and an array of ids for a multi pick. pods-get-item returns relationships the same way, as ids, so reading a book and writing its author back is a round trip with no lookup by title. Field names must not collide with WordPress query vars, which is why a field for a book's author has to be called something like book_author rather than author.

Querying Pods items without raw SQL

pods-list-items is the read owners lean on for reports, and its filters are deliberately narrower than Pods' own where clause. Each filter names a field (or a field.subfield path) and one of these operators: =, !=, the four numeric comparisons, LIKE and NOT LIKE (Pods adds the wildcards), IN and NOT IN with an array, and EXISTS or NOT EXISTS. Every value goes through prepared statements, REGEXP and RLIKE are not offered, and filters combine with AND only.

orderby accepts column references with an optional ASC or DESC, such as t.post_title ASC, and is validated because Pods writes a dotted orderby into SQL as given. A call returns at most a hundred items; pass fields to project only the columns you need when a pod carries a large WYSIWYG field. A question that needs OR, such as books by one author or in one series, becomes two calls the agent merges.

Renaming a pod or field is a migration, not an edit

pods-edit-pod accepts new_name, and Pods then renames the underlying post type, taxonomy or Advanced Content Type table. pods-edit-field takes new_name too. Both look like a label change in the request and are nothing of the sort: theme templates, Pods templates, shortcodes, saved queries and any code calling pods() or pods_field() with the old name keep using it. Whether existing stored values follow a renamed field on your storage type is something to confirm on a staging copy by reading an item with pods-get-item before and after, since none of the pods-* writes can be undone from the change log.

A safe order for a rename on a live site: export the Pods schema from Pods' own tools and take a database backup, rename on staging, search the theme and plugins for the old name, update those references, then repeat on production in a quiet hour.

Who can change a Pods schema through GoBuildWP

Every Pods ability is Pro and runs only for a user who can manage options. Read Only limits the agent to the inspection abilities, which is enough to document a site's content model: list every pod with its type and storage, then pull groups and fields for each. Production Safe allows schema and item writes; the four deletes are destructive and wait for confirm. pods-delete-group keeps the group's fields by default and only removes them with delete_fields true, so read the confirmation request for that flag before approving. The Pods reference lists every parameter.

• "Read only: document every pod on this site with its storage, groups and fields as a table."
• "Add a multi-select relationship from book to the author pod, check the pick options first, then link book 57 to authors 12 and 14."
• "List published events whose venue field is empty, newest first, showing only title and date."