Think of blueprints as stencils for your content. They control what fields users get to work with when publishing content, as well as the schema of the data developers will be tapping into to build the front-end of your site.
Each blueprint belongs to an item:
- You can define multiple Blueprints for collections, and each entry will have the opportunity to choose from one of them.
- Same goes for taxonomies and their terms.
- Global sets, Asset containers, and Forms each get their own Blueprint.
- Users all share a Blueprint.
There are 3 ways to create blueprints:
- In the respective areas of the control panel. For instance, the collections area will let you define its blueprints.
The forms area will let you define its blueprints, and so on.
- In the Blueprints area of the control panel. This page serves as a hub to jump over to managing blueprints in various areas.
- Creating a YAML file in the appropriate place within
resources/blueprints/. More on that in a moment.
Once created, you can begin to define fields and the sections that hold them. If you have more than one section, each becomes a tab in the publish form.
Whether you manually create your blueprint's YAML file, or use the control panel, they will all end up as YAML files in the
Collections and Taxonomies have their available blueprints organized in subdirectories named after their collections.
When you create an entry or term, you will be able to choose which blueprint to use (if there are multiple).
Globals, Asset Containers, and Forms can only have one blueprint per item, so they are organized into their own subdirectories, where each YAML file is the handle of the item.
All users will share the same blueprint, and it hangs out in the root of the directory.
It’s possible to have fields be displayed only under certain conditions. For example, you may only want to show a caption field if an asset field has an image selected, or a whole block of fields if a toggle switch is enabled.
To learn what's possible and how implement the various rules, head over to the article on conditional fields.
At its most basic, a blueprint has an array of sections.
A section has a handle, a display name, and an array of fields:
sections:main:display: Mainfields:-handle: contenttype: markdownmeta:display: SEO Metadatafields:-handle: meta_titletype: text-handle: meta_descriptiontype: textarea
A section's fields can be comprised of references to fields in fieldsets (so you can reuse fields) or inline field definitions.
You will likely want to pre-configure reusable fields to pull into your blueprints.
For example, you might have a rich text field configured with all your favorite buttons, which you've called
content and stored in the
You can pull it into your blueprint like so:
fields:-handle: my_content_fieldfield: common.content-handle: another_content_fieldfield: common.content
This way, you are free to reuse the same field as many times as you like. Update the field in the fieldset and it will be reflected across all your blueprints.
You may customize a referenced field by adding a
config array. Any keys found in this will override whatever was defined in your fieldset.
fields:-handle: my_content_fieldfield: common.contentconfig:display: My Content Fieldvalidate: required|max:200
validate would replace whatever was defined in the fieldset.
Note: This only applies to referenced fields. For inline fields, you can just set everything right there.
Fieldsets still exist in Statamic 3! They serve to create reusable sets of fields, just like v2. You may import an entire fieldset at any point by using the
import key, for example:
# blueprintfields:-import: surveyprefix: favorite_-import: surveyprefix: least_favorite_
# the survey.yaml fieldsetfields:-handle: foodtype: text-handle: food_reasontype: textarea
Doing the above would result in a blueprint like this:
fields:-handle: favorite_foodfield:type: text-handle: favorite_food_reasonfield:type: textarea-handle: least_favorite_foodfield:type: text-handle: least_favorite_food_reasonfield:type: textarea
It would bring every field inline and prefix each field's handle appropriately.
If you omit the
prefix you won't be able to import them more than once at the same level because they would have the same handle and overwrite each other.
Fields can have various validation rules applied to them, enforcing the need for content creators to fill them out in a specific way before saving or publishing.
While configuring a field, switch to the Validation tab where you can choose from any built in Laravel rule.
In this screenshot, you can see that the field has an
min:4 rule which means you can only type letters and dashes, like a slug, and that it
must be at least 4 characters. You have plenty of options to be creative and confident that your data will be entered the way you need it to be.
Here's a peek at how that YAML is structured.
-handle: your_fieldfield:type: textvalidation:- alpha_dash- 'min:4'
If you're interested in customizing user password validation, you can read about that here.
Being the most common type of validation rule, we give you a shortcut for that. Simply toggle it on, or add
required: true to the YAML.
The Grid fieldtype lets you define a set of sub-fields, which it will allow you to repeat as many times as you like.
You should define its fields using the blueprint field syntax. This will allow you to reference other fields and/or import entire fieldsets.
links:type: gridfields:-handle: urlfield: links.url-handle: textfield: links.text-handle: externalfield: links.external
While conditional fields allow you to control field visibility on the publish form, you may also customize column visibility on entry listings in the control panel.
This hides the field column from entry listings, which can be useful for toggle fields etc, which may never make sense in the context of an entry listing.
This will hide the field from entry listings by default, but still allows a user to toggle visibility using the column selector, and save those column preferences for his/her preferred workflow.