As explained in the Statamic Docs, Blueprints are a key component to the content modeling process. They let you define the fields that should be available in the Control Panel and the way your data is stored.
Every resource will have it's own blueprint. Just like with collections, you can manage the blueprints in the Control Panel.
When configuring fields, make sure that the field handles in your blueprint should match up exactly with the column names in the database, otherwise bad things will happen. You'll also want to ensure the database column type matches the fieldtype you're trying to use (see Supported Fieldtypes).
Runway supports pretty much ALL fieldtypes available in Statamic, including Bard. As long as you have the correct fieldtype and the correct column type, everything should "just work"!
For simplicity, here's a table matching Statamic's Core fieldtypes with the correct column types:
Fieldtype | Column Type | Notes |
---|---|---|
Array | json |
|
Asset Container | string /json |
|
Assets | string /json |
|
Bard | string /json |
If 'Display HTML' is true , then Bard will save as a string . |
Button Group | string |
|
Checkboxes | json |
|
Code | string |
|
Collections | string /json |
If 'Max items' is 1 , column type should be string . Otherwise, json is what you want. |
Color | string |
|
Date | string /range |
Format is specified field configuration options. Ranges are should be stored as json. |
Dictionary | string /json |
If 'Max items' is 1 , column type should be string . Otherwise, json is what you want. |
Entries | string /json |
If 'Max items' is 1 , column type should be string . Otherwise, json is what you want. |
Form | string /json |
If 'Max items' is 1 , column type should be string . Otherwise, json is what you want. |
Grid | json |
|
Group | json |
|
Hidden | string |
|
HTML | - | UI only |
Icon | string |
|
Integer | integer |
|
Link | json |
|
List | json |
|
Markdown | string |
|
Navs | string /json |
|
Radio | string |
|
Range | string |
|
Replicator | json |
|
Revealer | - | UI only |
Section | - | UI only |
Select | string /integer /json |
|
Sites | string /json |
|
Slug | string |
|
Spacer | - | UI only |
Structures | json |
|
Table | json |
|
Tags | json |
|
Taxonomies | string /json |
|
Template | string |
|
Terms | string /json |
|
Text | string |
|
Textarea | string |
|
Time | string |
|
Toggle | boolean |
|
User Groups | string /json |
When the resource is the User model, you don't need to create a column for this fieldtype. |
User Roles | string /json |
When the resource is the User model, you don't need to create a column for this fieldtype. |
Users | string /integer /json |
|
Video | string |
|
Width | integer |
|
YAML | string |
Runway provides two fieldtypes to let you manage Eloquent Relationships within Statamic:
To find out more about Runway's fieldtypes, check out the Fieldtypes page.
To avoid needing to create a migration for every new field you add to a blueprint, fields can be stored within JSON columns.
To do this, you'll first need to configure the JSON column under the nested_field_prefixes
key in your config/runway.php
config file.
'resources' => [Order::class => ['nested_field_prefixes' => ['address',],],],
'resources' => [Order::class => ['nested_field_prefixes' => ['address',],],],
Then, when you're adding fields to your blueprint, simply prefix the column name, like shown below, and Runway will be smart enough to read/write from your JSON column. 🧠
-handle: address_street_name # Represents the street_name key, in the address column.field:type: textdisplay: 'Street Name'
-handle: address_street_name # Represents the street_name key, in the address column.field:type: textdisplay: 'Street Name'
Heads up! In order for Nested Fields to work, you'll need to define a cast for the JSON column in your Eloquent model.
protected function casts(): array{return ['address' => 'array', // or 'json', AsArrayObject::class];}
protected function casts(): array{return ['address' => 'array', // or 'json', AsArrayObject::class];}
Like Statamic Core, Runway supports the concept of Computed Fields. However, instead of the computed values being part of a callback in your AppServiceProvider
, they're accessors on your Eloquent model.
For example, if you wanted to have a full_name
field that's computed based on the user's first & last name, you'd do something like this in your User
model:
use Illuminate\Database\Eloquent\Casts\Attribute;public function fullName(): Attribute{return Attribute::make(get: function () {return "{$this->first_name} {$this->last_name}";});}
use Illuminate\Database\Eloquent\Casts\Attribute;public function fullName(): Attribute{return Attribute::make(get: function () {return "{$this->first_name} {$this->last_name}";});}
Then, in your user blueprint, you'd set the field's visibility to "Computed":
It's worth noting, Runway requires any accessors to be public
functions, otherwise the attributes won't be augmentable.