Domain Config UI¶

Le module Domain Config UI fournit un moyen simple d'activer des surcharges de configuration par domaine directement depuis les formulaires de configuration existants. Lorsqu'un formulaire de configuration pris en charge est consulté dans un contexte de domaine, les utilisateurs disposant des droits adéquats voient un bouton en ligne permettant d'activer (ou de supprimer) une surcharge de configuration spécifique au domaine pour cet objet de configuration.

Fonctionnement¶

Lorsqu'un utilisateur disposant des permissions appropriées visite un formulaire de configuration d'administration sur un nom d'hôte de domaine (par exemple, https://one.example.com), le module inspecte le formulaire pour identifier le ou les objets de configuration sous-jacents.
Si la configuration peut être surchargée par domaine, un lien d'action en ligne apparaît en haut du formulaire :
- Activer la configuration de domaine
- Supprimer la configuration de domaine (une fois celle-ci activée)
Une fois activée, les modifications soumises via ce formulaire sont enregistrées en tant que surcharges par domaine, sans modifier la configuration globale.

Configurations non autorisées¶

Vous pouvez explicitement empêcher certains objets de configuration d'être surchargés par domaine. Lorsqu'un nom de configuration est interdit, le lien de basculement en ligne est masqué sur le formulaire correspondant.

Où configurer¶

Interface : Administration > Configuration > Domain > Domain Config UI (/admin/config/domain/config-ui)
Clé de configuration : domain_config_ui.settings: disallowed_configurations

Exemple¶

Pour interdire les surcharges au niveau du domaine pour le formulaire Informations du site (system.site) et les paramètres de thème (system.theme), définissez la configuration suivante (YAML), ou via le formulaire de paramètres :

domain_config_ui.settings:
  disallowed_configurations:
    - system.site
    - system.theme

Avec la configuration ci-dessus, le lien "Activer la configuration de domaine" n'apparaîtra plus sur :

Informations du site : /admin/config/system/site-information (system.site)
Pages d'apparence et de paramètres de thème correspondant à system.theme

Notes¶

Le module empêche également la surcharge de ses propres paramètres par défaut.
La vérification est appliquée côté serveur via la fabrique de configuration, et pas seulement masquée dans l'interface.

Issue associée¶

#3562763

Contrôle programmatique¶

Deux hooks alter permettent un contrôle avancé sur l'affichage du bouton de basculement et sur les objets de configuration éligibles aux surcharges par domaine.

Alter des configurations non autorisées¶

Empêcher les surcharges de domaine pour des noms de configuration spécifiques de manière globale :

/**
 * Implements hook_domain_config_ui_disallowed_configurations_alter().
 */
function mymodule_domain_config_ui_disallowed_configurations_alter(array &$disallowed): void {
  // Disallow domain overrides for image toolkit settings site-wide.
  $disallowed[] = 'system.image';
}

Alter des routes non autorisées¶

Masquer entièrement le bouton de basculement sur des routes spécifiques (même si la configuration sous-jacente serait normalement autorisée) :

/**
 * Implements hook_domain_config_ui_disallowed_routes_alter().
 */
function mymodule_domain_config_ui_disallowed_routes_alter(array &$routes): void {
  // Do not show the toggle on the account settings page.
  $routes[] = 'entity.user.admin_form';
}

Domaine d'édition de configuration (API développeur)¶

Par défaut, les formulaires de configuration lisent et écrivent dans le domaine négocié — celui résolu à partir de la requête courante (nom d'hôte, préfixe de chemin, etc.). Ce même domaine négocié pilote aussi le routing, la négociation de langue et la gestion des préfixes de chemin : il doit donc refléter la requête réelle et ne peut pas être simplement permuté pour éditer un autre domaine.

Pour permettre à du code d'éditer les surcharges d'un autre domaine sans changer le domaine négocié, le module fournit le service DomainConfigEditContext (Drupal\domain_config_ui\DomainConfigEditContext). Il conserve un domaine d'édition de configuration optionnel, restreint à un ensemble de noms de configuration. La fabrique de configuration et DomainConfigUIManager le consultent en priorité par rapport au domaine négocié, en retombant sur la négociation lorsqu'aucun n'est défini.

/** @var \Drupal\domain_config_ui\DomainConfigEditContext $edit_context */
$edit_context = \Drupal::service(DomainConfigEditContext::class);

// Éditer uniquement les surcharges system.site de one_example_com ; tout le
// reste (ainsi que le routing, la langue et les préfixes de chemin) continue
// d'utiliser le domaine négocié.
$edit_context->setEditingDomain('one_example_com', ['system.site']);

Propriétés clés :

Restreint par nom : seuls les noms de configuration que vous passez sont reciblés ; toute autre configuration continue de se résoudre sur le domaine négocié.
La négociation n'est pas touchée : le routing, la langue et la gestion des préfixes de chemin utilisent toujours le domaine réel de la requête, si bien que l'URL courante continue de fonctionner — y compris sur les sites utilisant des préfixes de chemin de langue ou le mode domaine à préfixe de chemin.
Rétrocompatible : lorsqu'aucun domaine d'édition n'est défini, chaque résolution retombe sur le domaine négocié ; le comportement est identique à celui obtenu sans utiliser le service.
Le contrôle d'accès s'applique toujours : les écritures restent soumises à l'enregistrement par domaine et aux permissions de domaine de l'utilisateur, évaluées vis-à-vis du domaine d'édition — un utilisateur ne peut écrire que dans un domaine qu'il est autorisé à administrer.

Cette API alimente le sous-module Domain Configuration Switcher du projet domain_extras, qui ajoute un sélecteur de domaine dans le formulaire.

Modifier la configuration de base (par défaut)¶

Passez DomainConfigEditContextInterface::BASE comme identifiant de domaine pour modifier la configuration de base — les valeurs par défaut dont hérite chaque domaine tant qu'il n'a pas son propre override par domaine — au lieu de l'override d'un domaine précis. getDomainId() résout la sentinelle en NULL, de sorte que la configuration factory écrit la configuration de base plutôt qu'une collection de domaine, même lorsque le domaine négocié possède un override enregistré.

use Drupal\domain_config_ui\DomainConfigEditContextInterface;

// Modifier la configuration system.site de base, indépendamment du domaine
// négocié. L'enregistrement écrit la valeur par défaut dont héritent les
// domaines sans override.
$edit_context->setEditingDomain(
  DomainConfigEditContextInterface::BASE,
  ['system.site'],
);

Comme getDomainId() renvoie NULL en mode base, le hook_form_alter() de domain_config_ui considère qu'aucun domaine d'édition n'est défini et ne s'exécute pas : il n'ajoute ni le bouton d'activation/désactivation ni les validateurs de permission. Le consommateur prend donc en charge l'interface dans le formulaire et doit lui-même restreindre la modification de la configuration de base derrière la permission set default domain configuration.

Issue associée¶

Aperçu des permissions¶

Les permissions courantes utilisées par ce module incluent :

use domain config ui — voir et utiliser le bouton de basculement en ligne sur les formulaires autorisés
administer domain config ui — gérer les paramètres
set default domain configuration — gérer les valeurs par défaut et spécifiques au domaine

Assurez-vous que les utilisateurs opèrent dans un contexte de domaine (c'est-à-dire en visitant le site sur le nom d'hôte d'un domaine) pour que le bouton de basculement soit disponible.

Le sous-module optionnel Domain Config Language UI apporte sa propre permission translate domain configuration pour gérer les surcharges par langue qui s'ajoutent à celles par domaine.

Références de tests¶

Le dépôt inclut des tests fonctionnels et JavaScript qui illustrent le comportement attendu :

DomainConfigUISettingsTest — activation/suppression des surcharges depuis les formulaires courants
DomainConfigUIDisallowedConfigurationsTest — vérifie que l'ajout de system.site à disallowed_configurations masque le bouton de basculement sur Informations du site
DomainConfigUIOptionsTest et DomainConfigUIPermissionsTest — couverture des permissions et des options

Ces tests peuvent servir d'exemples lors de l'intégration de cette fonctionnalité dans des modules personnalisés.

Sous-modules associés¶

Quand la configuration par domaine influence des éléments rendus à partir de définitions de plugins mises en cache par langue (local tasks, local actions, contextual links), un effet de bord apparaît : sans cache key qui distingue aussi les domaines, le premier domaine à peupler le cache fige le rendu pour tous les autres, qui se retrouvent alors avec des éléments obsolètes. Le sous-module domain_menu_extras (projet domain_extras) corrige ce comportement en remplaçant les plugin managers de menu par des variantes domain-aware. Activez-le si vous êtes concerné.