From Custom Fields → Add New in the admin, a field group starts as just a name and a blank list — everything else is adding fields to it one at a time.
Each field needs a Field Label (what an editor sees — "Client Name"), a Field Name (the key used to read it back in code, auto-filled from the label but worth checking), and a Field Type from the list in the previous lesson.
Get the Field Name right early
Field Name and Field Label look similar but do different jobs — the Label is what an editor sees, the Name is what your template code refers to (get_field( 'client_name' )). Renaming a Label later is free; renaming a Name after fields have real data in them means updating every template that reads it.
A field group does nothing until it's told where to appear — the Location Rules section at the bottom, built as a simple "Show this field group if..." condition:
Show this field group if
Post Type is equal to ProjectLocation rules can combine multiple conditions, and can target far more than just a post type — a specific page template, a taxonomy term, even a user role. For a project-specific field group, though, "Post Type is equal to Project" is usually the whole rule.
For the project post type from earlier, a reasonable field group might be:
| Field Label | Field Name | Type |
|---|---|---|
| Client Name | client_name | Text |
| Completion Date | completion_date | Text (or Date Picker, if available) |
| Project Gallery | project_gallery | Gallery / Repeater of Image fields |
Save the field group, open (or create) a project, and those three fields now appear right below the content editor — ready to fill in. The next lesson gets that data back out, into an actual template.