- Article
- 3 minutes read
- Reviewed August 3, 2026
Choosing a field type is a data modelling decision, not only an interface preference. The type should represent the meaning of the value, support validation and remain usable by templates, queries and integrations.
A visually convenient control can still produce poor data if its stored format is inconsistent or difficult to migrate.
Text Fields
Use short text for names, codes and concise values. Use longer text for summaries or notes that do not require a full block editor.
Define length limits and whether formatting is permitted. A title-like value and an HTML-rich description should not share the same assumptions.
Numbers
Use numeric storage for values that must be calculated, compared or sorted, such as price, capacity, rating or duration.
Do not store currency symbols or units inside the numeric value. Store the number and unit separately when the unit can vary.
Dates and Times
Dates require a canonical storage format and a clear timezone policy. Display formatting can change by locale without changing the stored value.
An event may need start and end timestamps, an all-day flag and a timezone. One text field cannot reliably represent every case.
Booleans
A boolean represents true or false, such as Featured or Registration required. Define the default explicitly and distinguish false from missing data when that difference matters.
Select, Radio and Multi-Select Fields
Use controlled choices when values come from a small, stable set. Store stable machine values while allowing editor-facing labels to change.
If choices need their own archives, descriptions, hierarchy or reuse across many systems, a taxonomy may be more appropriate.
Media Fields
Store attachment IDs when the media belongs to the WordPress library. IDs allow WordPress to generate responsive images and retrieve metadata.
External media may require a URL and provider information. Validate allowed protocols and do not assume every URL is safe to embed.
Relationship Fields
A relationship field connects one object to another, commonly by ID. Define allowed target types, cardinality, ordering and what happens when the related object is deleted.
Avoid storing only a title or URL when the real relationship points to a managed WordPress object.
Repeating and Grouped Data
Repeated values such as opening hours or speakers need a schema for each row. Decide whether the repeated item is merely part of the parent or deserves its own post type.
Large or independently reusable repeated records often become easier to query and govern as separate objects.
Rich Text and Blocks
Use the main editor or a rich-text field when editors need formatted narrative. Blocks are powerful for composition but should not replace queryable domain fields such as dates or prices.
Computed and Read-Only Fields
Some values are derived from other data or synchronized from an external service. Mark them read-only where possible and document their source of truth.
Allowing editors to change a computed value manually can create disagreement between systems.
Field Selection Checklist
- What does the value mean?
- Is it single, multiple or optional?
- Does it need validation or a controlled vocabulary?
- Must it be sorted, filtered or calculated?
- Does it relate to another managed object?
- What format will APIs and exports use?
- What should happen when the value is missing?
- Can the field type be migrated without losing meaning?
Frequently Asked Questions
Should dates be stored as formatted text?
Use a canonical machine-readable value and format it for display. Human formatting should not be the only stored representation.
When should a select field become a taxonomy?
Use a taxonomy when values are reusable classification objects that need archives, hierarchy, descriptions or independent management.
Should relationships store URLs?
When the target is a WordPress object, storing its ID usually preserves the relationship better than copying its current URL.