Éditeur CSS et templates PHP en ligne
QuietCMS permet d'éditer le CSS et les templates PHP du thème actif directement depuis le back-office.
Les thèmes QuietCMS donnent au site son identité et organisent la présentation de ses contenus. Cette rubrique accompagne les développeurs dans la construction des layouts, des modèles et des ressources visuelles. Les guides ci-dessous détaillent des choix d’intégration et les règles à respecter pour conserver un site lisible et maintenable. Après les extraits, le dossier relie direction artistique et usages : hiérarchie, typographie, navigation, images, animations et adaptation aux écrans. Il explique comment garder une personnalité forte sans multiplier les dépendances, ni rendre les fonctions éditoriales plus difficiles à utiliser pour les personnes qui administrent le site au quotidien.
QuietCMS permet d'éditer le CSS et les templates PHP du thème actif directement depuis le back-office.
Comment créer un thème PHP pour QuietCMS : structure des fichiers, variables disponibles et template.json.
Choisissez une police Google Fonts différente pour chaque niveau de titre H1 à H6. QuietCMS génère les variables CSS et héberge les fonts automatiquement.
QuietCMS intègre un gestionnaire de sidebars avec des zones de widgets configurables par type de page.
Le thème de QuietCMS organise l’apparence du site et la manière dont ses contenus sont présentés. Il réunit une mise en page commune, des modèles adaptés aux types de ressources et les fichiers de style nécessaires. Cette séparation permet de développer une identité propre sans réécrire les fonctions d’administration, de publication ou de stockage. Le travail commence par le projet du site : son public, les informations à rendre visibles et les actions qui comptent. Une direction artistique ne se réduit pas au choix d’une couleur. Elle doit définir une hiérarchie, un rythme de lecture et une manière cohérente de montrer les preuves du produit ou du service. Pour un CMS destiné aux développeurs, des captures réelles et des explications lisibles peuvent être plus utiles qu’une illustration technique sans rapport avec les fonctions disponibles. Le thème doit traduire ce choix dans les espacements, les contrastes, les tailles de caractères et les modèles de contenu. Une identité forte n’exige pas nécessairement de nombreux effets. Des formes simples et des conventions répétées avec mesure rendent le site reconnaissable tout en limitant sa complexité. Le développeur conserve ainsi un ensemble qu’il peut faire évoluer, tandis que les éditeurs continuent à gérer leurs textes avec les outils du moteur. Cette continuité est essentielle lorsqu’une refonte doit améliorer l’expérience sans remettre en cause les contenus existants.
Le layout produit les éléments communs à plusieurs pages : l’en-tête du document, la navigation, certaines métadonnées, les ressources et le pied de page. Les modèles traitent les différences entre l’accueil, une page, un article ou une archive. Cette organisation doit rester lisible pour que les corrections soient placées au bon niveau. Dupliquer un menu dans plusieurs modèles complique les mises à jour ; forcer une présentation unique pour tous les contenus peut rendre certaines ressources difficiles à parcourir. Le bon découpage suit les responsabilités réelles. Les informations du document sont calculées avant leur affichage, et les fonctions natives servent à générer les URL et les éléments SEO. Le thème ne devrait pas recopier une règle du moteur simplement parce qu’elle paraît courte. Les champs du contenu doivent également être interprétés de manière cohérente. Une image à la une, un titre visible et une description peuvent être présentés différemment selon le modèle, mais leur origine doit rester compréhensible. Les cas de repli méritent une attention particulière : absence d’image, contenu incomplet, page introuvable ou fonction d’extension désactivée. Un modèle doit produire un résultat utilisable dans ces situations. Tester uniquement une page riche et parfaitement renseignée laisse souvent passer des défauts qui apparaîtront dès la première publication ordinaire. Une architecture de thème propre réduit les surprises et facilite la reprise par une autre personne.
La typographie doit rendre les textes faciles à lire à plusieurs tailles d’écran. Les titres peuvent exprimer une personnalité, mais le corps du texte doit rester confortable et suffisamment contrasté. Une combinaison de caractères trop proches ne crée pas toujours une hiérarchie claire ; une multiplication des polices peut au contraire disperser l’identité et alourdir les ressources. Le projet doit préciser le rôle de chaque famille et ses graisses réellement utilisées. Les polices locales évitent certaines dépendances externes, mais leur format, leur chargement et leur licence restent à vérifier. Des polices système constituent aussi un choix valable lorsqu’elles répondent au besoin. La palette doit distinguer les fonds, les textes, les liens, les états et les accents sans faire porter une information uniquement sur la couleur. Une teinte claire qui paraît élégante peut devenir illisible sur mobile ou dans une zone peu contrastée. Les boutons et les liens doivent conserver leurs états de survol et de focus. Les formulaires demandent des libellés lisibles, des messages explicites et des champs faciles à distinguer. Les choix graphiques doivent être vérifiés sur de vrais contenus, notamment les titres longs et les paragraphes denses. Une maquette composée uniquement de petites phrases ne révèle pas les contraintes du site en exploitation. La cohérence visuelle se construit donc avec les usages, pas seulement avec une planche de couleurs approuvée avant l’intégration.
L’accueil doit permettre de comprendre rapidement le sujet du site, son utilité et les chemins disponibles. Il n’a pas à résumer chaque fonctionnalité dans son premier écran. Une promesse claire peut être suivie de preuves concrètes, puis d’explications plus détaillées et d’une invitation adaptée au public. Sur un site de logiciel, montrer l’interface réelle aide à distinguer une proposition disponible d’un simple concept. Les captures doivent être cadrées pour rester lisibles et accompagnées d’un contexte suffisant. Les blocs suivants peuvent expliquer les choix d’architecture, les conditions d’usage et les limites utiles à la décision. La mise en page gagne à varier les compositions tout en conservant une hiérarchie commune. Répéter le même groupe de cartes à chaque section peut rendre la page monotone et gommer les différences entre les messages. Les espaces vides participent à la lecture : ils donnent aux titres et aux visuels leur place sans exiger davantage de décor. Les appels à l’action doivent correspondre au stade du visiteur. Découvrir la documentation, examiner une réalisation ou prendre contact ne répondent pas exactement au même besoin. Leur formulation doit être concrète et leur destination prévisible. Une page réussie conserve cette progression sur mobile, où les éléments passent souvent les uns sous les autres. L’ordre du document doit donc rester logique sans dépendre d’un placement graphique réservé aux grands écrans.
Un menu peut contenir beaucoup de liens tout en laissant le visiteur hésiter sur son point de départ. Réduire les entrées principales oblige à clarifier les familles de besoins. Une distinction entre produit et ressources peut suffire à orienter un site de CMS, à condition que les sous-menus donnent accès aux pages attendues. Les rubriques techniques n’ont pas toutes besoin d’occuper la première ligne de navigation. Elles peuvent être regroupées dans un hub éditorial et retrouvées par la recherche. Le menu doit rester utilisable au clavier et sur écran tactile. Les sous-menus demandent une ouverture prévisible, des zones d’action suffisantes et un comportement cohérent lorsque la taille de l’écran change. Une ouverture au survol peut compléter l’interaction sur ordinateur, mais elle ne doit pas être le seul moyen d’atteindre une ressource. Le focus visible et la fermeture par la touche Échap participent au même parcours. Les liens d’évitement permettent de rejoindre le contenu sans reparcourir tout l’en-tête. La recherche doit conserver un formulaire classique utilisable sans JavaScript, même si des suggestions améliorent l’expérience. La navigation se vérifie enfin sur des pages profondes et des archives, pas seulement sur l’accueil. Une personne arrivée directement sur un article doit pouvoir comprendre où elle se trouve et comment revenir à sa rubrique.
Une animation peut signaler un changement d’état ou accompagner l’apparition d’un élément, mais elle devient gênante lorsqu’elle déplace le contenu que la personne essaie de lire. Les glissements répétés, les effets continus et les mouvements simultanés attirent l’attention sans toujours servir le message. Pour un site de contenu, une apparition discrète ou un changement d’opacité suffit souvent. Le visiteur doit garder la maîtrise du défilement et pouvoir consulter l’information sans attendre la fin d’une séquence. Les préférences de réduction du mouvement doivent être respectées par les règles CSS et les scripts concernés. Une page ne doit pas devenir vide si un observateur de défilement ne se déclenche pas ou si JavaScript est indisponible. L’amélioration progressive consiste à rendre le contenu accessible d’abord, puis à ajouter un comportement lorsqu’il est effectivement pris en charge. Les effets doivent aussi être évalués en termes de performance. Animer des propriétés qui obligent le navigateur à recalculer constamment la mise en page peut rendre l’expérience moins fluide. Une animation techniquement légère peut néanmoins rester inconfortable si son rythme est trop rapide. La validation doit donc porter sur la perception autant que sur l’exécution. Un schéma animé est utile lorsqu’il explique une relation ; il doit pouvoir être compris dans un état stable. Le mouvement accompagne le contenu, il ne devient pas une condition nécessaire à sa compréhension.
Les ressources visuelles doivent être préparées pour la place qu’elles occupent dans le thème. Une image principale demande une stratégie différente d’un aperçu situé plus bas dans la page. Réserver ses dimensions évite des déplacements de contenu pendant le chargement. Le chargement différé peut convenir aux images secondaires, mais il ne doit pas retarder inutilement celle qui porte le premier écran. Les formats modernes et les tailles adaptées réduisent les transferts lorsque leur utilisation est cohérente avec le contenu. Les composants ajoutés au thème doivent être évalués avec la même discipline. Une bibliothèque complète n’est pas forcément justifiée pour un accordéon ou un simple effet de survol que le navigateur sait déjà gérer. Les composants natifs conservent souvent une meilleure lisibilité et limitent les dépendances, à condition de les styliser et de tester leurs interactions. La CSP du site impose également des règles aux scripts, aux styles et aux ressources externes. Une intégration doit respecter les nonces et les sources autorisées plutôt que demander un assouplissement global. Les erreurs de console et les requêtes refusées donnent des indices utiles pendant la recette. Le contrôle porte ensuite sur la stabilité des mises en page, l’accessibilité des commandes et le comportement lorsque certaines ressources échouent. Un thème doit rester utilisable même lorsqu’une image manque ou qu’une connexion externe ne répond pas.
Le thème doit être livré avec ses fichiers, ses ressources et une description des décisions qui ne sont pas évidentes à la lecture du code. Les couleurs, les espacements, les familles de caractères et les composants communs gagnent à être définis dans des règles centrales. Une modification d’identité ne devrait pas obliger à rechercher la même valeur dans de nombreux modèles. Les contenus restent séparés des éléments de présentation autant que possible, et les zones particulières de l’accueil doivent être documentées. Une sauvegarde de la version précédente et une liste des fichiers modifiés facilitent le retour arrière. La livraison doit aussi préciser les caches à purger et ceux qu’il ne faut pas transférer. Le contrôle visuel comprend un grand écran, un écran étroit et des contenus représentatifs : titre long, tableau, formulaire, article illustré et page sans image. Les parcours clavier et les préférences de réduction du mouvement doivent être inclus dans cette validation. Après déploiement, il faut vérifier que les chemins des ressources et les en-têtes du serveur correspondent à l’environnement de préparation. La documentation peut rester courte si elle traite les points réellement spécifiques. Son objectif est de permettre à un autre développeur de corriger un détail sans reconstruire tout le raisonnement du projet. Un thème réussi garde ainsi sa personnalité tout en restant un outil de travail compréhensible, testable et évolutif.
La validation graphique doit dépasser le premier écran de l’accueil. Une équipe peut préparer un parcours qui traverse une réalisation, une page de documentation, une rubrique et un formulaire. Ce trajet révèle si les composants appartiennent au même univers et si les différences de présentation restent compréhensibles. Les titres longs, les tableaux et les images manquantes doivent faire partie des contenus de test. Ils montrent les limites que des textes de démonstration très courts peuvent masquer. Sur mobile, le contrôle porte sur l’ordre de lecture, les zones tactiles et l’absence de débordement horizontal. Au clavier, il vérifie le focus, les sous-menus et la recherche. Les captures prises pendant la recette servent à comparer les états, mais elles ne remplacent pas l’interaction réelle. Un menu peut sembler correct sur une image tout en se fermant avant que le visiteur atteigne son sous-menu. Une animation peut paraître élégante dans une démonstration et gêner la lecture répétée.