Introduction
Sometimes you need to register the same resource or page multiple times with different configurations. For example, an βOrdersβ resource might appear as both βActive Ordersβ and βArchived Ordersβ in the sidebar, each with different query scopes, navigation labels, and URL slugs - but sharing the same underlying resource class. Configurable resources and pages allow you to register a single class multiple times in a panel, each with a unique configuration key and its own set of options. Each configuration gets its own routes, navigation items, and URL slugs, while the resource or page class can use the active configuration to adjust its behavior at runtime.While this guide is in the plugins section, configurable resources and pages work in any
PanelProvider - you donβt need to be building a plugin to use them. They are especially useful for plugins because they let plugin authors expose flexible configuration to their users.Creating a resource configuration class
To make a resource configurable, you first need a configuration class. This class extendsResourceConfiguration and defines the options that can vary between registrations:
$this for chaining, and getter methods retrieve stored values.
Linking the configuration class to a resource
Set the$configurationClass property on your resource to link it with the configuration class:
make() method on the resource, which creates a new configuration instance that can be registered on a panel.
Registering configurations on a panel
You may register one or more configurations using themake() method. Each configuration needs a unique key:
'active', 'archived') is used internally to identify each registration.
You may also register the resource class on its own alongside configurations if you want a default (unconfigured) registration as well. This is optional - you can register only configurations if thatβs all you need:
URL slugs
When you register the resource class on its own (without a configuration), it uses the resourceβs default URL slug - for example,/orders.
When you register a configuration with a key, the key is appended to the resourceβs base slug. For example, OrderResource::make('active') would be accessible at /orders/active, and OrderResource::make('archived') at /orders/archived.
You may use slug() to override the entire slug for a configuration instead of using the default {base}/{key} pattern:
Using the configuration at runtime
Inside your resource class, callstatic::getConfiguration() to retrieve the active configuration for the current request. This returns null when the resource is accessed via its default (unconfigured) registration:
static::hasConfiguration() as a shorthand to check if a configuration is currently active:
Generating URLs for a specific configuration
When generating URLs for a configured resource, pass theconfiguration argument to getUrl():
getUrl() automatically uses the current configuration context. You only need to pass the configuration argument when linking to a different configuration from the one youβre currently in.
Configurable pages
Pages follow the same pattern as resources. The key differences are:- Your configuration class extends
PageConfigurationinstead ofResourceConfiguration - You register configurations using
$panel->pages()instead of$panel->resources() - Since pages are Livewire components, you can read configuration values in
mount():
Temporarily switching configuration context
You may usewithConfiguration() to execute code in the context of a specific configuration. This is useful when you need to generate URLs or access configuration values for a registration other than the currently active one: