Documentation

The main dashboard (Dashboard, the landing page after login) is built from widgets — the plan card, quick actions, analytics summary, stat cards, recent-content lists, and feature-contributed cards. Sites choose which widgets appear via the Customize button in the page header, and enabled feature modules (E-Commerce, Online Booking, …) contribute their own cards automatically, so a paid install's dashboard gets richer without any per-site configuration.

What's on the dashboard

In default order:

The CMS-update banner is not a widget — it always shows to admins when an update is pending.

Users below the Manager role see a minimal "You're logged in" screen instead of the widget dashboard.

Customizing

Dashboard → Customize (header button, Manager+) opens a checkbox modal listing every available widget. The selection is stored site-wide in the dashboard.widgets Setting (persisted in catalog order; unknown keys are dropped on save). When the Setting has never been saved, the default set above applies. Feature-gated widgets disappear from both the dashboard and the modal while their feature is off — and reappear, still honouring the saved selection, when it's turned back on.

Quick Actions keeps its own separate Customize modal (dashboard.quick_actions) for choosing which shortcut buttons appear inside that widget.

Free vs. paid installs

There is deliberately one dashboard, not a free and a paid variant. Tier differences express through feature flags:

• Free (Core) installs see the Your Plan card with an Upgrade button linking to config('cms.pricing_url') (CMS_PRICING_URL, default https://www.webprocms.com/pricing).
• Member installs see their tier (from the membership.tier Setting, populated by the daily phone-home) and the renewal date when known.
• Paid features contribute their widgets automatically when enabled, so a Pro install's dashboard differentiates itself without a separate layout.

For developers: contributing a widget from a feature module

Widgets live in app/Support/DashboardWidgetRegistry.php (a container singleton, same pattern as PresetRegistry). A feature module registers its card from its service provider — no blade partial needed; the dashboard renders it through the standard stat-card markup:

$this->app->afterResolving(DashboardWidgetRegistry::class, function (DashboardWidgetRegistry $registry): void {
    $registry->register([
        'key' => 'ecommerce_orders',
        'label' => 'Orders card',            // Customize-modal label; untranslated, the modal wraps it in __()
        'feature' => 'ecommerce',            // hidden while this feature flag is off
        'icon' => 'shopping-bag',            // heroicon shown in the card header
        'title' => 'Orders',                 // card header; untranslated, the card wraps it in __()
        'data' => fn (): array => [          // lazy; runs only when the card renders
            'value' => number_format($count),          // the big number
            'subline' => __('…· last 7 days'),         // optional small line under the number
            'href' => route('dashboard.shop.orders'),  // optional "See all →" target
        ],
    ]);
});

Requirements and options:

• The data callable runs on every dashboard render while the widget is visible — keep it to a couple of cheap queries.
• Translate sublines inside the callable with __(); it executes at render time so the admin locale applies. (These PHP-side strings are not picked up by the dashboard lang scanner — add them to lang/{code}.json manually or via the translation catch-up.)
• Add 'default' => false when the card would show a permanent empty state on a fresh install (see the Accessibility card).
• Visibility that isn't a plain feature flag: pass a visible callable instead of (or alongside) feature — it is evaluated at catalog time and hides the widget from both the dashboard and the Customize modal when it returns false. The Fleet card uses this because the fleet surface follows Membership::isFleetServer(), so the license server must get the card without the Fleet Management feature being on. Keep the callable cheap (catalog() runs every render) and lazy — registration happens during provider boot, where DB access is banned.
• Custom shapes: pass a view key (a namespaced blade partial) instead of relying on the standard renderer — the partial receives the resolved data array as variables and replaces the standard card entirely. Register a plain view namespace with loadViewsFrom() and keep the partial under the module's resources/views/dashboard/ so the dashboard CSS bundle scans it.
• Core widgets render inline in ⚡dashboard.blade.php gated by $this->isWidgetVisible('{key}'); only add a new core entry to the registry's boot() list when the dashboard blade gains a new section.