Validation

Built-in rules#

Validation is configured per field in the builder:

Required: the field must have a value before the editor can submit. Available on every field type.
Minimum / Maximum Length: character limits for text-based fields.
Validation Pattern (regex): the value must match a regular expression, e.g. ^[A-Z]{2}-\d{4}$ for an SKU format.
Validation Message: the error shown when the pattern fails. Leave it empty for a generic "has an invalid format" message.

Some types bring their own format checks on top: Email fields must contain a valid email address, URL fields a valid URL (lenient: www.example.com without a scheme is fine), and Number fields render with their configured min/max/step as native input constraints.

Client and server#

Length and pattern rules are enforced on both sides:

In the browser: invalid input is flagged before the post is submitted, so editors get immediate feedback.
On the server: the same rules run again on save. A value that fails validation is not persisted: the previous value stays in place and the field's error message is reported back.

The server is the source of truth: client-side validation exists for fast feedback, but an invalid value never reaches the database even if JavaScript is disabled or the request is hand-crafted. The same rules apply wherever fields are saved: the post editor, options pages, and front-end forms alike.