We zijn gewend om elke keer wanneer er een nieuwe versie uitgebracht wordt, kleine en minder kleine veranderingen en nieuwe functies aan de WordPress core te zien. WordPress 5.7 vormt hierop geen uitzondering en het is geweldig om te zien hoe elke nieuwe release ons een beetje dichter bij de Big Picture brengt.

Ook dit keer zijn er weer verschillende versies van de blok-editor samengevoegd in de core, waardoor deze nieuwe release de algehele bewerkingservaring verbetert en ontwikkelaars in staat stelt om geavanceerde blokken te bouwen en nog meer dingen aan te passen binnen de blok-editor.

Naast de editor introduceert WordPress 5.7 ook tal van wijzigingen en andere geweldige features, waaronder het lazyloaden van iframes, updates aan de login- en registratie-interface, links om wachtwoorden opnieuw in te stellen, een groot aantal bugfixes en nog veel meer.

We hebben alles uitvoerig getest op DevKinsta en we zijn klaar om onze favoriete features en wijzigingen van WordPress 5.7 met je te delen – natuurlijk volledig aangevuld met talloze screenshots en codesnippets.

Als je uitgebreider wil kijken naar de eerste major release van 2021 wil, kijk dan naar de officiële WordPress 5.7 Development Cycle, Planning Roundup en Field Guide.

Laten we dus, terwijl we blijven wachten op full-site bewerken (in de core van WordPress 5.8), achteroverleunen en genieten van alle nieuwe dingen in WordPress 5.7!

Wat is er nieuw in de blok-editor

WordPress 5.7 zorgt ervoor dat veel versies van de Gutenberg plugin nu naar de core komen. Het zou onmogelijk zijn om alle toevoegingen hier te noemen, om nog maar te zwijgen van de vele wijzigingen en bugfixes die aan de editor zijn toegevoegd, maar als je meer wil weten over de versies kan je de volgende links bezoeken: 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9.

Bugfixes en prestatieverbeteringen van Gutenberg 10.0 en 10.1 maken ook onderdeel uit van WordPress 5.7.

Dat gezegd hebbende, laten we onze zorgvuldig samengestelde lijst doornemen met daarin de meest interessante features en wijzigingen die zijn toegevoegd aan de blok-editor van WordPress 5.7:

Blokvariatie features, verbeteringen en API’s

Blokvariaties zijn geïntroduceerd in WordPress 5.4, en bieden gebruikers een manier om een andere instantie van hetzelfde blok te selecteren.

Deze feature werkt samen met de Block Variations API, een krachtige tool waarmee ontwikkelaars variaties van blokken kunnen toevoegen, beheren of verwijderen.

WordPress 5.7 introduceert verschillende verbeteringen, functies en nieuwe API’s voor blokvariaties, waardoor ontwikkelaars een betere gebruikersinterface en krachtigere tools krijgen. Laten we er eens naar kijken.

‘Transform to variation’ voor blokken

Deze functie werd voor het eerst geïntroduceerd met Gutenberg 9.4 en is nu onderdeel van WordPress 5.7. De Transform to variation switcher verschijnt nu onder de blokkaart bij blokken die deze feature ondersteunen.

De Transform to variation switcher voor een Buttons blok
De Transform to variation switcher voor een Buttons blok

Wanneer je een nieuwe blokvariant registreert, kunnen blokdevelopers nu een variatieschakelaar (variation switcher) toevoegen aan de blok-inspector door de nieuwe transform option toe te voegen aan het scope veld van het blok, zoals je in onderstaand voorbeeld kan zien (alleen JS code):

wp.blocks.registerBlockVariation( 'core/heading', { 
	name: 'green-text', 
	title: 'Green Text', 
	description: 'This block has green text. It overrides the default description.',  
	attributes: { 
		content: 'Green Text', 
		textColor: 'vivid-green-cyan' 
	}, 
	icon: 'palmtree', 
	scope: [ 'inserter', 'transform' ] 
} );

In dit voorbeeld verschijnt een blokvariatie in twee gebieden van de gebruikersinterface van de editor: de block inserter en de block inspector.

Voorbeeld blokvariatie met transform scope
Voorbeeld blokvariatie met transform scope

Zie ook PR #26687 voor een diepgaand overzicht van Block Variation Transformations.

Blokinformatie komt nu overeen met blokvariaties

Sinds WordPress 5.7 (en Gutenberg 9.7) toont de gebruikersinterface meer specifieke informatie over blokvariaties, terwijl het hiervoor alleen algemene informatie liet zien.

Vóór WordPress 5.7 toonden de interface-elementen algemene informatie over blokvariaties
Vóór WordPress 5.7 toonden de interface-elementen algemene informatie over blokvariaties

Embed blokken en Social Icons worden gebouwd als blokvariaties; ze zijn dan ook goede voorbeelden van hoe WordPress blokinformatie overeen laat komen met blokvariaties.

Nu tonen de interface-elementen informatie die specifiek is voor blokvariaties
Nu tonen de interface-elementen informatie die specifiek is voor blokvariaties

Deze wijzigingen zijn van invloed op de blok-inspector, de blok-navigatiebalk en de breadcrumbs. Sinds Gutenberg 9.8 is deze UI verbetering ook van toepassing op de blok-switcher.

Verbeteringen aan de UI voor blokvariaties in de blok-switcher
Verbeteringen aan de UI voor blokvariaties in de blok-switcher

Nieuwe blokvariaties API’s

WordPress 5.7 introduceert ook nieuwe API’s die developers kunnen gebruiken bij blokvariatieregistratie om de juiste informatie van een blokvariant te tonen (Gutenberg 9.7).

De nieuwe isActive property is een function die de attributes van een blok accepteert. Je kan de attributes van een variatie gebruiken om te bepalen of een variatie actief is (zie ook Block API reference).

Blokdevelopers kunnen deze functie gebruiken om informatie over de variatie weer te geven in plaats van blokinformatie. Een voorbeeld zou het embed blok kunnen zijn, waar we de waarde van de attribute providerNameSlug kunnen wijzigen (een voorbeeld van de dev note):

const variations = [
{
	name: 'wordpress',
	title: 'WordPress',
	keywords: [ __( 'post' ), __( 'blog' ) ],
	description: __( 'Embed a WordPress post.' ),
	attributes: { providerNameSlug: 'wordpress' },
	isActive: ( blockAttributes, variationAttributes ) =>
		blockAttributes.providerNameSlug === variationAttributes.providerNameSlug,
},
];

In het volgende voorbeeld wordt de property isActive gebruikt om de color attribute te wijzigen:

variations: [
{
	name: 'blue',
	title: __( 'Blue Quote' ),
	isDefault: true,
	attributes: { color: 'blue', className: 'is-style-blue-quote' },
	icon: 'format-quote',
	isActive: ( blockAttributes, variationAttributes ) =>
		blockAttributes.color === variationAttributes.color
},
],

De nieuwe useBlockDisplayInformation hook retourneert informatie over een bepaald blok. De nieuwe hook houdt rekening met de isActive property van een blokvariatie en retourneert de titel, icoon en beschrijving van een blok.

Deze wijzigingen zijn van invloed op Block Card (Inspector Tools), Navigation List View (bovenste balk) en Breadcrumbs (zie ook PR #27469).

Nieuwe features Buttons blok

Een paar nieuwe features zijn toegevoegd die de functionaliteiten en interface van het Buttons blok verbetert.

Knop afmetingen

Een nieuwe optie is beschikbaar in Settings Sidebar waarmee je een percentuele breedte kan opgeven voor knoppen die vallen onder het Buttons blok (Gutenberg 9.4).

Breedte-instellingen voor knoppen
Breedte-instellingen voor knoppen

Je hoeft hiervoor alleen een knop te kiezen en 25%, 50%, 75% of 100% te kiezen. Percentages hebben betrekking op de parent-container. De onderstaande afbeelding toont de verschillende combinaties van knopafmetingen.

Combinaties van knoppen met verschillende breedtewaarden
Combinaties van knoppen met verschillende breedtewaarden

Voor meer technische inzichten, lees dan pull requests #25999 en 26781.

Verticale layout

Deze nieuwe functie voegt variaties toe voor verticale oriëntatie aan het blok Buttons. Gebruikers kunnen overschakelen van een horizontale lay-out naar een verticale met behulp van de Transformations schakelaar die beschikbaar is in het paneel met blokinstellingen (Gutenberg 9.6).

Buttons blok met verticale oriëntatie
Buttons blok met verticale oriëntatie

Verbeteringen voor sociale iconen

WordPress 5.7 voegt nieuwe custumizationmogelijkheden toe aan de Social Icons: ondersteuning voor custom afmetingen en custom kleuren.

Grootte sociale iconen

Bij het selecteren van het Social Icons blok, biedt de bloktoolbar nu een keuzemenu Size met beschikbarre afmetingen (Gutenberg 9.4).

De 'huge' afmeting voor sociale iconen
De ‘huge’ afmeting voor sociale iconen

Custom kleuren in social icons

Hetzelfde blok ondersteunt nu ook kleurinstellingen, waardoor we verschillende custom kleuren voor iconen en achtergronden kunnen instellen (Gutenberg 9.9).

Sociale iconen met zwarte kleur als achtergrond
Sociale iconen met zwarte kleur als achtergrond

Je kan nu het kleurenpalet van het thema gebruiken voor sociale iconen, waardoor wordt voorkomen dat pictogramkleuren botsen met het kleurenschema van je website (zie ook PR #28084).

Ondersteuning voor lettergrootte

WordPress 5.7 ondersteunt nu lettertypegrootte voor zowel List en Code blokken.

Lettergrootte in List blok

Een typografiekaart met opties voor lettergrootte is nu toegevoegd aan de instellingen van het List blok (Gutenberg 9.4).

Lettergrootte in instellingen List blok
Lettergrootte in instellingen List blok

Gebruikers kunnen een van de beschikbare lettergroottes kiezen voor hun lijstitems of hun eigen lettergroottes kiezen aan de hand van pixels. De “Reset” knop herstelt de standaardwaarden.

Ondersteuning lettergrootte voor Code blok

WordPress 5.7 ondersteunt nu het beheer van lettergrootte binnen de Code blokken. Bij het selecteren van het Code blok, krijg je nu in de zijbalk met instellingen een nieuw element te zien genaamd Font size. Hiermee kan je een van de vooraf ingestelde groottes die in je thema beschikbaar is of een custom waarde in pixels instellen (Gutenberg 9.5).

Algemene lettergroottes die beschikbaar zijn in Twenty Twenty
Algemene lettergroottes die beschikbaar zijn in Twenty Twenty

De implementatie van deze functie maakt het ook mogelijk om globale stijlvariabelen te gebruiken in de CSS van codeblokken (zie ook PR #27294). De onderstaande afbeelding toont een codeblok op de front-end met het Twenty Twenty thema geïnstalleerd.

Globale CSS stijlen in een Code blok
Globale CSS stijlen in een Code blok

Full-height uitlijning in Cover blok

WordPress 5.7 introduceert een nieuwe component genaamd Full Height Toolbar Alignment. Het was voor het eerst toegevoegd aan de blok-editor in Gutenberg 9.5. Nu is het samengevoegd in de core en geïmplementeerd in het Cover blok.

Full-height uitlijning is nu onderdeel van het Cover blok
Full-height uitlijning is nu onderdeel van het Cover blok

Als je met de knop de bloktoolbar openklapt en naar de minimale hoogteregeling kijkt, dan zie je dat de uitlijning op volledige hoogte niet meer dan een afkorting is voor 100vh (lees hier meer over in lengtes viewpoort-percentages.

Full-height uitlijning in Cover blok
Full-height uitlijning in Cover blok

Je kan Full Height Alignment gebruiken in combinatie met andere besturingsinstellingen, zoals een vaste achtergrond, positie content enzovoort. Je zal waarschijnlijk verrast zijn door het aantal indrukwekkende effecten dat je op je pagina’s kan creëren.

Drag-and-drop blokken en patronen vanuit de Inserter

De blok-inserter ondersteunt nu drag-and-drop-functionaliteiten voor blokken en patronen. Gebruikers kunnen elk blok of patroon uit de inserter pakken en het ergens op het canvas van het bericht plaatsen (Gutenberg 9.6 en 9.7).

Nu kunt u blokken of patronen van de inserter naar het berichtcanvas slepen
Nu kunt u blokken of patronen van de inserter naar het berichtcanvas slepen

Let op dat drag-and-drop alleen werkt als je thema ook blokpatronen ondersteunt.

Semi-transparant Spacer blok

In plaats van de vroegere ondoorzichtige grijze kleur heeft het Space blok nu een semi-transparante achtergrond (Gutenberg 9.8).

Een ondoorzichtig Spacer blok in WordPress 5.6
Een ondoorzichtig Spacer blok in WordPress 5.6

Deze functie zou het gemakkelijker moeten maken om het Spacer blok bovenop elke mogelijke achtergrondkleur te identificeren.

Een semi-transparant Spacer blok in WordPress 5.
Een semi-transparant Spacer blok in WordPress 5.

Overige verbeteringen aan de blok-editor die het vermelden waard zijn

Onze list kan onmogelijk alle features bevatten die zijn toegevoegd aan de core, dus zorg ervoor dat je de officiële documentatie en devnotes checkt voor een uitgebreider beeld van wat er nieuw is in de blok-editor van WordPress 5.7.

Maar om er een paar te noemen, in 5.7 vind je ook:

Block transfors previews in WordPress 5.7
Block transfors previews in WordPress 5.7

Lazyloaden iframes

Lazyload is een optimalisatietechniek die het laden van niet-kritieke resources uitstelt totdat ze terecht komen in de viewport van de gebruiker. Het lazyloaden van afbeeldingen en embedded resources worden dus niet gedownload/gerenderd totdat ze nodig zijn. Het kan de prestaties van je site drastisch verbeteren, helemaal voor websites met veel afbeeldingen van hoge resolultie en video’s.

Voordat lazyloaden native werd, konden developers assets alleen maar lazyloaden via JavaScript. WordPress gebruikers werden gedwongen tot een plugin om hetzelfde effect te bereiken. Omdat lazyloaden nu de standaard is kunnen afbeeldingen en iframes nu worden ge-lazyload door simpelweg het loading="lazy" attribute toe te voegen aan img en iframe tags.

Safari ondersteunt het lazyloaden van afbeeldingen als een experimentele feature
Safari ondersteunt het lazyloaden van afbeeldingen als een experimentele feature

WordPress 5.5 introduceerde Native Image Lazy-Loading in de WordPress core waarmee automatisch de attribute loading="lazy" img werden toegevoegd met de attributes width en height als specificatie.

Sinds WordPress 5.7 wordt lazyloading nu uitgebreid naar iframe tags. Wat afbeeldingen betreft, om layout shifting te voorkomen, wordt loading="lazy" alleen toegevoegd aan iframe tags waarvan de width en height attributes zijn gespecificeerd.

Binnen WordPress werkt het native lazyloaden van iframes in de volgende context:

  • iframes in post content (the_content)
  • iframes in post excerpts (the_excerpt)
  • iframes in text widgets (widget_text_content)
Lazyloaden instellingenscherm in Chrome (beschikbaar op chrome://flags/)
Lazyloaden instellingenscherm in Chrome (beschikbaar op chrome://flags/)

In WordPress vertrouwen de meeste iframes op de oEmbed integratie, die automatisch een URL omzet in de bijbehorende iframe tag. Helaas biedt niet elke webservice width en height attributes voor iframes; dit weerhoudt WordPress errvan om het loading attribute toe te voegen aan deze iframes.

De onderstaande afbeelding laat een iframe tag zien met het loading="lazy" attribute:

Lazyloaden met een embedded YouTube video
Lazyloaden met een embedded YouTube video

In de woorden van Felix Arntz:

De markup van die iframe tags wordt bestuurd door de respectievelijke webservice en alleen een selectie van die webservices volgen de best practice voor het leveren van een width en height attribute. Omdat WordPress de dimensies van een embedded bron niet kan raden, wordt het loading="lazy" attribute alleen toegevoegd als de oEmbed iframe tag wordt geleverd met beide dimension attributes.

De volgende afbeelding toot een iframe tag zonder het atribute loading="lazy":

Een iframe zonder het loading attribute
Een iframe zonder het loading attribute

Lazyloaden iframes voor developers

Vanuit het perspectief van een ontwikkelaar vereist de nieuwe feature verschillende wijzigingen, waaronder:

  • Het gedrag van de function wp_filter_content_tags()< is uitgebreid om het loading attribute aan iframe tags toe te voegen. Het loading attribute werd voorheen alleen toegevoegd aan img tags.
  • Standaard retourneert de wp_lazy_loading_enabled() function nu true voor iframe tags (wanneer ingeschakeld).
  • De nieuwe function wp_iframe_tag_add_loading_attr() staat de toevoeging toe van het loading attribute aan iframe tags (vergelijkbaar met wp_img_tag_add_loading_attr() – zie Code Reference).
  • De wp_iframe_tag_add_loading_attr filter maakt het mogelijk om lazyloading op specifieke iframes te customizen. Wanneer false of een lege string wordt geretourneerd, dan wordt het attribute niet toegevoegd.

Je kan het standaardgedrag overschrijven met het bestaande wp_lazy_loading_enabled filter die nu true voor iframe tags retourneert.

add_filter(
	'wp_lazy_loading_enabled',
	function( $default, $tag_name, $context ){
		if ( 'iframe' === $tag_name && 'the_content' === $context ){
			return false;
		}
		return $default;
	},
	10,
	3
);

Ook kan je de nieuwe filter wp_iframe_tag_add_loading_attr gebruiken, waarmee je het gedrag van een specifieke iframe kan customizen. Je kan bijvoorbeeld lazyloading uitschakelen voor YouTube video’s binnen een bepaalde context.

De onderstaande code is gebaseerd op een voorbeeld van de devnotes en laat zien hoe je lazyloading uitschakelt voor iframes die YouTube video’s embedden:

add_filter(
	'wp_iframe_tag_add_loading_attr',
	function( $value, $iframe, $context ){
		if ( 'the_content' === $context && false !== strpos( $iframe, 'youtube.com' ) {
		return false;
	},
	10,
	3
);

Let op dat niet alle webbrowsers lazyloaden ondersteunen op moment van schrijven. Je kan hieronder zien dat Firefox en Safari alleen lazyloading op afbeeldingen ondersteunen.

Lazyloaden via attribute voor afbeeldingen en iframes (bron: caniuse.com)
Lazyloaden via attribute voor afbeeldingen en iframes (bron: caniuse.com)

Sitemigratie van HTTP naar HTTPS met één klik

Sinds 5.7 detecteert WordPress of de omgeving van een site HTTPS ondersteunt. Is dit inderdaad het geval, dan laat het HTTP Status gedeelte van de Site health tool een call-to-action knop zien waarmee sitebeheerders hun site met een enkele klik kunnen omschakelen van HTTP naar HTTPS. De content van de site wordt direct gemigreerd, waardoor we geen waarschuwing voor mixed content tegenkomen .

Update je site om HTTPS in WordPress 5.7 te gebruiken (bron: WordPress.org)
Update je site om HTTPS in WordPress 5.7 te gebruiken (bron: WordPress.org)

WordPress geeft een melding weer als HTTPS niet wordt ondersteund.

HTTPS wordt niet ondersteund
HTTPS wordt niet ondersteund

HTTP naar HTTPS migratie voor developers

Naast deze nieuwe automatische features die toegankelijk is via de Site Health tool, introduceert WordPress 5.7 nieuwe functions waarmee ontwikkelaars verschillende aspecten van HTTPS detectie en -migratie kunnen aanpassen.

De nieuwe wp_is_using_https() function retourneert true als zowel “Site Address” (home_url()) en “WordPress Address” (site_url()) een URL met https hebben. Deze nieuwe feature wordt duidelijk geïllustreerd door Felix Arntz in de devnotes:

In wezen geeft het wijzigen van beide URL’s naar HTTPS formeel aan dat de site HTTPS gebruikt. Hoewel er andere manieren zijn om HTTPS gedeeltelijk in WordPress in te schakelen (bijv. Met de FORCE_SSL_ADMIN constant), richt het nieuwe detectiemechanisme zich op het gebruik van HTTPS door de hele site, dwz, zowel de front-end als de back-end.

Terwijl de function wp_is_using_https() checkt op de aanwezigheid van https in de URL, checkt wp_is_https_supported() of de siteomgeving HTTPS correct ondersteunt.

Deze function controleert in wezen op de aanwezigheid van de option https_detection_errors in de database en retourneert true als er geen fouten worden gedetecteerd. Als je omgeving geen HTTPS ondersteunt, dan zal de option https_detection_errors aanwezig zijn in de wp_options tabel, zoals je kan zien in de volgende afbeelding:

HTTPS wordt niet ondersteund
HTTPS wordt niet ondersteund

Zoals hierboven vermeld, worden hardcoded URL’s in de sitecontent direct gewijzigd, dankzij twee nieuwe functions: wp_replace_insecure_home_url() en wp_should_replace_insecure_home_url().

Om een website te migreren van HTTP naar HTTPS, hoeft de sitebeheerder alleen handmatig “Site Address” en “WordPress Address” bij te werken om HTTPS op te nemen in plaats van HTTP. Om het echter nog gemakkelijker te maken, introduceert WordPress 5.7 de nieuwe function wp_update_urls_to_https().

Met deze function kan je met één klik alle content van HTTP naar HTTPS migreren (tenminste in de meest voorkomende scenario’s, zoals wanneer “Site Address” overeenkomt met “WordPress Address”). Dit is helemaal nieuw, en een aanzienlijke verbetering in de WordPress beheerervaring.

Voor meer technische aspecten van HTTPS detectie en migratie, lees je de devnotes van Felix Anrtz, en tickets #57577 en #51437.

Nieuwe parent-gerelateerde functies voor berichten

WordPress 5.7 introduceert twee nieuwe Post Parent gerelateerde functions. Ze zijn eenvoudig te gebruiken en helpen je de logica te verminderen in plugins en thema’s.

has_parent_post()

De function has_parent_post() is een conditional tag die controleert of een bepaald bericht een parent heeft en vervolgens true of false retourneert. Het accepteert bericht ID of WP_Post object als een parameter en gebruikt de $post global variable, indien beschikbaar. Zie het volgende voorbeeld:

<?php if ( has_parent_post( get_the_ID() ) ) : ?>
	// your code here
<?php endif; ?>

get_parent_post()

De function get_parent_post() is een template tag die het parent WP_Post object ophaalt voor een bepaald bericht. Net als de vorige function accepteert het bericht ID of WP_Post object als een parameter. Zie het volgende gebruiksvoorbeeld:

<a href="<?php the_permalink( get_parent_post( get_the_ID() ) ); ?>"><?php echo get_the_title( get_parent_post( get_the_ID() ) ); ?></a>

In de praktijk zouden we deze functions als combinatie gebruiken. Je kan zelf een test uitvoeren door de volgende code uit de devnotes toe te voegen naar het single.php templatebestand van je thema:

<?php if ( has_parent_post( get_the_ID() ) ) : ?>
	<p><a href="<?php the_permalink( get_parent_post( get_the_ID() ) ); ?>">
	<?php
		echo sprintf(
			esc_html__( 'Parent page: %s', 'text-domain' ),
			get_the_title( get_parent_post( get_the_ID() ) )
		);
	?>
	</a></p>
<?php endif; ?>

Updates aan interface login en registratie

WordPress 5.7 brengt verschillende verbeteringen aan de login en registratie feature, met een verbeterde Reset Password interface, nieuwe hooks en andere kleine wijzigingen.

Scherm voor wachtwoord reset

Het scherm om je wachtwoord opnieuw in te stellen geeft nu twee knoppen: Generate Password en Save Password. De eerste knop genereert bij elke klik een nieuw sterk wachtwoord, terwijl de tweede knop je wachtwoord opslaat. Deze verandering zou moeten resulteren in een verbeterde ervaring bij het opnieuw instellen van wachtwoorden voor nieuwe WordPress gebruikers.

De onderstaande afbeelding vergelijkt de schermen voor het opnieuw instellen van wachtwoorden in WordPress 5.6 en 5.7:

Het scherm Wachtwoord opnieuw instellen in WordPress 5.6 en 5.7
Het scherm Wachtwoord opnieuw instellen in WordPress 5.6 en 5.7

Nieuwe filters

De nieuwe lostpassword_user_data hook stelt je in staat om de $user_data variable te filteren bij het resetten van een wachtwoord. Developers kunnen nu gebruikersvalidatie uitvoeren met custom gegevens in plaats van een gebruikersnaam of e-mailadres. Bekijk deze opmerking van Marcelo Villela Gusmão voor een voorbeeld uit de praktijk:

De nieuwe login_site_html_link filter hook stelt ons in staat om de HTML die de “Back to {site_name}” link genereert volledig te vervangen door een aangepaste code/link. Ontwikkelaars kunnen aangepaste tekst voor de link instellen en de link zelf wijzigen. Je kan het filter gebruiken zoals geïllustreerd in het volgende voorbeeld:

function custom_login_site_html_link( $link ) {
	return '<a href="' . esc_url( home_url( '/blog/' ) ) . '">' . __( 'Back to my awesome blog', 'textdomain' ) . '</a>';
}
add_filter( 'login_site_html_link', 'custom_login_site_html_link', 10, 1 );

De onderstaande afbeelding toont de output op het scherm:

Custom “Back to {site_name}” link in WordPress 5.7
Custom “Back to {site_name}” link in WordPress 5.7

Controleer voor aanvullende wijzigingen de de devnote over de wijzigingen in de aanmeldings- en registratieschermen in WordPress 5.7

Nieuwe functions om te controleren of een bericht openbaar kan worden bekeken

WordPress 5.7 introduceert twee nieuwe functions waarmee developers kunnen checken of een bericht openbaar kan worden bekeken.

is_post_status_viewable()

Met de nieuwe functions is_post_status_viewable() kunnen developers bepalen of een bericht openbaar zichtbaar is, afhankelijk van post status.

Deze nieuwe function biedt een betere manier om te controleren of een bericht zichtbaar is dan de bestaande function is_post_type_viewable(), die kan controleren of een berichttype zichtbaar is voor anonieme gebruikers, maar helpt niet om te bepalen of een specifiek bericht kan worden bekeken of niet.

Voor ingebouwde berichttypen controleert is_post_status_viewable() het public attribute. Voor custom berichttypen controleert het in plaats daarvan het publicly_queryable attribute.

We hebben de volgende code getest, gebaseerd op het voorbeeld van de devnote, in een lokale installatie:

$current_post_status = get_post_status( $post );
if ( is_post_status_viewable( $current_post_status ) ) {
	echo '<p>This post uses a public post status.' . ' Current status: <strong>' . $current_post_status . '</strong></p>';
} else {
	echo '<p>This post uses a non public post status.' . ' Current status: <strong>' . $current_post_status . '</strong></p>';
}

is_post_status_viewable() accepteert één vereiste parameter:

  • $post_status (string|stdClass) De post status name of object.

In een openbare blogpost zou de bovenstaande code het volgende resultaat opleveren:

De huidige status van een openbaar zichtbaar bericht
De huidige status van een openbaar zichtbaar bericht

In een privébericht zou het er zo uit zien:

De huidige status van een privébericht
De huidige status van een privébericht

Jean-Baptiste Audras, de auteur van de devnote, waarschuwt:

Houd er rekening mee dat met een wachtwoord beveiligde berichten als openbaar zichtbaar worden beschouwd, terwijl privéberichten dat niet zijn.

is_post_publicly_viewable()

De nieuwe is_post_publicly_viewable() function retourneert true als zowel is_post_status_viewable() en is_post_type_viewable()  true retourneren. Het laat ons ook bepalen of een specifiek bericht openbaar zichtbaar is (dwz of het zichtbaar is voor uitgelogde gebruikers).

is_post_publicly_viewable() accepteert een optionele parameter:

  • $post (string|stdClass) Een post ID of object. Standaard wordt het globale $post object doorgegeven.

Een nieuwe dynamische hook om content van een specifiek bloktype te filteren

WordPress 5.7 introduceert een nieuwe dynamische hook waarmee developers de inhoud van een specifiek bloktype kunnen filteren.

Deze nieuwe  render_block_{$this->name} filter is vergelijkbaar met het al bestaande render_block filter, met een groot verschil: render_block filtert de content van een enkel blok, terwijl deze nieuwe dynamische hook filters ook de inhoud van een bloktype filteren  {$this->name}.

Om dit filter te gebruiken, moet je de volgende parameters opgeven:

  • $block_content (string): De blokinhoud die moet worden toegevoegd.
  • $block (array): Het volledige blok, inclusief naam en attributes.

De callback retourneert de gewijzigde blokinhoud.

Het volgende voorbeeld toont een praktijkvoorbeeld voor dit filter op een Paragraph blok:

add_filter( 
	'render_block_core/paragraph', 
	function( $block_content, $block ) {
		$content  = '<div class="my-custom-wrapper">' . $block_content . '</div>';
		return $content;
	}, 
	10, 
	2 
);

In dit voorbeeld is de suffix core/paragraph de slug van het bloktype van deze core alinea. Voor custom blokken zou de slug zoiets moeten zijn als my-custom-plugin/my-custom-block.

Zie de devnote voor een meer uitgebreid overzicht en extra gebruiksvoorbeelden.

Nieuwe Robots API

De robots meta tag stelt site-eigenaren in staat om te bepalen hoe een webpagina moet worden geïndexeerd en geleverd aan gebruikers binnen de zoekresultaten (bekijk trouwens onze gids over SEO).

WordPress 5.7 introduceert een nieuwe Robots API waarmee developers meer controle hebben over deze robots meta tag. De nieuwe API biedt een wp_robots filter voor thema-ontwikkelaars om hun eigen custom directives toe te voegen aan de robots meta tag.

Bovendien wordt de max-image-preview:large directive nu standaard toegevoegd aan websites die zijn geconfigureerd om zichtbaar te zijn voor zoekmachines. Het instrueert zoekmachines om grote afbeeldingsvoorbeelden weer te geven in zoekresultaten.

De ‘max-image-preview:large’ directive in WordPress 5.7
De ‘max-image-preview:large’ directive in WordPress 5.7

Developers kunnen de max-image-preview:large directive verwijderen met de volgende code:

remove_filter( 'wp_robots', 'wp_robots_max_image_preview_large' );

Het aanpassen van de robots directives is redelijk eenvoudig. Het volgende voorbeeld van de devnote laat zien hoe je een custom directive toevoegt aan de meta tag:

add_filter( 
	'wp_robots', 
	function( $robots ) {
		$robots['follow'] = true;
		return $robots;
	}
);

Het bovenstaande voorbeeld zal de volgende output produceren:

<meta name="robots" content="max-image-preview:large, follow">

Het is ook mogelijk om bestaande directives te verwijderen door simpelweg values uit te schakelen. De volgende code schakelt de max-image-preview directive uit:

function my_wp_robots_directives( $robots ) {
	unset( $robots['max-image-preview'] );
	$robots['follow'] = true;
	return $robots;
}
add_filter( 'wp_robots', 'my_wp_robots_directives' );

Je vindt een diepgaand overzicht van de robots meta tag op Ahrefs blog en Google Search reference. Zie de devnote voor meer informatie over de nieuwe WordPress Robots API en verouderde functions.

Links opnieuw instellen wachtwoord

Met deze nieuwe feature kunnen sitebeheerders nu links versturen voor het opnieuw instellen van wachtwoorden via e-mail naar elke geregistreerde gebruiker. Deze feature kan handig zijn als een gebruiker om welke reden dan ook geen toegang heeft tot de link om het wachtwoord opnieuw in te stellen.

Sitebeheerders kunnen vanuit verschillende gebieden een link voor het opnieuw instellen van het wachtwoord via e-mail verzenden. Allereerst vind je een Send Reset Link knop in het Profiel scherm van elke gebruiker.

Send Reset Link button in Your Profile screen
Send Reset Link button in Your Profile screen

Als alles goed gaat, zou je een beheerdersbericht moeten zien waarin wordt bevestigd dat de link voor het opnieuw instellen van het wachtwoord naar de gebruiker is gemaild.

Een beheerdersbericht bevestigt dat de e-mail met succes is verzonden
Een beheerdersbericht bevestigt dat de e-mail met succes is verzonden

Je kan ook een link voor het opnieuw instellen van uw wachtwoord verzenden vanuit het Gebruikers scherm.

Verzend de link voor het opnieuw instellen van het wachtwoord in het Gebruikers scherm
Verzend de link voor het opnieuw instellen van het wachtwoord in het Gebruikers scherm

Je kan zelfs meerdere gebruikers selecteren en in bulk links voor het opnieuw instellen van wachtwoorden verzenden.

Stuur wachtwoord reset link in bulk
Stuur wachtwoord reset link in bulk

Zoals eerder vermeld, ontvangen gebruikers een e-mail met een link voor het opnieuw instellen van het wachtwoord. De volgende afbeelding toont een e-mail voor het opnieuw instellen van het wachtwoord in de DevKinsta Email Inbox tool.

De e-mail voor het opnieuw instellen van het wachtwoord in DevKinsta
De e-mail voor het opnieuw instellen van het wachtwoord in DevKinsta

Developers kunnen de filters retrieve_password_title en retrieve_password_message om het onderwerp en het bericht van de e-mail aan te passen.

Overige verbeteringen voor ontwikkelaars

Nieuwe functions om attributes door te geven aan script tags

Verschillende nieuwe functions maken het nu mogelijk om attributes door te geven aan <script> tags (dwz async of nonce).

wp_get_script_tag()

wp_get_script_tag() laadt een formatted script tag en injecteert automatisch de type attribute als het thema geen ondersteuning heeft gedeclared voor HTML5 script tags. Het accepteert een array key-value pairs die de attributes vertegenwoordigen die worden toegevoegd aan het <script> tag.

De function gaat gepaard met het nieuwe wp_script_attributes filter die kan worden gebruikt om attributes te filteren.

wp_print_script_tag()

wp_print_script_tag() print een formatted script tag.

wp_get_inline_script_tag()

wp_get_inline_script_tag() wrapt inline JavaScript in een script tag.

Deze function heeft een overeenkomstige wp_inline_scripts_attributes hook die de attributes filtert die aan een script tag moeten worden toegevoegd.

wp_print_inline_script_tag()

wp_print_inline_script_tag() print inline JavaScript in een script tag.

wp_sanitize_script_attributes()

De nieuwe function wp_sanitize_script_attributes() wordt gebruikt om een array van attributes op te schonen tot een attribute string. Vervolgens kunnen ze worden toegevoegd aan een script tag.

Bekijk de devnote voor meer informatie en gebruiksvoorbeelden.

Gestandaardiseerde WP-Admin kleuren

Als onderdeel van een groter project om WP-Admin CSS strakker te maken, gebruikt WordPress nu een nieuw gestandaardiseerd WP-Admin kleurenpalet. Het nieuwe kleurenpalet bevat 12 tinten blauw, groen, rood en geel. Ook zijn 13 tinten grijs, zwart en wit toegevoegd. Bovendien voldoet het aan de minimum door WCAG 2.0 aanbevolen contrastverhoudingsvereisten.

WP-Admin kleurenpalet (bron: ryelle)
WP-Admin kleurenpalet (bron: ryelle)

In de woorden van Jean-Baptiste Audras:

Door deze set kleuren te standaardiseren, kunnen contributors consistente, toegankelijke ontwerpbeslissingen nemen. Ontwikkelaars van thema’s en plugins worden aangemoedigd om dit nieuwe kleurenpalet te gebruiken, voor een betere consistentie tussen hun producten en WordPress core.

WP_MEMORY_LIMIT Constant in Site Health

De WP_MEMORY_LIMIT constant specificeert de maximale hoeveelheid geheugen die PHP kan gebruiken.

De WP_MEMORY_LIMIT constant was niet eerder onderdeel van WordPress en is nu toegevoegd aan het tabblad Info in Site Health.

WP_MEMORY_LIMIT in WordPress 5.7
WP_MEMORY_LIMIT in Site Health Info tab

Aanvullende wijzigingen voor ontwikkelaars worden vermeld in de op ontwikkelaars gerichte wijzigingen en REST API wijzigingen in WordPress 5.7. Je vindt een volledige lijst van devnotes in de WordPress Field Guide.

Samenvatting

Het marktaandeel van WordPress blijft gestaag groeien:

WordPress wordt nu gebruikt door 64,4% van alle websites waarvan het contentmanagementsysteem bekend is. Dat is 40,3% van alle websites.

Het is een significant bewijs van de gezondheid van het CMS, vooral voor degenen die hun bedrijf op WordPress willen bouwen. En dit is ook een uitstekende reden om aandacht te besteden aan wat er speelt in het WordPress ecosysteem.

WordPress 5.7 voegt tal van nieuwe functies en verbeteringen toe voor zowel gebruikers als ontwikkelaars, maar dat is slechts een voorproefje van wat we in 2021 kunnen verwachten.

Nu is het aan jou. Hebben we iets belangrijks gemist? Wat zijn je favoriete wijzigingen en features van WordPress 5.7?

Carlo Daniele Kinsta

Carlo is een gepassioneerd liefhebber van webdesign en front-end development. Hij werkt al meer dan 10 jaar met WordPress, ook in samenwerking met Italiaanse en Europese universiteiten en onderwijsinstellingen. Hij heeft tientallen artikelen en gidsen over WordPress geschreven, gepubliceerd op zowel Italiaanse als internationale websites en in gedrukte tijdschriften. Je kunt Carlo vinden op X en LinkedIn.