Blueprints ​

Table of Contents

• Creating & managing blueprints
• Supported Fieldtypes
• Eloquent Relationships
• Generating migrations from your blueprints
• Generating blueprints from your database
• Computed Fields

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.

Creating & managing blueprints

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).

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 'Allow multiple' 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.
Entries	string/json	If 'Allow multiple' is 1, column type should be string. Otherwise, json is what you want.
Float	float
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
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
Belongs To	bigInteger	Usually bigInteger or integer but depends on personal preference.

Eloquent Relationships

Runway provides two fieldtypes to let you manage Eloquent Relationships within Statamic:

• Belongs To
• Has Many

To find out more about Runway's fieldtypes, check out the Fieldtypes page.

Generating migrations from your blueprints

If you’ve already created a blueprint for your model(s) and still need to do the database side of things, Runway can help!

Runway can automatically generate migrations for your models, based on the fields defined in your blueprint, and their configurations.

To generate a migration for a specific blueprint:

php please runway:generate-migrations resource-handle
php please runway:generate-migrations resource-handle

You may also run this same command for all resources pending a migration.

php please runway:generate-migrations
php please runway:generate-migrations

Generating blueprints from your database

If you've already got an Eloquent model setup, Runway can help you turn it into a blueprint!

Before you can generate blueprints, you'll need to have migrated your database already.

As well as having your model setup, you will also need to add the resource(s) to your config/runway.php config.

To generate a blueprint for a specific resource:

php please runway:generate-blueprints resource-handle
php please runway:generate-blueprints resource-handle

You may also run this same command for all resources:

php please runway:generate-blueprints
php please runway:generate-blueprints

Computed Fields

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":