Reference

This document lists every configuration key in config/cms.php and every console command the package ships, with each key's default and each command's options and effect. It is written for a developer looking up a specific key or command. The topic document linked from each section explains the behavior in depth.

The tables are maintained by hand from config/cms.php and the command classes in src/Console/. After an upgrade, compare the published config file with config/cms.php in the package, which is the authoritative list of keys and defaults.

---

config/cms.php

The config file is published by php artisan vendor:publish --tag=cms-config, or by cms:install. Publishing is optional: the package's own file is merged into the application's configuration whether or not a copy is published.

A published config file does not receive keys added in later releases. mergeConfigFrom merges only the top level of the array, so a published file's blocks array replaces the package's blocks array entirely, and a key the package adds to blocks in a later release is absent from the merged result. See Pitfalls. After an upgrade, compare the published file with this table.

License

Panel and routing

Inline editing

Delivery API

The delivery API is disabled by default and requires token authentication when enabled. See The delivery API.

Webhooks and notifications

Webhooks and notifications use two separate lists. A rebuild webhook is sent on every change, while a notification is sent only for the events a person chose to be told about. See Notifications.

Caching

See Caching.

Media

The three image conversions are not configurable. See Media.

Dashboard

The four default widgets are ContentStatsWidget, EditingActivityWidget, RecentlyEditedWidget and AwaitingPublicationWidget, all in the Mcg\FilamentCms\Widgets namespace. Together they show what is published, what is awaiting publication, and recent editing activity.

Assets

The key is the top-level vite.entries, not theme.vite.

Navigation and menus

Theme

See The design system.

Layouts, previews and versions

See Layouts.

Draft view

See Drafts and previews.

Multilingual and multi-site

See Multilingual sites.

After enabling locales, run php artisan cms:locales:backfill. Rows written before the feature was enabled carry an empty locale.

Snippets and layout areas

Forms

See Forms.

Tags, sitemap and feed

The sitemap has three behaviors that are not configurable:

1. It skips anything marked noindex. Listing a page while telling crawlers to ignore it is a contradiction that Search Console reports as an error. Snippets are absent because they have no URL.
2. It dates each entry from the published version's timestamp, never from the content row's updated_at. A cache stamp that updates updated_at is not a change to the page, and reporting it as one leads crawlers to disregard the date field.
3. It lists the homepage at / with priority 1.0, regardless of what its content type's sitemapPriority() returns.

/sitemap.xml and /robots.txt are cached with a Cache-Control max-age header instead of the page cache, because the page cache keys on a content id and neither response has one.

Structured data

The publisher node is built from the organization JSON column on site_settings, together with the site name, logo, tagline and social links stored in the same table. The page node's @type comes from ContentType::structuredDataType(), which a page can override with seo.page_type, and seo.structured_data merges hand-written JSON-LD over the result. See Content type reference.

Cookie consent

Answers are stored in localStorage under the key cookie_consent, as a map of category key to boolean. Every change dispatches a cookie-consent-updated window event that carries the map.

The package acts on one category only. It acts on the answer for the category named by consent.analytics_category, and reports every other category through the cookie-consent-updated event for the application's own code to act on.

The analytics category was previously the fixed string analytics. Renaming the category to measurement in Site settings left the scripts waiting on a key that no answer carried: the banner displayed correctly, the visitor consented, and the analytics scripts never ran, with no error. The category can now have any key, provided consent.analytics_category names it. Site settings shows a warning when analytics scripts are present and no category has the configured key.

Permissions

See Permissions.

The package never defines an ability. Abilities::all() lists every ability it checks. The MCP server is outside this system: it authorizes once at connection and then acts with full authority.

Content types and blocks

See Content types and Block reference.

Registration order is built-in blocks and types, then register, then discovery, and a later registration replaces an earlier one with the same key. A host application uses this order to replace a core block or the built-in Page type without modifying the package.

The map block

The map block itself has no settings. It embeds OpenStreetMap, which requires no API key, account or cookie, so there is no provider to choose and no consent category to set. The keys below configure the address lookup behind the block's Find button. The lookup is the only part of the block that sends a request to another service, and it runs only when an editor presses Find, never on save or on render.

MCP server

See The MCP server.

Reordering and deleting blocks are never gated. Those tools cannot introduce markup, and gating them would make a page that contains an html block impossible to rearrange over MCP.

---

Console commands

The package ships 18 cms:* commands, registered in FilamentCmsServiceProvider from the classes in src/Console/. Two further commands, mcp:start and mcp:inspector, come from laravel/mcp.

Input handling

Three rules apply to every command:

1. A missing required argument is prompted for, not rejected. cms:make-block with no name asks for one, validates the answer before writing anything, and then asks about the options that go with it. cms:mcp-token with no user searches users by email address instead of printing the user table.
2. Prompts appear only in an interactive terminal. Every prompt is behind a check that the input is interactive. Under the scheduler, in CI, or with --no-interaction, no command waits for input: it either proceeds or exits with a non-zero status. The two commands the package schedules itself are unaffected by prompts.
3. Every prompted value can be passed as an argument or option. A script never depends on a prompt. A command invoked with all its arguments behaves as it did before prompts were added, because passing the arguments suppresses the prompts.

The destructive commands also accept --force, which skips their confirmation, for an unattended run in an interactive environment.

Installing and licensing

A value passed with --admin-password= is saved in the shell history. Enter the password at the prompt instead.

Generators

Each generator writes files into the host application, not into the package.

Run without a name, a generator asks for one and rejects a name that is not a valid PHP class name before writing any file. It then asks about the generator's own option: Livewire or not for a block, nesting or not for a content type, the regions for a layout, and a partial or not for a skin.

A generator refuses to overwrite an existing file by default. In an interactive terminal, the refusal is asked as a question, so regenerating a file does not require retyping the command with --force. With --no-interaction, the refusal is an error with a non-zero exit status, which prevents a CI job from overwriting a file nobody reviewed.

Scaffolding a block from a description

cms:make-block --interactive asks what the block holds and writes a complete block from the answers, instead of a stub with one field. Running cms:make-block with no arguments offers the same option.

The first question determines most of the generated file. It has three answers:

The answer changes the schema, every validation key, the defaults and the structure of the view.

Answer Other blocks for any block structured like tabs or columns. A repeater gives every row the same fields, whether a row needs them or not; container blocks exist to let each row hold different content, and a repeater would reintroduce that limitation. After Other blocks, the generator asks whether the container holds one list or one list per row.

For the other two answers, the generator asks which fields one item has, whether the block has its own heading above the list, whether the editor may choose the column count, and which category the block appears under in the block picker.

The generator offers four field types, and each brings the supporting code it requires:

The generator's purpose is consistency between four declarations. A block declares each field in four places: schema(), rules(), searchableText() and the view. Nothing checks that the four agree. If rules() names a field that schema() does not define, that rule never validates anything and no error is raised. Generating all four from one description keeps them in agreement.

The generated block is a starting point intended for editing. When changing it, keep schema(), rules() and the markup naming the same fields.

The Livewire and class-based kinds receive the same questions. Answering yes to the Livewire question does not skip the description. A single-file Livewire block stores the same fields; it declares them as public properties and reads them from $this instead of from the view's scope. The generated code differs in two ways:

1. A single-file block has no withView() method, so a value that must be resolved before rendering (a media id into a file, a stored link into a URL) is resolved in a #[Computed] property, and the markup loops over $this->rows instead of the stored collection.
2. The four methods a block class overrides are closures on the BlockDefinition instead: mediaIdsFrom(), contentIdsFrom(), searchableText() and itemLabel(). They give a Livewire block the same capabilities as a class-based block. Without them, a single-file block holding a media picker reports no media ids, and its images appear unused to the media usage report and to the delete guard.

A hand-written single-file block can set the same closures. A definition that sets none of them behaves as it did before the closures existed.

Operations

The two automatically registered commands require Laravel's scheduler to be running; nothing needs to be added to routes/console.php. Areas created by cms:layout-areas are empty and unpublished, and a shared region renders nothing until its area has content and is published, so running the command is not the last step.

Commands not for a schedule

None of cms:mcp-token, cms:demo and cms:placeholders belongs in an unattended job: cms:mcp-token prints a credential to stdout, and cms:demo and cms:placeholders both write content. mcp:start is a long-running process that exchanges protocol messages on stdin and stdout.