Wat is er nieuw in WordPress 5.7 (lazyloading, HTTPS, updates UI, nieuwe API’s en veel meer)

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.

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.

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.

Embed blokken en Social Icons worden gebouwd als blokvariaties; ze zijn dan ook goede voorbeelden van hoe WordPress blokinformatie overeen laat komen met 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.

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).

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.

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).

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).

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).

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).

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).

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.

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.

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.

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).

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).

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

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:

• Automatisch donkere modus inschakelen wanneer de donkere achtergrond is ingeschakeld (PR #28233)
• Patreon, Telegram en TikTok iconen toegevoegd aan de Social Icons (PR #26118)
• Alle units worden ondersteund in de instellingen van Font Size (PR #26475)
• Blok transforms previews (PR #27861)
• Verbeterde blokpatroon preview in de blok-inserter (PR #27204)
• De Options modal is verbeterd en de naam veranderd in Preferences
• Veranderingen in @wordpress/data API
• Wijzigingen Inner Blocks API
• Import/Export feature verbeteringen
• Veranderingen aan de componenten en blokken van de blok-editor

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.

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)

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:

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":

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.

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 .

WordPress geeft een melding weer als HTTPS niet wordt 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:

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:

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:

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:

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

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.

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.

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.

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

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

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.

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.

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.

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?