# WordPress volledige site bewerking: gids voor 2026 URL: https://noonwp.com/nl/journal/wordpress-volledige-site-bewerking-gids-2026 Type: blog Locale: nl Published: 2026-09-01 Updated: 2026-09-02 --- > WordPress 6.9 kiest standaard voor block-architectuur. Dit folio behandelt de mechanica van FSE: block-themes, de Site Editor en Pattern Overrides. ## 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. ![Block theme layout structure visible in a modern web design interface](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/noonwp/2026-09/57b5f1-img-1.webp) ## 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 configuration file open in a dark-mode code editor for a WordPress block theme](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/noonwp/2026-09/3750e1-img-2.webp) ## 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 `` 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. ## 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. Voor Arabische en Hebreeuwse sites is handmatige aanpassing per block nodig, met name voor Group-blocks en cover-secties met vaste padding.