De introductie van Full-Site Editing (FSE) in WordPress benadrukt het groeiende belang van het theme.json bestand. Er is inmiddels een hele nieuwe hiërarchie en structuur om te begrijpen, samen met de verschillende properties om je te helpen bij het maken van je ontwerpen. Vooral de property blocks in theme.json is essentieel als je moderne, flexibele WordPress thema’s wilt maken met unieke blokken.
In deze handleiding verkennen we de ins en outs van de blocks property in theme.json, zodat je kunt werken met Blocks en ze kunt ontwerpen en stylen om meer dynamische en aanpasbare WordPress ervaringen te creëren.
De blocks property in theme.json begrijpen
Voordat we in de fijne kneepjes van de blocks property duiken, laten we eerst de rol ervan begrijpen binnen theme.json en de ontwikkeling van WordPress thema’s.
Allereerst, theme.json is het configuratiebestand waarmee je globale stijlen en instellingen voor je thema’s kunt definiëren. Met deze “centrale hub” kun je verschillende aspecten van het uiterlijk en gedrag van je thema regelen, waaronder typografie, kleuren en layout opties. Het kan echter meer doen dan alleen programmatische cosmetische aanpassingen.
Met de property blocks heb je uitgebreide controle op individuele bloktypes in plaats van op de site als geheel. Je kunt standaard stijlen, instellingen en gedrag definiëren voor specifieke blokken, wat zorgt voor consistentie in je thema en flexibiliteit voor site-eigenaren.
De relatie tussen de blocks property en full-site editing
FSE is een meer visuele benadering van het bouwen van je site met blokken als kern. Aan de voorkant heb je de meeste styling- en aanpassingsopties voor je hele site:
De property blocks is om een paar redenen een cruciaal onderdeel van het bestand theme.json:
- Het biedt een gestandaardiseerde manier om blokstijlen en instellingen te definiëren.
- Je kunt samenhangende ontwerpsystemen maken vanuit een programmatische basis.
- Je kunt meer controle bieden over het uiterlijk van blokken zonder dat je custom CSS nodig hebt.
- De property helpt je bij het maken van blokpatronen en templates.
Developers kunnen de property blocks gebruiken om thema’s te maken die optimaal gebruik maken van volledige full-site editing.
Hoe de blocks property te structureren (en zijn syntaxis)
De standaardisatie die de property blocks biedt, helpt als het gaat om structuur en syntaxis. Je nest hem altijd binnen het settings object:
{
"version": 3,
"settings": {
"blocks": {
"core/paragraph": {
"typography": {
"fontSizes": [
{
"name": "Small",
"slug": "small",
"size": "13px"
},
{
"name": "Medium",
"slug": "medium",
"size": "20px"
}
]
…Het bovenstaande voorbeeld definieert custom lettergroottes voor een Paragraph blok. Het opsplitsen van de belangrijkste componenten is eenvoudig:
- Je nest de property
blocksonder het objectsettings. - Elk bloktype heeft een namespace en naam (
core/paragraphin dit geval). - Vervolgens specificeer je de instellingen van het blok binnen het object.
De instellingen omvatten het meeste van wat beschikbaar is voor globale stijlen. Ze kunnen bijvoorbeeld typografie, kleur, spacing en nog veel meer bevatten.
Globale blokinstellingen configureren
Laten we eens kijken hoe je globale instellingen definieert en vervolgens hoe dit de property blocks beïnvloedt. Zo leg je een basis voor een consistent ontwerp in je hele thema.
{
"version": 3,
"settings": {
"typography": {
"fontSizes": [
{
"name": "Small",
"slug": "small",
"size": "13px"
},
{
"name": "Medium",
"slug": "medium",
"size": "20px"
}
…In dit voorbeeld definiëren we de globale lettergrootten die beschikbaar zijn voor alle blokken. In de WordPress Site Editor kun je deze opties vinden in het scherm Typography > Elements > Text:
Elke lettergrootte die je definieert binnen theme.json correleert met een van de grootteopties hier:
Natuurlijk zijn er nog veel meer manieren om je thema vanaf hier aan te passen. Het idee is om een globaal ontwerp te maken dat in 80% van de gevallen werkt.
Met de property blocks kun je die corestijlen van Block overschrijven om de laatste 20% te dekken. Met het scherm Styles in de Site Editor kun je ook de ontwerpinstellingen voor elk blok aanpassen:
Dit is uitstekend voor eindgebruikers, maar van minder waarde voor een ontwikkelaar. We richten ons op het gebruik van theme.json om te werken met de property blocks.
Hoe je individuele bloktypes kunt aanpassen
Hoewel globale instellingen belangrijk zijn om consistentie te behouden, ligt de echte kracht in het bereik van de blocks property om aan te passen. Met deze instelling kun je op enorm gedetailleerd niveau het uiterlijk en gedrag van specifieke blokken aanpassen aan het ontwerp van je thema, net als de Site Editor.
Laten we eens kijken naar een voorbeeld van het aanpassen van het header blok voor je thema:
{
"version": 3,
"settings": {
"blocks": {
"core/heading": {
"typography": {
"fontSizes": [
{
"name": "Small",
"slug": "small",
"size": "20px"
},
{
"name": "Medium",
"slug": "medium",
"size": "30px"
},
{
"name": "Large",
"slug": "large",
"size": "40px"
}
],
"fontWeight": "bold"
},
"color": {
"palette": [
{
"name": "Heading Primary",
"slug": "heading-primary",
"color": "#333333"
},
{
"name": "Heading Secondary",
"slug": "heading-secondary",
"color": "#666666"
}
]
…Je kunt zien dat de attributen weerspiegelen hoe je globale wijzigingen zou maken. Laten we samenvatten wat we doen:
- We definiëren specifieke lettergroottes voor koppen en wijzen deze toe aan grootte labels.
- Het gewicht van het lettertype voor alle koppen wordt gewoon vet.
- Deze koppen krijgen ook een custom kleurenpalet.
Dit zorgt ervoor dat onze koppen er in het hele ontwerp consistent uitzien. We hebben ook controle over deze elementen als we niet weten hoe de eindgebruiker ze zal toepassen, wat een consistent ontwerp ten goede komt.
De juiste combinatie van namespace en slug gebruiken
Wanneer je blok types callt, is het cruciaal dat je de juiste namespace en slug combinatie gebruikt. Anders zijn je wijzigingen niet van toepassing op de blokken die je wilt callen.
Elk blok heeft een namespace en een slug. Core WordPress Blocks hebben meestal de core namespace. De slug is de naam van het blok:
…
"blocks": {
"core/image": {
…Als je de slug voor een blok wilt weten, dan kun je kijken naar het specifieke block.json bestand. Je vindt dit in de wp-includes/blocks directory. Hier heb je verschillende mappen die elk een block.json bestand bevatten. In elke map moeten de namespace en de slug voor het blok bovenaan het bestand staan:
Als je door deze mappen bladert, zie je dat de wp-includes map een eigen theme.json bestand heeft. Hoewel dit misschien verwarrend lijkt, is het eenvoudig uit te leggen.
Waarom theme.json standaard custom blokinstellingen bevat
WordPress’ eigen theme.json bestand lijkt in eerste instantie misschien vreemd, namelijk omdat het geen thema is. Dit is echter geen toeval. De belangrijkste reden is om achterwaartse compatibiliteit met oudere versies van WordPress te ondersteunen.
Het Button blok stelt bijvoorbeeld een randradius in:
…
"blocks": {
"core/button": {
"border": {
"radius": true
}
},
…Andere blokken hebben vergelijkbare instellingen om te helpen bij de consistentie tussen verschillende versies van WordPress. Dit kan echter problemen veroorzaken als je er niet van op de hoogte bent.
Als je globale instellingen probeert te definiëren en je vraagt je af waarom die wijzigingen niet gelden voor specifieke blokken, dan kan achterwaartse compatibiliteit het antwoord zijn. Natuurlijk kun je deze instellingen zonder problemen overschrijven in je eigen theme.json bestand.
Custom blokken ontwikkelen met theme.json
Het theme.json bestand is ideaal voor het aanpassen van bestaande blokken, maar de mogelijkheden ervan strekken zich ook uit tot het ontwikkelen van custom blokken. Je kunt theme.json gebruiken om standaard stijlen en instellingen te definiëren voor elk van je custom blokken. Dit helpt je bij het leveren van naadloze integratie met het ontwerp van je thema.
Maar eerst moet je het blok zelf bouwen. Dit valt buiten het bestek van dit artikel, maar kort samengevat zijn er een paar facetten:
- Het blok scaffolden. Dit omvat het opzetten van een lokale ontwikkelomgeving en het maken van de bestandsstructuur voor het hele blok.
- Het
block.jsonbestand bijwerken. Hier moet je de blok-identiteit veranderen en supports toevoegen. Dit laatste zijn manieren om de ondersteuning voor specifieke WordPress functionaliteiten aan te geven. Je kunt bijvoorbeeld de uitlijning regelen, anchorvelden implementeren, werken met verschillende typografie-instellingen en meer. - Pas de JavaScript-bestanden van de Block aan. Zowel
index.jsalsedit.jshebben code nodig om WordPress te vertellen hoe het blok werkt en om het te laten verschijnen in de site-editor.
Mogelijk moet je ook render.php bewerken, statische rendering toevoegen en een heleboel andere taken uitvoeren. Op dit punt kun je stilistische wijzigingen aanbrengen op theme.json, net als bij elk ander blok. Laten we nu eens kijken naar block.json.
Het block.json bestand
Dit bestand is wat het WordPress ontwikkelteam de “canonical” manier noemt om blokken te registreren voor zowel de server- als de clientzijde. De metadata die je hier opneemt vertelt WordPress alles over het type blok en de ondersteunende bestanden:
{
"$schema": "https://schemas.wp.org/trunk/block.json",
"apiVersion": 3,
"name": "my-plugin/notice",
"title": "Notice",
"category": "text",
"parent": [ "core/group" ],
"icon": "star",
"description": "Shows warning, error or success notices...",
"keywords": [ "alert", "message" ],
"version": "1.0.3",
"textdomain": "my-plugin",
"attributes": {
"message": {
"type": "string",
"source": "html",
"selector": ".message"
}
},
…Het is verwant aan de metadata die je bovenaan een PHP bestand zou plaatsen voor thema’s en plugins. Hoewel het bestand uitsluitend JSON gegevens gebruikt, kun je nog steeds code delen via PHP, JavaScript en CSS:
…
"editorScript": "file:./index.js",
"script": "file:./script.js",
"viewScript": [ "file:./view.js", "example-shared-view-script" ],
"editorStyle": "file:./index.css",
"style": [ "file:./style.css", "example-shared-style" ],
"viewStyle": [ "file:./view.css", "example-view-style" ],
"render": "file:./render.php"
…We komen hier later op terug in het gedeelte over variaties. Om dit gedeelte af te sluiten, moet je weten hoe je jouw custom blok als standaard kunt instellen in WordPress. Er zijn een paar manieren om dit te bereiken. De klassieke manier is om een custom berichttype te registreren en de blokken daarin op te nemen. Er zijn echter nog een paar andere methoden.
Je kunt bijvoorbeeld een bestaand berichttype bijwerken om er een bloktemplate aan toe te voegen. Hier is een eenvoudig voorbeeld:
…
function load_post_type_patterns() {
// Define an initial pattern for the 'HypnoToad' post type
$post_type_object = get_post_type_object( 'hypnoToad' );
$post_type_object->template = array(
array(
'core/block',
…Een andere manier is om de hook default_content te callen en het blok te definiëren met markup:
function toad_content( $content, $post ) {
if ( $post->post_type === 'hypnoToad' ) {
$content ='
<div class="is-layout-flex wp-container-1 wp-block-columns"><!-- wp:column →
<div class="wp-block-column">
<p></p>
</div>
<div class="is-layout-flow wp-block-column">
<p></p>
</div>
</div>
';
}
return $content;
}
add_filter( 'default_content', 'toad_content', 10, 2 );Natuurlijk zul je niet alleen JSON, HTML en PHP gebruiken. Je zult ook andere talen gebruiken om te helpen met ontwerp en interactiviteit. Het goede nieuws is dat WordPress je een ongecompliceerde manier geeft om dit te doen.
Custom CSS properties gebruiken voor je blokken
Je kunt veel bereiken door gebruik te maken van de bestaande properties, attributen en objecten van theme.json, maar dat zal niet elk gebruik dekken. Het bestand geeft je de property custom die je zal helpen bij het maken van relevante CSS properties:
{
"version": 3,
"settings": {
"custom": {
"toad": "hypno"
}
}
}Hierin geef je een key-value paar op, dat verandert in een CSS variabele aan de voorkant:
body {
--wp--custom--toad: hypno;
}Merk op dat de variabele dubbele koppeltekens gebruikt om de elementen te scheiden. Over het algemeen zie je altijd --wp--custom--, die dan de sleutel aan het einde tagt. Soms definieer je variabelen en properties met camel case:
{
"version": 3,
"settings": {
"custom": {
"hypnoToad": "active"
}
}
}Hier zal WordPress koppeltekens gebruiken om de woorden te scheiden:
body {
--wp--custom--hypno-toad: active;
}Tussen de property custom en block.json heb je alle ruimte om je Blokken naar eigen inzicht op te bouwen, inclusief alle variaties die je wilt toevoegen.
Een snelle blik op blok-, stijl- en blokstijlvariaties
Voordat we verder gaan met het stylen met behulp van de blocks property, kijken we eerst naar variaties. Je hebt een paar verschillende variatietypes voor je ontwerpen, en de naamgevingsconventies kunnen ervoor zorgen dat je het verkeerde type gebruikt voor wat je nodig hebt. Hier volgt een overzicht van de verschillen:
- Blokvariaties. Als je blok alternatieve versies heeft (denk aan een blok dat veel custom links weergeeft die door de gebruiker zijn ingesteld), dan is dit een blokvariatie. Het Social Media Blok is hier een goed voorbeeld van.
- Stijlvariaties. Dit zijn alternatieve versies van
theme.jsondie werken op je globale site. We behandelen dit hier niet, maar de meeste Block-thema’s bieden ze aan voor verschillende kleurenpaletten en typografie-instellingen. - Blokstijlvariaties. Dit neemt de kernfunctionaliteit van stijlvariaties over en stelt je in staat om alternatieve ontwerpen voor een Block te maken.
Je vraagt je misschien af of je een blokvariatie of een blokstijlvariatie moet gebruiken; het antwoord is ongecompliceerd. Als de wijzigingen die je wilt aanbrengen binnen theme.json of met CSS kunnen worden doorgevoerd, maak dan een blokstijlvariatie. Iets anders vereist een blokvariatie.
Blokvariaties
Blokvariaties registreer je met JavaScript. Het is een goed idee om een bestand te maken in de map van een thema, maar het kan overal naartoe gaan. Er is één regel nodig om een variatie te registreren in je JavaScript-bestand:
const registerBlockVariation = ( blockName, variation )Voor de blockName moet je hier ook de namespace opgeven, net als bij de blocks property. Binnen het variation object voeg je de naam, titel, beschrijving, of de variatie standaard actief is en meer toe. Om het bestand in de Site Editor te laden, roep je gewoon de enqueue_block_editor_assets hook aan en enqueue je je script daarin.
Blokstijlvariaties
Voor blokstijlvariaties heb je twee opties:
- Gebruik de functie
register_block_style()met PHP. - Maak een
block-editor.jsJavaScript-bestand, gebruik deregisterBlockStyle()functie op dezelfde manier als bij Blokvariaties en enqueue het script.
Zodra je een blokstijlvariatie hebt geregistreerd, kun je de blok targeten met de property variations:
…
"styles": {
"blocks": {
"core/button": {
"variations": {
"outline": {
"border": {
"color": "var:preset|color|black",
"radius": "0",
"style": "solid",
"width": "3px"
},
…Dit betekent dat je misschien helemaal geen custom CSS nodig hebt – bijna elk aspect van het ontwerp van een blok is mogelijk via de property blocks.
Een standaard blok stylen met de blocks property van begin tot eind
Om te demonstreren hoe de property blocks werkt, laten we een voorbeeld uit de praktijk bekijken. Onze site gebruikt het thema Twenty Twenty-Four en gebruikt de standaard stijlvariant:
Tot nu toe ziet dit er voor ons ideaal uit – hoewel de koppen en de bodytekst qua kleur te veel op elkaar lijken. We willen een of beide kleuren veranderen om ze te onderscheiden. Als eindgebruiker of site-eigenaar kunnen we dit oplossen in de zijbalk Styles van de Site Editor. Als je naar Blocks > Heading gaat, kun je op het element Text klikken en de kleur veranderen in iets geschikter:
Als developer kun je dit echter doen binnen theme.json. Net als bij elk ander thema kun je het beste een childthema maken om alle wijzigingen die je aanbrengt te behouden. Een tweede voordeel is dat je theme.json bestand er netter uitziet.
We maken een map binnen wp-content/themes/ en noemen die twentytwentyfour-child. Voeg hier een geldig style.css bestand en een leeg theme.json bestand toe.
Vanaf hier kun je het JSON bestand openen en aan de slag gaan.
Een theme.json bestand maken en vullen voor het childthema
Het belangrijkste verschil tussen het maken van een ouder- en kindthema met betrekking tot theme.json is de structuur van het bestand. Je hoeft niet per se het schema op te geven of alles in het settings object te zetten. In ons geval moeten we de property styles gebruiken:
{
"version": 3,
"styles": {
"blocks": {}
}
}Vervolgens moeten we de namespace en slug vinden voor het Heading blok. In de officiële Core Blocks Reference Guide staan deze allemaal opgesomd en er staat zelfs in welke attributen en properties het blok ondersteunt. De gids vertelt ons dat we de waarden background, gradient, link, en text kunnen aanpassen voor de property color.
"blocks": {
"core/heading": {
"color": {}
}
}Nu de structuur compleet is, kunnen we gaan uitzoeken hoe we de tekst kunnen restylen.
Een kleurenschema vinden en de wijzigingen toepassen
Nu hebben we een kleur nodig die past bij onze behoeften. De standaardvariant van Twenty Twenty-Four heeft een uitstekend kleurenpalet en door het te controleren in een speciale contrastchecker krijgen we wat ideeën:
Vervolgens kunnen we de kleurkeuze voor ons blok toevoegen aan theme.json. Omdat het hoofdthema van Twenty Twenty-Four custom CSS properties gebruikt om paletstijlen te definiëren, kunnen we dit hier ook callen:
…
"core/paragraph": {
"color": { "text": "var(--wp--preset--color--contrast)" },
…Als je de naam van een paletkleur moet weten, kun je die in de Site Editor vinden in de kleurenkiezer:
Zodra je je wijzigingen hebt opgeslagen, vernieuw je je site en zou je het nieuwe kleurenschema op zijn plaats moeten zien. Als dat niet het geval is, controleer dan of je de property blocks nest binnen het juiste object, want dit is een veelvoorkomend knelpunt.
Als we naar de site kijken, is de tekst minder contrasterend en gemakkelijker te lezen. We willen echter nog steeds wat definitie zien tussen het Paragraph blok en de omringende koppen. Het standaardpalet van het thema heeft een aantal andere, krachtigere kleuren. We gaan de Accent / 3 kleur proberen voor het Heading blok:
"blocks": {
"core/heading": {
"color": { "text": "var(--wp--preset--color--accent-3)" }
},
"core/paragraph": {
"color": { "text": "var(--wp--preset--color--contrast)" }
}
}Nadat je de wijzigingen hebt opgeslagen en de voorkant hebt vernieuwd, zie je dat het Heading blok meer definitie heeft:
Dit hoeft niet het einde te zijn van je bewerkingen. Je kunt zelfs de opties van de Site Editor aanpassen vanaf theme.json.
Attribuutopties toevoegen aan blokken
De ondersteuningen van elk blok bepalen de opties binnen de Site Editor. Het Paragraph blok schakelt bijvoorbeeld standaard de drop caps feature uit.
We kunnen dit weer inschakelen in het bestand theme.json en de property blocks. Als we naar het referentiemateriaal kijken, kunnen we de typography-property gebruiken om de Drop Caps in te schakelen:
…
"core/paragraph": {
"color": { "text": "var(--wp--preset--color--contrast)" },
"typography": { "dropCap": true }
…Zodra we deze wijzigingen opslaan en de editor verversen, is de optie om een druppelkap in te schakelen weer beschikbaar:
Het bestand theme.json is niet alleen een configuratie voor het ontwerp. Het kan ook helpen bij het toevoegen en verwijderen van functionaliteit in de Site Editor.
Hoe Kinsta’s managed hosting je WordPress thema-ontwikkeling kan ondersteunen
De fijne kneepjes van thema-ontwikkeling en theme.json zijn afhankelijk van kwaliteitsoplossingen in de hele ontwikkelingsketen om te profiteren van het potentieel voor betere prestaties.
Een lokale ontwikkelomgeving is cruciaal, want hiermee kun je WordPress sites maken, beheren en eraan sleutelen op je lokale machine. DevKinsta kan daarbij helpen.
DevKinsta biedt veel voordelen:
- Het draait op Docker containers, wat betekent dat je je installatie isoleert van de rest van je machine. Zo kun je zonder zorgen je
theme.jsonconfiguraties en custom blokken testen. - Je kunt snelle iteraties maken in je
theme.jsonbestand en de resultaten direct zien in je lokale omgeving. - Het maken van meerdere lokale sites om je thema te testen met verschillende WordPress versies en configuraties is een fluitje van een cent.
Bovendien gebruik je geen resources van je server totdat je tevreden en klaar bent. De testomgevingen van Kinsta bieden een ideale volgende stap. Je kunt snel een kopie van je productiesite maken en deze zelfs naar je lokale omgeving pullen om verder te werken.
Dit is een geweldige manier om de prestaties van je thema te testen, vooral als je de testomgeving combineert met Kinsta’s Application Performance Monitoring (APM) tool.
Je kunt ook gebruikmaken van Kinsta’s Git-integratie in al je omgevingen. Hiermee kun je wijzigingen pushen en pull-en naar repo’s en van daaruit ook deployen.
Samenvatting
Het begrijpen van de property blocks in theme.json is een noodzakelijke stap voor alle thema-ontwikkelaars. Dit kan een globaal ontwerp unieker, samenhangender en relevanter maken. De volledige mogelijkheid om te werken met individuele kern- en custom blokinstellingen helpt elke gebruiker om de mogelijkheden van full-site editing te benutten. Bovendien betekent het beschikbaar hebben van deze opties in de Site Editor dat eindgebruikers hun eigen wijzigingen kunnen aanbrengen zonder code, terwijl je standaardopties presenteert.
Heb je vragen over het gebruik van de property blocks met het bestand theme.json? Stel ze gerust in de comments hieronder!
Laat een reactie achter