Routes, permissions et écrans d'administration

Brancher un module au front, la matrice des groupes et la navigation d'administration.

Routes#

Deux fichiers, chargés depuis boot() :

PHP

$this->loadRoutesFrom(__DIR__.'/../routes/web.php');
$this->loadRoutesFrom(__DIR__.'/../routes/admin.php');

Nommez chaque route avec votre slug en préfixe (directory.index, admin.directory.settings). C'est ce qui fait de Route::has() un garde fiable pour les autres modules, et ce qui permet au panneau de créer un lien vers votre écran de réglages.

Les routes d'administration passent derrière le middleware du panneau, exactement comme celles du core. Ne créez jamais votre propre authentification d'administration.

Permissions#

Déclarez-les dans le manifeste :

JSON

"provides": { "permissions": ["directory.view", "directory.manage"] }

Elles sont enregistrées dans la matrice des groupes à l'installation et apparaissent dans Members > Member groups aux côtés des permissions de tous les autres modules. Vérifiez-les de la façon habituelle :

PHP

Gate::allows('directory.manage');

Trois règles :

N'inventez jamais un système de permissions parallèle. La matrice des groupes est la seule réponse à « qui peut faire ceci », et les acheteurs la comprennent déjà.
Vérifiez toujours côté serveur. Cacher un bouton relève de la présentation, pas de la sécurité.
Découpez là où c'est pertinent. Une permission par zone de votre module vaut mieux qu'un simple interrupteur global.

Navigation d'administration#

La navigation du panneau est construite à partir d'un registre, pas codée en dur. Vous contribuez via l'emplacement admin.menu dans boot() :

PHP

Hooks::on('admin.menu', fn (HookContext $ctx) => [
    'label' => __('directory::admin.title'),
    'url'   => route('admin.directory.settings'),
    'order' => 40,
]);

N'ajoutez que des entrées que l'administrateur actuel peut réellement atteindre. Un élément de menu qui mène à un 403 est du bruit.

Emplacements d'interface#

Le core déclare les suivants, et un module peut déclarer les siens :

admin.menu, admin.dashboard.widgets, profile.tabs, profile.sidebar, settings.pages, search.sources, editor.toolbar, member.actions, head.meta, body.end.

Enregistrement :

PHP

Hooks::on('profile.tabs', fn (HookContext $ctx) => [
    'label' => __('directory::labels.items'),
    'url'   => route('directory.member', $ctx->get('member')),
    'order' => 20,
]);

Consommation, dans une vue Blade :

Blade

@hook('profile.tabs', ['member' => $member])

Les contributions sont collectées, ordonnées par order et rendues.

Recherche#

Contribuez à la recherche du site via search.sources. Votre source est responsable d'appliquer vos propres règles de visibilité : un résultat ne doit jamais apparaître pour quelqu'un qui ne pourrait pas ouvrir la page qu'il pointe.

Écrans#

Les écrans d'administration utilisent les composants du panneau, afin que votre module ressemble au produit plutôt qu'à un plugin. En particulier :

des boutons-icône carrés de taille uniforme, avec un dropdown en chevron pour les actions secondaires, dans chaque liste ;
la modale du produit pour la confirmation, jamais window.confirm ;
des selects avec le chevron personnalisé, jamais le natif tout nu ;
zéro violation axe sur chaque écran que vous ajoutez, en clair comme en sombre.