Fields
WordPress Core
Core fields ContentGuard can target in V1.
ContentGuard can target these WordPress Core fields in the Rule Builder and on supported save paths:
| Field | Catalog type | Notes |
|---|---|---|
| Title | text | Requires post type support for title |
| Content | wysiwyg | Requires editor support; HTML is stripped for evaluation |
| Excerpt | textarea | Requires excerpt support |
| Slug | text | Available when the post type exposes permalink UI (public or publicly queryable) |
| Featured Image | true/false-style presence | Requires thumbnail support; evaluated as present or absent |
| Author | text | Requires author support; compared as the author user ID |
Where they appear
Core fields show under the WordPress group in the Rule Builder for post types that support them. Availability is supports-based: if a custom post type does not support excerpts or featured images, those fields do not appear for that type.
Editors
ContentGuard validates Core fields in:
- Classic Editor — blocking validation before publication/save on supported paths
- Block editor (Gutenberg) — Core validation can block through WordPress REST responses, with ContentGuard feedback in the editor
Behavior is the same rule model in both editors; the notice surface differs.
Stored vs incoming values
On save, ContentGuard evaluates incoming request values for the fields present in the save payload. It does not invent omitted fields or auto-generate slugs.
When reading existing posts (including Audit), ContentGuard uses stored post values:
- Content — tags are stripped; whitespace-only or empty Gutenberg markup is treated as empty
- Featured Image — missing or invalid thumbnail IDs are empty (
false); a positive attachment ID is present (true) - Author — user ID
0/ missing is empty; otherwise the ID string is compared
Prefer empty / not empty and Required for presence checks. Featured Image is presence-oriented rather than a media library picker integration.
Post type limitations
Internal and system post types do not expose Core fields for rules, including for example: attachments, revisions, nav menu items, templates, global styles, navigation, font faces/families, and ContentGuard’s own rule post type.
Editable custom post types participate when they are not in that excluded set and when each field’s supports (or permalink UI for Slug) is available.
Not exposed in V1
ContentGuard does not currently expose other Core surfaces as rule targets—for example categories, tags, custom taxonomies, comments, or arbitrary meta keys outside the ACF catalog.