Ignorer le thème pour le backend admin, ou ajouter une classname à <html> ?

Suite à la discussion de Un thème différent pour l’interface d’administration ? :

La solution de contournement recommandée actuellement pour ne pas appliquer de thème à l’interface d’administration est :

Discourse prend en charge le SCSS, ce qui signifie que vous n’avez besoin d’ajouter body:not(.admin-interface) qu’une seule fois à votre thème. Vous n’avez pas besoin de l’ajouter à chaque règle.

À première vue, cela semble quelque peu problématique car le sélecteur :root, où diverses couleurs sont définies, se trouve au-dessus de <body>, et les couleurs personnalisées affectent toujours à la fois l’interface d’administration et celle des utilisateurs.

Ce serait plus simple si la balise <html> avait également une classe .admin-interface (ou une variante). (Ou, mieux encore, les personnalisations de thème seraient encore plus faciles si un thème séparé (par défaut) pouvait être configuré pour l’interface d’administration.)

Si Discourse permettait aux créateurs de thèmes de ne personnaliser que les parties visibles par les utilisateurs normaux, cela faciliterait probablement la création et la personnalisation des thèmes.


Un sujet quelque peu lié est l’utilisation d’une langue distincte pour l’interface d’administration (discuté ici : Can discourse have different language interfaces for admin only?) — cela serait particulièrement utile pour ajuster les traductions dans des langues dont la couverture est très approximative (c’est-à-dire incorrecte) ou incomplète (beaucoup de chaînes non traduites).

Je configure actuellement Discourse en estonien et j’aimerais corriger les mauvaises traductions destinées aux utilisateurs au fur et à mesure que je les repère, mais l’utilisation de l’interface d’administration en estonien est très confuse car de nombreux textes sont incorrects ou tout simplement incompréhensibles.

Oui, je pense qu’il serait logique de séparer la zone d’administration à un moment donné. Cela peut certainement constituer une charge supplémentaire pour la mise en thème, ce qui n’est généralement pas nécessaire. WordPress sépare également les thèmes et styles de l’administration.

En attendant, j’ai soumis une PR pour ajouter une classe admin-area à la balise HTML. J’ai utilisé un nom différent et conservé l’ancienne balise body afin de ne pas affecter les thèmes existants.