Block presets

A fresh install hands you an empty constructor: you open a page, press "add block" and face an empty list. To get anything at all you first have to define a type with fields and write a template — developer work, not editor work.

Presets close that gap: one button turns "installed it and did not know what to do" into "installed it and built a page".

PageBlocks → Constructor → Blocks → the "Presets" button.

The starter preset is free and ships with the ordinary package.

Installing

Three steps, the same as for the component's seeds: pick a preset → read the plan → install. The plan is not ceremony: a preset writes into the constructor tables, and you should see the list of changes beforehand rather than discover it afterwards.

Installation is idempotent — it looks things up by name and creates only what is missing. A second run on a ready database reports "already there" and not a single "create".

Removal lives in the same place and also shows a plan first: you see how many types and how many blocks already placed on pages would go.

What is inside

Seven types. They were chosen to build a landing page in ten minutes and to show different field mechanics — not to make the list look long.

Type	Chunk	What it demonstrates
Hero	pageblocks.block.hero	media, a button, list layout
Rich text	pageblocks.block.richtext	rich text, column width
Cards	pageblocks.block.cards	a repeater with media inside a row
Gallery	pageblocks.block.gallery	a repeater of images
FAQ	pageblocks.block.faq	a repeater with rich text in a row
Call to action	pageblocks.block.cta	two buttons
Spacer	pageblocks.block.spacer	a utility block with no content

These are types, not filled-in blocks

A preset installs schemas with fields — the thing an editor assembles a page from. Ready-made blocks with text and images are the block library, a separate story for 3.1.

Repeaters

Cards, gallery and FAQ carry an items repeater field. Along with the blocks, the preset creates three constructor tables for their rows; the rows live in the shared pb_table_data, so a repeater needs neither its own migration nor its own model.

The gallery is built from a repeater rather than the "Gallery" field: galleryfield itself is paid while the preset is free, and a block with a lock inside it would be impossible to fill in.

Your own markup

Templates live in core/components/pageblocks/elements/blocks/ and are addressed by the chunk_path field of a block type.

To adapt the markup, copy the file somewhere of your own and point chunk_path at it. The component's files then stay untouched and an update can safely overwrite them. Editing a file inside the component directory survives exactly until the next update.

Styles live in assets/components/pageblocks/css/web/pb.starter.css and are built on the pb.blocks.css tokens: your theme overrides them on the same .pb-page wrapper.

Pictures in the add catalogue

A type's card shows a picture of its markup — otherwise a block is picked by name blind, and "Cards" in three columns and "Gallery" in three columns do not differ in words.

The path is stored in the preview column and filled in by the preset installer. The field is optional: a type defined by hand renders in the same card without a picture.

The seed as a second entrance

Useful where nobody will press a button: automated staging builds, a run against a clean database before a release.

# plan
php core/components/pageblocks/vendor/bin/phinx seed:run \
  -c core/components/pageblocks/src/phinx.php -s StarterBlocksSeed

# write
PB_APPLY=1 php core/components/pageblocks/vendor/bin/phinx seed:run \
  -c core/components/pageblocks/src/phinx.php -s StarterBlocksSeed

PB_REMOVE=1 switches both steps to removal. Clear the MODX cache afterwards.

On shared hosting the button is the safer route

A seed needs the CLI, and a number of hosts disable exec(). The button runs in the same process as the manager and does not depend on a shell at all.