Create a custom field group

In short. A custom field group is a named set of extra fields you attach to Pages, Blog, Events, or Custom Objects. Once published, those fields appear on the matching edit screens so authors fill in structured data without touching HTML. Values render on public pages through the [custom_field name=".."] shortcode. You define the shape once; authors fill it in per post.

On this page: What it is · Field types · Steps · Tips · Troubleshooting

How to extend Pages, Blog, Events, and Custom Objects with structured author-side fields

A custom field group is a set of extra fields you attach to one or more post-types — Pages, Blog, Events, or Custom Objects. Once published and assigned, those fields appear on the matching edit screens so content authors can fill in structured data without touching HTML. The field values then render on public pages through the [custom_field name=".."] shortcode. A single field group can be assigned to multiple post-types at once — one "Product Metadata" group can serve both Pages and a Custom Object with a single definition.

What is this for?

Use a field group when you want authors to fill in the same shape of data on every post of a given type — product specs, staff bios, FAQ pairs. Define the shape once; authors fill in values per post; the shortcode renders them consistently everywhere.

Every field group has four decisions:

• What fields? — label, internal name, type (Text / Number / URL / Textarea / Checkbox / Radio / Select / Image / Attachment / HTML / Group / Repeatable / Section Title / Section Information), and per-type options (choices, default, placeholder, required).
• Where does it show up? — the Locations checkboxes bind the group to Page, Blog, Events, and/or any Custom Object you have. An unassigned group is invisible to authors.
• Is it live? — Status Publish surfaces the fields on edit screens; Draft saves the definition but keeps it hidden.
• What does the public page show? — embed [custom_field name="material"] anywhere in a Page, Blog post, Event description, or SG-Builder HTML block to render the author-supplied value.

A typical small site with a few field groups in play reads like this across the list filter row. Published groups are live on author screens. Draft groups are saved but hidden from every edit screen until you flip them to Publish:

The create panel is one long form: Title at the top, then one row per field, then Locations checkboxes, then Status. The mock below shows the panel populated for the Product Details group. Click any field to see its hint:

Examples

Example 1 — Product Details (product pages). Create a group named Product Details, tick Page, and add these five fields:

Set Status to Publish and click Create Item. Every product page edit screen now shows a "Product Details" panel with those five inputs. Authors fill them in per product. On the public page template, place the shortcodes where the product details should appear. The block below is ready to paste into any SG-Builder HTML component or Text Editor paragraph:

<dl  class="product-details"> <dt>Materialdt> <dd>[custom_field  name="material"]dd> <dt>Sizedt> <dd>[custom_field  name="size"]dd> <dt>Care notesdt> <dd>[custom_field  name="care_notes"]dd> <dt>Colordt> <dd>[custom_field  name="color"]dd> <dt>Finishdt> <dd>[custom_field  name="finish"]dd>dl>

Visitors landing on a product page see the author-entered values rendered inline — no per-product HTML required. A product filled in by a teammate (content author) with Material "Cotton canvas", Size "Large", Care Notes "Machine wash cold, hang dry", Color "Natural", Finish "Matte" renders like this:

Example 2 — Staff Bio (Team Custom Object). Create a group named Staff Bio with an Image field headshot, Text role, URL instagram_url, and Textarea bio. Tick the "Team Member" Custom Object location. Every team member's edit screen exposes those four inputs; the public template renders each card via shortcodes.

Example 3 — FAQ Repeatable (Blog posts). Create a group named FAQ with a single Repeatable Fields field containing a Text subfield question and a Textarea subfield answer. Tick Blog. Authors click "Add Row" to append Q/A pairs — no theme changes required when a post needs 3 FAQs vs 12.

Example 4 — Wholesale Info (Products). Create a group named Wholesale Info with a Number field min_order_qty (default 6), a Text field wholesale_price, and a Textarea field wholesale_notes. Tick Products. The product page template renders:

<div class="wholesale-box"> <p>Min. order: [custom_field name="min_order_qty"] units</p> <p>Wholesale price: [custom_field name="wholesale_price"] / unit</p> <p>[custom_field name="wholesale_notes"]</p></div>

The wholesale box is shown conditionally by the template — the field values themselves are always output by the shortcode wherever it appears.

Example 5 — Event Details (Blog posts). Create a group named Event Details with a Text field event_date (placeholder "e.g. Friday 9 May 2026, 6 pm") and a Text field event_venue. Tick Blog. The template renders them in a call-out panel above the body copy — dates stay consistent regardless of how each author writes the post.

Example 6 — Availability toggle (Pages). Create a group named Availability with a Select field availability_status (choices: available : In stock / coming_soon : Coming soon / unavailable : Out of season) and a Text field availability_note. Tick Page. Authors update the select as seasons change; the template renders an availability badge:

After creating your groups, they appear on the Custom Fields list with field counts and status. Click a row title to adjust fields — Edit a custom field group. The list below shows the six groups above — four published, two in draft:

Scope

This flow covers: naming the group, selecting locations, adding typed field rows, and saving as Published or Draft. It does not set per-post values — authors fill those in on individual edit screens after the group is published.

Vocabulary

What NOT to use this for

• Do not use Custom Fields to collect visitor-submitted data.

The fields here are filled in by your admin team on the author side. For visitor-submitted forms (contact, lead capture, surveys), use the dedicated Forms area.

• Do not use Custom Fields for site-wide copy or chrome.

Header text, footer links, SEO defaults, and similar chrome belong in their own Settings panels or theme templates. Custom Fields is per-post data — it only exists on the specific post the author fills it in on.

• Do not change a field's Type after posts already have values.

If authors have filled in a Text field on 40 pages and you switch the type to Number, the existing text values stay in storage but may render blank or incorrect. Prefer adding a new field with the correct type and migrating the content manually.

• Do not rely on Custom Fields to hide sensitive data.

Anything an author types into a field is visible to anyone who can view the public page via its shortcode. Treat all stored values as public content.

• Do not use the field's Label text as a shortcode key.

The shortcode uses the internal name (slug), not the label. [custom_field name="Size"] will not work — use [custom_field name="size"].

How this connects to other features

• Pages / Blog / Events / Custom Objects — ticking a Locations checkbox attaches the group's fields to that post-type's edit screen. An author editing a Page sees the group's fields inline and fills them in per page.
• SG-Builder + Text Editor — the [custom_field name=".."] shortcode works inside SG-Builder text components and the basic Text Editor. Drop it in a paragraph or an HTML block and the value renders on the public page.
• Repeatable + Group Fields types — for multi-row data (FAQ pairs, team cards, testimonials) use the Repeatable type; for grouped-but-single data (address with street / city / postcode) use the Group Fields type. Both are configured like any other field inside the group editor.
• Settings → Custom Objects — if you need the same field shape to live on a non-standard post type, create a Custom Object first, then tick its location here. Pages / Blog / Events are always available without any extra setup.

Before you start

• Know your post-types — Page, Blog, Events, or a Custom Object already created on your site.
• Plan field names (slugs) before you create. Changing a name after authors have saved values orphans those values. Use lowercase snake_case: material, size, care_notes.
• For Select / Radio / Checkbox fields, write out choices ahead of time in key : Display Label format per line (e.g. light : Light). The key is stored; the Display Label is what authors see and what shortcodes output.
• For Repeatable or Group Fields, sketch the sub-field structure before opening the create panel — restructuring after authors have entered data is harder.

Where to go

1. Open the left navigation.
2. Select Custom → Fields to open the Custom Fields list at /sg-admin/custom_fields/.
3. Click + Add New in the top-right corner — or navigate to /sg-admin/custom_fields/add_new directly.

Steps — Create a field group

1. Name the group

In the Create a group of fields panel, set Title to something descriptive — "Product Details", "Staff Bio", "Event Details". This label appears on the Custom Fields list, on the author's post edit screen, and in the group's own edit panel header. Use a noun phrase that describes what the fields collect, not what they do.

2. Add fields

Click Add New Field to append a field row. Each row collapses to a header once you move to the next — click the pencil icon to expand it again. For each field, fill in:

• Label — what authors see above the input on the post edit screen. Use plain English: "Material", "Size", "Care Notes".
• Name — internal slug used in [custom_field name=".."]. Lowercase, snake_case, no spaces. Auto-generated from the label if left blank — but verify the auto-slug before saving, especially for multi-word labels.
• Type — choose the type that matches the data shape. See the table below.
• Choices (Radio / Select / Checkbox) — one key : Display Label per line. Leave the colon off to use the key as both the stored value and the display.
• Description — helper text shown under the input on the author's edit screen. Use it to guide authors: "Enter the primary fabric or material, e.g. Cotton canvas."
• Default value / Placeholder — pre-fill and hint text for authors.
• Is required — tick for fields that must have a value before the post can be saved.
• Is multiple — tick for checkbox groups where authors should be able to select more than one value.

Reorder fields by dragging the handle on the left of each row. Duplicate a field with the duplicate icon — useful when two fields share the same type and similar options. Remove a field with the trash icon — note this cannot be undone on an already-saved group without editing.

Field type reference — choose the right type the first time:

3. Pick Locations

Tick every post-type this group should attach to: Page, Blog, Events, plus any Custom Objects you have created. An unticked group is invisible — authors will not see the fields on any edit screen. The Locations list shows exactly the post-types your site has. If you expect to see a Custom Object here but it is missing, confirm the object was created and published under Settings → Custom Objects first, then reload the add-new screen.

4. Set Status

• Publish — the group goes live immediately.

The next time an author opens a matching post-type edit screen, the fields appear in an inline panel below the content editor.

• Draft — the definition is saved but hidden from every author screen.

Use Draft while you are still deciding on field names or types, before rolling out to the authoring team. You can switch to Publish at any time by editing the group.

5. Save

Click Create Item at the top of the sidebar. SGEN writes the group, assigns it an ID, and redirects you to the edit screen for the new group — ready to adjust fields or add more. The green save banner at the top of the screen confirms the write committed and shows the timestamp:

Tips for clean field groups

Settle field names before you involve authors. A field rename after authors have saved values orphans every stored value under the old slug. Map out slugs like material, size, care_notes before clicking Create Item — the auto-slug from the label is a good starting point, but confirm it.

Use Section Title fields to break long groups into chunks. A group with 12 fields is hard to navigate. Add a Section Title row to create a visual heading — "Product Details" / "Care Specs" — that separates the fields without storing any data.

Keep Select / Radio choices to five to eight. A dropdown with 25 choices is a usability problem. If a field genuinely needs that many options, consider whether it belongs in a Custom Object instead.

Draft first for complex repeatable groups. Repeatable Fields sub-field structures are harder to change after authors have entered data. Create in Draft, fill in a few test posts, confirm the shortcode output, then switch to Publish.

What success looks like

• The Custom Fields list shows your new group with the correct status (Published or Draft), field count, author, and date.

A site with six groups reads: All Fields (6) / Published (4) / Draft (2).

• Opening any Page / Blog / Event / Custom Object edit screen with a ticked location shows the group as an inline panel with your fields laid out as inputs.
• Filling in values on a post and saving makes [custom_field name=".."] shortcodes resolve to those values on the public page.
• Select and Radio fields render the Display Label (the value after the : in your choices list), not the stored key.

An author picking medium from the Size dropdown sees "Medium" on the public page.

• A field group with Status Draft does not appear on any author edit screen, regardless of which Locations are ticked.

Flip to Publish when you are ready for authors to see it.

What to do if it does not work

• The fields do not appear on my Page edit screen.

Confirm the group's Status is Publish and the Page location is ticked. Draft groups are hidden. Hard-reload the edit screen once — SGEN caches the inline field renderer on the first load of each session.

• The shortcode renders as literal text on the public page.

The shortcode must be inside a content block that renders shortcodes — a paragraph or text block — not an HTML block that escapes brackets. Also confirm the name matches exactly: [custom_field name="Size"] with a capital letter will not match a field named size.

• I renamed a field and now existing posts render blank.

Changing a field's name orphans the values stored under the old name. Rename back to the original slug to recover existing values, then enter the data under the new name on each post if a rename is truly needed.

• I see the old Label on the author edit screen after renaming.

Close and re-open the edit screen. Older browser tabs may cache the previous label render.

• My Select field shows the key (medium) instead of the label ("Medium") on the public page.

Check the choices list format — it must be key : Display Label per line with a space on each side of the colon. A missing colon or missing space causes the key to be used as the display value.

• My new group does not appear on the Custom Objects edit screen.

Confirm the Custom Object was created and published before you created the field group. If you created the group first, edit it and re-tick the Custom Object location — it may not have appeared in the Locations list yet when the group was originally saved.

Next step

• Edit a custom field group