Modules

Modules are the building blocks of Adminix pages. A page can contain one module, several modules, or nested modules inside layout modules such as dashboards and panels.

Each module is configured in PHP. Adminix reads that configuration at runtime, resolves the datasource or handler on the server, and renders the matching Blade view.

Shared action metadata for links, modal togglers, bulk actions, and page-level callback actions is documented in Actions.

Pick the right module

Start from the job the page must do:

Need	Start with
Show and operate on many records	List
Edit one record	Resource
Create a record on its own page	New resource
Create or edit inside a modal	Modal resource, Modal new resource
Show a read-only record	Detail
Compose several modules into a workspace	Dashboard, Panel
Run CSV import workflow	Import
Browse files from an application-owned disk scope	Media
Show tenant context, maintenance state, or health checks	Tenant Switcher, Maintenance Banner, Health Status
Show one database value	Display value
Show simple content or navigation	Text, Link, Clock

When a screen writes data, keep the write rules in the module, handler, policy, datasource criteria, or application service. Do not make browser-provided module names, record IDs, field lists, tenant IDs, upload paths, or action payloads authoritative.

Basic example

use AlexKudrya\Adminix\Modules\List\ListField;
use AlexKudrya\Adminix\Modules\List\ListSearch;
use AlexKudrya\Adminix\Modules\Module;
use App\Models\Order;

$page->addModule(
    Module::list()
        ->name('orders')
        ->dataSource(Order::class)
        ->primaryKey('id')
        ->search(ListSearch::searchFields(['number', 'customer_name']))
        ->addFields(
            ListField::name('Number')->field('number')->sortable(),
            ListField::name('Customer')->field('customer_name'),
            ListField::name('Status')->field('status')->badge()
        )
);

Result: Adminix renders a searchable list using server-declared fields. The browser can request search and sort state, but it cannot choose a different datasource or writable field list.

Module visibility

Every built-in page module supports server-side visibility helpers. Use them when a module should be available only for a role, policy, tenant mode, feature flag, or other trusted application condition.

use AlexKudrya\Adminix\Modules\Module;
use Illuminate\Http\Request;

$page->addModules(
    Module::list()
        ->name('orders')
        ->dataSource(Order::class)
        ->can('viewAny', Order::class),

    Module::text()
        ->name('ops-note')
        ->body('Operations-only instructions.')
        ->visibleUsing(
            fn (Request $request): bool => $request->user()?->can('viewOpsNotes') === true
        )
);

Result: hidden modules are removed before Adminix prepares data providers and before the shared Blade renderer sees the module. Nested modules inside DashboardModule and PanelModule use the same visibility check. Adminix endpoint resolution also respects visibility, so a hidden named module cannot be used by package API routes only because the browser knows its name.

Available helpers:

Helper	Use
`visible(false)`	Hide the module from render and endpoint resolution.
`hidden()`	Convenience alias for `visible(false)`.
`visibleUsing(callable $callback)`	Run a custom callback. The callback receives `Request $request`, the module, page params, and context.
`authorizeUsing(callable $callback)`	Alias for `visibleUsing()` when the callback is authorization-oriented.
`can(string $ability, mixed $arguments = [])`	Require a Laravel Gate or policy ability.
`canAny(array $abilities, mixed $arguments = [])`	Show the module when any configured ability passes.

Use can('viewAny', Model::class) for normal Laravel policies, or pass a model/DTO when the module represents a specific record. If render-time arguments depend on page route params, pass a callback as the second argument:

Module::resource()
    ->name('order')
    ->dataSource(Order::class)
    ->can('view', fn (Request $request, $module, array $params) => Order::find($params[0] ?? null));

Visibility helpers are not a replacement for write authorization. Keep datasource criteria, tenant scope, resource policies, action handlers, import/media routes, and queued jobs protected server-side. Contextual module endpoints resolve visibility only after verifying their signed page parameters and reject missing, invalid, or mixed contexts before module lookup. Endpoint callbacks can inspect Request $request, but visibility still is not row-level authorization: enforce record permissions in policies, handlers, and datasource criteria.

List
Detail
Link
Resource
New Resource
Modal Resource
Modal New Resource
Audit
Display value — create it with Module::displayValue().
Chart-Bar
Chart-Line
Counter
Metric
Progress Bar
Import
Media
Tenant Switcher
Dashboard
Panel
Text
Maintenance Banner
Health Status
Clock

Last modified: 23 July 2026