Dit is er nieuw in WordPress 5.6 (toegankelijkheid, prestatie, beveiliging)

WordPress 5.6 “Simone” is uitgebracht en we zijn verheugd om een diepe duik te nemen in de meest interessante features en toevoegingen die in de core zijn samengevoegd met de nieuwste WordPress release van 2020.

Net als eerdere releases bevat WordPress 5.6 verschillende versies van de Block Editor die de bewerkingservaring verbeteren voor WordPress gebruikers die de Gutenberg plugin nog niet hebben geïnstalleerd op hun websites of deze hebben bijgewerkt.

Maar niet alles in deze update draait om de Block Editor. Er zijn verschillende features toegevoegd aan de WordPress core, zoals het nieuwe standaard WordPress thema Twenty Twenty-One, automatische updates voor grote (major) releases, (betere) ondersteuning voor PHP 8.0 en Application Passwords voor REST API verificatie.

Maar dat was het nog lang niet! In WordPress 5.6 zien we ook nog verbeteringen in toegankelijkheid, betere UI, talloze bugfixes en een enorme lijst met wijzigingen voor ontwikkelaars.

Als je meer wilt lezen over de ontwikkelingscyclus van WordPress 5.6, bekijk dan onderstaande links:

• 20 oktober 2020: Beta 1
• 27 oktober 2020: Beta 2
• 2 november 2020: Beta 3
• 12 november 2020: Beta 4
• 17 november 2020: RC 1
• 7 december 2020: Testrun voor release WordPress 5.6
• 8 december 2020: release van WordPress 5.6 “Simone”

Klaar om meer te lezen?

Wat is er nieuw in de Block Editor?

Met de release WordPress 5.6 worden er verschillende versies van de Gutenberg plugin samengevoegd tot de core, dus WordPress gebruikers en schrijvers zouden verschillende verbeteringen in de editor moeten tegenkomen. We zien verbeterde blokpatronen, het aantal woorden in het infopaneel, verbeterde toetsenbordnavigatie, verbeterde drag-and-drop interface en nog veel meer.

Voor een uitgebreidere lijst van alle verbeteringen en wijzigingen die je aan zal treffen in de Block Editor, kan je het best de aankondigingsberichten van de afzonderlijke Gutenberg releases lezen: 8.6, 8.7, 8.8, 8.9, 9.0, 9.1 en 9.2. Bugfixes en prestatieverbeteringen die waren geïmplementeerd in Gutenberg 9.3 en 9.4 zal je ook aantreffen in WordPress 5.6.

Laten we eens uitgebreider kijken naar de meest interessante wijzigingen die we in de Block Editor zullen aantreffen.

1. Verbeteringen aan blokken, patronen en UI
2. Block API V2
3. Overige features en verbeteringen voor ontwikkelaars van blokken

Verbeteringen aan blokken, patronen en UI

Door de nieuwe blokfeatures, -verbeteringen en bugfixes zullen we zien dat de algehele bewerkingservaring zal verbeteren. Ook is er goed werk verricht op het gebied van toegankelijkheid. Hieronder vind je onze zorgvuldig geselecteerde selectie van de meest interessante features die je in de Block Editor zal aantreffen zodra je je website hebt bijgewerkt naar WordPress 5.6.

Positieregelaars voor video’s in het Cover blok

Deze feature is toegevoegd aan Cover blokken in Gutenberg 8.6 en stelt je in staat om met positieregelaars te spelen met het focal point (brandpunt) en een custom positie in te stellen voor video’s. Deze functionaliteit was daarvoor alleen beschikbaar voor afbeeldingsachtergronden.

Je kan positiewaarden instellen door ergens op de focal point kiezer te klikken en/of door de pijltjestoetsen op je toetsenbord te gebruiken. Door shift ingedrukt te houden kan je waarden met 10 verspringen (zie ook #22531).

Updates aan blokpatronen

WordPress 5.6 bevat ook een aantal blokpatronen die onderdeel uitmaakten van Gutenberg 8.6.

De lay-out, tekst en kleur van de Large header and paragraph is bijgewerkt (#23858)

De heading van Two columns of text is uit het tekstblok verplaatst en staat nu boven de kolommen (#23853)

Het Quote patroon bevat nu bovenaan een afbeelding en onderaan een separator.

Een nieuw Heading and Pargraph patroon is toegevoegd met Gutenberg 8.7 (#24143).

Wat verbeteringen van de gebruiksvriendelijkheid betreft is de categorie-dropdown voor blokpatronen noemenswaardig, waarmee je patronen kan filteren op categorie. Dit is uitermate handig als je veel patronen hebt waaruit je moet kiezen (#24954).

Ondersteuning voor ondertiteling video’s

Video blokken ondersteunen nu video-ondertiteling.

Redacteuren en contentmakers moeten hiervoor hun video-ondertitels toevoegen in het WebVTT format (Web Video Text Tracks Format), “een format waarmee je getimede teksttracks kan laten zien (zoals ondertitels en captions) met het <track> element” (#25861).

Zodra je je .vtt bestanden hebt geladen, kunnen sitebezoekers ondertitels inschakelen in hun taal naar keuze.

Transformeer meerdere blokken in een Columns blok

Een interessante verbetering aan de gebruiksvriendelijkheid is de mogelijkheid om meerdere geselecteerde blokken om te zetten in een Columns blok.

Je hoeft alleen maar de blokken te selecteren die je in de kolommen wil laten zien en vervolgens op de knop rechtsboven in de toolbar van het blok te klikken.

Elk geselecteerd blok wordt omgezet in een kolom van een Columns blok.

Achtergrondpatronen in Cover blok

Cover blokken kunnen nu achtergrondpatronen weergeven.

Om een achtergrondpatroon toe te voegen, upload je een patroonafbeelding en schakel je de optie Repeated background in (hier is alles wat je moet weten over de Mediabibliotheek in WordPress).

Wanneer je klaar bent, kan je de focal point picker naar wens aanpassen en verschillende combinaties proberen van vaste achtergronden.

Controle over afbeeldingsgroottes toegevoegd aan het blok Media & Text

Sinds Gutenberg 9.1 heb je meer controle over de groottes van afbeeldingen in het blok Media & Text.

Gebruikers kunnen nu kiezen uit alle beschikbare afbeeldingsgroottes (#24795).

Block API V2

Een nieuwe Block API versie zorgt dat blokken hun wrapper element kunnen renderen. Het doel van deze nieuwe API versie is om de DOM van de editor lichter te maken en deze af te stemmen op de content van de front page. Volgens Ella van Durpe:

Het grootste voordeel hiervan is dat thema’s en plugins de content van het blok makkelijker kunnen stylen als de markup hetzelfde is in de editor.

De nieuwe versie vereist dat de property apiVersion wordt gedeclared bij het registreren van block type:

registerBlockType( name, { apiVersion: 2 } );

De nieuwe API vereist ook het gebruik van de useBlockProps hook in de Edit function van het blok. Deze hook markeert het wrapper element van een blok als een block element.

Elke property die aan deze hook wordt doorgegeven, wordt gemerged en geretourneerd naar het wrapper element. Het volgende voorbeeld van de dev notes is een simpele use case:

import { useBlockProps } from '@wordpress/block-editor';
 
function Edit( { attributes } ) {
	const blockProps = useBlockProps( {
		className: someClassName,
		style: { color: 'blue' },
	} );
	return <p { ...blockProps }>{ attributes.content }</p>;
}

Bekijk Block API version 2 voor meer voorbeelden.

Overige features en verbeteringen voor ontwikkelaars van blokken

Naast Block API versie 2 is hier een lijst met toevoegingen voor developers.

Block Supports API

Block Supports API kan door blokdevelopers worden gebruikt om features aan hun blokken toe te voegen. Kleuren, achtergronden, lettergroottes zijn slechts een aantal van de vele features die aan blokken kunnen worden toegevoegd via de Block Supports API.

WordPress 5.6 introduceert ook verschillende nieuwe supports voor blokken “om de consistentie te vergroten en het gemakkelijker te maken om deze opties aan blokken toe te voegen”.

Ontwikkelaars kunnen deze nieuwe block supports toevoegen door de overeenkomstige keys toe voegen aan de property supports van het block.json bestand of rechtstreeks in de registerBlockType function.

Het volgende voorbeeld van Block Supports dev note laat zien hoe dit in zijn werk gaat:

supports: {
	color: {
		background: true, // Enable background color UI control.
		gradient: true, // Enable gradient color UI control.
		text: true // Enable text color UI control.
	},
	fontSize: true, // Enable font size UI control.
	lineHeight: true // Enable line height UI control.
}

De style value wordt automatisch aan het wrapper element gekoppeld ofwel via de class has-<value>-<preset-category> (voor preset values) of met een style element (voor custom values).

Dit is dan ook de reden dat Block Supports bedoeld zijn om te worden gebruikt met de nieuwe Block API V2.

Block Supports kunnen ook gebruikt worden met dynamische blokken.

createBlocksFromInnerBlocksTemplate API

Ontwikkelaars kunnen het InnerBlocks component gebruiken om custom blokken te maken die andere blokken bevatten. Voorbeelden zijn het Columns blok en het Social Links blok.

Met de nieuwe Block API createBlocksFromInnerBlocksTemplate kan je blokken maken op basis van het InnerBlocks template.

Lees de dev notes voor meer informatie en een voorbeeld van code.

Toolbar componenten

Een aantal van de veranderingen hebben betrekking op de Toolbar componenten:

1. Component ToolbarGroup

Vóór WordPress 5.6 konden ontwikkelaars met de Toolbar component om gerelateerde options te groeperen in een gemeenschappelijke container. In plaats daarvan wordt nu een nieuwe ToolbarGroup component gebruikt.

<BlockControls>
	<ToolbarGroup>
		<ToolbarButton />
	</ToolbarGroup>
</BlockControls>

2. Componenten ToolbarButton en ToolbarItem

Het rechtstreeks gebruiken van tabbable elementen als toolbar-items (bijv <button>) kan nu niet meer. Om de toegankelijkheid te verbeteren, kunnen toolbalk-items worden toegevoegd met ToolbarButton voor knoppen en ToolbarItem voor andere controls. Het onderstaande voorbeeld laat een knop en een dropdown-menu zien:

<BlockControls>
	<ToolbarItem as="button" />
	<ToolbarButton />
	<ToolbarItem>
		{ ( itemProps ) => ( <DropdownMenu toggleProps={ itemProps } /> ) }
	</ToolbarItem>
</BlockControls>

Core blokpatronen uitschakelen

Core patronen kunnen nu worden uitgeschakeld met behulp van de support flag core-block-patterns (#24042)

Inline afbeeldingseditor uitschakelen

Gutenberg 8.4 voegde een feature toe om inline afbeeldingen te bewerken waarmee gebruikers afbeeldingen rechtstreeks vanuit de Block Editor konden bewerken.

Ontwikkelaars kunnen deze Image Editor nu uitschakelen met het filter block_editor_settings (#23966):

add_filter( 'block_editor_settings', function( $settings ) {
	$settings['imageEditing'] = false;
	return $settings;
} );

Herbruikbare blokken verplaatst naar een aparte package

Herbruikbare blokken, voorheen onderdeel van de package @wordpress/editor is verplaatst naar de package @wordpress/reusable-blocks om ze beschikbaar te maken in andere editors.

Een nieuw standaard thema: Twenty Twenty-One

WordPress 5.6 bevat een gloednieuw standaard thema. Twenty Twenty-One is een zeer toegankelijk, minimalistisch WordPress thema met een enkele kolomindeling en een footer zijbalk.

Het nieuwe thema gebruikt een system font stack en een minimaal kleurenpalet op basis van pastelkleurige achtergrondkleuren.

Je kan veel meer lezen over Twenty Twenty-One in onze uitgebreide blogpost: Twenty Twenty-One: een diepe duik in het nieuwe standaard WordPress thema.

Automatische updates voor grote releases

Automatische updates is een core feature uit alweer WordPress 3.7 en is bedoeld om de sitebeveiliging te verbeteren en het voor sitebeheerders gemakkelijker te maken om hun WordPress websites up-to-date te houden.

Hoewel eerdere versies het automatisch updaten van kleinere core-updates mogelijk maakten, zorgt WordPress 5.6 ervoor dat sitebeheerders nu ook handmatig automatische updates voor grote releases kunnen inschakelen (daarover zodirect meer).

Helaas kan deze cruciale onderhoudstaak nog steeds enigszins lastig zijn voor niet-technische gebruikers. Je kan meer lezen over hoe automatische updates werken in ons uitgebreide artikel over automatische updates binnen WordPress.

Daarom introduceert WordPress 5.6 een nieuwe interface waarmee sitebeheerders automatische updates voor belangrijke kernreleases kunnen inschakelen.

De aard van deze feature is gedurende de betacycle van WordPress 5.6 veranderd en de oorspronkelijke dev note is inmiddels vervangen. In de woorden van Jb Audra

is de initiële strekking achter de auto-updates van de core verplaatst naar:

• Aanbrengen van updates aan het ontwerp van de UI.
• Voor bestaande installaties blijft het werken zoals altijd: standaard aangemeld voor kleine updates, maar een gebruiker moet zelf aangeven dat dit ook geldt voor grote updates (constants en filters die al door hosts of bureaus zijn opgegeven hebben hierop nog steeds voorrang).
• Voor nieuwe installaties verandert het standaard gedrag: standaard aangemeld voor kleine updates en standaard aangemeld voor grote updates.

Vanaf WordPress 5.6 kan je op de pagina Updates ervoor kiezen dat WordPress automatisch updates uitvoert voor belangrijke coreversies, waar een nieuwe UI je een selectievakje geeft waarmee je automatische updates voor alle nieuwe versies van WordPress inschakelt – Enable automatic updates for all new versions of WordPress.

Zodra je hebt ingeschakeld dat WordPress automatisch de core bijwerkt voor grote release, kan je vervolgens deze zo instellen dat het alleen voor onderhouds- en beveiligingsupdates wordt getriggerd bij Switch to automatic updates for maintenance and security releases only.

Grote automatische core-updates voor ontwikkelaars

Wanneer automatisch updaten van de grote core-updates is ingeschakeld, dan wordt de auto_update_core_major option opgeslagen in de database met de option_value ingeschakeld. Als get_site_option('auto_update_core_major') true retourneert, dan wordt de checkbox voor automatische updates aangevinkt.

Vervolgens controleert WordPress of auto-updates van de grote core-releases zijn ingeschakeld via de WP_AUTO_UPDATE_CORE constant of het allow_major_auto_core_updates filter en stelt het selectievakje dienovereenkomstig in.

Developers kunnen auto-updates van grote core-updates ook uitschakelen door de constant van WP_AUTO_UPDATE_CORE op false of minor te zetten (lees ook Controle over achtergrondupdates via wp-config.php):

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables minor updates:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

De mogelijke waarden voor WP_AUTO_UPDATE_CORE zijn true (alles), 'beta', 'rc', 'minor', false.

Een andere opties om standaard de grote core-updates uit te schakelen is door gebruik te maken van de nieuwe filter allow_major_auto_core_updates:

add_filter( 'allow_major_auto_core_updates', '_return_false' );

Een paar opmerkingen aan de toevoeging van automatische updates aan de core

In december 2018 deelde Matt Mullenweg de negen prioriteiten voor 2019, waar “Een manier bieden aan gebruikers om automatische updates van belangrijke core-releases in te schakelen” op plek 7 kwam. Beter laat dan nooit!

Deze automatische core-updates zouden een grote impact moeten hebben op de beveiliging en algehele ervaring van WordPress sites. Eén ding lijkt duidelijk: vanuit technisch oogpunt is deze belangrijke feature van automatische core-updates een complexe taak die niet 100% volbracht is met de release van WordPress 5.6.

Na een evenwichtige discussie op Slack vatte Josepha Haden de zorgen en vragen van Core contributors samen.

Het belangrijkste langetermijndoel is om automatische updates beschikbaar te hebben op de meeste WordPress websites om de beveiliging van het hele WordPress ecosysteem (meer dan 30% van het internet) te verbeteren.

Dit is wat Helen Hou-Sandí, Core Lead Developer, erover te zeggen heeft:

Wat mij betreft zijn er een aantal zeer moeilijke technische zaken om uit te voeren en dit vereist HEEL gedisciplineerd en gericht technisch producteigendom

We zouden dus in de loop van de tijd aanvullende wijzigingen en verbeteringen aan de gebruikersinterface van de automatische updates van de belangrijkste core-releases moeten zien. Dit is wat we vanaf nu kunnen verwachten:

WordPress 5.6:

• Bij bestaande installaties moeten gebruikers zelf automatische updates van de belangrijkste core-releases inschakelen. Alle constants en filters die al in gebruik zijn, hebben voorrang. Kleine (minor) updates zijn standaard ingeschakeld.
• Bij nieuwe installaties zijn standaard zowel kleine als grote updates ingeschakeld.

WordPress 5.6.1:

• Op basis van feedback zouden we enkele wijzigingen moeten zien in de gebruikersinterface van automatische updates.

WordPress 5.7:

• Waarschijnlijk wordt een nudge (herinnering) toegevoegd aan de pagina Sitediagnose voor iedereen die zich heeft afgemeld voor automatische updates.
• In WordPress 5.7 wordt waarschijnlijk een opt-in voor automatische updates toegevoegd aan het installatieproces.

Een groot probleem met automatische core-updates is dat gebruikers het vaak niet vertrouwen. Volgens Helen:

Ik geloof dat we nog veel werk kunnen verzetten om proactief het vertrouwen van gebruikers te werven, en dan met name van de groep die eerder slechte ervaringen hebben gehad met WordPress en/of updates

Elke WordPress site is echter een mix van core, plugins en thema. In de woorden van Helen:

Core-updates zijn over het algemeen redelijk veilig en bevatten een aantal beveiligingsmechanieken, maar omdat sites code van elke bron kunnen uitvoeren, bestaat er niet iets als “100% werkend” voor “elke soort WordPress website”.

Gebruikers die hebben gekozen voor automatische updates moeten regelmatig een back-up maken van hun website of een webhost kiezen die automatische back-ups aanbiedt in hun pakketten.

Core auto-updates hebben ook invloed op de algemene update-ervaring, inclusief automatische updates van plugins en thema’s. Joost de Valk merkte in een reactie op:

Als we het automatisch updaten van de WordPress core standaard inschakelen, moeten we hetzelfde doen voor plugins. Anders kunnen plugins en thema’s niet worden bijgewerkt voor dingen die ze moeten oplossen vanwege core-updates. Ik denk dat gebruikers dit ook zouden verwachten: als WordPress auto-updatet, zouden plugins en thema’s dit ook moeten doen.

Verandering in Sitediagnose in WordPress 5.6

Naast alle features die we al hebben besproken, brengt WordPress 5.6 ook een verbeterde versie van de Sitediagnose tool, die zich nu op de achtergrond anders gedraagt.

Datavalidatie Sitediagnose check

Een validator controleert nu de probleemresponses van Sitediagnose tests. De validator zal elke ongeldige respons negeren, waarmee wordt voorkomen dat de Sitediagnose tool fatale fouten veroorzaakt en verdere controles worden stopgezet.

Vanaf nu hebben ongeldige responses geen invloed op de Sitediagnose indicator (#50145).

Asynchrone checks via REST endpoint

De Sitehealth tool is een krachtige beveiligingstool waarmee site-eigenaren op de hoogte kunnen blijven van de gezondheid van hun websites.

Deze tool voert een aantal beveiligingstests uit die samen een overzicht geven van de gezondheidsstatus van je website.

Deze tests kan je in twee categorieën onderverdelen: direct tests, die worden uitgevoerd bij pageloads, en async tests, die vaak wat langer duren en later via JavaScript calls worden uitgevoerd.

Eerder werden deze tests uitgevoerd met een call naar admin-ajax.php. Met WordPress 5.6 wordt admin-ajax.php hier minder bij betrokken en wordt in plaats daarvan een nieuw REST API endpoint gebruikt. Vanaf WordPress 5.6 kunnen de asynchrone tests worden gevonden onder de namespace /wp-json/wp-site-health/v1.

Dankzij deze toegevoegde REST API verbetering, kunnen plugins en thema’s ook gebruik maken van REST endpoints en zijn ze wat sitediagnose-tests niet beperkt tot Ajax actions.

Elke asynchrone test kan nu het argument has_rest declaren, dat standaard op false staat.

De onderstaande code van wp-admin/includes/class-wp-site-health.php laat de array van asynchrone tests in WordPress 5.6 zien:

'async'  => array(
	'dotorg_communication' => array(
		'label'             => __( 'Communication with WordPress.org' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/dotorg-communication' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_dotorg_communication' ),
	),
	'background_updates'   => array(
		'label'             => __( 'Background updates' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/background-updates' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_background_updates' ),
	),
	'loopback_requests'    => array(
		'label'             => __( 'Loopback request' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/loopback-requests' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_loopback_requests' ),
	),
	'authorization_header' => array(
		'label'     => __( 'Authorization header' ),
		'test'      => rest_url( 'wp-site-health/v1/tests/authorization-header' ),
		'has_rest'  => true,
		'headers'   => array( 'Authorization' => 'Basic ' . base64_encode( 'user:pwd' ) ),
		'skip_cron' => true,
	),
),

Geplande Sitediagnose-checks:

Hoewel asynchrone tests zijn geïmplementeerd om langzame paginalaadtijden en time-outs te voorkomen, geldt dit nadeel niet voor geplande tests.

Met dat in gedachten kunnen test arrays – naast het has_rest argument dat we hierboven noemden – ook het async_direct_test argument declaren (met behulp van de bovenstaande code), wat een een callable instance van een test zou moeten zijn.

Als een test wordt uitgevoerd tijdens een gepland event, dan gebruikt de test niet het REST API endpoint maar wordt deze rechtstreeks uitgevoerd.

Application Passwords voor REST API verificatie

Application Passwords is een nieuw systeem voor het maken van geverifieerde verzoeken naar verschillende API’s.

Wachtwoorden zijn 24 tekens lang en bestaan uit hoofdletters, kleine letters en numerieke tekens, die handmatig of via de REST API kunnen worden gegenereerd.

Om handmatig een nieuw applicatiewachtwoord te genereren, blader je naar je Profile pagina en scrol je naar beneden.

Kies een naam voor je Application Password en bevestig. WordPress laat je nieuwe wachtwoord zien.

Applicatiewachtwoorden worden weergegeven in blokken van 4 tekens, gescheiden door spaties, zoals je hieronder kan zien:

gsUc UhkU 0ScI gdRd TGoU vrW5

Wachtwoorden kunnen echter met of zonder spaties worden gebruikt:

De applicatiewachtwoorden die tijdens het verificatieproces worden teruggestuurd, bevatten geen spaties. Deze zijn er alleen maar om het voor iemand die de hele dag naar een scherm zit te kijken, makkelijk te maken om het handmatig in te voeren.

Ze kunnen in stukjes worden opgedeeld, zonder spaties of – als je helemaal los wil gaan – kan je waarschijnlijk ook na elk teken een spatie plaatsen.

Op de pagina User Profile kan je applicatiewachtwoorden bekijken, aanmaken en intrekken. De kolommen Last Used en Last IP maken het je makkelijker om wachtwoorden te vinden die je niet meer gebruikt en dus kan intrekken.

Op het moment van schrijven kunnen applicatiewachtwoorden worden gebruikt met de REST API geverifieerde verzoeken en met de inmiddels verouderde XML-RPC API. In de toekomst zullen we waarschijnlijk zien dat Application Passwords ook met andere API’s wordt gebruikt. George Stephanis legt uit:

Het verificatieschema voor applicatiewachtwoorden kan ook worden toegepast op toekomstige API’s voor WordPress zodra deze beschikbaar komen. Als GraphQL of andere systemen ook naar WordPress komen, zal Application Passwords ze een solide, al bestaande authenticatie-infrastructuur bieden waar ze zo op kunnen inhaken.

Je kan Application Passwords niet gebruiken op wp-login.php.

Raadpleeg de volgende bronnen als je meer wil weten over deze functie en de technische achtergronden:

• Voorstel: REST API Authentication / Application Passwords
• Application Passwords: handleiding integratie
• Application Passwords feature plugin

Betere ondersteuning voor PHP 8

PHP 8.0 brengt talloze nieuwe features en optimalisaties met zich mee en kan met recht een mijlpaal worden genoemd in de evolutie van deze codetaal. Deze nieuwere versie van PHP bevat veel updates die achterwaartse compatibiliteit opheffen en veel verouderde features zijn nu officieel verwijderd. Zorgen dat PHP 8 wordt ondersteund door WordPress is dus een hele uitdaging.

Zelfs nu WordPress core contributors hun best doen om te zorgen dat WordPress 5.6 compatibel wordt met PHP 8, kunnen we niet verwachten dat elk mogelijk probleem wordt ontdekt. Het doel is natuurlijk om op een punt te komen dat het hele WordPress ecosysteem compatibel is met PHP 8, maar op dit moment lijkt dat nog iets te ver weg.

Verder bevat elke WordPress website minstens één thema en een aantal plugins. We kunnen dus verwachten dat solide ondersteuning voor PHP 8 door de WordPress core niet lang uitblijft, maar dat dit niet per se geldt voor de vele thema’s en plugin en hun ondersteuning voor PHP 8.

We zijn het dus eens met Jonathan Desrosiers als hij zegt:

Het is onmogelijk te voorspellen hoe de ondersteuning van PHP 8 met het bredere ecosysteem (plugins, thema’s, etc.) uitpakt. Om die reden moet WordPress 5.6 worden beschouwd als “beta compatible” met PHP 8.

“Beta compatible met PHP 8” is een goede beschrijving die aan de ene kant aangeeft dat het een doorlopend proces is dat nog niet afgerond is, maar die aan de andere kant ook het geweldige werk erkent dat tot nu toe is verricht.

Echter,

alle plugin- en thema-ontwikkelaars, net als hostingcommunity’s, worden opgeroepen om hun code compatibel te maken met PHP 8. Hiermee kan WordPress snelle “fully compatible” worden, zonder dat de eindgebruiker de last hoeft te dragen.

Een aantal PHP wijzigingen om rekening mee te houden

Zoals we hierboven al zeiden, is volledige compatibiliteit van WordPress met PHP 8 een “work in progress”. Jonathan Desrosiers heeft een lijst uitgebracht met PHP 8 features en wijzigingen waarvan WordPress ontwikkelaars op de hoogte moeten zijn.

Named Parameters

Met PHP named arguments is het nu mogelijk om arguments door te geven aan een function op basis van de naam van de parameter, in plaats van de positie van de parameter. Dit maakt het mogelijk om self-documenting code te schrijven, arguments zijn order-independent en de default values kunnen naar wens worden overgeslagen.

Helaas kunnen momenteel named parameters achterwaartse compatibiliteitsproblemen veroorzaken in WordPress. De belangrijkste reden is dat parameternamen zonder kennisgeving kunnen worden gewijzigd totdat de huidige audit is voltooid. Dus op het moment van schrijven:

Het gebruik van named parameters bij het callen van WordPress functions en class methods wordt expliciet niet ondersteund en ten zeerste afgeraden totdat deze audit kan worden voltooid, aangezien tijdens de audit de parameternamen zonder kennisgeving kunnen worden gewijzigd. Wanneer deze audit is voltooid, wordt dit aangekondigd in een toekomstige dev note.

Strikte type/value validations voor internal functions

Wanneer een parameter van een illegaal type wordt doorgegeven, gedragen internal en user-defined functions zich anders. User-defined functions veroorzaken een TypeError, maar internal functions gedragen zich op verschillende manieren, afhankelijk van verschillende voorwaarden.

Om deze inconsistenties te verwijderen, genereren de internal parameters die de API’s parsen altijd een ThrowError in het geval van een parameter type mismatch.

Strict type declaration wordt niet in WordPress core gebruikt. Core contributors werken er op dit moment echter aan om te voorkomen dat invalid types worden doorgegeven aan core functions. Totdat dit proces is afgerond, kan deze PHP 8 wijziging leiden tot TypeErrors, “vooral als het type van een value incorrect wordt gewijzigd door code dat is gehooket aan een filter”.

Strengere type checks voor arithmetic en bitwise operators

In eerdere versies was het toegestaan om arithmetic en bitwise operators te gebruiken voor een array, resource en non-overloaded object, maar het gedrag was inconsistent en soms zelfs gewoon raar:

var_dump([] % [42]);
// int(0)

Met PHP 8 is dit gedrag altijd hetzelfde en zullen alle arithmetic and bitwise operators een TypeError exception genereren wanneer de operand een array, resource of non-overloaded object is (zie de RFC).

Dit is ook een wijziging die wat extra werk van de core contributors vraagt, zoals de vele foutmeldingen, waarschuwingen en andere wijzigingen.

Nogmaals, vanwege de verschillende problemen die nog steeds niet zijn opgelost, wordt het ten zeerste aanbevolen om compatibiliteitstests uit te voeren op een staging- of ontwikkelomgeving voordat je de overstap maakt naar PHP 8 op je live website. Lees meer over WordPress en PHP 8.0.

Overige wijzigingen voor ontwikkelaars

WordPress 5.6 brengt veel veranderingen voor ontwikkelaars met zich mee en we konden deze niet allemaal in onze lijst opnemen. Maar dit is de top 3 waarvan we denken dat ze het bekijken waard zijn:

1. Action hook wp_after_insert_post

Vóór WordPress 5.6 kon je save_posts of soortgelijke actions gebruiken om custom code uit te voeren nadat een bericht was gepubliceerd. Nu introduceert WordPress 5.6 de nieuwe action hook wp_after_insert_post, die pas wordt geactiveerd als terms en metadata zijn opgeslagen.

Verder zijn er ook een aantal functions bijgewerkt om te voorkomen dat deze hooks worden gefired. De nieuwe parameter $fire_after_hooks is toegevoegd aan de functions wp_insert_posts(), wp_update_post() en wp_insert_attachment(). Als deze op false staat, dan wordt voorkomen dat de after insert hooks worden gefired.

Bekijk de dev note voor meer informatie.

2. Typecasting

Typecasting functions intval(), strval(), floatval() en boolval() zijn verwijderd uit de core ten gunste van direct typecasting:

1. intval() → (int)
2. strval() → (string)
3. floatval() → (float)

Deze wijziging heeft directe gevolgen voor de prestaties omdat direct typecasting zo’n 6x sneller is dan typecasting functions.

3. WP_Error objects

De WP_Error class is verbeterd door de mogelijkheid om meerdere WP_Error instances samen te voegen tot één. Voorheen kon je dat alleen handmatig doen. Nu worden met WordPress 5.6 drie nieuwe methodes geïntroduceerd om meerdere WP_Error instances te helpen verwerken. De onderstaande code is een voorbeeld uit de dev note:

<?php
$error_1 = new WP_Error(
	'code1',
	'This is my first error message.',
	'Error_Data'
);
 
$error_2 = new WP_Error(
	'code2',
	'This is my second error message.',
	'Error_Data2'
);
 
// Merge from another WP_Error.
$error_1->merge_from( $error_2 );
 
// Retrieve all error data, optionally for a specific error code.
$error_1->get_all_error_data( 'code2' );
 
// Export to another WP_Error
$error_1->export_to( $error_2 );

Verdere leessuggesties voor ontwikkelaars

Het is onmogelijk om alle wijzigingen van WordPress 5.6 te noemen die zich richten op ontwikkelaars, maar je kan er meer over lezen in de volgende bronnen:

• Updaten jQuery versie die geleverd wordt met WordPress
• Core jQuery updaten naar versie 3 – deel 2
• WordPress en PHP 8.0
• REST API batch framework in WordPress 5.6
• Overige op developers gerichte wijzigingen in WordPress 5.6

Samenvatting

WordPress 5.6 is een major release met tal van nieuwe features en wijzigingen voor zowel gebruikers als developers. We zijn altijd enthousiast om te zien hoe de evolutie van webtechnologieën de beveiliging, prestaties, bruikbaarheid en toegankelijkheid van WordPress rechtstreeks beïnvloedt.

Maar de ontwikkeling stopt nooit en we kunnen nu al een kijkje nemen naar toekomstige mogelijke releasedata.

Nu is het jouw beurt: wat spreekt jou het meest aan in WordPress 5.6? En welke features zou je toegevoegd willen hebben aan WordPress 5.7?