Until now every content module re-invented field handling: an ACF-style prototype in Pages, ad-hoc fields in Blog. As a result mass-assignment protection (Manifesto Law 5.3), XSS sanitisation and the flat field index (Law 6.3) were implemented inconsistently in each module. The Field API closes that gap.
Concepts
- Bundle — the Node::type value (post, page, portfolio). Fields attach to a bundle.
- Field type — code; defines normalize / validate / index / settings schema. 14 core types ship: Text, Textarea, RichText, Boolean, Integer, Decimal, Email, Url, Date, DateTime, Select, EntityReference, Image, File.
- Field definition — which field on which bundle: stored in cp_field_definitions, editable at runtime from AACP.
- Widget / Formatter — turn a field into a form control and into safe HTML.
Security
FieldValueNormalizer writes only keys backed by a FieldDefinition; raw request arrays are never merged straight into Node::data. RichText goes through a sanitiser, every other formatter escapes. Per-field view/edit capability checks apply both on the form and on display.
Performance
Type registration happens at compile time (zero runtime cost). Field definitions are cached per bundle. Reference fields resolve in a single query per target type via ReferenceBatchLoader — no N+1 in lists. Fields flagged queryable are written to the existing flat index (node_field_index) and queried independently of the database engine.
Administration
From /aacp/fields you pick a bundle, add a field, fill a dynamic settings sub-form driven by the type picker, and order by weight. Capability: system.fields.manage.
Modules consume this API — the code stays in the module, exactly as they already consume #[CpApi] and the Hook system.
Comments (0)
No comments yet. Be the first to write one.
Leave a comment
Your comment will appear after it is reviewed.