WordPress block theme vs classic theme: de eerlijke vergelijking

Open je themamap. Zit daar een map templates in met een index.html, plus een theme.json in de hoofdmap, dan heb je een block theme. Zit daar een index.php in naast bestanden als header.php en footer.php, en toont je beheermenu Weergave en dan Customizer, dan heb je een classic theme.

Dat ene verschil in structuur bepaalt wie wat op je site kan wijzigen, waar die wijzigingen worden bewaard, en welke helft van het WordPress-plugin-ecosysteem zich normaal gedraagt.

De controle van 30 seconden

Signaal	Classic theme	Block theme
Sjabloonbestand in de hoofdmap	index.php	templates/index.html
Header en footer	header.php, footer.php	parts/header.html, parts/footer.html
Globale configuratie	functions.php	theme.json (plus optioneel functions.php)
Beheermenu	Weergave > Customizer	Weergave > Editor
Waar wijzigingen belanden	Bestanden op schijf	Database, als wp_template-berichten
Widgetscherm	Aanwezig	Afwezig

WordPress hakt de knoop door op basis van templates/index.html. Een thema dat wel een theme.json meelevert maar zijn PHP-sjablonen houdt, geldt nog steeds als classic — die tussenvorm komt veel voor en heeft een naam, verderop meer daarover.

Heb je shelltoegang, dan is één commando genoeg:

wp eval 'var_dump( wp_is_block_theme() );'

WP-CLI is de snelste controle op een site die je niet zelf hebt gebouwd, zeker wanneer een paginabouwer de gebruikelijke beheermenu’s heeft verstopt.

Wat er verandert voor wie de site beheert

In een classic theme zitten de header, footer, sidebar, kleuren en het logo achter de Customizer, en krijg je alleen de bedieningselementen die de themamaker heeft ingebouwd. Heeft het thema geen bedieningselement voor de copyrighttekst in de footer, dan is er geen bedieningselement. Je past een PHP-bestand aan of je leeft ermee.

In een block theme opent de site-editor de hele pagina. Header, footer, de loop, de 404-pagina, de weergave van zoekresultaten — het zijn allemaal blokken en het is allemaal aan te passen door iemand die nog nooit PHP heeft gezien. Dat is de echte hoofdfunctie, en het scheelt werkelijk enorm.

De keerzijde is dat alles aan te passen is door iemand die nog nooit PHP heeft gezien. Een klant kan om twee uur ‘s nachts de sitetitel uit de header verwijderen, en er is geen versiegeschiedenis op schijf om op terug te vallen — alleen de revisies van de site-editor zelf. Dichttimmeren kan wel, met blokvergrendeling en door te beperken wie bij de editor komt, maar dat is werk dat je zelf moet aanzetten en onthouden.

Twee kleinere verliezen die in de praktijk pijn doen: block themes hebben geen widgetscherm (widgetgebieden worden vervangen door sjabloononderdelen en blokken), en klassieke menu’s worden vervangen door het navigatieblok, dat zijn items opslaat als een apart inhoudstype in plaats van in het vertrouwde menuscherm.

Wat er verandert voor de developer

Classic themes gebruiken de PHP-sjabloonhiërarchie. WordPress lost een verzoek op via een bekende keten — single-{post-type}.php, dan single.php, dan singular.php, dan index.php — en jouw bestand draait, roept get_header() aan, doorloopt The Loop en drukt markup af die je teken voor teken zelf bepaalt.

<?php get_header(); ?>
<main class="site-main">
  <?php while ( have_posts() ) : the_post(); ?>
    <h1><?php the_title(); ?></h1>
    <?php the_content(); ?>
  <?php endwhile; ?>
</main>
<?php get_footer(); ?>

Block themes gebruiken dezelfde namen uit de hiërarchie maar met de extensie .html, alleen bevat het bestand blokmarkup — HTML met blokscheidingstekens in commentaar — en zijn er geen template tags:

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Drie gevolgen waar developers meteen tegenaan lopen:

get_header() en get_footer() draaien nooit. Alles wat aan die acties hangt, in een plugin of een oud child theme, doet stilzwijgend niets meer. wp_head en wp_footer vuren nog wel, dus het meeste inladen van scripts en stijlen overleeft het, maar hooks die specifiek op de header zitten niet.

De database wint van je bestanden. Zodra iemand een sjabloon opslaat in de site-editor, bewaart WordPress die versie als een wp_template-bericht en serveert dat in plaats van jouw bestand. Je kunt de hele middag aan het HTML-bestand sleutelen zonder ook maar iets aan de voorkant te zien veranderen. De aanpassingen voor dat sjabloon wissen zet de bestandsversie terug. Dit is verreweg de meest gemelde “mijn block theme is stuk”, en het is geen bug.

Opmaak verhuist naar theme.json. Kleuren, de spacing-schaal, typografie en standaarden per blok worden als data gedeclareerd in plaats van als CSS, en WordPress genereert de CSS. Dat is schoner en veel consistenter — totdat je iets nodig hebt dat het schema niet kan uitdrukken, waarna je alsnog CSS zit te schrijven en tegen de gegenereerde regels aan het vechten bent over specificiteit.

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "brand", "color": "#1a1a1a", "name": "Brand" }
      ]
    }
  }
}

Controleer de waarde van version tegen de WordPress-release die je draait — het schema is meer dan eens herzien, en een versienummer overnemen uit een oude tutorial levert instellingen op die geruisloos worden genegeerd.

Let op: functions.php verdwijnt niet. Block themes gebruiken het nog steeds voor het inladen van scripts en stijlen, het registreren van add_image_size-formaten, custom post types en al het andere PHP-werk. Je doet er alleen veel minder templating in.

Wat je echt wint, en wat je echt verliest

Met block win je: controle over de hele pagina vanuit de editor, ontwerpconsistentie die door theme.json wordt afgedwongen, minder bestanden om te onderhouden, en stijlen die veel vaker overeenkomen tussen de editor en de voorkant dan classic themes ooit voor elkaar kregen.

Met block verlies je: directe controle over de uitgestuurde markup, eenvoudige aanpassingen via hooks, compatibiliteit met alles wat uitgaat van PHP-sjablonen, en de zekerheid dat het uiterlijk van de site in versiebeheer staat.

Dat laatste verdient nadruk. In een classic theme vertelt git log je wat er is veranderd. In een block theme woont een flink deel van het uiterlijk van de site in de database, waar je deploypijplijn niet kijkt.

Wanneer een classic theme nog steeds het juiste antwoord is

• Er draait een paginabouwer op de site. Elementor, Divi, Beaver Builder en soortgelijke tools nemen de templating zelf over. Er een block theme onder leggen voegt een tweede templatingsysteem toe dat niets doet.
• De markup moet exact kloppen. Eigen componentbibliotheken, strikte toegankelijkheidsmarkup, ongebruikelijke schema-eisen — blokuitvoer wordt begrensd door wat blokken produceren, en daartegenin werken kost meer dan gewoon PHP schrijven.
• Zware templating vanuit plugins. Membership-, LMS-, directory- en oudere commerce-uitbreidingen leveren vaak PHP-sjabloonoverschrijvingen mee. Veel ervan hebben inmiddels een blokvariant; veel ook niet.
• De site is af en werkt. Een thema met vijf jaar aan opgestapelde aanpassingen heeft geen upgradepad naar block, alleen een herbouw. “Het is de nieuwere aanpak” is geen zakelijke reden.
• Niemand behalve jij past het aan. Het grootste voordeel van de site-editor is dat je controle uit handen geeft aan mensen zonder programmeerkennis. Zijn die er niet, dan betaal je de prijs voor een voordeel dat niemand gebruikt.

De hybride tussenweg

Een classic theme kan een theme.json toevoegen en zo het global styles-systeem krijgen, met de kleur- en spacing-presets en consistente opmaak in de editor — terwijl het zijn PHP-sjablonen en de Customizer gewoon houdt. WordPress noemt dit geen block theme en de site-editor blijft onbeschikbaar, maar je krijgt het grootste deel van het designsysteemvoordeel voor een fractie van het werk.

Voor een bestaande site die grotendeels goed werkt is dit meestal de juiste eerste stap. Voeg theme.json toe, leg je palet en spacing vast, gooi de CSS weg die daarmee overbodig wordt, en kijk daarna of je de rest nog wilt.