Console

Install

Publish config and public assets:

Publish example pages too:

Overwrite published files:

Doctor

Inspect Adminix configuration, pages, menus, modules, data sources, criteria, filters, row actions, editable lists, and common security settings:

Text output highlights severity levels: errors in red, warnings in yellow, and informational diagnostics in cyan. Findings include a Location column with the nearest known file and line, resolved from Adminix fluent configuration metadata, the published config/adminix.php, or the inspected class as a fallback.

Return machine-readable diagnostics:

JSON findings keep severity and code as strings and include location.file plus location.line when a location can be resolved.

Fail on warnings as well as errors:

By default the command fails when errors are found. With --strict, warnings also produce a non-zero exit code. Informational diagnostics, such as an unpublished local config file, do not fail the command.

Make action

Create a reusable bulk action handler:

The command writes app/Adminix/Actions/ArchiveOrdersAction.php. Generated action handlers implement BulkActionHandlerInterface and receive BulkActionRequest. Use $request->query() for writes so Adminix keeps the datasource, criteria, selected IDs, and page context resolved from server-side list configuration.

Generate a starter Testbench-style handler test:

Preview generated paths without writing files:

Overwrite existing generated action files:

--type=bulk is the default and currently the only supported action handler type. The option is explicit so future action handler kinds can be added without changing the command shape. Like the page and resource generators, make:adminix_action writes files only; register the handler on a configured BulkAction after reviewing the generated code.

Make page

Create an empty Adminix page provider:

When the page command is run interactively without explicit options, Adminix uses Laravel Prompts as a wizard:

• asks for the missing page name;

• asks whether to generate a starter Testbench test;

• asks whether to run as --dry-run;

• asks about --force only when files will actually be written.

If any option is passed explicitly, the command uses the passed CLI options and skips the wizard branch.

Overwrite an existing generated page provider:

Generate a starter Testbench-style consuming app test with the page provider:

Preview generated page provider paths without writing files:

Make resource page

Create a starter list plus create form page:

When the resource command is run interactively without explicit options, Adminix uses a branching Laravel Prompts wizard:

• asks for the missing resource page name;

• suggests a model class derived from the page name;

• asks whether to inspect a database table and infer fields;

• asks which module sections to generate: list, full-page create form, modal create form, or a detail read-only page;

• automatically enables the list section when modal create is selected, because the modal toggler is rendered from the list;

• treats the detail section as exclusive because it expects a route param such as /products/15;

• asks whether to generate a starter Testbench test;

• asks whether to run as --dry-run;

• asks about --force only when files will actually be written.

If any option is passed explicitly, the command uses the passed CLI options and skips the wizard branch.

The generated resource page uses App\Models\Product as a starter model reference. Adjust the model, fields, validation, filters, and menu links for your application before exposing the page.

Use a specific model class without requiring the class to exist at generation time:

--model accepts a short class name or a fully-qualified PHP class name. Invalid class names are rejected before dry-run output or file generation.

Generate a resource page from the current database schema:

--smart asks Adminix to inspect a table through Laravel Schema before writing the page provider. If --table is omitted, Adminix tries the model getTable() when the model class exists, then falls back to the conventional table name derived from the model/page name. Passing --table also enables smart generation.

Smart generation maps common database types to Adminix fields:

• string-like columns become normal text inputs;

• integer columns become ResourceInputTypeEnum::INTEGER/ListFieldTypeEnum::INTEGER;

• money-like decimal columns such as amount, price, total, cost, fee, or balance become money() fields;

• string columns named color, *_color, or *_colour become color() fields;

• string columns named slug or *_slug become slug() fields;

• string/text columns named markdown, *_markdown, or *_md become markdown() fields;

• string/text/JSON columns named tags, *_tags, tag_list, or labels become tags() fields;

• JSON/JSONB columns named metadata, meta, settings, options, attributes, config, or matching *_meta, *_settings, *_options, *_attributes, *_config become keyValue() fields;

• JSON and JSONB columns become json() fields;

• boolean columns and MySQL tinyint(1) become checkbox/switch fields;

• date, datetime, timestamp, time, text, email, and phone-like columns map to the closest Adminix input type;

• MySQL enum(...) columns become select fields with generated SelectRecord options;

• single-column foreign keys, plus conventional *_id columns when the related table exists, become select fields using InputSelectSrc::dataSource('{foreign_table}'), the referenced column as valueField(), and a best-effort display field such as name, title, label, or email.

Adminix does not generate sensitive fields such as password, remember_token, api_token, *_token, or *_secret. System columns such as id, created_at, and updated_at may be listed, but they are not generated as writable create-form inputs. When --with-detail is used, smart generation maps visible schema fields to DetailField helpers and keeps system fields visible because detail pages are read-only. Review the generated fields, validation, labels, and relation display fields before exposing the page in a real admin panel.

Choose generated module sections:

--modal generates a ModalNewResourceModule and a list ModalTogglerModule. --with-detail generates a DetailModule with ResourceProperty::key('id')->value('param:0'); use it for pages opened as /adminix/{page-uri}/{id}. When no section option is passed, the command keeps the historical default and generates a list plus full-page create form. In wizard mode, choosing only the modal section still generates the required list section automatically. Choosing the detail section makes the generated page detail-only, even if list/form/modal were also selected.

Generate a starter test or overwrite existing generated files:

Preview generated files and resource options without writing files:

Generator commands write files only. They do not provide --register and do not edit config/adminix.php; register generated pages explicitly in the consuming application after reviewing the generated code.