Wat is er nieuw in WordPress 5.8 (full-site editing, WebP afbeeldingen, algemene stijlen en instellingen en meer)

WordPress 5.8 “Tatum” is gearriveerd en het is een gedenkwaardige release

Naast een groot aantal nieuwe features, verbeteringen en bugfixes, introduceert WP 5.8 een nieuwe manier voor websites bouwen door middel van de eerste features die vallen onder het grotere project dat ze Full Site Editing noemen.

Behalve full-site editing biedt WordPress 5.8 ook allerlei andere kleinere veranderingen en verbeteringen op verschillende gebieden in de CMS.

WordPress gebruikers die de Gutenberg plugin nog niet gebruiken zullen ook in één keer alle features en verbeteringen van negen Gutenberg versies ontvangen (voor details over elke release, zie Gutenberg 9.9, 10.0, 10.1, 10.2, 10.3, 10.4, 10.5, 10.6, 10.7).

Een belangrijke nieuwe feature voor gebruikers die veel bezig zijn met de prestaties van hun website is ondersteuning voor het WebP format.

Developers zullen ook blij zijn dat IE11 niet langer op de lijst met ondersteunde browsers staat én met de nieuwe blockconfiguratie en het stylingmechanisme dat gebaseerd is op theme.json, het verbeterde block-registratiesysteem op basis van block.json en de verschillende API verbeteringen in deze tweede WordPress release in 2021.

Lees dus lekker door voor een vrij lange lijst met features en verbeteringen, die de weg vrijmaken voor krachtigere site-building tools die verwacht worden in de komende maanden.

Full Site Editing features in WordPress 5.8

Het idee achter Full Site Editing is dat je een aantal tools en features krijgt waarmee WordPress gebruikers een complete website kunnen bouwen via blocks. Met Full Site Editing komen allerlei blocks beschikbaar waarmee je verschillende onderdelen op de pagina kan maken, van navigatiemenu’s tot branding, widgets, templates en nog veel meer.

WordPress 5.8 introduceert verschillende features die onder Full Site Editing (FSE) vallen, maar verwacht geen volledig uitgeruste visuele site-bouwomgeving te zien. Er wordt nog hard gewerkt aan FSE, en de release van WordPress 5.8 is meer een soort publieke beta-fase. Volgens de woorden van Josepha Haden Chomphosy:

Full site editing is een verzameling van projecten die samen een grote verandering betekenen, veel te veel voor één enkele release. Het belangrijkste om hierbij te weten is dat we het niet verpakken als de complete, standaard ervaring voor alle gebruikers. Eén van de belangrijkste opmerkingen die we uit het Phase One proces kregen was dat er niet genoeg tijd was voor al onze partners (bureau’s, thema-ontwikkelaars, plugindevelopers, sitebouwers) om zich voor te bereiden op de veranderingen.

Om daar rekening mee te houden, zal dit veranderingsproces geen aan/uit verandering zijn. Het idee is nu dat er nog niet per se een volledige en perfecte gebruikerservaring is, maar dat er met WordPress 5.8 meer een soort publieke beta ontstaat.

WordPress 5.8 introduceert dus geen perfecte en volledige FSE ervaring. In plaats daarvan zullen we steeds meer nieuwe features en verbeteringen te zien krijgen, die meteen bij versie 5.8 beginnen. We hoeven daarom ook niet te verwachten dat WordPress 5.8 meteen een dramatische verandering zal zijn van hoe we gewend zijn om websites te bouwen.

Op het moment van schrijven moeten beheerders en admins nog specifiek voor FSE kiezen door een block-thema te installeren, zoals Twenty-Twenty One Blocks (de block-based versie van Twenty-Twenty One), en de Gutenberg plugin activeren.

Full Site Editing is in feite een verzameling sub-projecten, zoals de Site Editor, Global Styles, Query block, Navigation block, Templates, block-thema’s, en meer. Wat het dichtst bij Full Site Editing komt binnen WordPress 5.8 is de Template Editing Mode en bijbehorende Theme Blocks die daarin beschikbaar zijn, zoals we later nog uitgebreid aan bod laten komen.

Tijd om in een aantal FSE features te duiken die samengevoegd zijn met de WordPress-core in WordPress 5.8.

Template Editing Mode

Template Editing Mode biedt een manier om templates voor artikelen en pagina’s te maken door middel van blocks. Dit is een handige manier om de complexiteit rond het bouwen van website te verminderen, waardoor gebruikers diverse bewerkingsfuncties van buiten de site-editor interface kunnen gebruiken, terwijl ze alvast wennen aan het werken met blocks. Dit is daarnaast ideaal voor gebruikers die geen block-based thema’s gebruiken, maar wel geïnteresseerd zijn in een makkelijke manier om templates te maken en te bewerken via de block editor UI.

Het bewerken van thema’s was nog nooit zo makkelijk in WordPress. Je hebt nu geen child-thema mee nodig om je eigen templates te maken. In WordPress 5.8 is het bewerken van templates niet beperkt tot blockthema’s, maar ook te gebruiken met klassieke thema’s, ook al moet je het zelf activeren als je ook klassieke thema’s wil bewerken (opt-in).

Om een nieuw template te maken, moet je alleen de Template Editing Mode inschakelen in de Settings zijbalk. Er is nu een nieuw Template paneel beschikbaar waarmee gebruikers de gewenste bewerkingsmodus kunnen kiezen (zie ook de Gutenberg 10.5 release notes).

Vanaf het Template paneel, kan je een nieuw template maken of bewerken.

Om een nieuw template te maken, klik je op New. Je voert een templatenaam in en klikt op Create, en klaar is Kees.

In de Template Editing Mode kan je templates bouwen met alle beschikbare blocks, waaronder FSE blocks zoals Site Title, Site Tagline, Login/out, en allerlei anderen.

Zodra je tevreden bent met je template, kan je teruggaan naar de Post Editing mode en de template los opslaan van de content, zoals hieronder te zien:

Templates worden opgeslagen in je WordPress database als custom post type, genaamd wp_template. Dit zorgt ervoor dat je templates kan bewerken via de editor-interface, maar maakt het ook makkelijk om ze te exporteren of importeren. Zo kan je templates op verschillende websites gebruiken (dit is momenteel alleen beschikbaar als je de Gutenberg plugin activeert).

Template Editing Mode is nog een beetje buggy op het moment van schrijven, zoals ook gemeld in deze call for testing en dit experiment van Justin Tadlock.

Het vergt dus nog een beetje geduld tot de grotere problemen zijn opgelost voordat we echt kunnen zeggen hoe Template Editing Mode de look en feel van je websites zal veranderen.

In ieder geval zullen gebruikers geen developer meer hoeven te worden om volledige controle te hebben over het uiterlijk van hun websites.

Template Editing Mode was aanvankelijk beschikbaar voor zowel block thema’s als klassieke thema’s. Na een diepe discussie in het kanaal 5.8 leads, werd besloten om de template editor opt-in te maken voor klassieke thema’s en opt-out voor block thema’s (zie ook pull #32858).

Volgens Carolina Nymark:

Aanvankelijk was het bewerken van templates voor alle thema’s ingeschakeld. Thema-ontwikkelaars maakten zich zorgen dat ze niet al hun bestaande klassieke thema’s konden updaten om deze nieuwe functie te ondersteunen. Met een late wijziging hebben het releaseteam en het redactieteam ervoor gekozen om het wijzigen van templates op opt-in te zetten voor klassieke thema’s.

Om het voor klassieke thema’s in te schakelen, moeten ontwikkelaars nu zlf thema-ondersteuning toevoegen:

add_theme_support( 'block-templates' );

Klassieke thema’s die gebruikmaken van theme.json kunnen zich afmelden door de thema-ondersteuning te verwijderen:

remove_theme_support(  'block-templates' );

Voor meer details over de Template Editing Mode in WordPress 5.8 en een aantal handige voorbeelden, kan je deze video van Anne McCarty eens bekijken:

Theme Blocks

Zoals eerder gezien is Full Site Editing niet één enkele feature, maar een complete verzameling van features die verder gaan dan alleen de site editor. Template Editing Mode is daar dus alleen een voorbeeld van. Naast Template Editing biedt WordPress 5.8 ook allerlei theme blocks die dynamisch informatie kunnen weergeven uit de database. Sommige van deze blocks kunnen ook buiten een FSE context gebruikt worden (zie probleem #28744).

Theme Blocks brengen de functionaliteit van template tags naar klassieke thema’s, en je kan ze op dezelfde manier gebruiken als gewone blocks. Zo kan je bijvoorbeeld artikel tags toevoegen aan de uitgelichte afbeeldingen van je artikel, in de content van een artikel of in een template. Om een idee te krijgen van het enorme aantal theme blocks die aan de kern zijn toegevoegd in WordPress 5.8, typ je /post in de block placeholder:

Een handig theme block dat beschikbaar is in WordPress 5.8 is het Login/out block, waarmee je links voor inloggen en uitloggen krijgt. Je kan ook een inlogformulier laten zien in plaats van een link. Site admins kunnen ook de redirect wijzigen (zie PR #29766).

Voor meer informatie over FSE blocks, kan je “Enabling Full Site Editor blocks in classic themes” op Github lezen.

De Query Loop Block

Hoe vaak heb je niet gehad dat je graag een aangepaste lijst van artikelen of custom berichttypen wou laten zien? Denk aan producten, evenementen, of vastgoed… Je kan daar natuurlijk allerlei plugins voor gebruiken, maar om goede, op maat gemaakte queries te maken heb je vaak een developer nodig die overweg kan met de WordPress Loop.

Door de introductie van de Query Loop block in de WordPress core kunnen admins en beheerders lijsten van artikelen en custom artikeltypen maken zonder complexe code of het inhuren van een developer, in ieder geval voor de meeste standaard toepassingen.

Wat doet de Query Loop Block precies?

In het kort komt het erop neer dat het een WordPress Loop is, maar binnen de visuele context van de block editor.

De Query Loop block voert een query uit op de WordPress database op basis van de instellingen van de gebruiker, “loopt” door elk opgehaald artikel, en geeft de gevraagde data weer.

Na intensieve ontwikkeling heeft deze block de huidige structuur gekregen, en bestaat nu uit twee geneste blocks: de Query en Post Template blocks.

Als geavanceerde feature heeft een Query Loop block wel wat configuratie nodig.

Allereerst moet je kiezen tussen verschillende blockpatronen, in de Carousel en Grid view. Na je keuze klik je op Choose, en de Query Loop block maakt de gevraagde lijst van artikelen.

Als je klikt op Start blank, zie je een lijst met vier kernvariaties van blocks: Title & Date; Title & Excerpt; Title, Date & Excerpt; en Image, Date & Title (zie ook Aanbieden van patronen bij Block setup).

Na je keuze zal het selecteren van de Query Loop block een instellingenbalk tonen, waar je de daadwerkelijke query kan samenstellen. Je kan de query gebruiken uit de URL of de argumenten aanpassen, zoals het type artikelen in de lijst, de volgorde van weergave, en of er sticky artikelen zijn.

Je kan ook verschillende filters gebruiken, categorieën kiezen, auteurs en keywords.

Daarnaast is er een knop voor Display settings in de toolbar van de block met meer instellingen voor het aantal items per pagina, de offset, en het maximale aantal pagina’s.

De Query Loop block is zonder meer een krachtige tool, waarmee je een erg nauwkeurige lijst van artikelen en custom artikeltypen kan tonen.

Maar als je de WP_Query class parameters langsloopt, is het duidelijk dat je via code nog veel mogelijkheden hebt dan via de Query Loop block.

Desalniettemin is het een handige en flexibele tool voor allerlei gevallen, en we zien vast nog meer verbeteringen in de nabije toekomst.

Persistent List View in de Post Editor

Een andere Full Site Editing feature die doorgetrokken is naar de Post Editor is de Persistent List View. Voor WordPress 5.8 (en Gutenberg 10.7), werd de List View weergegeven in een popover. Zodra je de muis buiten de popover bewoog, verdween de lijst.

De Site Editor daarentegen laat de List view zien in de zijbalk, inclusief de gehele hiërarchie van de block.

Met WordPress 5.8 wordt de List View weergegeven in de zijbalk van de Post Editor, waardoor gebruikers sneller de hele hiërarchie van de block af kunnen gaan.

Door op een item in de List View te klikken wordt het item gemarkeerd, en gaat de focus meteen naar het bijbehorende block in de Post Editor. Daarnaast, als je hovert boven de items in de List view, worden zoals het item als het bijbehorende block in de Post Editor gemarkeerd.

Als laatste wordt het toevoegen van een anker aan een block ook getoond in het item op de List view.

Met al deze verbeteringen in de List view wordt het navigeren in complexe documenten een stuk makkelijker.

Block-Based Widgets Editor en Block Widgets in de Customizer

De block-based widgets editor is een breed project dat de interface van de block editor naar klassieke themawidgets moet overbrengen.

De nieuwe widget editor biedt allerlei voordelen voor de grote meerderheid van de gebruikers die nog altijd de klassieke thema’s gebruiken. Tegelijkertijd biedt het een prettige introductie voor de block interface, voordat het de algemene standaard wordt voor alle WordPress gebruikers.

Zoals Anne McCarty aangeeft bieden block-based widgets diverse voordelen, waaronder:

• Je kan layouts in zijbalken, headers en footers maken, door middel van kolommen, scheidingstekens, spacers en andere ontwerpblocks.
• Widgets bieden nu standaard ondersteuning voor rich text editing, zonder dat gebruikers eigen code moeten toevoegen of een externe HTML editor moeten gebruiken via een plugin.
• Veel widgets die shortcodes gebruiken zijn nu beschikbaar als blocks, wat het ontwerpen veel makkelijker maakt.

Andrei Draganescu benadrukt ook de voordelen die je krijgt door widgets te bewerken via een block-based interface:

Het voornaamste voordeel van de verbetering in de functionaliteit van widgets is dat blocks de mogelijkheid hebben om widgets direct te bewerken via de bekende block interacties, die je ook gebruikt bij het bewerken van een pagina of artikel op je website. Door blocks te kunnen gebruiken krijg je allerlei nieuwe creatieve mogelijkheden, van code-loze mini layouts tot het gebruik van de enorme bibliotheek met blocks uit de core of van derden om content te maken.

Je hoeft je geen zorgen te maken dat je widgets opeens stoppen te werken door WordPress 5.8, aangezien de community hard gewerkt heeft om achterwaartse compatibiliteit te bieden, zodat “bestaande widgets en externe widgets zullen blijven werken, en naast de blocks gebruikt kunnen worden” (zie ook Block-based widgets editor in WordPress 5.8).

Maar nogmaals, test altijd op problemen met compatibiliteit door eerst een nieuwe versie in een testomgeving uit te proberen, voordat je meteen je live website update.

Voor iedereen die nog niet de block-based widget editor wil gebruiken, kan je nog altijd op drie manieren teruggaan naar het klassieke widgets scherm:

1. Je kan de officiële Classic Widgets plugin installeren, die de oude interface herstelt. De plugin zal “worden ondersteund en onderhouden tot tenminste 2022, of zo lang als nodig”.
2. Thema developers kunnen de block-based widget editor uitzetten door de ondersteuning voor een thema te stoppen, op de gebruikelijke manier:

   remove_theme_support( 'widgets-block-editor' );

3. Je kan ook een nieuw use_widgets_block_editor filter gebruiken:

   add_filter( 'use_widgets_block_editor', '__return_false' );

Lees ook over het herstellen van de klassieke widgets editor in het Widget Block Editor overzicht.

Block Widgets naar de Customizer

Als onderdeel van hetzelfde project, brengt WordPress 5.8 block widgets naar de Customizer.

Block-based widgets toevoegen via de customizer is vrij eenvoudig. Je kan de customize widget inserter starten door op het plusje rechtsboven bij de widgets te klikken.

Je kan ook de quick inserter starten onderaan in het widgets-scherm, zoals hieronder te zien.

Op het moment van schrijven had de nieuwe widget editing interface nog allerlei verbeteringen en bugfixes nodig, maar vervolgens zullen de mogelijkheden voor customization nagenoeg onbeperkt zijn.

Vanaf WordPress 5.8 heb je in feite de mogelijkheden van de block editor binnen de customizer, en kan je dus in hoge mate aangepaste zijbalken maken zonder al te veel gedoe.

De block-based widgets editor dev-note biedt een uitgebreid overzicht van de block-based widgets editor, met voorbeelden en resources voor developers.

Block Editor features en verbeteringen

Naast de eerste FSE implementaties, biedt WordPress 5.8 ook allerlei nieuwe features en verbeteringen voor verschillende delen van de block editor, wat het bewerken van je website aanzienlijk prettiger maakt.

Deze veranderingen zijn onder meer:

Verbeteringen in de Media & Text block

Het omzetten van een block naar een columns block is al een poosje mogelijk. Maar alle blocks gingen meteen over naar een columns block met één kolom. Dat kon nogal onhandig zijn bij een media & text block, waarbij één kolom nooit erg mooi wordt.

Vanaf WordPress 5.8 (en Gutenberg 10.2) zal het veranderen van een media & text block naar een columns block automatisch twee kolommen aanmaken: één voor de afbeeldingen en één voor de tekst.

Verbeteringen voor reusable blocks

Reusable blocks maken het mogelijk om een block of aantal blocks op te slaan en ze in een ander artikel of pagina weer te gebruiken. Dit is vooral erg handig voor gebruikers die regelmatig dezelfde block of groep blocks gebruiken in verschillende artikelen of pagina’s.

Door WordPress 5.8 zijn reusable blocks veel overzichtelijker, waardoor je ze makkelijker kan gebruiken.v

Een korte lijst van verbeteringen voor reusable blocks vanaf WordPress 5.8:

• Bij het maken van een reusable block, kan je nu een naam toewijzen aan het block.
• De naam wordt gebruikt in de toolbar, lijst voor navigatie, en in de breadcrumbs.
• Wanneer je een sub-block selecteert, worden reusable blocks gemarkeerd. Dit maakt het gebruik aanzienlijk makkelijker, omdat je eenvoudig de hoofd-block en bijbehorende content kan vinden.
• Het is nu mogelijk om de naam van een block aan te passen via de zijbalk inspector.

Genormaliseerde toolbar voor Image blocks

De toolbars van diverse blocks zijn gereorganiseerd om een consistente User Interface tussen blocks te bieden, wat de user experience aanzienlijk verbetert. De instellingen in toolbars worden nu gegroepeerd op de volgorde “meta, block-level, inline”.

Sinds Gutenberg 10.1 en Gutenberg 10.3, zijn een hoop toolbars genormaliseerd. Dit zijn onder meer de blocks image, button, buttons, list, heading, paragraph, quote, audio, file, media & text, video, en nog een aantal.

Volgens Matias Ventura:

De semantische groeperingen in de toolbar, meta, block level, inline, zouden ook visueel te zien moeten zijn met randen. Op dit moment hebben aparte instellingen in het block verschillende representaties, waaronder gevallen zoals Navigation waarbij elk individueel element randen heeft.

Sinds WordPress 5.8 groepeert de block toolbar instellingen in segmenten, die omgeven zijn door randen. Daarnaast:

• Het Meta segment bevat block-type instellingen, zoals de block switcher, de drag handle en de mover-instelling.
• Het Block level segment bevat specifieke tools voor het block, die de hele content bepalen, zoals de uitlijning in een paragraph block of links in een image block.
• Het Inline level/Other segment bevat inline transformatie tools, zoals inline formatting binnen een text block.
• Het More menu bevat overige tools.

De onderstaande afbeelding vergelijkt de Image block toolbar in WordPress 5.7 en 5.8:

Verbeteringen van de top toolbar

Wanneer je de top toolbar mode inschakelde bij vorige WordPress versies, werden de top toolbar en block toolbar naast elkaar getoond, zoals hier te zien:

Bij WordPress 5.8 zorgt het inschakelen van de top toolbar ervoor dat de block toolbar vastgemaakt wordt aan de bovenkant van de editor, direct onder de top toolbar. Dit wordt onafhankelijk van de breedte van de browser gedaan, en zou aanzienlijke verbeteringen voor de user experience moeten bieden.

Deze verbetering heeft ook gevolgen voor developers, aangezien het de toolbar API’s samenvoegt onder het <BlockTools /> component (zie PR #31134).

Embedded PDF’s

Wanneer een PDF bestand wordt toegevoegd aan het document via een file block, biedt een nieuwe schakelaar in de zijbalk je de keuze om een embedded PDF versie in/uit te schakelen (zie PR #30857).

Je kan het bestand direct naar de editor slepen of het selecteren in de bibliotheek. Het is ook mogelijk om handmatig de hoogte van de PDF viewer aan te passen, of daarvoor de instellingen in de zijbalk te gebruiken.

Alle grote browsers ondersteunen de PDF viewer, behalve mobiele browsers.

Duotone Block ondersteuning

Eén van de meest interessante features die aan de WordPress core is toegevoegd in WordPress 5.8 is de duotone filter, die we voor het eerst zagen in Gutenberg 10.6.

Beschikbaar als “block support” feature is het duotone filter standaard ingeschakeld in image en cover blocks. In het cover block werkt het echt niet bij vaste achtergronden.

Image en cover block toolbars tonen nu een instelling Apply duotone filter, waarbij je een duotone picker te zien krijgt met allerlei keuzes.

Twee sub-instellingen bieden keuzes qua schaduwen en highlighting. Dit effect wordt toegepast met een SVG filter dat verborgen zit in inline styles en toegepast wordt via een specifieke class naam.

De nieuwe tool komt tegelijk met een nieuwe eigenschap, color.__experimentalDuotone, waarmee developers de duotone filter kunnen toevoegen aan blocks of onderdelen van block in hun block.json bestand (daarover meer in color object reference):

supports: {
	color: {
		__experimentalDuotone: '> .duotone-img, > .duotone-video',
		background: false,
		text: false
	}
}

Wanneer een block ondersteuning biedt voor color.__experimentalDuotone, kan een style attribuut gebruikt worden voor custom standaardkleuren:

attributes: {
	style: {
		type: 'object',
		default: {
			color: {
				duotone: [
					'#FFF',
					'#000
				]
			}
		}
	}
}

Hieronder zie je dezelfde afbeelding met twee verschillende duotone effecten:

Developers kunnen duotone presets definiëren in het bestand theme.json (meer in het onderstaande stuk), zoals te zien in dit stukje code:

{
"version": 1,
"settings": {
	"color": {
		"duotone": [
			{
				"colors": [ "#000", "#7f7f7f" ],
				"slug": "black-and-white",
				"name": "dark-grayscale"
			}
		],
	...

Je kan meer lezen over duotone filters in het Kleuren van je afbeeldingen met duotone filters.

Table Block kleuren en randen

WordPress 5.8 brengt ook een aantal verbeteringen voor het Table block, waaronder meer controle over de achtergrond- en voorgrondkleuren van de tabel.

Een andere toevoeging aan de Table block is ondersteuning voor de border block, waardoor je de kleur, stijl en dikte van randen kan instellen.

Wanneer het actieve thema de nieuwe feature ondersteunt, biedt een nieuw paneel met instellingen voor randen die nieuwe instellingen voor aanpassingen.

Developers kunnen ondersteuning voor border blocks bieden in hun thema’s door de volgende code toe te voegen aan het theme.json bestand:

"border": {
	"customColor": true,
	"customStyle": true,
	"customWidth": true
}

Verbeteringen van de Block Inserter

In WordPress 5.8, is de block inserter verbeterd met diverse aanpassingen (PR #26938 en #21080):

1. Tweedimensionale toetsenbordnavigatie in de block inserter. We kunnen nu dus makkelijker en beter navigeren tussen blocks.

• Door op pijl omhoog (↑) en pijl omlaag (↓) te drukken, verschuift de focus een rij naar boven of beneden.
• Door op Tab en Shift + Tab te drukken kan je meteen naar de zoekbalk gaan, de tab-lijst of het eerste item in elke categorie.

2. Een nieuwe “Theme” categorie voor onderdelen en variaties voor templates verschijnt nu in de inserter in Full Site Editing (zie PR #30020).

3. Meerdere woorden in de autocomplete phrase matcher zijn nu toegestaan (zie PR #29939).

Overige verbeteringen in de Block Editor

WordPress 5.8 biedt nog allerlei andere kleinere en kleine verbeteringen die het noemen waard zijn. Zo zouden we de volgende verbeteringen willen benoemen:

Ondersteunen voor afbeeldingen verslepen in Cover blocks

Je kan nu afbeeldingen vanaf je computer verslepen om de achtergrond van een cover block te wijzigen (zie Gutenberg 10.3 en PR #29813).

Verbeterde gebruikersinterface bij publicatie

Sinds WordPress 5.8 toont de UI bij publicatie het icoon en de titel van de site om duidelijk te maken waar je de artikelen of pagina’s naartoe publiceert (Gutenberg 10.4).

Deze vebetering is ideaal als je in full-screen modus zit of op een mobiel apparaat.

Block instellingen en stijlen met theme.json

Bij WordPress 5.8, is het theme.json bestand een centraal punt voor configuratie geworden, wat een nieuwe manier biedt voor themadevelopers om de editor instellingen en stijlen te customizen.

Via het theme.json bestand kunnen thema’s custom presets of ondersteuning voor nieuwe features bieden, zoals duotone en randen bij tabellen (zoals bij Algemene instellingen en stijlen).

Volgens André Maneiro:

Het nieuwe mechanisme moet alle vorige calls naar add_theme_support overnemen en consolideren, die eerst nodig waren voor de editor.

Je kan voortaan een algemene custom duotone preset instellen met de volgende code:

{
	"version": 1,
	"settings": {
		"color": {
			"duotone": [
				{
					"colors": [ "#000", "#0FF" ],
					"slug": "black-cyan",
					"name": "Black Cyan"
				}
			],

Hiermee worden alle standaard presets overschreven, en zie je nog maar één duotone optie:

Dit nieuwe mechanisme biedt een manier om instellingen zowel algemene als per-block te bepalen. Zo kan je bijvoorbeeld een custom 12px lettertypegrootte algemeen beschikbaar maken door de volgende preset toe te voegen aan je theme.json bestand:

{
	"version": 1,
	"settings": {
		"typography": {
			"customLineHeight": true,
			"fontSizes": [
				{
					"slug": "extra-extra-small",
					"size": "12px",
					"name": "Extra extra small"
				},
				{...}

Hierdoor wordt een nieuwe grootte voor lettertypen beschikbaar die gebruikers bij alle tekst in hun content kunnen toepassen.

Wil je alleen de paragraph block aanpassen, dan is je code net wat anders:

{
	"version": 1,
	"settings": {
		"blocks": {
			"core/paragraph": {
				"typography": {
					"fontSizes": [
						{
							"slug": "extra-extra-small",
							"size": "12px",
							"name": "Extra extra small"
						},
						{
							"slug": "extra-small",
							"size": "16px",
							"name": "Extra small"
						},
						{
							"slug": "small",
							"size": "18px",
							"name": "Small"
						},
						{
							"slug": "normal",
							"size": "20px",
							"name": "Normal"
						},
						{
							"slug": "large",
							"size": "24px",
							"name": "Large"
						}
					]
				}
			}
		}
	}
}

En klaar alweer. Je hebt nu een nieuwe grootte voor lettertypen toegevoegd aan het paragraph block.

Core blocks zijn ook aangepast om het nieuwe mechanisme te kunnen volgen, terwijl externe blocks het nieuwe mechanisme kunnen volgen via de React useSetting hook (lees meer over deze optie in de dev-note en API documentatie):

const isEnabled = useSetting( 'spacing.margin' );

Het nieuwe mechanisme via het theme.json bestand is niet alleen van toepassing op instellingen voor blocks. Vanaf WordPress 5.8 is het zelfs niet langer nodig om editor styles te maken en in de rij te plaatsen. Je kan gewoon presets definiëren in het theme.json bestand en de engine zal automatisch classes aanmaken en in de rij plaatsen voor zowel de editor als de frontend.

De engine zal ook de corresponderende CSS Custom Properties genereren.

In het vorige voorbeeld hadden we vijf fontSizes presets aangemaakt voor het paragraph block. Voor die presets zullen automatisch de volgende CSS Custom Properties aangemaakt worden:

p {
	--wp--preset--font-size--extra-extra-small: 12px;
	--wp--preset--font-size--extra-small: 16px;
	--wp--preset--font-size--small: 18px;
	--wp--preset--font-size--normal: 20px;
	--wp--preset--font-size--large: 24px;
}

Nadat je de grootte voor lettertypen in de alinea hebt ingesteld via het theme.json bestand, zal het corresponderende p element de has-{preset-slug}-{preset-category} class krijgen.

Dat betekent dat een alinea die de grootte extra-extra-small heeft, ook de class has-extra-extra-small-font-size krijgt:

<p class="has-extra-extra-small-font-size">Lorem ipsum dolor...</p>

En dit is het CSS declaration block:

p.has-extra-extra-small-font-size {
	font-size: var(--wp--preset--font-size--extra-extra-small) !important;
}

Voor meer details over de instellingen en stijlen via theme.json, lees vooral de dev-note en API documentatie eens door.

Kijk ook naar de FSE call for testing van Anne McCarty voor meer inzichten en interessante uitdagingen voor developers die de nieuwe features van theme.json willen uittesten.

Block API verbeteringen

Block API verbeteringen in WordPress 5.8 verdienen extra aandacht van plugindevelopers.

Het gebruik van het block.json wordt nu aangemoedigd als de standaardmanier om block types te registreren, en dat biedt ook diverse voordelen:

• Qua prestaties, als het thema ondersteuning biedt voor lazy loading, dan zal het registreren van block types via json automatisch het laden van de resources optimaliseren. Dit komt doordat de resources die gespecificeerd zijn via de eigenschappen style en script alleen geladen worden op de frontend wanneer het block wordt gedetecteerd. Hierdoor kan je efficiëntere plugins maken, de grootte van pagina’s verminderen, en verschillende problemen voorkomen die hier beschreven worden.
• Het json bestand vereenvoudigt de server-side block registratie door de Block Types REST API Endpoint toe te staan voor registratie van blocks.
• Het json bestand is ook nodig als je besluit om je block plugin in de WordPress Plugin Directory op te laten nemen.

Veranderingen in de register_block_type functie

Sinds WordPress 5.8 is de register_block_type functie verbeterd, zodat de metadata uit het block.json bestand gelezen kan worden. De eerste parameter accepteert nu het bestandspad voor het block.json bestand.

De functie kan zo gebruikt worden:

function create_custom_block_init() {
	register_block_type( __DIR__ );
}
add_action( 'init', 'create_custom_block_init' );

Hierdoor wordt het geregistreerde block type teruggestuurd, of false als het mislukt.

Zoals je wellicht opgevallen is, wordt de functie register_block_type nu op dezelfde manier gebruikt als de functie register_block_type_from_metadata wat vroeger de enige functie was waarmee je een block type kon registreren door de metadata uit het bestand block.json te lezen. Zoals Greg Ziółkowski het uitlegt:

We hebben besloten om de bestaande functionaliteit van de register_block_type_from_metadata methode te consolideren naar register_block_type om de bestaande verwarring te verminderen. Je kan nog steeds beide functies gebruiken, maar we zijn van plan om voortaan alleen de kortere versies in alle officiële documenten en tools te gebruiken.

Zodra het block geregistreerd is op de server, hoef je alleen maar de instellingen te registreren van de client via dezelfde blocknaam in je index.js bestand.

Voor meer details over block API verbeteringen in WordPress 5.8, kan je de dev-note van Greg Ziółkowski lezen.

WebP ondersteuning in WordPress 5.8

Hier bij Kinsta hebben we een lichte obsessie voor snelheid en prestaties van WordPress websites. Daarom vinden we de ondersteuning van het WebP format in WordPress 5.8 erg interessant.

WebP wordt namelijk als een next-gen format gezien, als een afbeeldingsformat dat door Google ontwikkeld is om meer compressie te bieden dan PNG en JPEG, en dus snellere downloads en minder dataverbruik.

Volgens Google:

WebP is een modern afbeeldingsformat met superieure lossless en lossy compressie voor afbeeldingen op het web. Door WebP kunnen webmasters en webdevelopers kleinere, rijkere afbeeldingen maken waardoor het internet sneller wordt.

WebP lossless afbeeldingen zijn 26% kleiner dan dezelfde afbeelding in PNG. WebP lossy afbeeldingen zijn 25-34% kleiner dan vergelijkbare JPEG afbeeldingen, met een vergelijkbare SSIM kwaliteitsindex.

Vanaf WordPress 5.8 kan je het WebP afbeeldingsformat op dezelfde manier gebruiken als de bestaande JPEG, PNG en GIF formats. Je kan dus gewoon je afbeeldingen uploaden naar de Media Library en ze opnemen in je content.

In een vorig artikel hebben we in detail gekeken naar het WebP format en de tools waarmee je dit binnen WordPress kan gebruiken. Dankzij de ondersteuning voor WebP afbeelding in WordPress 5.8 zal dit wat veranderen. Aangezien WebP voortaan standaard wordt ondersteund, heb je geen extra plugins meer nodig om de WebP afbeelding naar WordPress te kunnen uploaden, in ieder geval niet voor standaardtoepassingen.

Je kan trouwens, ondanks de mogelijkheid voor het uploaden van WebP afbeeldingen naar je Media Library, nog niet automatisch afbeeldingen omzetten naar het WebP format. Om dat toch te kunnen doen op je website, heb je dus nog steeds een externe WebP WordPress plugin nodig.

Zo gebruik je WebP afbeeldingen bij WordPress

Je kan je afbeeldingen op verschillende manieren omzetten naar WebP:

• Je kan de geprecompileerde WebP tools en library van Google gebruiken voor Linux, Windows, of Mac OS X.
• Mac gebruikers kunnen een package manager installeren, zoals de Homebrew WebP package of het Macports WebP package.
• Je kan ook een afbeeldingsbewerkingstool gebruiken met ondersteuning voor WebP, zoals Squoosh van Google Chrome Labs, de batch image converter XnConvert, of een populaire afbeeldingseditor zoals GIMP.
• Je kan ook een WebP WordPress plugin installeren voor meer controle over je WebP afbeeldingen in WordPress.

Als je kiest voor een command-line tool, dan kan je afbeeldingen encoden en decoden via cwebp en dwebp. Het volgende commando voert bijvoorbeeld een standaard JPEG naar WebP conversie uit:

cwebp [options] original_image.jpg -o compressed_image.webp

Je kan ook in bulk conversies van je afbeeldingen doen via Bash en cwebp (voorbeeld van Jeremy Wagner):

find ./ -type f -name '*.png' -exec sh -c 'cwebp -q 75 $1 -o "${1%.png}.webp"' _ {} \;

Bovenstaande opdracht zet alle .png afbeeldingen om naar het .webp format, met een compressiefactor van 75.

Nadat je de WebP afbeeldingen hebt, kan je ze voortaan dus gewoon uploaden naar de WordPress Media Library. Hieronder zie je een 127 KB JPEG afbeelding voor de conversie, in de Media Library:

De gecomprimeerde bestandsgrootte van de WebP afbeelding is nota bene 42% kleiner dan de originele JPEG afbeelding.

Als laatste bieden WebP afbeeldingen dezelfde bewerkingsfeatures als JPEG, PNG en GIF afbeeldingen. Je kan dus gewoon bijsnijden, draaien, spiegelen, en schalen, en veranderingen toepassen op de grootte van afbeeldingen.

Kanttekeningen bij WebP in WordPress 5.8

Volgens Adam Silverstein:

WebP afbeeldingen bieden ondersteuning voor lossy en lossless compressie, naast animaties en ondersteuning voor transparante afbeeldingen. In WordPress wordt het lossless WebP format alleen ondersteunt wanneer de hostingserver Imagick (de PHP library) gebruikt, totdat ook LibGD dit gaat ondersteunen. Daarnaast worden geanimeerde en transparante formats nog niet ondersteund voor resized afbeeldingen (dus wanneer je afbeeldingen uploadt in deze formats, worden er lossy afbeeldingen voor in de plaats gezet).

Als je webhost geen ondersteuning biedt voor WebP afbeeldingen, zal je ook een foutmelding zien wanneer je die probeert te uploaden. Weet je niet zeker of je webhost de Imagick library ondersteunt, dan bevat het Info tabblad van de Site Health tool een item dat je vertelt of er ondersteuning voor Imagick library is.

Met WebP ondersteuning introduceert WordPress 5.8 ook twee extra velden voor de Media Handling binnen Site Health: Imagick version en ImageMagick supported file formats.

Als WebP niet bij de ondersteunde bestandstypen staat, zul je contact op moeten nemen met je webhost voor ondersteuning.

De dev-note biedt extra informatie over WebP ondersteuning binnen WordPress 5.8, waaronder handige FAQ’s en andere zaken.

Ben je geïnteresseerd in het optimaliseren van afbeeldingen, kijk dan ook eens naar deze tutorials:

• Zo optimaliseer je afbeeldingen voor het internet en snelheid
• Waarom en hoe je lossy compressie gebruikt voor je WordPress afbeeldingen
• Zo gebruik je WebP afbeeldingen in WordPress (en verklein je de grootte van afbeeldingen tot 35%
• 15 beste bestandstypes voor afbeeldingen
• Alles wat je moet weten over afbeeldingsgroottes in WordPress

Overige features voor developers

Je vindt nog tientallen andere interessante features voor developers in WordPress 5.8. In dit artikel hebben we ons vooral gericht op de features die de meeste impact zullen hebben op je werk als developer. Maar er zijn nog allerlei andere nieuwe features die ook interessant zijn, zoals:

Block Supports API

WordPress 5.8 biedt nieuwe block supports flags waarmee developers geregistreerde blocks kunnen aanpassen met de nieuwste block features.

Naast de experimentele duotone block ondersteuning die we al noemden (color._experimentalDuotone), biedt WordPress 5.8 ook ondersteuning voor kleur van links. Om deze feature te gebruiken, moet je de volgende flag toevoegen aan je block metadata:

supports: {
	color: {
		link: true;
	}
}

Je kan verschillende waarden instellen via attributen, zoals in onderstaande voorbeeld te zien, of je presets instellen via theme.json:

attributes: {
	style: {
		type: 'object',
		default: {
			color: {
				link: '#FF0000',
			}
		}

Overige veranderingen in Block Supports API zijn bijvoorbeeld:

• fontSize en lineHeight supports zijn nu stabiel.
• spacing ondersteuning is uitgebreid, en je kan nu margin en padding instellen, en individueel de grootte bepalen van top, right, bottom en left.

Je kan meer over de Block Supports API in WordPress 5.8 lezen in de Block Supports API updates dev-note.

Voor meer details over het gebruik van de Block Supports API, lees je de officiële documentatie van Block Supports API.

Custom tabbladen in Site Health

Twee nieuwe hooks maken het mogelijk dat developers hun eigen tabblad toevoegen aan de Site Health interface, en de reeds beschikbare schermen aanpassen.

Het site_health_navigation_tabs filter is een associatieve array van tab ID’s en labels, waarmee je een nieuw tabblad kan registreren binnen Site Health. Je kan het filter gebruiken door de volgende code toe te voegen aan het functions bestand van je thema of via een eigen plugin:

function kinsta_site_health_navigation_tabs( $tabs ) {
	$tabs['kinsta-site-health-tab'] = esc_html_x( 'Kinsta', 'Site Health', 'text-domain' );

	return $tabs;
}
add_filter( 'site_health_navigation_tabs', 'kinsta_site_health_navigation_tabs' );

Onderstaande afbeelding toont het nieuwe Site Health tabblad:

Dankzij het site_health_navigation_tabs filter, is het nu ook mogelijk om de tabs een andere volgorde te geven of te verwijderen.

De site_health_tab_content action wordt geactiveerd wanneer de gebruiker het Site Health scherm bezoekt, behalve bij het standaard Status scherm. Je kan deze hook gebruiken zoals in volgende stukje code (een voorbeeld uit de dev-note):

function kinsta_site_health_tab_content( $tab ) {
	// Return if this is not your tab.
	if ( 'kinsta-site-health-tab' !== $tab ) {
		return;
	}

	// Include the interface, kept in a separate file just to differentiate code from views.
	include trailingslashit( plugin_dir_path( __FILE__ ) ) . 'views/kinsta-site-health-tab.php';
}
add_action( 'site_health_tab_content', 'kinsta_site_health_tab_content' );

Allereerst detecteert het of het huidige tabblad je custom tabblad is, en vervolgens wordt de content voor je Site Health scherm geladen uit een .php bestand. De site_health_tab_content action biedt developers ook de mogelijkheid om het standaard Info tabblad uit te breiden met bepaalde stukjes informatie over hun plugins of thema’s.

Block Editor API ondersteuning in meerdere admin schermen

In WordPress 5.8 is de artikel editor niet meer het enige admin scherm waarin de block editor gebruikt kan worden (zo is het widgets venster een goed voorbeeld).

De core had diverse hooks die gedefinieerd zijn op de server en afhankelijk zijn van het $post object. Dit object is niet aanwezig in de schermen voor site edits, widgets en navigatie. Verder zijn diverse filters afgeschreven en vervangen door context-bewuste opvolgers.

Ook is er een nieuwe WP_Block_Editor_Context class die de huidige context van de block editor vertegenwoordigt, en zijn er verschillende methods geïntroduceerd.

Deze veranderingen verbeteren de schermen met nieuwe opties en bieden developers mogelijkheden voor nieuwe customizations.

Voor een complete lijst met veranderingen in de Block Editor API in de admin schermen, zie de dev note van Greg Ziółkowski.

Overige features en verbeteringen

Er zijn zoveel nieuwe features en veranderingen voor developers in WordPress 5.8, dat we ze nooit allemaal in één artikel kunnen behandelen. Daarom hebben we een lijst met dev-notes voor je verzameld, voor meer informatie:

• Geen support meer voor Internet Explorer 11
• Block-styles loading verbeteringen in WordPress 5.8
• Blocks in een iframed (template) editor
• Layout en content breedte in WordPress 5.8
• Introductie “Update URI” pluginheader in WordPress 5.8
• Verscheidene Block Editor API removals in WordPress 5.8
• REST API wijzigingen in WordPress 5.8
• Verschillende op developers gerichte wijzigingen in WordPress 5.8
• Diverse blockeditor API toevoegingen in WordPress 5.8

Samenvatting

WordPress 5.8 is een belangrijk mijlpaal onderweg naar Full Site Editing. Maar de tweede WordPress release van dit jaar heeft nog veel meer te bieden. Gebruikers en developers zullen ladingen verbeteringen vinden, onder meer in de block editor, het nieuwe theme.json mechanisme, een krachtiger Block API, ondersteuning voor WebP afbeeldingen, en nog veel meer.

Wij zijn vooral erg enthousiast over alle verbeteringen in de block editor en de bijbehorende User Interface, zowel over de grote als de kleine aanpassingen. Het is erg fijn dat de navigatie tussen blocks is verbeterd, de gereorganiseerde block toolbar, het verbeterde overzicht van de interface, en de diverse verberingen in verschillende individuele blocks.

Deze relatief kleine veranderingen vergemakkelijken het bewerken van sites, en haast zonder dat we het merken gebruiken we opeens betere en robuustere software. Dat is voor ons de essentie van WordPress!

En nu jij. Wat denk je van Full Site Editing? En wat zijn jouw favoriete veranderingen in WordPress 5.8?