WordPress volledige site bewerking: gids voor 2026

WordPress volledige site bewerking: gids voor 2026

WordPress volledige site bewerking heeft in 2026 een kantelpunt bereikt. In WordPress 6.9 kiest 68% van de nieuwe site-installaties standaard voor block-architectuur. Voor freelancers en bureaus die nog klassieke PHP-themes aan klanten leveren, is de vraag niet meer of ze FSE moeten adopteren, maar hoe ze dat doen zonder bestaande productieprocessen te breken.

Dit folio behandelt de mechanica, niet de marketingpraat. Getest op echte klantprojecten met WordPress 6.8 en 6.9.

Wat FSE vervangt, en wat het behoudt

Klassieke WordPress-themes draaien op PHP-bestanden die HTML genereren. De template hierarchy bepaalt welk bestand wanneer geladen wordt: single.php, archive.php, page.php. Dat model werkt, maar het vereist PHP-kennis voor aanpassingen die eigenlijk puur visueel zijn.

FSE verplaatst de template-rendering naar de block-engine. In plaats van single.php schrijf je een single.html in de map templates/, gevuld met block-markup. De PHP-laag blijft aanwezig, want WordPress is nog altijd PHP. Maar de presentatielaag is nu een JSON-achtige block-syntax die de Site Editor begrijpt en visueel kan bewerken.

Wat FSE behoudt: de template hierarchy zelf. single.html, archive.html en page.html volgen dezelfde prioriteitsregels als hun PHP-equivalenten. De logica is hetzelfde; de uitdrukking is veranderd. Dat maakt de overgang minder steil dan hij op het eerste gezicht lijkt.

Het minimale block-theme: drie bestanden

Een block-theme dat WordPress als geldig herkent, heeft drie bestanden nodig. Dat is alles.

style.css bevat de theme-header: naam, beschrijving, versienummer. Geen CSS-regels zijn vereist voor erkenning. index.php is een leeg bestand of bevat een enkelvoudige opmerking. Dit is een historisch artefact: WordPress verwacht het bestand, maar gebruikt het niet actief. templates/index.html is de fallback-template. Zonder dit bestand kan WordPress niets renderen.

Alles wat je daarna toevoegt, is uitbreiding: theme.json voor design-tokens, aanvullende templates, template parts, patronen. De kern bestaat uit die drie bestanden. Dat helpt je begrijpen wat verplicht is en wat optioneel, voor je begint te bouwen voor een client.

De Site Editor in WordPress 6.9: vijf zones en een hiërarchie

De Site Editor is toegankelijk via Weergave > Editor in het WordPress-dashboard. In WordPress 6.9 is de interface georganiseerd in vijf zones.

Templates bevatten de pagina-level opmaak: homepage, single, archive, 404. Template parts zijn herbruikbare fragmenten die je in templates insluit, zoals de header, de footer, een zijbalk. Patronen zijn herbruikbare block-composities die je in content of templates plaatst. Stijlen vormen de visuele laag bovenop theme.json. Navigatie beheert globale menustructuren als block-content.

De hiërarchie werkt van boven naar beneden: template parts zitten in templates, patronen zitten in templates of content, stijlen overschrijven theme.json. Een wijziging in de Site Editor wordt opgeslagen in de database, niet in bestanden. Dat is de oorzaak van een van de meest voorkomende productieproblemen: een template in de database overschrijft stilzwijgend de bestandsversie in het theme.

Na een deployment zie je soms de oude versie op het scherm, niet de nieuwe. Wie dat eenmaal heeft meegemaakt op een live site van een klant, onthoud het verschil tussen database-state en bestandsstaat.

Template parts: de juiste abstractie, verkeerd gebruikt

Template parts zijn het juiste instrument voor fragmenten die op meerdere templates verschijnen: de header, de footer, een terugkerend zijvenster. Een goed ontworpen block-theme bevat gemiddeld vier tot zes template parts.

De meest gemaakte fout: te veel template parts aanmaken voor secties die uniek zijn per template. Een hero-sectie die alleen op de homepage staat, hoeft geen template part te zijn. Een block-patroon of een ingebedde groep in de template zelf volstaat, en is eenvoudiger te onderhouden.

Waarom maakt het uit? Template parts worden opgeslagen als custom post types (wp_template_part). Bij elke databaseoverschrijving via de editor wordt een extra revisie aangemaakt. Op sites met veel redactiesessies en weinig onderhoud stapelt dat zich op. De revisiegeschiedenis van template parts is ook minder overzichtelijk dan die van gewone berichten, wat herstelacties bemoeilijkt.

Een vuistregel: als een fragment op slechts één template verschijnt, is het geen template part.

De Query Loop-block: jouw PHP-loop, zonder PHP

De Query Loop-block vervangt WP_Query voor de meest gangbare gebruiksgevallen. Je configureert post type, taxonomie, volgorde en maximumaantal berichten via het blokpaneel. Binnenin de loop gebruik je post-aware blocks als Post Title, Post Excerpt en Post Featured Image. Die pikken automatisch de context van het huidige bericht op.

Beperkingen die je kent uit WP_Query en die de Query Loop-block niet oplost: complexe meta_query-filters, joins op aangepaste tabellen en dynamische argumenten op basis van de ingelogde gebruiker. Voor die gevallen schrijf je nog altijd een PHP-block via Server Side Render of een custom block.

Aan de klantkant levert de Query Loop-block iets wat PHP-templates nooit konden bieden: de klant configureert de loop zelf in de editor, zonder code aan te raken. Dat verandert de dynamiek bij klantoverdracht fundamenteel. Minder afhankelijkheid van de ontwikkelaar voor dagelijkse contentwijzigingen is precies wat veel klanten zoeken.

theme.json: wat het regelt en wat het delegeert

theme.json v3, geïntroduceerd in WordPress 6.7, is het configuratiebestand voor design-tokens: kleuren, typografie, spatiering, randen. Het werkt op twee niveaus.

Wat theme.json regelt: de beschikbare waarden in het blokpaneel. Je bepaalt welke kleuren de klant kan kiezen, welke lettertypegewichten beschikbaar zijn, welke spatiering-presets verschijnen in de interface. Wat theme.json delegeert: de werkelijke toepassing. theme.json genereert CSS custom properties. De blocks gebruiken die variabelen. De klant kan via Stijlen de waarden overschrijven, en die overschrijvingen worden opgeslagen in de database.

Een patroon dat goed werkt: leg je merkkleur vast als custom-token in theme.json, en verwijs er vanuit je blocks naar via var(--wp--custom--merk-kleur). De klant past de kleur aan in Stijlen zonder de templatebestanden aan te raken.

Valkuil: theme.json heeft geen versioning op individuele waarden. Verwijder je een kleur die de klant al gebruikte via Stijlen, dan verdwijnt de waarde stil. Documenteer je theme.json-interface zoals je een API documenteert.

Pattern Overrides: vaste structuur, bewerkbare inhoud

Pattern Overrides, geïntroduceerd in WordPress 6.8 via de Block Bindings API met de source core/pattern-overrides, lossen een fundamenteel klantoverdrachtprobleem op.

Klassieke patronen zijn statisch: je synchroniseert ze via wp:pattern-type="synced", en dan is de inhoud overal hetzelfde. Dat werkt voor een footer, maar niet voor een hero-sectie waarbij elke pagina een andere tekst nodig heeft.

Met Pattern Overrides vergrendel je de structuur, maar maak je specifieke attributen per instantie bewerkbaar. De klant ziet een patroon met een bewerkbare koptekst en een bewerkbare afbeelding. De structuur eromheen is onveranderlijk. Dat is de juiste balans voor klantoverdracht.

Technisch stel je allowedOverrides in op block-niveau in het patroondefinitiebestand. In de praktijk kun je een <!-- wp:pattern --> insluiten in een template en de klant toch per pagina inhoud laten aanpassen. Dat is wat veel bureaus al jaren probeerden te bereiken met Advanced Custom Fields en Elementor; FSE doet het nu in core.

Wat nog steeds stukgaat in productie

Eerlijkheid over de grenzen van FSE hoort bij dit folio.

Template-databaseoverschrijving: als een redacteur via de Site Editor een template wijzigt, primeert de databaseversie boven de bestandsversie. Dat is verwarrend bij deployments: je pusht een gewijzigd single.html, maar de klant ziet de databaseversie. Oplossing: herstel de bestandsversie via de Site Editor zelf, of gebruik wp theme reset op de commandoregel.

RTL-ondersteuning: niet alle core blocks zijn volledig RTL-proof in WordPress 6.9. Group-blocks met vaste links-rechts padding omdraaien is handmatig werk. Op Arabische en Hebreeuwse sites vereist FSE nog altijd per-block aanpassingen en extra CSS.

Geneste DOM-diepte: complexe block-composities produceren diep geneste HTML. Een Query Loop met Group met Cover met Paragraph geeft al vijf tot acht DOM-lagen. Dat is meetbaar in prestaties en een onderhoudslast bij CSS-specificiteit.

Geen back-up van stijlwijzigingen: wijzigingen die de klant maakt via Stijlen zijn databasedata. Ze zitten niet in de themabestanden en worden niet meegegeven bij een standaard thema-export. Informeer klanten hierover expliciet voor je een site overdraagt.

Tools die het werken waard zijn voor FSE-productiewerk

Create Block Theme (officieel WordPress-plugin) exporteert de volledige Site Editor-staat terug naar bestanden. Essentieel voor versiebeheer na een redactiesessie met de klant.

Block Theme Generator genereert een minimaal block-theme scaffold op basis van je invoer. Goed startpunt, maar controleer de gegenereerde theme.json altijd op onnodige opties.

Gutenberg-plugin (canary-versie) biedt nieuwe block-API's voor ze in core landen. Als je op WordPress 6.9 werkt en de volgende FSE-features wilt testen, is dit de enige betrouwbare manier.

Voor klanten die naast hun WordPress-site ook een webwinkel beheren, zijn er gecombineerde platformoplossingen beschikbaar:

FAQ

Werkt WordPress volledige site bewerking met alle plugins?

De meeste plugins die blocks toevoegen zijn compatibel met FSE. Plugins die klassieke widgets of PHP-shortcodes gebruiken kunnen problemen geven in block-templates. Controleer de plugin-documentatie op expliciete FSE-ondersteuning.

Kan ik een bestaand klassiek theme omzetten naar een block-theme?

Technisch is het mogelijk, maar in de praktijk is het een herbouw. Tools als Create Block Theme helpen bij de export van stijlen, maar de template-structuur moet je opnieuw opbouwen. Voor nieuwe projecten is een block-theme vrijwel altijd de betere keuze.

Zijn Pattern Overrides beschikbaar in alle WordPress-versies?

Pattern Overrides zijn geïntroduceerd in WordPress 6.8 via de Block Bindings API. Je hebt minimaal WordPress 6.8 nodig, of de Gutenberg-plugin op oudere versies.

Hoe exporteer ik mijn Site Editor-wijzigingen naar bestanden?

Gebruik de Create Block Theme-plugin (officieel, via WordPress.org). Die exporteert templates, template parts en stijlen terug naar je thema-bestandsstructuur, zodat je de wijzigingen kunt committen in versiebeheer.

Wat is theme.json v3 en wat verandert er ten opzichte van v2?

theme.json v3, geïntroduceerd in WordPress 6.7, voegt fluid typography presets toe en verbetert de spacing-API. De meeste v2-configuraties werken zonder aanpassing in v3.

Hoe ga ik om met RTL-ondersteuning in FSE?

FSE heeft beperkte native RTL-ondersteuning in de huidige WordPress-versies. Voor Arabische en Hebreeuwse sites is handmatige aanpassing per block nodig, met name voor Group-blocks en cover-secties met vaste padding. De Gutenberg-plugin biedt soms vroegere fixes dan de WordPress-core.