Blueprints

# Entry

An entry blueprint is the standard content structure used to define areas of your website. The content structures and entries can be organised in different ways as we describe in more detail here.

The entry type supports multiple entries and should be used when no other variant applies.

handle: Team\Member
type: entry
name: Team Member

fields:
    name:
        label: First Name
        type: text

The following properties are supported by the entry blueprint.

# Entry Variants

While an entry type has no specific behavior, there are also several variants that can be used for organizing content. The following types are variants of an entry.

• entry is a basic entry for common purposes.
• single is a single entry with dedicated fields, eg: Contact Us Page.
• structure is a defined structure of entries, eg: Documentation Pages.
• stream is a stream of time stamped entries, eg: Blog Posts.

# Single Entries

The single type will force a single entry for each section definition. This is useful for one-off content, such as a Home page or Contact Us page. The following defines a Homepage section with a Welcome Message (welcome_message) text field.

handle: Homepage
type: single
name: Homepage Content

fields:
    welcome_message:
        label: Welcome Message
        type: text

# Structure Entries

The structure type allows multiple structured entries, allowing for parent-child relationships to exist. This is useful for nested content, such as a Documentation section. Entries of the type structure are sortable. Their sort order can be adjusted by dragging them in the list view. The following defines a Documentation tree section with an Article Content (article_content) markdown field.

handle: Docs\Article
type: structure
name: Documentation Article

fields:
    content:
        label: Article Content
        type: markdown

By default structures support unlimited nesting, however, you may specify a maximum depth for the tree using maxDepth in the structure property. In the next example there can only be a top level and a second level.

# ...
type: structure

structure:
    maxDepth: 2
    # ...

The following values are supported by the structure property.

# Stream Entries

The stream type is used for time-based entries that are often listed in chronological order. This is useful for publishing recent activity, such as a Blog section. The following defines a Blog feed section with a Post Content (content) rich editor field.

handle: Blog\Post
type: stream
name: Blog Post

fields:
    content:
        label: Post Content
        type: richeditor

The defaultSort property is used to set the default sorting column when the blueprint record is displayed as a list. This will be set to the published date by default.

handle: Blog\Post
type: stream
name: Blog Post

defaultSort:
    column: title
    direction: asc

# Content Groups

All entries optionally support the ability to define multiple content groups for a section. For example, a blog section may have a regular post and a featured post, and these are two entry groups.

Entry groups are defined by the groups property in the section blueprint file and different fields can be specified for each type. The selected group value is available as the content_group attribute on the record.

handle: Blog\Post
type: stream
name: Blog Post

groups:
    regular_post:
        name: Regular Post
        fields:
            # ...

    featured_post:
        name: Featured Post
        fields:
            # ...

# Custom Messages

Specify the customMessages property to override the default messages used by the interface. The values can be plain text or can refer to a localization string.

customMessages:
    buttonCreate: Create New Event

The following messages are available to override as custom messages.

# Disabling Required Fields

The entry record will require the title and slug fields to be populated before they can be saved, additionally, the slug field must also be unique. You may modify this functionality by overriding these fields in your blueprint. Either by setting the validation property to false or setting the hidden property to true and hiding it from the user interface. The following example will disable the validation for both fields and hide the slug field.

fields:
    title:
        validation: false

    slug:
        hidden: true

# Page Finder Configuration

By default, all entries are included in the page finder lookup values. This can be disabled by setting the pagefinder to false.

pagefinder: false

You may restrict the page finder context to only allow locating the page as a single item (e.g. Blog Post) or a list of items (e.g. All Blog Posts), or when set to all will display both.

pagefinder: item
pagefinder: list

The page finder will automatically resolve the id, code, slug and fullslug attributes and use them as replacements in the page URL parameters. You may specify custom replacements as an array using the pagefinder properties, including the optional context from above.

pagefinder:
    context: list
    replacements: []

Each replacement key should match a URL parameter name and use a dot notation path to the attribute value. Take the following URL example for a blog post page.

url = "/blog/post/:author/:category/:slug/:id"

The following replacements will set the :author parameter to the related author slug attribute value, and the :category parameter to the first related categories slug attribute value.

pagefinder:
    replacements:
        author: author.slug
        category: categories.0.slug

# Global

Globals are used to define globally available content for your website. The field values are often used in CMS layouts and contain settings, such as social networking links.

The following defines a Footer Config global with a Facebook Link (facebook_link) text field.

handle: Site\Footer
type: global
name: Footer Config

fields:
    facebook_link:
        label: Facebook Link
        type: text

The following properties are supported by the global blueprint.

# Mixin

Mixins are groups of fields that are used to avoid repetition when defining content structures. For example, a Location field may be used in several places, yet we can define it once using a mixin definition.

The following defines a Location collection with Country (country_code) and State (state_code) text fields.

handle: Fields\Location
type: mixin
name: Location

fields:
    country_code:
        label: Country
        type: text

    state_code:
        label: State
        type: text

The following properties are supported by the mixin blueprint.

# Using the Mixin

To include these fields in your entries, like any other form field, use the type of mixin and reference the UUID or handle in the source property.

_location_fields:
    type: mixin
    source: Fields\Location

See the Mixin field for more information on using mixins.

# See Also