Het maken van moderne, onderhoudbare CSS voor WordPress thema’s gaat gepaard met verschillende uitdagingen waar ontwikkelaars mee om moeten gaan. Het gebruik van Sass (Syntactically Awesome Style Sheets) als je CSS preprocessor kan je helpen om je stijlen effectiever te organiseren, te onderhouden én op te schalen.

Het opzetten van een efficiënte Sass workflow die op natuurlijke wijze past in WordPress ontwikkeling vereist echter doordachte planning en technische kennis.

Deze gids laat je zien hoe je een professionele Sass workflow opzet voor de ontwikkeling van WordPress thema’s. Het behandelt moderne bouwtools, slimme bestandsorganisatie en implementatiepraktijken die de productiviteit verhogen en je stijlen onderhoudbaar houden.

Achtergrondinformatie over het gebruik van Sass voor WordPress ontwikkeling

Professionele WordPress ontwikkeling is vaak afhankelijk van tools en workflows die verder gaan dan de ingebouwde mogelijkheden van het platform. Sass kan een belangrijke rol spelen door je te helpen de complexiteit van CSS te beheren met functies als variabelen, nesting, mixins, imports en ingebouwde features.

De homepage van de Sass programmeertaal met het Sass logo in roze, een navigatiemenu en de slogan “CSS met superkrachten”. Hieronder staat wat beschrijvende tekst voor Sass. Het ontwerp bevat een illustratie van een groenblauwe cat-eye bril en paragrafen die de functionaliteit en voordelen van Sass benadrukken.
De Sass website.

Sass biedt verschillende voordelen voor het ontwikkelen van thema’s. Een typisch WordPress thema bevat stijlen voor talloze componenten en template parts. In plaats van alles in een enkel, log stylesheet te beheren, maakt Sass een modulaire architectuur mogelijk die de onderhoudbaarheid en schaalbaarheid bevordert door middel van een programmatische structuur.

Deze gestructureerde aanpak gaat verder dan wat standaard CSS biedt en sluit goed aan bij de unieke stylingeisen van WordPress. In tegenstelling tot het gebruik van style.css met WordPress, kun je met Sass modulaire, doelgerichte stylesheets maken die worden gecompileerd in geoptimaliseerde CSS bestanden met behulp van een eenvoudige workflow:

  1. Een bouwproces om Sass bestanden te compileren tot CSS.
  2. Een bestandsstructuur om je stijlen op een onderhoudbare manier te organiseren.
  3. Ontwikkeltools voor lokaal testen en kwaliteitscontrole.
  4. Implementatiestrategieën om wijzigingen naar test- en productieomgevingen te pushen.

Hoe je deze workflow implementeert hangt af van de voorkeuren van je team voor tooling, de technische stack en de complexiteit van je project. Maar de meeste Sass-gebaseerde WordPress opstellingen volgen een paar algemene werkwijzen: het configureren van source maps voor debuggen, het bekijken van bestanden tijdens ontwikkeling en het optimaliseren van output voor productie.

Een typische opzet scheidt je Sass bronbestanden van gecompileerde assets, waardoor het eenvoudiger wordt om je codebase te onderhouden en strakke uitvoer naar de browser te leveren.

3 manieren om Sass te compileren in WordPress projecten

De basis van elke Sass workflow is het bouwproces dat je Sass bestanden omzet in browser-ready CSS. Er zijn verschillende manieren om dit in WordPress te implementeren.

1. Met behulp van plugins: De ongecompliceerde aanpak

De meest toegankelijke manier om Sass te gebruiken in een WordPress thema is via plugins. Deze aanpak is ideaal als je net begint of werkt aan een klein project waarvoor je geen volledige build pipeline nodig hebt.

WP-Sass bijvoorbeeld voert de compilatie uit via WordPress’s eigen action hooks binnen wp-config.php en controleert de Sass map van je thema op wijzigingen:

<?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' );

?>

Een andere optie, Sassify, is al wat ouder en heeft een andere aanpak: het haakt in op de API’s van WordPress om de compilatie, uitvoerpaden en compressie-instellingen van Sass te beheren.

Hoewel op plugins gebaseerde oplossingen eenvoudig zijn, hebben ze een paar beperkingen:

  • Prestatie-overhead. Deze plugins compileren Sass op de server, wat aanzienlijke resources kan verbruiken.
  • Beperkte bouwopties. De meeste Sass plugins bieden basic compilatie maar missen essentiële functionaliteit. Er is bijvoorbeeld vaak beperkte ondersteuning voor source maps, ontbrekende autoprefixing mogelijkheden en meer.
  • Beveiligingsoverwegingen. Het draaien van een compiler op je productieserver kan het potentiële aanvalsoppervlak vergroten, vooral als de plugin niet regelmatig wordt onderhouden.
  • Versiebeheer problemen. Gecompileerde CSS bestanden staan vaak in je themamap, wat schone Git workflows bemoeilijkt. In het ideale geval zouden gecompileerde bestanden uit je repo moeten blijven.

Maar ondanks deze beperkingen is een plugin nog steeds een goede optie in bepaalde scenario’s. Bijvoorbeeld kleine sites met minimale stylingvereisten, een project overdragen aan een klant zonder de technische expertise om op een dieper niveau met Sass te werken, of werken met beperkte dev resources.

2. NPM scripts gebruiken: De evenwichtige oplossing

Als je op zoek bent naar meer controle en flexibiliteit, dan kunnen NPM scripts een goed alternatief zijn voor plugins. Sass compilatie is een ideale taak voor NPM, omdat het een balans vindt tussen eenvoud en mogelijkheden. Het biedt aanzienlijke verbeteringen ten opzichte van plugins voor het ontwikkelen van thema’s zonder de complexiteit van volledige task runners:

  • Door de compilatie gescheiden te houden van de uitvoering van WordPress, elimineer je de overhead van serverprestaties.
  • Je krijgt precieze controle over elke stap van het compilatieproces.
  • Het package.json bestand zorgt ervoor dat alle teamleden hetzelfde bouwproces gebruiken.
  • npm scripts integreren naadloos met CI/CD pijplijnen.

Hoewel deze aanpak meer initiële instellingen vereist dan plugins, biedt het een robuustere en schaalbare oplossing voor de ontwikkeling van professionele thema’s.

Sass compilatie instellen met NPM

Begin met het maken van een package.json bestand. Je kunt dit doen door uit te voeren:

npm init -y

Installeer vervolgens Dart Sass:

npm install sass --save-dev

Voeg vervolgens deze scripts toe aan je 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"
  }
}

Deze opstelling geeft je drie handige scripts:

  • npm run sass compileert je Sass bestanden één keer.
  • sass:watch kijkt of er wijzigingen zijn en compileert opnieuw als dat nodig is.
  • build compileert je Sass bestanden voor productie met compressie.

Voeg Autoprefixer toe via PostCSS om oudere browsers te ondersteunen:

npm install postcss postcss-cli autoprefixer --save-dev

Werk je package.json scripts bij:

{
  "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%"
  ]
}

Voeg source maps toe om te helpen bij het debuggen:

{
  "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"
  }
}

Tot slot, om je gecompileerde CSS te gebruiken in WordPress, enqueue je je gecompileerde CSS in 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');

Deze functie laadt je gecompileerde CSS en voegt automatische cache busting toe door de modificatietijd van het bestand te gebruiken als versienummer.

3. Gulp gebruiken: De uitgebreide oplossing

Gulp is een krachtige task runner die uitblinkt in het automatiseren van complexe bouwprocessen. Voor de ontwikkeling van WordPress thema’s met uitgebreide stylingbehoeften kan het de meest uitgebreide oplossing zijn.
Het stelt je in staat om Sass compilatie, browsersynchronisatie en alles daar tussenin af te handelen. Waarom Gulp?

  • Gulp beheert bijna elk aspect van je bouwproces, zoals compilatie, optimalisatie en implementatie.
  • Je kunt meerdere taken tegelijk uitvoeren, wat de bouwtijden verkort.
  • Het ecosysteem biedt tools voor vrijwel elke bouwbehoefte.
  • De BrowserSync integratie zorgt voor directe feedback tijdens het ontwikkelen.

Hoewel Gulp een steilere leercurve heeft dan andere benaderingen, zorgen de voordelen ervoor dat het voor velen de voorkeur geniet.

Gulp instellen voor WordPress thema’s

Om aan de slag te gaan met Gulp moet je het installeren samen met verschillende plugins die specifieke taken uitvoeren:

# 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-cssnano

Je moet ook een gulpfile.js aanmaken in de hoofdmap van je thema, die een paar verschillende stappen afhandelt. Dit eerste deel is een manier om alle benodigde tools te importeren:

// 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');

Elk pakket dient een specifiek doel:

  • gulp: de kerntaak runner.
  • gulp-sass en sass: compileert Sass naar CSS.
  • gulp-autoprefixer: voegt leveranciersvoorvoegsels toe voor browsercompatibiliteit.
  • gulp-sourcemaps: genereert bronmappen voor debuggen.
  • browser-sync: ververst browsers tijdens ontwikkeling.
  • gulp-cssnano: minificeert CSS voor productie.

Vanaf hier kun je paden definiëren naar je bron- en doelbestanden en een functie maken om Sass te compileren:

// 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());
}

Deze functie vindt in wezen al je Sass bestanden, initialiseert source maps voor debuggen en compileert Sass naar CSS (met foutafhandeling). Het voegt ook vendor prefixes toe voor browsercompatibiliteit, schrijft je source maps, slaat de gecompileerde CSS op en werkt de browser bij met wijzigingen. Al met al een hoop werk!

Je moet ook kijken naar het maken van een productieklare bouwfunctie, een task watcher en een exporteerfunctie:

// 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;

Deze productieversie laat sourcece maps weg en voegt minification toe voor optimale bestandsgrootte. Over het geheel genomen kun je met deze setup npx gulp gebruiken voor ontwikkeling (met bestandsmonitoring en browserverversing) en npx gulp build voor productie builds.

Je Gulp workflow verbeteren

Voor grotere projecten wil je misschien stijlen scheiden voor verschillende doeleinden. Hier is een voorbeeld:

// 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());
}

Voor complexe thema’s met veel Sass bestanden moet je ook de bouwprestaties optimaliseren door verwerkte bestanden te cachen om onnodige hercompilatie te voorkomen, Sass dependencies bij te houden om alleen de betreffende bestanden te hercompileren en meer. Dit valt echter buiten het bestek van dit artikel.

Andere bouwtools die het overwegen waard zijn

Hoewel de meeste ontwikkelaars vasthouden aan NPM scripts of Gulp, zijn er verschillende andere alternatieven die unieke voordelen bieden voor de ontwikkeling van WordPress thema’s. Vite en Webpack zijn twee veelgebruikte oplossingen.

Webpack blinkt uit in het bundelen van JavaScript en assets, wat ideaal is als je thema gebruik maakt van componentgebaseerde architecturen of JavaScript frameworks. De kracht ligt in de mogelijkheid om geoptimaliseerde bundels te maken door code op te splitsen en ’tree shaking’ – waardevol voor complexe, JavaScript-intensieve thema’s.

Vite is daarentegen een nieuwere buildtool die prioriteit geeft aan ontwikkelingssnelheid door zijn innovatieve benadering van het laden van modules. Zijn ontwikkelserver biedt bijna onmiddellijke vervanging van warme modules. Dit is een snelle manier om iteratieve ontwikkeling te implementeren. Hoewel de integratie met WordPress workflows zich blijft ontwikkelen, is het een interessante optie als je het kunt gebruiken voor je eigen thema-ontwikkeling.

Voor eenvoudigere projecten of persoonlijke voorkeur biedt de Sass CLI een eenvoudige aanpak zonder extra gereedschap:

# Install Sass globally
npm install -g sass

# Compile Sass files
sass --watch src/sass/main.scss:assets/css/main.css

Hoewel handmatige compilatie de automatiserings- en integratiemogelijkheden van speciale bouwtools mist, heeft de eenvoud wel een voordeel. Deze aanpak werkt goed voor eenvoudige thema’s met eenvoudige stylingbehoeften, snelle prototypes of kleine projecten. Het kan ook geschikt zijn voor mensen die de voorkeur geven aan minimale hulpmiddelen.

Hoe je een WordPress ontwikkelproject met Sass kunt structureren en organiseren

Naast het bouwproces is het effectief organiseren van je Sass bestanden essentieel voor onderhoudbaarheid en samenwerking. Een goed geplande structuur maakt je code makkelijker te navigeren, bij te werken en op te schalen als je thema groeit.

Het 7-1 patroon: Modulaire organisatie voor complexe thema’s

Het 7-1 patroon is een typische methode voor het organiseren van Sass bestanden in grote projecten. Het verdeelt je stylingcode in zeven thematische mappen plus één hoofdbestand (main.scss) dat alles importeert.

Dit patroon creëert een logische scheiding, waardoor het gemakkelijker wordt om specifieke stijlen te vinden en bij te werken. Hier is een overzicht van de structuur:

  • Abstracts. Bevat helpers die niet direct CSS uitvoeren, variabelen voor kleuren, typografie en spatiëring, functies voor berekeningen en logica, mixins voor herbruikbare stijlpatronen en plaatshouders voor uitbreidbare stijlen.
  • Basis. Bevat fundamentele stijlen en standaardinstellingen, typografische regels, hulpprogramma klassen en element selectoren (zonder klassen). Hiermee kun je ook CSS resetten of normaliseren.
  • Componenten. Dit bevat herbruikbare UI-componenten zoals knoppen, formulieren en kaarten, navigatiemenu’s, widgets en zijbalken, en mediaformaten (zoals afbeeldingen en video’s).
  • Lay-outs. Hier definieer je structurele elementen zoals je header en footer, rastersystemen, containerstructuren en zijbalkindelingen.
  • Pagina’s. Dit bevat paginaspecifieke stijlen, home pagina specialisaties, enkele post lay-outs, archiefpagina variaties en speciale landingspagina’s.
  • Thema’s. Voor deze sectie heb je verschillende visuele thema’s of modi. Lichte en donkere thema’s, seizoensgebonden variaties, aanpassingen in het beheergebied en merkspecifieke thema’s vind je hier allemaal.
  • Leveranciers. De laatste sectie is waar je stijlen van derden, plugin overschrijvingen, framework aanpassingen en externe component styling opslaat.

Het hoofdbestand (meestal main.scss) importeert alle onderdelen in een specifieke volgorde:

// 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';

Deze modulaire aanpak kan de ‘CSS-soep’ voorkomen die vaak grotere projecten teistert. Het is een onderhoudbaar systeem dat meegroeit met de complexiteit van je thema.

Op blokken gerichte structuur: Moderne organisatie voor de blok- en site-editor

Als je thema zich richt op de Block Editor, is een structuur die prioriteit geeft aan deze componenten vaak zinvoller. Dit kan je Sass-organisatie afstemmen op het op blokken gebaseerde inhoudsmodel van WordPress.

De structuur is rechtlijniger in vergelijking met het 7-1 Patroon:

  • Kern. Je basis stijlen en configuraties zitten hier, zoals variabelen, mixins, helpers, basis element styling en WordPress Blocks.
  • Blokken. Hier vind je aangepaste Block variaties, uitgebreide Block stijlen en Block patroon stijlen.
  • Sjablonen. Hier voeg je je sjablonen voor afzonderlijke berichten, archiefsjablonen en aangepaste paginasjablonen toe.
  • Hulpprogramma’s. Dit zijn hulpprogramma’s en -klassen zoals hulpprogramma’s voor spatiëring, typografie en kleuren of achtergronden.

Deze structuur ondersteunt de modulaire aard van het ontwikkelen met blokken, waardoor het gemakkelijker wordt om consistentie te behouden tussen je variaties en sjablonen.

WordPress-specifieke overwegingen voor Sass organisatie

Bij het organiseren van Sass voor WordPress thema’s verdienen verschillende platformspecifieke overwegingen aandacht. De sjabloonhiërarchie van WordPress bepaalt welke PHP-bestanden moeten worden gebruikt voor verschillende inhoudstypen.

Door deze hiërarchie te spiegelen in je Sass organisatie creëer je intuïtieve verbanden tussen PHP sjablonen en hun bijbehorende stijlen. Overweeg daarom om je paginaspecifieke stijlen zo te organiseren dat ze overeenkomen met de WordPress sjabloonstructuur:

// _archive.scss
.archive {
  // Base archive styles
  
  &.category {
    // Category archive styles
  }
    
  &.tag {
    // Tag archive styles
  }
    
  &.author {
    // Author archive styles
  }
}

Deze aanpak maakt het meteen duidelijk welke stijlen van toepassing zijn op specifieke sjablooncontexten, terwijl het onderhoud en updates vereenvoudigt.

Plugin compatibiliteit organiseren

Plugins injecteren vaak hun eigen stijlen, en het kan nodig zijn dat je thema deze moet overschrijven. In plaats van overrides te verspreiden over je basisbestanden, kun je overwegen om ze te isoleren:

De structuur voor WooCommerce integratie kan bijvoorbeeld een van de volgende structuren aannemen:

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 styles

Deze organisatie maakt het gemakkelijk om plugin compatibiliteitsstijlen bij te werken wanneer de plugin wordt bijgewerkt, de scheiding tussen thema- en plugin-stijlen te behouden en specifieke plugin-gerelateerde stijlen snel te vinden.

En geef je overrides altijd een namespace om stijlbotsingen te voorkomen:

// _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;
    }
  }
}

Deze aanpak voorkomt dat plugin stijlen weglekken in het kernontwerp van je thema, terwijl je duidelijke overrides krijgt waar je ze nodig hebt.

Editor- en beheerstijlen

Vaak moet je zowel de voorkant als de interface van de Block Editor stylen. Daarom kun je een speciale structuur maken voor admin-specifieke stijlen:

admin/
├── _editor.scss         // Block editor styles
├── _login.scss          // Login page customization
└── _dashboard.scss      // Dashboard customizations

Voor Block Editor ondersteuning compileer je een apart stylesheet enqueue je het als volgt:

function theme_editor_styles() {
  add_theme_support('editor-styles');
  add_editor_style('assets/css/editor.css');
}
add_action('after_setup_theme', 'theme_editor_styles');

Dit houdt de context van je editor schoon, consistent en visueel uitgelijnd met de front-end.

Responsive ontwerp implementatie

WordPress thema’s moeten werken op verschillende apparaat-indelingen, dus je hebt een systematische aanpak nodig voor je responsive design. Dit is waar het gebruik van Sass mixins een consistent, onderhoudbaar systeem kan creëren:

// 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; }
  }
}

Als je responsieve stijlen contextueel dicht bij de basisdefinities houdt, creëer je een beter onderhoudbare codebase die duidelijk laat zien hoe componenten zich aanpassen over breekpunten heen.

Een lokale ontwikkelomgeving opzetten

Lokale ontwikkeling is een kernonderdeel van elke WordPress workflow – en het wordt nog belangrijker als je tools als Sass gebruikt. Een goede setup maakt snelle iteratie, real-time feedback en een naadloze verbinding tussen je Sass bouwproces en je WordPress site mogelijk.

DevKinsta is een geweldige manier om een lokale ontwikkelomgeving op te zetten die je kunt aanpassen aan je behoeften, en de installatie en instelling is eenvoudig.

Een gestileerde digitale illustratie in blauwe tinten van handen die een computer gebruiken. Een hand typt op een toetsenbord terwijl een andere wijst naar een computermonitor waarop een witte letter “K” staat op een blauwe achtergrond. De illustratie heeft een moderne, graphic design uitstraling met abstracte vormen op de achtergrond.
Het DevKinsta logo.

Gulp gebruiken om de Sass compilatie in je themamap in te stellen is de meest eenvoudige optie. Navigeer eerst naar je themamap, initialiseer dan NPM en installeer de afhankelijkheden zoals we eerder hebben uitgelegd.

Maak vervolgens een gulpfile.js met BrowserSync geconfigureerd voor je DevKinsta site:

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);

Stel vervolgens je bestandsstructuur in:

mkdir -p src/sass/{abstracts,base,components,layouts,pages,themes,vendors}
touch src/sass/main.scss

Nu ben je klaar om npx gulp uit te voeren. Elke keer dat een Sass of PHP bestand verandert, worden je stijlen gecompileerd, in de browser geïnjecteerd en vernieuwd als dat nodig is.

Van ontwikkeling naar productie

Zodra je je thema lokaal hebt ontwikkeld, heb je een betrouwbare strategie nodig om het uit te rollen naar test- en productieomgevingen.

Kinsta maakt dit eenvoudig met ingebouwde testomgevingen die direct synchroniseren met DevKinsta. Met slechts een paar klikken kun je je thema van lokaal naar staging verplaatsen:

De MyKinsta interface met bovenaan knoppen voor Push omgeving, Open WP Admin en Bezoek site. Daaronder is een beige gedeelte met Push to Live tekst en een groene pilvormige knop met het label Live. De interface toont ook een sectie voor Updates.
De Push to Live drop-down optie binnen het MyKinsta dashboard.

Dit zorgt ervoor dat zowel je gecompileerde CSS als je Sass bronbestanden veilig naar staging worden verplaatst. Voor teams met complexere implementatiebehoeften kun je staging implementaties automatiseren met Gulp. Hier is een voorbeeld:

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
);

Na het uitrollen naar staging moet je nog steeds grondig testen om er zeker van te zijn dat je met Sass gecompileerde CSS correct werkt:

  1. Visueel testen. Controleer hier of alle stijlen op de pagina’s worden toegepast zoals verwacht.
  2. Responsive testen. Controleer of al je breakpoints correct werken.
  3. Prestaties testen. Google PageSpeed Insights, Lighthouse en andere tools kunnen je helpen bij het controleren van het laden van CSS.
  4. Cross-browser controle. Vergeet niet te testen op verschillende browsers om compatibiliteitsproblemen op te sporen.

Besteed tijdens het testen speciale aandacht aan paden, cache-instellingen en bestandsrechten, want dit zijn veelvoorkomende oorzaken van problemen met de implementatie. Vervolgens kun je je thema uitrollen naar productie. Kinsta’s Selectieve Push maakt dit proces eenvoudig met behoud van controle over wat je uitrolt.

Het dialoogvenster Push to Live dat verschijnt bij het deployen vanuit een testomgeving binnen MyKinsta. Het modale venster toont opties voor wat te pushen van staging naar live, met selectievakjes voor Bestanden, Database en het uitvoeren van een zoek- en vervangactie. Een drop-down menu toont Alle bestanden en mappen is geselecteerd, en er is een opmerking dat MyKinsta een automatische backup zal maken van de live omgeving.
Kinsta’s Selective Push feature.

Dit is een ander moment waarop je ervoor moet zorgen dat je CSS goed wordt geoptimaliseerd voordat je het uitrolt. Er zijn een paar manieren om dit te doen, zoals minificatie, bestandsorganisatie en cache busting.

Effectieve Block Editor integraties maken

Moderne WordPress ontwikkeling draait om de Block Editor en een goede styling zorgt voor consistentie tussen het bewerken en de front-end.

Bijvoorbeeld, in plaats van stijlen puur op pagina templates te organiseren, kun je in plaats daarvan een blokgerichte organisatie overwegen. Je kunt beginnen met het maken van speciale Sass partials voor elk bloktype:

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 styles

Dit maakt het eenvoudiger om stijlen te onderhouden als de core van WordPress evolueert en de Block bibliotheek van je thema groeit. De stijlen van elk blok kunnen netjes worden ingeperkt en onafhankelijk van elkaar worden bijgewerkt.

Probeer binnen elk Block bestand duidelijke naamgevingsconventies op te stellen die overeenkomen met de Block klassen van 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;
  }
}

Deze aanpak creëert een directe relatie tussen de besturingselementen van de Block Editor en de resulterende stijlen, wat je thema voorspelbaarder en beter onderhoudbaar maakt.

Om de bewerkingservaring synchroon te houden met de front-end, stel je aparte stylesheets samen en deel je variabelen tussen de stylesheets:

// 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/'));
}

Enqueue deze editor stijlen specifiek voor de Block Editor context:

function theme_editor_styles() {
  add_theme_support('editor-styles');
  add_editor_style('assets/css/editor.css');
}
add_action('after_setup_theme', 'theme_editor_styles');

Om visuele consistentie te behouden, kun je gedeelde variabelen en mixins gebruiken in beide stylesheets:

// 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.scss

Deze aanpak zorgt ervoor dat kleuren, typografie en spatiëring consistent blijven tussen de bewerkings- en weergave-ervaring.

Integreren met theme.json

Het theme.json bestand is hoe Block thema’s globale instellingen definiëren die zowel de editor als de voorkant beïnvloeden. Door je Sass variabelen af te stemmen op theme.json instellingen kun je een samenhangend systeem creëren. Bijvoorbeeld:

{
  "version": 2,
  "settings": {
    "color": {
      "palette": [
        {
          "name": "Primary",
          "slug": "primary",
          "color": "#0073aa"
        }
      ]
    }
  }
}

Je kunt dit afstemmen in je Sass bestanden:

// Match theme.json values
$color-primary: #0073aa;

// Generate matching custom properties
:root {
  --wp--preset--color--primary: #{$color-primary};
}

Deze eenvoudige synchronisatie zorgt ervoor dat je aangepaste stijlen in harmonie werken met de ingebouwde besturingselementen en het globale stijlsysteem van de Block Editor.

Prestatieoptimalisatie met Sass

Prestatieoptimalisatie is een kritische overweging voor professionele WordPress thema’s. Naast basiscompilatie kunnen Sass workflows verschillende andere technieken gebruiken om laadsnelheden en de gebruikerservaring (UX) te verbeteren.

Kritische CSS implementeren om sneller te laden

Kritische CSS is een optimalisatietechniek die de minimale CSS die je site nodig heeft om inhoud ‘above the fold’ te renderen, eruit haalt en inlineërt. Kritische renderpaden in het algemeen zijn belangrijk bij het ontwikkelen voor WordPress; het optimaliseren van je kritieke CSS kan de waargenomen laadtijden verbeteren door het verminderen van render-blocking CSS.

Het schrijven van kritische CSS is een vaardigheid op zich – het toevoegen van Sass zal de moeilijkheidsgraad verhogen. Je begint met het maken van een apart Sass bestand speciaal voor kritieke stijlen en configureert vervolgens je bouwproces om dit bestand apart te compileren:

// 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/'));
}

Om deze kritieke CSS in je thema te implementeren, inline je het eenvoudigweg in de head tags terwijl je de CSS vulling async laadt:

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);

Deze techniek kan de inhoud sneller weergeven terwijl de rest van de stijlen op de achtergrond wordt geladen. Niet elke pagina heeft echter alle stijlen van je thema nodig. Voorwaardelijk laden op basis van het huidige template of inhoudstype kan de prestaties nog meer verbeteren.

Je kunt dit doen door template-specifieke CSS te laden in de functions.php van je thema:

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');

Deze aanpak vermindert de CSS belasting van elke pagina, verbetert de laadtijden en behoudt een hoge ontwerpkwaliteit.

Slim cachebeheer implementeren

Het beheren van je cache is altijd in het voordeel van de eindgebruiker, omdat ze de nieuwste stijlen krijgen terwijl ze gebruik maken van caching voor onveranderde assets. Automatische cache-busting met behulp van Sass gebeurt binnen de style enqueuing van je thema:

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');

Deze techniek gebruikt de wijzigingstijd van het bestand als een versienummer, wat ervoor zorgt dat browsers CSS alleen cachen totdat het wordt gewijzigd, waarna automatisch de bijgewerkte versie wordt gedownload.

Source maps veilig beheren

Source maps zijn van onschatbare waarde tijdens de ontwikkeling, maar kunnen je Sass broncode blootgeven in productie. Dit is waar het implementeren van omgevingsspecifieke source map afhandeling handig kan zijn:

// 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/'));
}

Voor gecontroleerd debuggen in productie wil je source maps misschien alleen aan beheerders beschikbaar stellen:

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);

Dit behoudt de voordelen van source maps voor debuggen en beschermt je broncode tegen onnodige blootstelling – een groot voordeel voor iedereen.

Effectieve teamworkflows bouwen

Consistente workflows en standaarden zijn essentieel voor elk team dat werkt aan WordPress thema’s met Sass. Voor Sass-specifieke workflows moet je duidelijke standaarden opstellen op een paar belangrijke gebieden.

Probeer bijvoorbeeld consistente naamgevingsconventies en -patronen te definiëren voor variabelen, mixins en klassen:

// 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 */ }
}

Het is een goed idee om ook te standaardiseren hoe nieuwe bestanden aan het project worden toegevoegd. Hier zijn enkele voorbeeldstandaarden die je zou kunnen implementeren:

  • Nieuwe componenten komen in de components directory.
  • Elk component krijgt zijn eigen bestand.
  • Alle bestanden gebruiken dezelfde importvolgorde.
  • Partials beginnen altijd met een underscore.

Definieer daarnaast ook eisen voor codecommentaar en documentatie. Je kunt deze standaarden ‘codificeren’ in een .stylelintrc configuratiebestand om de handhaving te automatiseren:

{
  "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
  }
}

Codebeoordelingen zijn belangrijk voor Sass omdat kleine wijzigingen verstrekkende gevolgen kunnen hebben voor het uiterlijk van je thema. Je eigen beoordelingsprocessen moeten specifiek gericht zijn op styling op een paar manieren:

  • Naleving van de stijlgids. Zorg ervoor dat nieuwe stijlen voldoen aan het huidige ontwerpsysteem van je project.
  • Prestatie-overwegingen. Controleer al je CSS-uitvoer op optimalisatiemogelijkheden.
  • Cross-browser compatibiliteit. Controleer of de stijlen die je maakt werken in alle vereiste browsers.

Natuurlijk moet je deze Sass specifieke aandachtspunten opnemen in de checklists voor codebeoordeling van je team om hoge standaarden te handhaven in je codebase.

Versiebeheerstrategieën voor Sass projecten

Er zijn verschillende Sass-specifieke overwegingen binnen versiebeheer die je aandacht verdienen. Een belangrijke beslissing is of je je gecompileerde CSS commit. Er zijn twee stromingen die meewegen in je keuze:

  • CSS niet committen houdt je repo schoon, maar vereist bouwstappen tijdens de implementatie.
  • Het committen van de CSS zal de grootte van je repo vergroten, maar zal er ook voor zorgen dat de bestanden die je uitrolt precies overeenkomen met wat je test.

Als je ervoor kiest om gecompileerde bestanden niet vast te leggen, dan wil je er zeker van zijn dat ze de juiste uitsluiting krijgen in je .gitignore bestand:

# .gitignore
.sass-cache/
*.css.map
*.scss.map
node_modules/
/assets/css/

Bekijk tot slot je branchstructuur voor stijlwerk en overweeg hoe je die stijlveranderingen beheert voor nieuwe onderdelen (zoals feature branches), visuele variaties (die thema branches zouden kunnen gebruiken) en grote ontwerpupdates (misschien met behulp van stijl-specifieke branches).

Samenvatting

Een moderne Sass workflow kan de ontwikkeling van je WordPress thema’s veranderen van een uitdaging in een gestructureerd, onderhoudbaar proces.

De belangrijkste onderdelen van een effectieve Sass workflow zijn onder andere een bouwproces dat eenvoudig maar bekwaam is, doordachte bestandsorganisatie, prestatieoptimalisaties en solide teamworkflows. Naarmate de Block Editor evolueert, kun je je met een flexibele en robuuste Sass implementatie aanpassen en toch resultaten van hoge kwaliteit leveren.

En als je op zoek bent naar WordPress hosting die dit soort workflows ondersteunt – van SSH toegang en WP-CLI tot testomgevingen met één klik – dan biedt Kinsta een ontwikkelaarsvriendelijk platform dat gebouwd is om moderne tooling out of the box te ondersteunen.

Jeremy Holcombe Kinsta

Content & Marketing Editor bij Kinsta, WordPress Web Developer en Content Writer. Buiten alles wat met WordPress te maken heeft, geniet ik van het strand, golf en films. En verder heb ik last van alle problemen waar andere lange mensen ook tegenaan lopen ;).