Create a custom field group

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.

What is this for?

Custom Fields turn your CMS into a structured-content authoring tool. You reach for a field group when you want content authors to fill in the same shape of data on every page of a given type — product specs on a product page, staff bio fields on a team page, FAQ question/answer pairs on a support page. Instead of asking authors to write raw HTML, you define the shape once in a field group; they fill in values on each post; visitors see a consistent rendering everywhere the shortcode lives.

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="staff_role"] anywhere in a Page, Blog post, Event description, or SG-Builder HTML block to render the author-supplied value.

Good use cases

Example 1: Acme Coffee Roasters — Product Specs group for Pages. Acme sells coffee beans on individual Pages, each describing one origin (Ethiopia Yirgacheffe, Colombia Supremo, etc). Marketing wants every product page to show the same shape: Roast Level, Origin, Tasting Notes, Weight, Bag Size. Create a field group named Product Specs. Add five Text fields with names roast_level, origin, tasting_notes, weight, bag_size. Tick the Page location. Set Status to Publish. Click Create Item. From now on, every Page edit screen shows a "Product Specs" panel with those five inputs. Authors fill them in per page. On the public page template, marketing pastes the shortcodes where they want the values to appear:

<ul class="product-specs"> <li>Roast: [custom_field name="roast_level"]</li> <li>Origin: [custom_field name="origin"]</li> <li>Tasting notes: [custom_field name="tasting_notes"]</li> <li>Weight: [custom_field name="weight"]</li> <li>Bag size: [custom_field name="bag_size"]</li>
</ul>

Visitors landing on /coffee/ethiopia-yirgacheffe see the author-entered values rendered inline — no HTML edits required for each new product.

Example 2: Acme Coffee Roasters — Staff Bio group for a Team custom object. Acme has a Team page with five baristas. They want to keep every bio consistent: headshot, role, Instagram handle, and an About paragraph. Create a field group named Staff Bio. Add an Image field headshot, a Text field role, a URL field instagram_url, and a Textarea field bio. If the site has a Custom Object called "Team Member", tick that location. Every team member's edit screen now exposes those four inputs, and the public team page template renders each card with the shortcodes.

Example 3: Acme Coffee Roasters — FAQ Repeatable group for Blog posts. Acme's long-form blog posts ("Why single-origin matters") often end with a Q&A. Create a field group named FAQ with a single Repeatable Fields field containing a Text subfield question and a Textarea subfield answer. Tick the Blog location. Now every Blog post edit screen has a "FAQ" repeater where authors click "Add Row" to append another Q/A pair — no theme changes required when a post needs 3 FAQs vs 12.

Example 4: Wholesale tier field on Products. Acme Coffee sells wholesale to cafes and restaurants. Their ecommerce products each have a minimum order quantity and a wholesale price that differ from the retail price. Create a field group named Wholesale Info. Add a Number field min_order_qty (label "Min. order qty", default 6), a Text field wholesale_price (label "Wholesale price per unit"), and a Textarea field wholesale_notes (label "Notes for wholesale buyers"). Tick the Products location (visible once ecommerce is configured). Authors fill in these fields on each product. 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>

Retail visitors see the standard price; the wholesale box is only visible because a design conditional wraps it — the field values themselves are always output by the shortcode wherever it is placed.

Example 5: Event date field on Blog posts. Acme runs monthly cupping events and announces each one in a Blog post. Rather than embedding the date in the body copy (which makes it invisible to templates), create a field group named Event Details. Add a Text field event_date (label "Event date", placeholder "e.g. Friday 9 May 2026, 6 pm") and a Text field event_venue (label "Venue", placeholder "e.g. Acme Roastery, Unit 4"). Tick the Blog location. Authors fill in the two fields when writing the announcement post. The blog template renders them in a call-out panel above the body copy using [custom_field name="event_date"] and [custom_field name="event_venue"] — dates stay consistent and scannable regardless of how the author writes the post body.

Example 6: Seasonal availability toggle on Pages. Some products are seasonal — "Summer Cold Brew Kit" is only available May–September. Create a field 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 (label "Availability note", placeholder "e.g. Back in May 2027"). Tick Page. Authors update the select on each product page as seasons change. The page template reads [custom_field name="availability_status"] and [custom_field name="availability_note"] to render an availability badge:

After creating your groups, they appear on the Custom Fields list with their field counts and status. Click a row title to open the group again and adjust fields — see Edit a custom field group.

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.
• 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.
• 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="Weight"] will not work — use [custom_field name="weight"].

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

• You are signed in to SGEN as an Administrator.
• You know which post-type(s) should get the fields — Page, Blog, Events, or a Custom Object you have already created.
• You have a shortlist of the fields you want in the group — names, types, and which are required.
• Plan the field names (slugs) in advance. Changing a name after posts have values orphans those values. Lowercase snake_case is the safest pattern.

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 (or open /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 Specs", "Staff Bio", "Event Details". This is the label you will see on the Custom Fields list.

2. Add fields

Click Add New Field to append a field row. For each field:

• Label — what authors see above the input on the post edit screen.
• Name — internal slug used in [custom_field name="..."]. Lowercase, snake_case, no spaces. Auto-generated from the label if left blank.
• Type — choose from Text / Number / Tel/Phone / URL / Textarea / Checkbox / Radio / Select / Image / Attachment / HTML / Group Fields / Repeatable Fields / Section Title / Section Information.
• Choices (Radio / Select / Checkbox) — one key : value per line. Leave the : off to use the same value as the key.
• Description — helper text shown under the input.
• Default value / Placeholder — pre-fill and hint text for authors.
• Is required / Is multiple — validation toggles.

Reorder fields by dragging the handle on the left of each row. Duplicate a field with the duplicate icon, remove with the trash icon. Collapse a field row with the pencil icon.

3. Pick Locations

Tick every post-type this group should attach to: Page, Blog, Events, plus any Custom Objects you have created. An untcked group is invisible — authors will not see the fields on any edit screen.

4. Set Status

• Publish — the group goes live immediately; the next time an author opens a matching edit screen, the fields appear.
• Draft — the definition is saved but hidden from author screens. Useful while you are still iterating.

5. Save

Click Create Item at the top of the sidebar. You land on the edit screen for the new group, ready to adjust or continue building.

What success looks like

• The Custom Fields list shows your new group with the correct status (Published or Draft), field count, author, and date.
• 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.

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. Also hard-reload the edit screen once — SGEN caches the inline field renderer.
• The shortcode [custom_field name="weight"] renders as literal text on the public page. The shortcode has to be inside a content block that renders shortcodes (a paragraph / text block), not an HTML block that escapes brackets. Also confirm the name matches exactly — [custom_field name="Weight"] with a capital W will not match a field named weight.
• 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 recover, or re-enter the data under the new name.
• 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.

Next step