Structure

Conditional field display breaks your content model

By Holt

Conditional logic feels like good UX until you export

You add a checkbox: "This product has variants." When checked, three new fields appear: Size, Color, Material. When unchecked, they hide. Your form looks cleaner. Your content editors appreciate the reduced clutter. You pat yourself on the back.

Then you try to bulk-edit twenty products, and half your variant data disappears because the export didn't preserve the checkbox state. Or your API consumer requests all product data and gets inconsistent field presence. Or you migrate to a new CMS and discover that "conditional" meant "stored differently" in ways your migration script didn't account for.

Conditional field display creates phantom dependencies in your content model. The data exists, but its visibility depends on runtime evaluation of other fields. That runtime dependency doesn't travel with your content when you move it, export it, or query it outside the CMS interface.

Hidden fields aren't optional fields

If a field can be hidden, you're making an architectural claim: this field only matters when certain conditions are true. But your content model doesn't actually support conditional existence — it supports conditional display. The field is still there in your database schema. It still accepts values. It still needs validation rules.

When you hide "Variant SKU" until someone checks "Has variants," you're not making the SKU optional. You're making it invisible. Users can still populate it through CSV import, API calls, or by toggling the checkbox on and off. Your validation logic has to handle all three states: empty-and-hidden, empty-and-visible, populated-and-hidden. You've tripled your edge cases for the sake of a cleaner form.

Most CMSs implement conditional display as client-side JavaScript. The field exists in the DOM, gets submitted with the form, and lives in your database regardless of visibility. You haven't simplified your data model — you've added a presentation layer that obscures it.

Required fields become context-dependent landmines

The worst version of conditional display: required fields that only appear under certain conditions. "Event Date" is required if Content Type equals "Event." "Product Price" is required if you checked "Available for purchase." You've created validation rules that depend on reading multiple fields in sequence.

Your content editor creates an event, forgets to set the type dropdown, fills out everything else, hits save, and gets an error about a missing date field they never saw. Or they import fifty products, half marked as purchasable but missing prices, and your import fails without explaining which specific conditional requirement broke.

Required fields need to be unconditionally present. If "Event Date" only matters for events, you need an Event content type with a required date field — not a generic content type with conditional requirements. Type-specific fields belong in type-specific models, not hidden behind checkboxes in a universal form.

Bulk operations ignore your clever UI logic

Conditional display lives in your CMS's edit interface. It doesn't exist in:

  • CSV exports and imports
  • API responses
  • Database queries
  • Migration scripts
  • Search indexes
  • Third-party integrations

When you bulk-edit via CSV, you're editing the raw data model. All fields are present, all at once. Your conditional logic doesn't apply. Users populate fields that "shouldn't" be visible given other field values, creating data states your edit interface never anticipated.

Your search index doesn't know that "Internal SKU" should only appear when "Product Type" equals "Physical." It indexes everything. Users find products by searching internal SKUs, click through, and see a form where that field is hidden. The data exists, the UI hides it, and nobody understands why the search result doesn't match the edit screen.

Make fields optional or make them separate

If a field doesn't always need a value, mark it optional and leave it visible. Users can scroll past empty fields. They cannot scroll past fields that appear and disappear based on complex logic they have to reverse-engineer.

If a group of fields only applies to a specific content variant, create a separate content type. Events get an Event type with date fields. Physical products get a Physical Product type with dimension fields. You're not "duplicating" fields across types — you're giving each type the fields it actually needs, with appropriate validation, without runtime dependencies.

Conditional display optimizes for the edit interface at the expense of everything else that touches your content. Your edit UI is the least important place your content exists. Stop breaking your content model to make one screen slightly cleaner.

← All posts