Model constructor
Create a table, get a migration and a model — from the manager, without opening an editor. PageBlocks → Constructor → Migrations.
Sudo only
All of its routes sit behind the SudoOnly middleware. This writes files into core/App/ and runs migrations against the live database, so it is not something a content manager should reach.
What it produces
One row in the constructor turns into three things:
- a Phinx migration in
core/App/Database/migrations/; - after it runs —
core/App/Models/Base<Model>.php, generated from the table's real columns; core/App/Models/<Model>.php— only if it does not exist yet.
The split matters: the base class is regenerated on every run, the child is written once and never touched again. Your methods, relations and casts go in the child.
Do not edit the Base model
It is overwritten the next time a migration for that table runs, without warning.
A row
| Field | What it is |
|---|---|
name | Human-readable name, shown in the list |
table_name | Table, without the prefix |
model_name | Model class to generate. Empty means "migration only" |
table_comment | Comment on the table |
type | What the migration does — see below |
status | pending, executed, rolled_back, failed |
with_constructor_fields | Add the constructor tail — data, menuindex, published_at |
with_timestamps | Add created_at / updated_at |
with_soft_deletes | Add deleted_at |
The three flags default to on: a table made here is ready for publishing, ordering, the basket and constructor fields without any extra thought.
Types
create_table, drop_table, add_column, change_column, drop_column, rename_column, add_index, drop_index, add_foreign_key, drop_foreign_key.
Columns are described in the child grid — type, length, precision, nullable, unsigned, default, comment, after, and an index with its kind (index, unique, fulltext). Foreign keys are a separate grid, with on_delete and on_update.
Running one
Execute writes the migration file, runs Phinx against the site layer (core/App/phinx.php, log pb_app_migrations), and then generates the model. Status becomes executed and executed_at is filled.
Rollback is only allowed for a migration in executed status — anything else answers 405.
The current shape of a table is not read from the database schema but recomputed from every executed migration for that table. That is what lets add_column know what the model already has.
A dropped table keeps its files
drop_table deliberately does not touch core/App/Models/. Removing the table is a schema decision; deleting your model and everything you wrote in it is not something the constructor should decide for you.
When two migrations collide
Two separate "add column to pb_cargo" rows would both want the same class name. The service checks the existing files and disambiguates, so a second migration for the same table does not overwrite the first one's file.
Where this fits
The model constructor writes into the site layer, never into the component. That is why it is safe: a component upgrade cannot overwrite what it generated, and what it generates cannot end up in somebody else's installation.
For the layout of migrations and the two Phinx configs, see Migrations; for what the generated model can do, see Models.