La création de feuilles de style CSS modernes et faciles à entretenir pour les thèmes WordPress s’accompagne de plusieurs défis que les développeurs doivent relever. L’utilisation de Sass (Syntactically Awesome Style Sheets) comme préprocesseur CSS peut vous aider à organiser, maintenir et mettre à l’échelle vos styles plus efficacement.
Cependant, la mise en place d’un flux de travail Sass efficace qui s’intègre naturellement au développement de WordPress nécessite une planification réfléchie et un savoir-faire technique.
Ce guide vous montre comment mettre en place un flux de travail Sass professionnel pour le développement de thèmes WordPress. Il couvre les outils de construction modernes, l’organisation intelligente des fichiers et les pratiques de déploiement qui stimulent la productivité et assurent la maintenance de vos styles.
Quelques informations sur l’utilisation de Sass pour le développement de WordPress
Le développement professionnel de WordPress s’appuie souvent sur des outils et des flux de travail qui vont au-delà des capacités intégrées de la plateforme. Sass peut jouer un rôle clé en vous aidant à gérer la complexité des CSS grâce à des fonctionnalités telles que les variables, l’imbrication, les mixins, les importations et les fonctions intégrées.
Sass offre plusieurs avantages pour le développement de thèmes. Un thème WordPress typique comprend des styles pour de nombreux composants et parties de modèles. Au lieu de tout gérer dans une feuille de style unique et peu pratique, Sass permet une architecture modulaire qui favorise la maintenabilité et l’évolutivité grâce à une structure programmatique.
Cette approche structurée va au-delà de ce qu’offre le CSS standard et s’aligne bien sur les exigences uniques de WordPress en matière de style. Contrairement à l’utilisation de style.css avec WordPress, Sass vous permet de créer des feuilles de style modulaires et spécifiques qui se compilent en fichiers CSS optimisés à l’aide d’un flux de travail simple :
- Un processus de construction pour compiler les fichiers Sass en CSS.
- Une structure de fichiers pour organiser vos styles de façon à pouvoir les maintenir.
- Des outils de développement pour les tests locaux et l’assurance qualité.
- Des stratégies de déploiement pour pousser les changements vers des environnements de staging et de production.
La façon dont vous mettez en œuvre ce flux de travail dépend des préférences de votre équipe en matière d’outils, de la pile technique et de la complexité du projet. Mais la plupart des installations WordPress basées sur Sass suivent quelques pratiques communes : la configuration des cartes de source pour le débogage, la surveillance des fichiers pendant le développement et l’optimisation de la sortie pour la production.
Une configuration typique sépare vos fichiers sources Sass des ressources compilées, ce qui facilite la maintenance de votre base de code et permet de fournir une sortie propre au navigateur.
3 façons de compiler Sass dans les projets WordPress
La base de tout flux de travail Sass est le processus de construction qui transforme tes fichiers Sass en CSS prêts pour le navigateur. Il y a plusieurs façons de mettre cela en œuvre dans WordPress.
1. Utiliser des plugins : L’approche la plus simple
La façon la plus accessible d’utiliser Sass dans un thème WordPress est par le biais d’extensions. Cette approche est idéale si vous commencez à peine ou si vous travaillez sur un petit projet qui ne nécessite pas un pipeline de construction complet.
Par exemple, WP-Sass gère la compilation via les crochets d’action natifs de WordPress dans wp-config.php, en surveillant le répertoire Sass de votre thème pour les changements :
<?php
// Include the class (unless you are using the script as a plugin)
require_once( 'wp-sass/wp-sass.php' );
// enqueue a .less style sheet
if ( ! is_admin() )
wp_enqueue_style( 'style', get_stylesheet_directory_uri() . '/style.scss' );
else
wp_enqueue_style( 'admin', get_stylesheet_directory_uri() . '/admin.sass.php' );
// you can also use .less files as mce editor style sheets
add_editor_style( 'editor-style.sass' );
?>Une autre option, Sassify, est un peu plus ancienne et adopte une approche différente – en se connectant aux API de WordPress pour gérer la compilation Sass, les chemins de sortie et les réglages de compression.
Bien que les solutions basées sur des extensions soient simples, elles présentent quelques limites :
- Surcharge de performance. Ces extensions compilent Sass sur le serveur, ce qui peut consommer des ressources importantes.
- Options de compilation limitées. La plupart des extensions Sass offrent une compilation de base mais manquent de fonctionnalités essentielles. Par exemple, la prise en charge des cartes de source est souvent limitée, les capacités d’auto-référencement manquent, et bien d’autres choses encore.
- Considérations de sécurité. L’exécution d’un compilateur sur votre serveur de production peut augmenter la surface d’attaque potentielle, en particulier si l’extension ne reçoit pas de maintenance régulière.
- Problèmes de contrôle de version. Les fichiers CSS compilés vivent souvent dans le répertoire de votre thème, ce qui complique les flux de travail Git propres. Idéalement, les ressources compilées devraient rester en dehors de votre dépôt.
Cependant, malgré ces limitations, une extension reste une bonne option dans certains scénarios. Par exemple, les petits sites avec des exigences minimales en matière de style, la remise d’un projet à un client qui n’a pas l’expertise technique pour travailler avec Sass à un niveau plus profond, ou le travail avec des contraintes de ressources de développement.
2. Utiliser des scripts NPM : La solution équilibrée
Si vous recherchez plus de contrôle et de flexibilité, les scripts NPM pourraient être une alternative solide aux extensions. La compilation Sass est une tâche idéale pour NPM, car elle trouve un équilibre entre simplicité et capacité. Elle offre des améliorations substantielles par rapport aux extensions pour le développement de thèmes sans la complexité des exécutions de tâches complètes :
- En séparant la compilation de l’exécution de WordPress, vous éliminez les surcharges de performance du serveur.
- Vous obtenez un contrôle précis sur chaque étape du processus de compilation.
- Le fichier package.json garantit que tous les membres de l’équipe utilisent le même processus de compilation.
- Les scripts npm s’intègrent parfaitement aux pipelines CI/CD.
Bien que cette approche nécessite plus de configuration initiale que les extensions, elle offre une solution plus robuste et plus évolutive pour le développement de thèmes professionnels.
Configurer la compilation Sass avec NPM
Commencez par créer un fichier package.json. Vous pouvez le faire en exécutant :
npm init -yPuis installez Dart Sass :
npm install sass --save-devEnsuite, ajoutez ces scripts à votre package.json :
{
"name": "your-theme-name",
"version": "1.0.0",
"description": "A WordPress theme with Sass",
"scripts": {
"sass": "sass src/sass/main.scss:assets/css/main.css",
"sass:watch": "sass --watch src/sass/main.scss:assets/css/main.css",
"build": "sass src/sass/main.scss:assets/css/main.css --style=compressed"
},
"devDependencies": {
"sass": "^1.58.3"
}
}Cette configuration vous donne trois scripts utiles :
npm run sasscompile tes fichiers Sass une seule fois.sass:watchsurveille les changements et recompile si nécessaire.buildcompile vos fichiers Sass pour la production avec compression.
Pour prendre en charge les navigateurs plus anciens, ajoutez Autoprefixer via PostCSS :
npm install postcss postcss-cli autoprefixer --save-devMettez à jour vos scripts package.json :
{
"scripts": {
"sass": "sass src/sass/main.scss:assets/css/main.css",
"prefix": "postcss assets/css/main.css --use autoprefixer -o assets/css/main.css",
"build": "npm run sass && npm run prefix"
},
"devDependencies": {
"autoprefixer": "^10.4.13",
"postcss": "^8.4.21",
"postcss-cli": "^10.1.0",
"sass": "^1.58.3"
},
"browserslist": [
"last 2 versions",
"> 1%"
]
}Pour faciliter le débogage, ajoutez des cartes de source :
{
"scripts": {
"sass": "sass src/sass/main.scss:assets/css/main.css --source-map",
"sass:watch": "sass --watch src/sass/main.scss:assets/css/main.css --source-map"
}
}Enfin, pour utiliser ton CSS compilé dans WordPress, mets-le en file d’attente dans functions.php :
function theme_enqueue_styles() {
$style_path = '/assets/css/main.css';
$full_path = get_template_directory() . $style_path;
wp_enqueue_style(
'theme-styles',
get_template_directory_uri() . $style_path,
array(),
file_exists($full_path) ? filemtime($full_path) : false
);
}
add_action('wp_enqueue_scripts', 'theme_enqueue_styles');Cette fonction charge votre CSS compilé et ajoute un système de cache automatique en utilisant l’heure de modification du fichier comme numéro de version.
3. Utiliser Gulp : La solution complète
Gulp est un puissant gestionnaire de tâches qui excelle dans l’automatisation de processus de construction complexes. Pour le développement de thèmes WordPress avec des besoins étendus en matière de style, il peut être la solution la plus complète.
Il vous permet de gérer la compilation Sass, la synchronisation des navigateurs, et tout ce qui se trouve entre les deux. Pourquoi Gulp ?
- Gulp gère presque tous les aspects de ton processus de construction, comme la compilation, l’optimisation et le déploiement.
- Vous pouvez exécuter plusieurs tâches simultanément, ce qui réduit les temps de construction.
- L’écosystème offre des outils pour pratiquement toutes les exigences de construction.
- L’intégration de BrowserSync permet un retour d’information instantané pendant le développement.
Bien que Gulp ait une courbe d’apprentissage plus raide que d’autres approches, ses avantages en font un choix privilégié pour beaucoup.
Configuration de Gulp pour les thèmes WordPress
Pour commencer avec Gulp, il faut l’installer en même temps que plusieures extensions qui gèrent des tâches spécifiques :
# Initialize your project
npm init -y
# Install Gulp and related packages
npm install --save-dev gulp gulp-sass sass gulp-autoprefixer gulp-sourcemaps browser-sync gulp-cssnanoVous devez également créer un gulpfile.js dans le répertoire racine de votre thème, qui gère quelques étapes différentes. Cette première partie permet d’importer tous les outils nécessaires :
// 1. Import dependencies
const { src, dest, watch, series, parallel } = require('gulp');
const sass = require('gulp-sass')(require('sass'));
const autoprefixer = require('gulp-autoprefixer');
const sourcemaps = require('gulp-sourcemaps');
const browserSync = require('browser-sync').create();
const cssnano = require('gulp-cssnano');Chaque paquetage a un but précis :
gulp: Le programme d’exécution des tâches de base.gulp-sassetsass: Compilent Sass en CSS.gulp-autoprefixer: Ajoute des préfixes de fournisseur pour la compatibilité avec les navigateurs.gulp-sourcemaps: Génère des cartes de source pour le débogage.browser-sync: Rafraîchit les navigateurs pendant le développement.gulp-cssnano: Minifie les feuilles de style CSS pour la production.
À partir d’ici, vous pouvez définir les chemins d’accès à tes fichiers source et de destination et créer une fonction pour compiler Sass :
// 2. Define file paths
const files = {
sassPath: './src/sass/**/*.scss',
cssPath: './assets/css/'
}
// 3. Sass development task with sourcemaps
function scssTask() {
return src(files.sassPath)
.pipe(sourcemaps.init())
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(sourcemaps.write('./'))
.pipe(dest(files.cssPath))
.pipe(browserSync.stream());
}Cette fonction trouve essentiellement tous tes fichiers Sass, initialise les cartes sources pour le débogage et compile Sass en CSS (avec gestion des erreurs). Elle ajoute également des préfixes de fournisseur pour la compatibilité avec les navigateurs, écrit vos cartes source, enregistre le CSS compilé et met à jour le navigateur avec les changements. Dans l’ensemble, il fait beaucoup de travail !
Vous devez aussi envisager de créer une fonction de construction prête pour la production, un observateur de tâches et une fonction d’exportation :
// 4. Sass production task with minification
function scssBuildTask() {
return src(files.sassPath)
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(cssnano())
.pipe(dest(files.cssPath));
}
// 5. Watch task for development
function watchTask() {
browserSync.init({
proxy: 'localhost:8888' // Change this to match your local development URL
});
watch(files.sassPath, scssTask);
watch('./**/*.php').on('change', browserSync.reload);
}
// 6. Export tasks
exports.default = series(scssTask, watchTask);
exports.build = scssBuildTask;Cette version de production omet les cartes de source et ajoute la minification pour optimiser la taille des fichiers. Dans l’ensemble, la configuration vous permet d’utiliser npx gulp pour le développement (avec l’observation des fichiers et le rafraîchissement du navigateur) et npx gulp build pour les constructions de production.
Améliorer votre flux de travail Gulp
Pour les projets plus importants, vous pouvez vouloir séparer les styles pour des objectifs différents. Voici un exemple :
// Define paths for different style types
const paths = {
scss: {
src: './src/sass/**/*.scss',
dest: './assets/css/'
},
editorScss: {
src: './src/sass/editor/**/*.scss',
dest: './assets/css/'
}
}
// Main styles task
function mainStyles() {
return src('./src/sass/main.scss')
.pipe(sourcemaps.init())
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(sourcemaps.write('./'))
.pipe(dest(paths.scss.dest))
.pipe(browserSync.stream());
}
// Editor styles task
function editorStyles() {
return src('./src/sass/editor-style.scss')
.pipe(sourcemaps.init())
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(sourcemaps.write('./'))
.pipe(dest(paths.scss.dest))
.pipe(browserSync.stream());
}Pour les thèmes complexes comportant de nombreux fichiers Sass, vous devriez également optimiser les performances de construction en mettant en cache les fichiers traités pour éviter toute recompilation inutile, en suivant les dépendances Sass pour ne recompiler que les fichiers concernés, et plus encore. Cependant, cela dépasse le cadre de cet article.
Autres outils de compilation à prendre en compte
Alors que la plupart des développeurs s’en tiennent aux scripts NPM ou à Gulp, vous pourriez trouver plusieurs autres alternatives qui offrent des avantages uniques pour le développement de thèmes WordPress. Vite et Webpack sont deux solutions courantes.
Webpack excelle dans le regroupement de JavaScript et de ressources, ce qui est idéal si votre thème utilise des architectures basées sur des composants ou des frameworks JavaScript. Sa force réside dans sa capacité à créer des paquets optimisés grâce au fractionnement du code et au « tree shaking » – ce qui est précieux pour les thèmes complexes et riches en JavaScript.
En revanche, Vite est un outil de construction plus récent qui donne la priorité à la vitesse de développement grâce à son approche innovante du chargement des modules. Son serveur de développement permet un remplacement quasi instantané des modules à chaud. C’est un moyen rapide de mettre en œuvre un développement itératif. Bien que son intégration aux flux de travail de WordPress continue d’évoluer, c’est une option intéressante si vous pouvez l’utiliser pour le développement de votre propre thème.
Pour les projets plus simples ou les préférences personnelles, l’interface de programmation Sass offre une approche directe sans outil supplémentaire :
# Install Sass globally
npm install -g sass
# Compile Sass files
sass --watch src/sass/main.scss:assets/css/main.cssBien que la compilation manuelle ne dispose pas des fonctions d’automatisation et d’intégration des outils de construction dédiés, sa simplicité présente un avantage. Cette approche fonctionne bien pour les thèmes simples avec des besoins de style directs, les prototypes rapides ou les petits projets. Elle peut également convenir à ceux qui préfèrent un outillage minimal.
Comment structurer et organiser un projet de développement WordPress avec Sass ?
Au-delà du processus de construction, organiser efficacement vos fichiers Sass est essentiel pour la maintenabilité et la collaboration. Une structure bien planifiée rend votre code plus facile à naviguer, à mettre à jour et à faire évoluer au fur et à mesure que votre thème grandit.
Le modèle 7-1 : Organisation modulaire pour les thèmes complexes
Le modèle 7-1 est une pratique typique pour organiser les fichiers Sass dans les grands projets. Il divise votre code de style en sept dossiers thématiques plus un fichier principal (main.scss) qui importe tout.
Ce modèle crée une séparation logique, ce qui facilite la recherche et la mise à jour de styles spécifiques. Voici un aperçu de la structure :
- Résumés. Contient des aides qui ne produisent pas de CSS directement, des variables pour les couleurs, la typographie et l’espacement, des fonctions pour les calculs et la logique, des mixins pour les modèles de style réutilisables et des espaces réservés pour les styles extensibles.
- Base. Comprend les styles fondamentaux et les valeurs par défaut, les règles de typographie, les classes utilitaires et les sélecteurs d’éléments (sans classes). Elle vous permet également de réinitialiser ou de normaliser les feuilles de style CSS.
- Composants . Cette section contient les composants réutilisables de l’interface utilisateur tels que les boutons, les formulaires et les cartes, les menus de navigation, les widgets et les colonnes latérales, ainsi que les formats multimédias (tels que les images et les vidéos).
- Mises en page. Vous définissez ici les éléments structurels tels que l’en-tête et le pied de page, les systèmes de grille, les structures de conteneurs et les dispositions des colonnes latérales.
- Pages. Cette section contient les styles spécifiques aux pages, les spécialisations de la page d’accueil, les mises en page d’un seul article, les variations des pages d’archives et les pages de destination spéciales.
- Thèmes. Cette section contient différents thèmes ou modes visuels. Les thèmes clairs et foncés, les variations saisonnières, les personnalisations de la zone d’administration et les thèmes spécifiques à une marque se trouvent tous ici.
- Fournisseurs. La dernière section est celle où vous stockez les styles de tiers, les remplacements d’extensions, les personnalisations du framework et le style des composants externes.
Le fichier principal (généralement main.scss) importe tous les fichiers partiels dans un ordre spécifique :
// Abstracts
@import 'abstracts/variables';
@import 'abstracts/mixins';
// Vendors (early to allow overriding)
@import 'vendors/normalize';
// Base styles
@import 'base/reset';
@import 'base/typography';
// Layout
@import 'layouts/header';
@import 'layouts/grid';
// Components
@import 'components/buttons';
@import 'components/forms';
// Page-specific styles
@import 'pages/home';
@import 'pages/blog';
// Themes
@import 'themes/admin';
Cette approche modulaire permet d’éviter la « soupe CSS » qui affecte souvent les grands projets. C’est un système facile à maintenir qui s’adapte à la complexité de ton thème.
Structure axée sur les blocs : Organisation moderne pour l’éditeur de blocs et de sites
Si votre thème se concentre sur l’éditeur de blocs, une structure qui donnera la priorité à ces composants a souvent plus de sens. Cela permet d’aligner ton organisation Sass sur le modèle de contenu de WordPress basé sur les blocs.
La structure est plus simple par rapport au modèle 7-1 :
- Core. C’est ici que se trouvent les styles et les configurations de base, tels que les variables, les mixins, les helpers, le style des éléments de base et les blocs WordPress de base.
- Blocs. C’est ici que se trouvent les variations personnalisées des blocs, les styles étendus des blocs de base et les styles des modèles de blocs.
- Modèles. C’est ici que vous ajouterez vos modèles d’articles uniques, vos modèles d’archives et vos modèles de pages personnalisées.
- Utilitaires. Il s’agit de classes d’aide et d’outils tels que les utilitaires d’espacement, les classes de typographie et les utilitaires de couleur ou d’arrière-plan.
Cette structure prend en charge la nature modulaire du développement avec Blocks, ce qui facilite le maintien de la cohérence entre tes variations et vos modèles.
Considérations spécifiques à WordPress pour l’organisation de Sass
Lors de l’organisation de Sass pour les thèmes WordPress, plusieurs considérations spécifiques à la plateforme méritent d’être prises en compte. La hiérarchie des modèles de WordPress détermine les fichiers PHP à utiliser pour les différents types de contenu.
Le fait de refléter cette hiérarchie dans votre organisation Sass crée des connexions intuitives entre les modèles PHP et les styles qui leur sont associés. Ainsi, vous devez envisager d’organiser les styles spécifiques à votre page pour qu’ils correspondent à la structure des modèles de WordPress :
// _archive.scss
.archive {
// Base archive styles
&.category {
// Category archive styles
}
&.tag {
// Tag archive styles
}
&.author {
// Author archive styles
}
}Cette approche permet de savoir immédiatement quels styles s’appliquent à des contextes de modèles spécifiques tout en simplifiant la maintenance et les mises à jour.
Organisation de la compatibilité avec les plugins
Les extensions injectent souvent leurs propres styles, et votre thème peut avoir besoin de les remplacer. Plutôt que d’éparpiller les dérogations dans vos fichiers de base, envisagez de les isoler :
Par exemple, la structure pour l’intégration de WooCommerce pourrait prendre l’une des nombreuses structures suivantes :
vendors/woocommerce/
├── _general.scss // Base WooCommerce styles
├── _buttons.scss // WooCommerce button styles
├── _forms.scss // WooCommerce form styles
├── _shop.scss // Shop page styles
└── _single-product.scss // Single product page stylesCette organisation permet de mettre facilement à jour les styles de compatibilité avec l’extension lorsque celle-ci se met à jour, de maintenir la séparation entre les styles du thème et ceux de l’extension, et de trouver rapidement les styles spécifiques liés à l’extension.
Et mettez toujours un espace de noms pour vos remplacements afin d’éviter les collisions de styles :
// _woocommerce.scss
.woocommerce {
.products {
// Custom product grid styles
display: grid;
grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
gap: 2rem;
}
.single-product {
// Single product page styles
.price {
font-size: 1.5rem;
color: $price-color;
}
}
}Cette approche empêche les styles d’extensions de s’infiltrer dans la conception de base de ton thème tout en fournissant des dérogations claires là où vous en avez besoin.
Style de l’éditeur et de l’administrateur
Vous aurez souvent besoin de styliser à la fois la partie frontend et l’interface de l’éditeur de blocs. Vous pouvez donc créer une structure dédiée aux styles spécifiques à l’administrateur :
admin/
├── _editor.scss // Block editor styles
├── _login.scss // Login page customization
└── _dashboard.scss // Dashboard customizationsPour la prise en charge de l’éditeur de blocs, compilez une feuille de style distincte et mets-la en file d’attente comme ceci :
function theme_editor_styles() {
add_theme_support('editor-styles');
add_editor_style('assets/css/editor.css');
}
add_action('after_setup_theme', 'theme_editor_styles');Cela permet de garder le contexte de l’éditeur propre, cohérent et visuellement aligné avec la partie frontend.
Mise en œuvre de la conception responsive
Les thèmes WordPress doivent fonctionner sur différentes tailles d’appareils, vous avez donc besoin d’une approche systématique de votre design responsive. C’est là que l’utilisation des mixins Sass peut créer un système cohérent et facile à maintenir :
// Breakpoint mixin
@mixin respond-to($breakpoint) {
@if $breakpoint == "sm" {
@media (min-width: 576px) { @content; }
}
@else if $breakpoint == "md" {
@media (min-width: 768px) { @content; }
}
@else if $breakpoint == "lg" {
@media (min-width: 992px) { @content; }
}
}Si vous gardez les styles responsives contextuellement proches de ses définitions de base, vous créez une base de code plus facile à maintenir qui montre clairement comment les composants s’adaptent à travers les points de rupture.
Mise en place d’un environnement de développement local
Le développement local est un élément essentiel de tout flux de travail WordPress – et il devient encore plus important lorsque l’on utilise des outils comme Sass. Une configuration adéquate permet une itération rapide, un retour d’information en temps réel et une connexion transparente entre votre processus de construction Sass et votre site WordPress.
DevKinsta est un excellent moyen de mettre en place un environnement de développement local personnalisable en fonction de vos besoins, et l’installation et la configuration sont simples.
L’utilisation de Gulp pour mettre en place la compilation de Sass dans le répertoire de votrethème est l’option la plus simple. Tout d’abord, naviguez dans le répertoire de votre thème, puis initialisez NPM et installez les dépendances comme nous l’avons expliqué précédemment.
Ensuite, créez un site gulpfile.js avec BrowserSync configuré pour votre site DevKinsta :
const { src, dest, watch, series } = require('gulp');
const sass = require('gulp-sass')(require('sass'));
const autoprefixer = require('gulp-autoprefixer');
const sourcemaps = require('gulp-sourcemaps');
const browserSync = require('browser-sync').create();
// Get your DevKinsta site URL from the dashboard
const siteURL = 'your-site-name.local';
function scssTask() {
return src('./src/sass/**/*.scss')
.pipe(sourcemaps.init())
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(sourcemaps.write('./'))
.pipe(dest('./assets/css/'))
.pipe(browserSync.stream());
}
function watchTask() {
browserSync.init({
proxy: siteURL,
notify: false
});
watch('./src/sass/**/*.scss', scssTask);
watch('./**/*.php').on('change', browserSync.reload);
}
exports.default = series(scssTask, watchTask);Puis mettez en place votre structure de fichiers :
mkdir -p src/sass/{abstracts,base,components,layouts,pages,themes,vendors}
touch src/sass/main.scssVous êtes maintenant prêt à lancer npx gulp. Chaque fois qu’un fichier Sass ou PHP sera modifié, vos styles seront compilés, injectés dans le navigateur et rafraîchis si nécessaire.
Passer du développement à la production
Une fois que vous avez développé votre thème localement, vous avez besoin d’une stratégie fiable pour le déployer dans des environnements de staging et de production.
Kinsta facilite cette tâche grâce à des environnements de staging intégrés qui se synchronisent directement avec DevKinsta. En quelques clics, vous pouvez faire passer votre thème de l’environnement local à l’environnement de production :
Cela permet de s’assurer que les fichiers sources CSS et Sass compilés sont transférés en toute sécurité vers la phase de staging. Pour les équipes ayant des besoins de déploiement plus complexes, vous pouvez automatiser les déploiements de la phase de préparation à l’aide de Gulp. Voici un exemple :
const { src, parallel, series } = require('gulp');
const rsync = require('gulp-rsync');
// Clean and build tasks defined earlier
// Deployment task
function deployToStaging() {
return src('dist/**')
.pipe(rsync({
root: 'dist/',
hostname: 'your-kinsta-sftp-host',
destination: 'public/wp-content/themes/your-theme/',
archive: true,
silent: false,
compress: true
}));
}
// Export the deployment task
exports.deploy = series(
parallel(cleanStyles, cleanScripts),
parallel(styles, scripts),
deployToStaging
);Après le déploiement vers le staging, vous devez encore effectuer des tests approfondis pour vous assurer que votre CSS compilé par Sass fonctionne correctement :
- Test visuel. Il s’agit ici de vérifier que tous les styles s’appliquent comme prévu d’une page à l’autre.
- Test responsive. Vérifie que tous vos points de rupture fonctionnent correctement.
- Tests de performance. Google PageSpeed Insights, Lighthouse et d’autres outils peuvent vous aider à vérifier le chargement des CSS.
- Vérification inter-navigateurs. N’oubliez pas de faire des tests sur différents navigateurs pour repérer les problèmes de compatibilité.
Pendant les tests, accordez une attention particulière aux chemins d’accès, aux réglages de cache et aux autorisations de fichiers, car ce sont des causes courantes de problèmes de déploiement. Ensuite, vous pouvez déployer votre thème en production. La poussée séléctive de Kinsta rend ce processus simple tout en gardant le contrôle sur ce que vous déployez.
C’est un autre moment où vous devez vous assurer que votre CSS reçoit une optimisation appropriée avant que vous ne le déployez. Il y a quelques façons de le faire, comme la minification, l’organisation des fichiers et la destruction du cache.
Créer des intégrations efficaces de l’éditeur de blocs
Le développement moderne de WordPress est centré sur l’éditeur de blocs, et un bon style assurera la cohérence entre l’édition et la partie frontend.
Par exemple, plutôt que d’organiser les styles purement en fonction des modèles de page, envisagez plutôt une organisation centrée sur les blocs. Vous pouvez commencer par créer des partiels Sass dédiés à chaque type de bloc :
blocks/
├── _paragraph.scss // Paragraph block styles
├── _heading.scss // Heading block styles
├── _image.scss // Image block styles
├── _gallery.scss // Gallery block styles
└── _custom-block.scss // Custom block stylesCela facilite la maintenance des styles au fur et à mesure que le noyau de WordPress évolue et que la bibliothèque de blocs de votre thème s’agrandit. Les styles de chaque bloc peuvent être conservés et mis à jour indépendamment.
Dans chaque fichier de bloc, cherchez à établir des conventions de dénomination claires qui s’alignent sur les classes de blocs de WordPress :
// _paragraph.scss
.wp-block-paragraph {
// Base paragraph block styles
font-family: $body-font;
line-height: 1.6;
// Block variations
&.is-style-lead {
font-size: 1.2em;
font-weight: 300;
}
&.has-background {
padding: 1.5rem;
}
}Cette approche crée une relation directe entre les commandes de l’éditeur de blocs et les styles qui en résultent, ce qui rend votre thème plus prévisible et plus facile à maintenir.
Pour que l’expérience de l’édition reste synchronisée avec l’interface, compilez des feuilles de style séparées et partagez les variables entre elles :
// In your gulpfile.js
function themeStyles() {
return src('./src/sass/main.scss')
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(dest('./assets/css/'));
}
function editorStyles() {
return src('./src/sass/editor.scss')
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(dest('./assets/css/'));
}Mettez en attente ces styles d’éditeur spécifiquement pour le contexte de l’éditeur de blocs :
function theme_editor_styles() {
add_theme_support('editor-styles');
add_editor_style('assets/css/editor.css');
}
add_action('after_setup_theme', 'theme_editor_styles');Pour maintenir la cohérence visuelle, vous pouvez utiliser des variables et des mixins partagés dans les deux feuilles de style :
// abstracts/_variables.scss
$primary-color: #0073aa;
$secondary-color: #23282d;
$heading-font: 'Helvetica Neue', Helvetica, Arial, sans-serif;
$body-font: 'Georgia', serif;
// Import in both main.scss and editor.scssCette approche permet de s’assurer que les couleurs, la typographie et l’espacement restent cohérents entre les expériences d’édition et de visualisation.
Intégration avec theme.json
Le fichier theme.json est le moyen par lequel les thèmes de Block définissent les paramètres globaux qui affectent à la fois l’éditeur et le frontend. L’alignement des variables Sass sur les réglages de theme.json permet de créer un système cohérent. Par exemple :
{
"version": 2,
"settings": {
"color": {
"palette": [
{
"name": "Primary",
"slug": "primary",
"color": "#0073aa"
}
]
}
}
}Vous pouvez faire correspondre ceci dans vos fichiers Sass :
// Match theme.json values
$color-primary: #0073aa;
// Generate matching custom properties
:root {
--wp--preset--color--primary: #{$color-primary};
}Cette simple synchronisation garantira que vos styles personnalisés fonctionnent en harmonie avec les contrôles intégrés et le système de styles globaux de l’éditeur de blocs.
Optimisation des performances avec Sass
L’optimisation des performances est une considération essentielle pour les thèmes WordPress professionnels. Au-delà de la compilation de base, les flux de travail Sass peuvent apporter plusieurs autres techniques pour améliorer les vitesses de chargement et l’expérience utilisateur (UX).
Mise en œuvre de CSS critiques pour un chargement plus rapide
Le CSS critique est une technique d’optimisation qui extrait et met en ligne le minimum de CSS dont votre site a besoin pour rendre le contenu « au-dessus du pli ». Les chemins de rendu critiques en général sont importants lorsque vous développez pour WordPress ; l’optimisation de votre CSS critique peut améliorer les temps de chargement perçus en réduisant le CSS qui bloque le rendu.
L’écriture de feuilles de style CSS critiques est une compétence en soi – l’ajout de Sass augmentera la difficulté. Vous commencez par créer un fichier Sass séparé spécifiquement pour les styles critiques, puis vous configurez votre processus de construction pour compiler ce fichier séparément :
// critical.scss - Only include styles for above-the-fold content
@import 'abstracts/variables';
@import 'abstracts/mixins';
// Only essential styles
@import 'base/reset';
@import 'layouts/header';
@import 'components/navigation';
function criticalStyles() {
return src('./src/sass/critical.scss')
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(cssnano())
.pipe(dest('./assets/css/'));
}Pour implémenter ce CSS critique dans votre thème, il vous suffit de le mettre en ligne dans les balises head pendant que vous asynchronisez le chargement du CSS de remplissage :
function add_critical_css() {
$critical_css = file_get_contents(get_template_directory() .
'/assets/css/critical.css');
echo '' . $critical_css . '';
// Async load full CSS
echo '';
}
add_action('wp_head', 'add_critical_css', 1);Cette technique permet d’afficher le contenu plus rapidement pendant que le reste des styles se charge en arrière-plan. Cependant, toutes les pages n’ont pas besoin de tous les styles de votre thème. Le chargement conditionnel basé sur le modèle ou le type de contenu actuel peut encore améliorer les performances.
Vous pouvez le faire en chargeant des feuilles de style CSS spécifiques au modèle dans le fichier functions.php de votre thème :
function load_template_specific_css() {
// Base styles for all pages
wp_enqueue_style('main-styles',
get_template_directory_uri() . '/assets/css/main.css');
// Product page specific styles
if (is_singular('product')) {
wp_enqueue_style('product-styles',
get_template_directory_uri() . '/assets/css/product.css');
}
// Archive page specific styles
elseif (is_archive()) {
wp_enqueue_style('archive-styles',
get_template_directory_uri() . '/assets/css/archive.css');
}
}
add_action('wp_enqueue_scripts', 'load_template_specific_css');Cette approche réduit la charge utile CSS de chaque page, améliore les temps de chargement et maintient une qualité de conception élevée.
Mise en place d’un contrôle intelligent du cache
La gestion de votre cache est toujours bénéfique pour l’utilisateur final, car il obtient les styles les plus récents tout en tirant parti de la mise en cache pour les ressources inchangées. L’élimination automatique du cache à l’aide de Sass se produit dans la mise en file d’attente des styles de votre thème :
function enqueue_styles_with_cache_busting() {
$css_file = get_template_directory() . '/assets/css/main.css';
$version = filemtime($css_file);
wp_enqueue_style('main-styles',
get_template_directory_uri() . '/assets/css/main.css',
array(), $version);
}
add_action('wp_enqueue_scripts', 'enqueue_styles_with_cache_busting');Cette technique utilise l’heure de modification du fichier comme numéro de version, ce qui garantit que les navigateurs ne mettent en cache que les feuilles de style CSS jusqu’à ce qu’elles soient modifiées, puis qu’ils téléchargent automatiquement la version mise à jour.
Gérer les cartes de source en toute sécurité
Les cartes de source sont inestimables pendant le développement, mais elles peuvent exposer votre code source Sass en production. C’est là que la mise en œuvre d’une gestion des cartes de source spécifique à l’environnement peut s’avérer utile :
// In your gulpfile.js
const isProduction = process.env.NODE_ENV === 'production';
function styles() {
return src('./src/sass/main.scss')
.pipe(gulpif(!isProduction, sourcemaps.init()))
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(gulpif(!isProduction, sourcemaps.write('./')))
.pipe(dest('./assets/css/'));
}Pour un débogage contrôlé en production, vous pouvez vouloir fournir les cartes de source uniquement aux administrateurs :
function conditional_source_maps() {
// Only for administrators with debug parameter
if (current_user_can('manage_options') && isset($_GET['debug_css'])) {
wp_enqueue_style('debug-maps',
get_template_directory_uri() . '/assets/css/main.css.map');
}
}
add_action('wp_enqueue_scripts', 'conditional_source_maps', 999);Cela permet de conserver les avantages des cartes de source pour le débogage et de protéger votre code source d’une exposition inutile – une grande victoire pour tout le monde.
Créer des flux de travail d’équipe efficaces
Des flux de travail et des normes cohérents sont essentiels pour toute équipe travaillant sur des thèmes WordPress avec Sass. Pour les flux de travail spécifiques à Sass, vous devriez chercher à établir des normes claires dans quelques domaines clés.
Par exemple, cherchez à définir des conventions et des modèles de dénomination cohérents pour les variables, les mixins et les classes :
// Variables: use kebab-case with descriptive prefixes
$color-primary: #0073aa;
$font-heading: 'Helvetica Neue', sans-serif;
$spacing-base: 1rem;
// Mixins: verb-based naming
@mixin create-gradient($start, $end) {
background: linear-gradient(to bottom, $start, $end);
}
// Classes: BEM convention
.card {
&__header { /* header styles */ }
&__body { /* body styles */ }
&--featured { /* featured variant */ }
}C’est aussi une bonne idée de normaliser la façon dont les nouveaux fichiers rejoignent le projet. Voici quelques exemples de normes que tu pourrais mettre en place :
- Les nouveaux composants seront placés dans le répertoire des composants.
- Chaque composant reçoit son propre fichier.
- Tous les fichiers utiliseront le même ordre d’importation.
- Les partiels commencent toujours par un trait de soulignement.
En outre, vous pouvez également définir des exigences pour les commentaires de code et la documentation. Vous pouvez « codifier » ces normes dans un fichier de configuration .stylelintrc pour en automatiser l’application :
{
"extends": "stylelint-config-standard-scss",
"rules": {
"indentation": 2,
"selector-class-pattern": "^[a-z][a-z0-9-]*$",
"max-nesting-depth": 3,
"selector-max-compound-selectors": 4
}
}Les révisions de code sont importantes pour Sass car de petites modifications peuvent avoir des effets considérables sur l’apparence de votre thème. Vos propres processus de révision devraient aborder spécifiquement la question du style de quelques façons :
- Conformité au guide de style. Assurez-vous que les nouveaux styles respectent le système de conception actuel de votre projet.
- Considérations sur les performances. Examinez tous les résultats de ton CSS pour voir s’il y a des possibilités d’optimisation.
- Compatibilité inter-navigateurs. Vérifiez que les styles que vous avez créés fonctionneront dans tous les navigateurs nécessaires.
Bien sûr, vous devrez inclure ces préoccupations spécifiques à Sass dans les listes de contrôle de révision du code de votre équipe afin de maintenir des normes élevées dans l’ensemble de votre base de code.
Stratégies de contrôle de version pour les projets Sass
Il y a plusieurs considérations spécifiques à Sass dans le cadre du contrôle de version qui méritent votre attention. L’une des décisions les plus importantes est celle de savoir si vous devez livrer vos feuilles de style CSS compilées. Il existe deux écoles de pensée qui pèseront dans votre choix :
- Ne pas livrer le CSS permet de garder votre dépôt propre mais nécessite des étapes de construction lors du déploiement.
- Transférer le CSS augmentera la taille de votre dépôt, mais garantira également que les fichiers que vous déploierez correspondront exactement à ce que vous avez testé.
Si vous choisissez de ne pas livrer les fichiers compilés, vous devrez vous assurer qu’ils bénéficient d’une exclusion appropriée dans votre fichier .gitignore :
# .gitignore
.sass-cache/
*.css.map
*.scss.map
node_modules/
/assets/css/Enfin, examinez la structure de vos branches pour le travail sur le style et réfléchissez à la façon dont vous gèrez ces changements de style pour les nouveaux composants (comme les branches de fonctionnalités), les variations visuelles (qui pourraient utiliser des branches de thèmes), et les mises à jour majeures du design (peut-être en utilisant des branches spécifiques au style).
Résumé
Un flux de travail Sass moderne peut transformer le développement de votre thème WordPress d’un défi en un processus structuré et facile à maintenir.
Les éléments clés d’un flux de travail Sass efficace comprennent un processus de construction simple mais performant, une organisation des fichiers réfléchie, des optimisations de performance et des flux de travail d’équipe solides. Au fur et à mesure que l’Éditeur de blocs évolue, une implémentation Sass flexible et robuste vous permet de vous adapter tout en continuant à fournir des résultats de haute qualité.
Et si vous cherchez un hébergement WordPress qui prenne en charge ce type de flux de travail – de l’accès SSH et WP-CLI aux environnements de staging en un clic – Kinsta offre une plateforme adaptée aux développeurs, construite pour prendre en charge des outils modernes dès la départ.
