Wat is er nieuw in WordPress 5.5? Een duik in een (fantastische) release

WordPress 5.5 is er, en er is genoeg nieuws. Hoog tijd dat we de meest opvallende veranderingen en features bespreken die zijn toegevoegd aan de WordPress core.

Het is alweer de tweede WordPress release van dit jaar en net als bij de vorige WordPress releases zijn er ook hier weer een flink aantal toevoegingen aan de blok-editor. WordPress 5.5 stelt niet teleur!

Maar uiteraard zijn ook buiten de editor tal van andere wijzigingen die een grote impact zullen hebben op de manier waarop we het CMS gebruiken.

WordPress 5.5 brengt veel wijzigingen in WordPress core, maar helaas zijn een aantal features die we hadden verwacht in 5.5 uitgesteld en verwijderd van deze versie vanwege een aantal onopgeloste problemen. Full-site bewerkingen, navigatieblok, navigatiescherm en widgetscherm zijn dus zaken die we helaas niet aan zullen treffen in WordPress 5.5.

Als je meer wil lezen over de ontwikkelingscyclus van WordPress 5.5, lees dan de onderstaande links:

• 7 juli 2020: Beta 1
• 14 juli 2020: Beta 2
• 21 juli 2020: Beta 3
• 27 juli 2020: Beta 4
• 28 juli 2020: RC 1
• 4 augustus 2020: RC 2
• 10 augustus 2020: Testronde voor de WordPress 5.5 release
• 11 augustus 2020: Releasedatum van WordPress 5.5

Dus, wat is er allemaal voor nieuws te verwachten in WordPress 5.5?

Nieuwe toevoegingen aan de blok-editor

Met de release van WordPress 5.5 zijn tien versies van de Gutenberg plugin toegevoegd aan WordPress core. Al met al is dit een groot aantal UI verbeteringen, features, verbeteringen en bugfixes. Het bewerken van artikelen zal dus weer een beetje worden verbeterd door verbeterde bruikbaarheid, functionaliteit en prestaties.

Het is bijna onmogelijk om alle veranderingen hier te noemen, dus in dit artikel vind je een zorgvuldig uitgekozen selectie van onze favoriete nieuwe functies en verbeteringen.

Voor een uitgebreidere lijst met verbeteringen en functies die met WordPress 5.5 zijn toegevoegd aan de blok-editor, kan je het beste de officiële aankondigingen bekijken van de releases van de plugin zelf: 7.5, 7.6, 7.7, 7.8, 7.9, 8.0, 8.1, 8.2, 8.3, 8.4, 8.5.

Dat gezegd hebbende, we bespreken de volgende toevoegingen aan de blok-editor die WordPress 5.5 doet:

1. Nieuw UI design
2. Blokdesigntools
3. Inline afbeeldingsbewerking
4. Blokcategorieën en nieuw blokinvoegpaneel
5. De blokdirectory en blokplugins
6. Blokpatronen

Nieuw UI design

Elke versie van de Gutenberg plugin brengt kleine en niet zo kleine verbeteringen met zich mee. Samen veranderen ze stap-voor-stap de bewerkingservaring. Veel van deze wijzigingen zijn nu samengevoegd in WordPress core. Wanneer je dus de blok-editor voor het eerst opstart in WordPress 5.5, zal de iets andere interface waarschijnlijk meteen je aandacht trekken. Dit kan je verwachten:

• Een vereenvoudigde blokbewerkingsbalk
• Sterker kleurcontrast
• Nieuwe iconen
• Blokverplaatsers
• Omringende elementen
• Previews voor verschillende apparaten
• Verbeterde drag-and-drop
• Verbeterde en uniforme blokfocusstijlen binnen de gehele gebruikersinterface
• Mogelijkheid om meerdere blokken tegelijk op te maken
• Betere prestaties

De hierboven genoemde toevoegingen komen van Gutenberg 7.7 en is maar een selectie van de vele veranderingen die de bewerkingservaring zullen verbeteren.

Een aantal overige wijzigingen:

Opties voor subscript en superscript

Je kan nu subscript en superscript tekst gebruiken vanuit de Rich Text controls (Gutenberg 8.0).

Selectie parentblok

Een gloednieuwe werkbalkknop verschijnt nu wanneer je over de linkerkant van de werkbalk zweeft. Deze nieuwe knop maakt het mogelijk om (bovenliggende) parentblokken binnen nexted contexts te selecteren (Gutenberg 8.3).

Blokdesigntools

Ook zijn er de afgelopen maanden verschillende ontwerptools aan de Gutenberg plugin toegevoegd. Deze zijn met WordPress 5.5 nu opgenomen in WordPress core.

Hoogteregeling en achtergrondverloop

Met deze set aan tools heb je meer controle over de afmetingen en achtergrondkleur voor een aantal verschillende blokken (Gutenberg 7.9).

Meer controle opvulling en linkkleuren

Ook komen er twee andere features naar WordPress core (Gutenberg 8.3), ook al hebben ze op moment van schrijven nog de experimentele status:

• Meer controle over opvulling van het Cover blok.
• Meer controle over de linkkleur voor de blokken Paragraaf, Kop, Kolommen en Media & Tekst.

Deze functies staan standaard uitgeschakeld. Als developers deze functies in willen schakelen, moeten ze dit expliciet declaren, zoals uitgelegd in het Block Editor Handbook.

Als je de opvullingscontrols voor het Cover blok ook aan jouw thema’s wil toevoegen, voeg dan eenvoudig de volgende regel toe aan het functions.php bestand van je thema:

add_theme_support( 'experimental-custom-spacing' );

Als je de linkkleurcontrols wil toevoegen aan de Paragraaf, Kop, Groep, Kolommen en Media & Tekst blokken, voeg dan de volgende regel toe aan het functions bestand van je thema:

add_theme_support( 'experimental-link-color' );

Custom units en custom line hoogte

Met deze nieuwe feature kan je px, em, rem, vw en vh height values instellen voor het Cover blok (Gutenberg 7.9). Ook % wordt ondersteund, maar is “verborgen” vanwege de onvoorspelbare weergave van procentuele hoogten.

Met de verbeterde hoogtecontrols kan je waarden met 10 verspringen door Shift ingedrukt te houden terwijl je up of down drukt.

Developers kunnen ondersteuning voor custom units toevoegen door de support flag custom-units te definiëren:

add_theme_support( 'custom-units' );

Ook kan je specifieke custom units instellen:

add_theme_support( 'custom-units', 'rem', 'em' );

Developers kunnen ook aan Koppen en Parafragen custom line heights toevoegen door de support flag custom-line-height te definiëren:

add_theme_support( 'custom-line-height' );

Inline afbeeldingsbewerking

Met Gutenberg 8.4 werd een nieuwe bewerkingsfunctie toegevoegd aan de blok-editor, waardoor gebruikers afbeeldingen rechtstreeks vanuit het afbeeldingsblok konden wijzigen.

Nu het is samengevoegd in WordPress core kan je vanaf WordPress 5.5 makkelijk afbeeldingsposities bijsnijden, draaien, roteren, zoomen en aanpassen zonder dat je de Mediabibliotheek hoeft te openen. Dit resulteert in een snellere bewerkingservaring.

Als je veel foto’s publiceert, dan zul je ongetwijfeld deze feature weten te waarderen.

Klik op de Bijsnijden knop in de afbeelding-werkbalk om toegang te krijgen tot de nieuwe bewerkingsfuncties. Als je tevreden bent met je aanpassingen, pas je de wijzigingen toe en je bent klaar.

WordPress slaat een nieuwe afbeelding op als bijlage in de Mediabibliotheek en kopieert details van de originele afbeelding ((titel, beschrijving, ondertitel, alt text, en EXIF data). Dit geeft je volledige controle over nieuwe afbeeldingsversies.

Blok categorieën en het nieuwe  blok toevoegen paneel

Het opnieuw ontworpen invoegpaneel toont blokken en patronen per categorie, wat het hele bewerkingsproces aanzienlijk verbetert en waardoor blokken en patronen makkelijker te vinden zijn (Gutenberg 8.3).

De blokdirectory en blokplugins

Door de toevoeging van de blokdirectory kan je blokken van derden rechtstreeks binnen het blokinvoegpaneel vinden, installeren en toevoegen.

Wanneer je zoekt naar een blok, en je hebt deze nog niet geïnstalleerd, dan krijg je een lijst met plugins te zien uit de pluginbibliotheek. Deze plugins worden “block plugins” genoemd en je kan ze met een simpele klik toevoegen aan je editor.

Dankzij deze nieuwe geweldige functie, kan je nu je eigen blokken bouwen en ze publiceren binnen de pluginbibliotheek, waardoor je makkelijk je creaties kan delen met de WordPress community.

Om je eigen aangepaste blokken te maken, hoef je geen PHP guru te zijn, en dat is natuurlijk goed nieuws. Het enige wat je nodig hebt is basiskennis van JavaScript.

Weet je niet zeker waar je moet beginnen met het ontwikkelen van je eigen blokken? De fantastische WordPress community helpt je goed op weg met een eenvoudige stap-voor-stap tutorial.

De eerste versie van de bloktutorial is nu beschikbaar in het officiële Block Editor Handbook om je te helpen de basisprincipes van blokontwikkeling onder de knie te krijgen. Je kan meer lezen over de blokdirectory en ontwikkeling van blokplugins op de blog van Make WordPress Plugins.

Blokpatronen

In maart 2020 introduceerden Gutenberg 7.7 en Gutenberg 7.9 blokpatronen en het blokpatroon API voor thema’s en plugins.

Blokpatronen zijn vooraf gedefinieerde bloklay-outs waarmee gebruikers snel complexe structuren van nested blokken konden toevoegen aan hun pagina’s. Hun bedoeling was om contentschrijvers en sitebeheerders te helpen het “legepaginasyndroom” te overwinnen en met gemak professionele lay-outs en geavanceerde weergaven konden bouwen.

Blokpatronen komen het best tot hun recht bij full-site bewerking.

Een duidelijke uitleg van waar blokpatronen voor bedoeld zijn, komt van Mathias Ventura, hoofdarchitect van het Gutenberg project:

Even iets tussendoor – het idee achter blokpatronen, oftewel de “block patterns” – gaat niet zozeer over de afzonderlijke template onderdelen (die structureel zinvol zijn) maar meer over algemene ontwerpelementen die bestaan uit kleine blokken. Zodra ze worden ingebracht, worden ze niet afzonderlijk opgeslagen. Dit kan bijvoorbeeld een “Cover” afbeelding zijn die een aantal blokken combineert om een specifieke look te krijgen die gebruikers anders veel tijd zou kosten. Zie het dus meer als een verzameling van ontwerpen die overal toegevoegd kan worden zonder noodzakelijkerwijs een herbruikbaar onderdeel van een thematemplate te vertegenwoordigen.

Blokpatronen zijn ontwerpelementen die verschillen van template onderdelen in dat ze sitebeheerders en contentcreators kunnen helpen het bewerkingsproces te versnellen en verbeteren.

Blokpatronen werd gelanceerd met Gutenberg 7.7 als een plugin in de zijbalk. Later, met de release van Gutenberg 8.0 stapten ze over naar de vernieuwde blokinvoerder die je nu kan aantreffen als een paneel aan de linkerkant van de editor, zoals te zien in onderstaande afbeelding:

In hun vroege stadium hebben blokpatronen een zeer beperkt aantal patronen. Desalniettemin zullen ze het bewerkingsproces enorm verbeteren, en hopelijk zullen er in de nabije toekomst meer en meer worden toegevoegd.

Net als gewone blokken zijn patronen doorzoekbaar en worden ze onderverdeeld in de volgende categorieën:

• Tekst
• Hero
• Kolommen
• Knoppen
• Galerij
• Features
• Recensies
• Ongecategoriseerd

Naast ingebouwde blokpatronen kunnen WordPress ontwikkelaars hun thema’s en plugins ook voorzien van aangepaste patronen door gebruik te maken van een geheel nieuwe API.

Je kan je custom patronen registreren met de register_block_pattern function en register_block_pattern_category voor categorieën.

register_block_pattern bevat twee argumenten:

1. De naam van het patroon.
2. De array met de properties van het patroon.

Properties omvatten het volgende:

• title
• content
• description
• categories
• keywords
• viewportWidth

register_block_pattern_category heeft ook twee argumenten:

1. De naam van de categorie van het patroon.
2. Een array van properties.

Met de API komen ook twee functions om patronen en categorieën te unregisteren: unregister_block_pattern en unregister_block_pattern_category.

De manier waarop je je eigen blokpatronen kan bouwen spreekt redelijk voor zich. Je kan bijvoorbeeld de onderstaande code kopiëren en plakken in een custom plugin of het functions bestand van een child-thema, en vervolgens de naam van het patroon naar voorkeur aanpassen.

add_action( 'init', function(){

	register_block_pattern_category( 
		'kinsta', 
		array( 'label' => __( 'Kinsta stuff', 'kinsta-pattern' ) ) );

	register_block_pattern(
	'kinsta-pattern/my-custom-pattern',
	array(
		'title'			=> __( 'Two Kinsta buttons', 'kinsta-pattern' ),
		'description'	=> _x( 'Two nice buttons.', 'Kinsta Buttons', 'kinsta-pattern' ),
		'content'		=> "<!-- wp:buttons {\"align\":\"center\"} -->\n<div class=\"wp-block-buttons aligncenter\"><!-- wp:button {\"backgroundColor\":\"very-dark-gray\",\"borderRadius\":0} -->\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link has-background has-very-dark-gray-background-color no-border-radius\">" . esc_html__( 'Button One', 'kinsta-pattern' ) . "</a></div>\n<!-- /wp:button -->\n\n<!-- wp:button {\"textColor\":\"very-dark-gray\",\"borderRadius\":0,\"className\":\"is-style-outline\"} -->\n<div class=\"wp-block-button is-style-outline\"><a class=\"wp-block-button__link has-text-color has-very-dark-gray-color no-border-radius\">" . esc_html__( 'Button Two', 'kinsta-pattern' ) . "</a></div>\n<!-- /wp:button --></div>\n<!-- /wp:buttons -->",
		'categories'	=> array( 'kinsta' ),
	)
	);
});

De bovenstaande code is een eenvoudige aanpassing van het originele fragment uit de Block API Reference. Zoals je kan zien, is er geen JavaScript vereist.

Ook kan je de pagina Block Patterns in WordPress 5.5 raadplegen.

Ingebouwde lazyloading van afbeeldingen in WordPress Core

Lazyloading is een optimalisatietechniek die het laden van niet-kritieke bronnen uitstelt. Dit betekent dat de browser wordt geïnstrueerd om alleen de zichtbare inhoud van een pagina te laden. Alles wat buiten het beeldscherm valt, inclusief afbeeldingen, wordt uitgesteld totdat ze daadwerkelijk nodig zijn.

Voordat de ingebouwde lazyload werd toegevoegd, moesten webdevelopers lazyload bewerkstelligen via JavaScript, door gebruik te maken van de IntersectionObserver API of door de scroll, resize en orientationchange event handlers te gebruiken.

Maar sinds lazyloading de standaard is geworden, hoeven we geen custom code meer te schrijven of JavaScript bibliotheken te gebruiken. Het lazyloaden van afbeeldingen kan nu worden geïmplementeerd met het nieuwe loading attribute in img en iframe tags.

Het loading attribute bepaalt of de browser een resource onmiddellijk moet laden of moet wachten tot aan bepaalde voorwaarden is voldaan. Momenteel worden de volgende waarden ondersteund:

• lazy: wacht tot aan bepaalde condities wordt voldaan
• eager: laadt de bron onmiddellijk

Op moment van schrijven wordt de ingebouwde lazyloading ondersteund door Microsoft Edge, Firefox, Google Chrome, Opera browser, Android browser en Chrome for Android.

Vóór WordPress 5.5 was lazyloading alleen mogelijk in WordPress met een optimalisatieplugin als Autoptimize, BJ Lazy Load en anderen. Gelukkig maakt het vanaf nu deel uit van WordPress core en hoeven er geen extra plugins te worden geïnstalleerd!

Ingebouwde lazyloading in WordPress

Zoals Felix Arntz meldde in een oude blogpost op Make WordPress Core blog, werd al een aantal jaren geleden een JavaScript implementatie van lazyloading voorgesteld, maar werd het nooit onderdeel van WordPress Core. De nieuwe implementatie van het lazyloaden van afbeeldingen zorgt dat mogelijke compatibiliteitsproblemen ophouden te bestaan. De nieuwe feature wordt dus nu toegevoegd aan Core met WordPress 5.5.

Volgens Felix zou deze ingebouwde lazyloading van WordPress afbeeldingen een gunstige invloed moeten hebben op de siteprestaties en gebruiksbeleving voor een groot deel van de WordPress sites die niet gebruikmaken van lazyloadingplugins:

… zonder enige technische kennis of zelfs maar een idee hebben van het concept van lazyloading. Het toevoegen van dit nieuwe loading attribute is een mooie kans voor WordPress om de weg vrij te maken naar een sneller internet.

Om het verschuiven van lay-outs te voorkomen, wordt loading="lazy" automatisch toegevoegd aan img tags met width en height attributes. Dat is alleen mogelijk als de afbeelding als bijlage beschikbaar is voor WordPress en een wp-image-$id class bevat.

Lazyloading is een onmisbare optimalisatie voor elke WordPress installatie en website met een aanzienlijk aantal afbeeldingen. Felix merkt op:

Dit bespaart een aanzienlijke hoeveelheid bandbreedte voor zowel servers als gebruikers op sites waar de afbeeldingen buiten beeld voorheen meteen werden geladen, zelfs in de gevallen waarin de gebruiker nooit naar beneden scrolde.

Het nieuwe ingebouwde lazyloading in WordPress werkt met de volgende afbeeldingen:

• Afbeeldingen in de inhoud van berichten (the_content).
• Afbeeldingen in excerpts van berichten (the_excerpt).
• Afbeeldingen in tekstwidgets (widget_text_content).
• Avatarafbeeldingen weergegeven via get_avatar ().
• Template afbeeldingen die gebruik maken van wp_get_attachment_image

Bij deze eerste implementatie ondersteunt lazyloading alleen afbeeldingen, maar dat ook iframe tags in de toekomst worden ondersteund ligt in de lijn der verwachting.

Lazyloading voor WordPress developers

Developers kunnen het standaardgedrag overschrijven met verschillende nieuwe filters. Van die filters zijn wp_lazy_loading_enabled en wp_img_tag_add_loading_attr het meest handig voor developers:

• wp_lazy_loading_enabled schakelt het loading attribute aan en uit. Deze filter kan globaar of per tag worden toegepast.
• wp_img_tag_add_loading_attr filtert de value van het loading attribute en biedt een manier om lazyloading per afbeelding te regelen.

Het volgende voorbeeld laat zien hoe je lazyloading globaal kan uitschakelen:

add_filter( 'wp_lazy_loading_enabled', '__return_false' );

We kunnen lazyloading ook uitschakelen voor een specifieke tag. In het onderstaande voorbeeld is lazyloading uitgeschakeld voor afbeeldingen in the_content context (lees meer op Make WordPress Core):

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

• $default: De boolean default value (true).
• $tag_name: De naam van de tag van de elementen waarvan je lazyloaden wil inschakelen.
• $context: Een optionele parameter die de context van de afbeelding specificeert (zie de lijst hierboven).

Merk op dat op moment van schrijven de parameter $tag_name alleen de img tag ondersteunt. Ook hier geldt dat er waarschijnlijk in toekomstige implementaties meer tags worden toegevoegd.

Als je meer controle wil over het lazyloaden van afbeeldingen in WordPress, kan je twee kiezen uit twee verschillende benaderingen, afhankelijk van de context.

Als je met content werkt (bijv the_content, the_excerpt, widget_text_content), dan kan je de filter wp_img_tag_add_loading_attr gebruiken. Het volgende voorbeeld laat zien hoe je lazyloading uitschakelt voor een specifieke afbeelding:

add_filter(
	'wp_img_tag_add_loading_attr',
	function( $value, $image, $context ){
		if ( 'the_content' === $context ){
			$image_url = wp_get_attachment_image_url( 67, 'medium' );
			if ( false !== strpos( $image, ' src="' . $image_url . '"' ) ) {
				return false;
			}
		}
		return $value;
	},
	10,
	3
);

Thema-ontwikkelaars kunnen afbeeldingen ook instellen via wp_get_attachment_image. In dit scenario kan je eenvoudig de attribute value loading van de afbeelding instellen op false:

echo wp_get_attachment_image(
	67,
	'medium',
	false,
	array( 'loading' => false ),
);

Als je het lazyloaden van afbeeldingen wil proberen vóór de definitieve release van WordPress 5.5, dan kan je de officiële Lazy Loading Feature Plugin installeren of de coursecode op Github eens bekijken.

Native lazy-loading images is coming to #WordPress 5.5, for faster sites and less waste of network resources! And it's accompanied by further image improvements which reduce those annoying layout shifts that make you accidentally click on the wrong things. https://t.co/e7g2s9uSPk

— Felix Arntz (@felixarntz) July 14, 2020

Meer informatie over het lazyloaden van afbeeldingen in WordPress 5.5 vind je op de Make WordPress Core blog.

Automatische updates voor plugins en thema’s

Een van de grootste zorgen van site-eigenaren is en blijft toch wel sitebeveiliging. Het up-to-date houden van software is een algemene aanbeveling die elke site-eigenaar wel zou moeten opvolgen.

Automatische updates van WordPress zijn als functie beschikbaar sinds WordPress 3.7. Het probleem hierbij was dat veel site-eigenaren, vóór WordPress 5.5 althans, geen gebruik maakten van deze automatische updates voor plugins en thema’s. Merk hierbij op dat deze optie voor onderhoud aan de WP core en beveiligingsreleases wél standaard was ingeschakeld.

De reden hiervoor was dat deze functie basiskennis van WordPress development vereist. Ontwikkelaars konden hun updatevoorkeuren verfijnen door een of meerdere constants te definiëren in wp-config.php of door een filter te gebruiken in een plugin.

Met WordPress 5.5 kunnen sitebeheerders het automatisch updaten van plugin en thema’s met een enkele klik in- en uitschakelen vanuit hun WordPress dashboard.

Je kan automatische updates van plugins in- en uitschakelen door op de link te klikken in de kolom Automatische updates die nu beschikbaar is op de Plugins pagina.

Als je automatische updates wil inschakelen voor je thema, ga je naar Weergave > Thema’s. Vervolgens plaats je je cursor op het thema en klik je op Themadetails. Klik vervolgens op de link Automatische updates inschakelen en klaar is Kees.

De nieuwe gebruikersinterface voor automatische updates voor plugins en thema’s valt samen met een aantal nieuwe functions en hooks die developers kunnen gebruiken om het proces van auto-updates te customizen.

Auto-update functions en filters voor developers van plugins en thema’s

Met een nieuwe functie en een aantal filters kunnen WordPress ontwikkelaars veel aspecten van automatische updates voor plugins en thema’s aanpassen.

De automatische updates check UI

De nieuwe wp_is_auto_update_enabled_for_type() WordPress function controleert of de auto-update UI is ingeschakeld voor een bepaald type. De nieuwe function houdt een enkel argument ($type) dat het type update bepaalt die gecontroleerd moet worden ('theme' of 'plugin') en retourneert vervolgens dienovereenkomstig true of false.

De nieuwe auto-update UI kan uitgeschakeld worden voor plugins en thema’s dankzij twee nieuwe filters: plugins_auto_update_enabled en themes_auto_update_enabled. Zie het voorbeeld hieronder:

// Disable plugins auto-update UI elements.
add_filter( 'plugins_auto_update_enabled', '__return_false' );

// Disable themes auto-update UI elements.
add_filter( 'themes_auto_update_enabled', '__return_false' );

De bovenstaande filters zijn gedocumenteerd in wp-admin/includes/update.php.

Auto-update links customizen

Plugin- en themaontwikkelaars kunnen de HTML output van auto-update links aanpassen.

De plugin_auto_update_setting_html filter maakt het mogelijk om toggle links en time lapses tussen twee updatepogingen aan te passen.

De callback function houdt drie arguments:

• $html: De HTML van de inhoud van de auto-update kolom, inclusief de toggle auto-update actionlinks en tijd tot de volgende update.
• $plugin_file: Pad naar het pluginbestand relatief aan de plugindirectory.
• $plugin_data: Een array van plugindata.

Als je nu het label van de linktekst van de auto-update wil customizen, kan je een filter gebruiken zoals weergegeven in het volgende fragment.

add_filter( 'plugin_auto_update_setting_html', function( $html, $plugin_file, $plugin_data ){
	if ( 'kinsta-plugin/kinsta-plugin.php' === $plugin_file ) {
		$html = __( 'Custom HTML', 'kinsta-plugin' );
	}
	return $html;	
	}, 
	10, 
	3 
);

De onderstaande afbeelding laat het resultaat van de pagina zien.

Deze filter is gedocumenteerd in wp-admin/includes/class-wp-plugins-list-table.php.

Op single sites kan je het JS template van de auto-update link aanpassen via dit filter theme_auto_update_setting_template. De blogpost waarin de auto-updatefunctie voor plugins en thema’s werd aangekondigd geeft het volgende voorbeeld van dit filter:

function myplugin_auto_update_setting_template( $template ) {
    $text = __( 'Auto-updates are not available for this theme.', 'my-plugin' );
 
    return "<# if ( [ 'my-theme', 'twentytwenty' ].includes( data.id ) ) { #>
        <p>$text</p>
        <# } else { #>
        $template
        <# } #>";
}
add_filter( 'theme_auto_update_setting_template', 'myplugin_auto_update_setting_template' );

Het wordt aanbevolen om het doelthema te checken met de parameter data.id.

Als je werkt op een WordPress Multisite installatie, moet je het theme_auto_update_setting_html filter gebruiken, waarmee je de auto-update links van de Thema’s pagina kan customizen (op dezelfde manier als de Plugins pagina).

De volgende twee extra filters controleren de auto-updates voor elk thema en elke plugin, inclusief thema’s en plugins die in de toekomst zouden moeten worden geïnstalleerd.

Deze filters, beschikbaar sinds WordPress 3.7, overschrijven alle auto-update instellingen binnen je WordPress dashboard. Je kan meer leren in onze uitgebreide handleiding over automatische updates binnen WordPress. Voor meer informatie over auto-updates voor plugins en thema’s, lees je deze blogpost.

E-mailnotificaties voor auto-updates en sitediagnose

Vanaf WordPress 5.5 wordt er een e-mailnotificatie verzonden na elke auto-update poging.

De filterhook auto_plugin_theme_update_email filtert de e-mails die worden verzonden na een automatische update op de achtergrond. Bekijk de dev-notes blogpost voor een gebruiksvoorbeeld.

Met twee nieuwe filters kunnen deze auto-update e-mailnotificaties worden uitgeschakeld:

// Disable auto-update email notifications for plugins.
add_filter( 'auto_plugin_update_send_email', '__return_false' );

// Disable auto-update email notifications for themes.
add_filter( 'auto_theme_update_send_email', '__return_false' );

Informatie over auto-updates van plugins en thema’s wordt ook weergegeven in het tabblad Sitediagnose.

Developers kunnen de tekst die binnen deze pagina verschijnt, wijzigen met de filters plugin_auto_update_debug_string en theme_auto_update_debug_string. Meer informatie en voorbeelden zijn hier te vinden.

Uitbreidbare Core sitemaps

Een sitemap is eigenlijk niets meer dan een lijst met URL’s waarmee zoekmachines je site sneller kunnen crawlen.

Sitemaps lijken veel op robots.txt, met het verschil dat een robots.txt bestand content uitsluit van indexering, terwijl een sitemap een lijst levert met URL’s die kunnen worden geïndexeerd door zoekmachines.

Vóór WordPress konden sitemaps alleen aan WordPress sites worden toegevoegd met behulp van een plugin of andere tools.

Met WordPress 5.5 brengt het platform een gloednieuwe XML sitemapfunctie naar de WordPress Core.

Deze nieuwe feature voegt basisfunctionaliteit toe, maar wordt ook geleverd met een groot aantal hooks en filters waarmee ontwikkelaars van plugins de ingebouwde functionaliteiten verder kunnen uitbreiden.

XML sitemaps zijn standaard ingeschakeld (tenzij je zoekmachines wil ontmoedigen om je site te indexeren) en bieden de volgende object types:

• Homepage
• Posts page
• Core post types (pagina’s en berichten)
• Custom post types
• Core taxonomies (tags en categorieën)
• Custom taxonomies
• Author archives

De sitemapindex is bereikbaar op /wp-sitemap.xml en bevat maximaal 2.000 URL’s. Wanneer de maximale limiet is bereikt, wordt een nieuw sitemapbestand toegevoegd.

Zoals eerder vermeld, kunnen plugindevelopers hun sitemaps aanpassen met de vele beschikbare actions en filters. Voor een uitgebreide lijst van sitemap-gerelateerde hooks, kan je de feature plugin documentatie en de inleidende blogpost bekijken.

Je kan bijvoorbeeld de core sitemaps programmatisch uitschakelen door het filter wp_sitemaps_enabled te gebruiken, dat filtert of de XML sitemaps zijn ingeschakeld of niet, of voorkomt dat de function wp_sitemaps_get_server wordt uitgevoerd:

add_filter( 'wp_sitemaps_enabled', '__return_false' );

Core sitemaps mogen niet in strijd zijn met eventuele sitemapplugins die je op je website hebt geïnstalleerd. Volgens Pascal Birchler op Make WordPress Core:

De core sitemapsfeature is op een robuuste en gemakkelijk uitbreidbare manier opgebouwd. Als om de een of andere reden twee sitemaps op een website worden weergegeven (een via de core, een andere via een plugin), heeft dit geen negatief effect op de vindbaarheid van een site.

Als onderdeel van de XML Sitemaps feature, escapet een nieuwe esc_xml() function strings voor XML blokken. De function en het bijbehorende filter zijn gedocumenteerd in wp-includes/formatting.php.

Op moment van schrijven, ondersteunt deze nieuwe sitemapfeature geen sitemaps voor afbeeldingen, video’s en nieuws. Het lijkt er niet op dat dit in de toekomst anders zal zijn. Hoe dan ook, nieuwe filters en hooks waarmee ontwikkelaars deze feature kunnen toevoegen, kunnen mogelijk in toekomst worden toegevoegd.

Voor meer informatie over deze uitbreidbare sitemaps kan je het best de introductie van sitemaps voor ontwikkelaars lezen, waarin je alles kan vinden over nieuwe classes, functions, hooks en filters.

Doorgeven van arguments aan templatebestanden

Vóór WordPress 5.5 was het doorgeven van data aan templatebestanden alleen mogelijk via global variables, query vars en een aantal andere niet-optimale opties. Nu, beginnend met WordPress 5.5 is een $args parameter toegevoegd aan de loading functions van het template (de bijbehorende hooks zijn dienovereenkomstig bijgewerkt):

• get_header()
• get_footer()
• get_sidebar()
• get_template_part()
• locate_template()
• load_template()

Thema-ontwikkelaars kunnen nu een variable instellen in een templatebestand en deze toegankelijk maken in elk opgenomen template-onderdeel door simpelweg een array van arguments te passen.

Hoewel deze functie nieuwe mogelijkheden biedt voor thema-ontwikkelaars, plaatst Justin Tadlock van WP Tavern een aantal vraagtekens:

De vraag blijft: is de komst van deze functie niet te laat? WordPress is hard bezig om het hele themasysteem op de schop te doen en deze te integreren met de aanstaande full-site bewerkingsfeature. Is deze feature daarom niet alleen de komende maanden handig?

John Blackbourne maakt een goed punt:

Zelfs in het toekomstige full-site bewerken, is er nog steeds voldoende behoefte aan template-onderdelen. Dynamisch gerenderde bloktypes kunnen bijvoorbeeld gebruik maken van gestructureerde template-onderdelen. Ze sluiten elkaar niet uit, en er zullen altijd wel thema’s zijn die niet gebruikmaken van blokken voor hun lay-out.

We sluiten af met Enrico Sorcinelli, WP Core Contributor, die ook zijn gedachten met ons deelde:

Als je me vraagt of we hier niet te laat mee zijn, naar mijn mening is het nooit te laat!
 Ik geloof dat thema-ontwikkelaars ook in de toekomst blijven profiteren van deze mogelijkheid, wat niet uitsluit dat het kan worden gebruikt sámen met de opkomende full-site bewerkingservaring (bijv. blokken voor dynamisch rederen).

Misschien is het simpelweg te vroeg om te zeggen hoe deze functie precies past bij full-site bewerking, maar een ding is zeker: toekomstige ontwikkelingen zullen geweldige mogelijkheden bieden om betere sites te bouwen – voor zowel gebruikers als developers.

Plugins en thema’s bijwerken vanuit een .zip bestand

Ik weet wat je nu denkt: het is wellicht wat “onverwacht” om deze functie samen met de auto-updates te zien verschijnen. Toch is het vrij logisch.

Vóór WordPress 5.5 konden sitebeheerders – bij het ontbreken van een one-click updatefunctie – alleen plugins/thema-updates uploaden via FTP/SFTP of de file manager (leer het verschil tussen FTP en SFTP). Dit gebeurde voornamelijk bij aangepaste plugins/thema’s of met extensies die werden gehost op externe marktplaatsen.

Vanaf WordPress 5.5 kan je binnen je WordPress dashboard plugins en thema’s bijwerken door een .zip bestand te openen vanaf je computer.

Om een plugin te updaten, ga je naar Plugins > Nieuwe toevoegen en klik je op de Plugin uploaden knop. Als je vervolgens de plugin op je website hebt geïnstalleerd, laat een nieuw scherm je weten dat deze plugin al geïnstalleerd is, samen met de gegevens van de huidige én de geüploade versie.

Het proces is vergelijkbaar met het updaten van thema’s.

Ga naar Weergave > Thema’s en klik op Nieuwe toevoegen en dan op Thema uploaden. Als je al een thema hebt geïnstalleerd op je WordPress website, laat een nieuw scherm je weten dat dit thema al is geïnstalleerd en worden de details van de huidige en geüploade versie weergegeven.

Overige verbeteringen voor ontwikkelaars in WordPress 5.5

Naast wat we tot nu toe hebben behandeld, verdienen ook een aantal andere toevoegingen de aandacht van de gemiddelde developer.

Nieuwe wp_get_environment_type() function

De nieuwe wp_get_environment_type() function stelt je in staat om het huidige omgevingstype van een website te detecteren, waardoor ontwikkelaars plugins en themafuncties kunnen aanpassen aan de huidige omgeving.

Standaard retourneert wp_get_environment_type() production. Andere ondersteunde values zijn development en staging. Uiteraard is het developers toegestaan om hun eigen aanvullende omgevingstypen te definiëren.

Er zijn drie beschikbare methoden om een website omgevingstype op te stellen. Op prioriteit gerangschikt, kan je het volgende gebruiken:

• WP_ENVIRONMENT_TYPE PHP omgevingsvariable.
• WP_ENVIRONMENT_TYPE constant.
• wp_get_environment_type filter.

Ter illustratie, als je je omgeving wil instellen op staging, kan je als volgt de WP_ENVIRONMENT_TYPE constant definiëren in je wp-config.php bestand:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

Als het omgevingstype staging is, dan zegt WP_DEBUG deze automatisch op true, zelfs als je deze niet expliciet hebt gedefinieerd.

Wijzigingen aan de REST API in WordPress 5.5

WordPress 5.5 brengt ook veel veranderingen aan de REST API. We zien een aantal nieuwe endpoints, nieuwe parameters en wijzigingen aan JSON schema, nieuwe functions en verdere verbeteringen.

Hier is een korte lijst met nieuwe endpoints:

Block types

Met dit nieuwe endpoint kan je alle geregistreerde bloktypes opvragen:

• GET /wp/v2/block-types retourneert alle geregistreerde bloktypes.
• GET /wp/v2/block-types/core retourneert alle blokken binnen de  core namespace.
• GET /wp/v2/block-types/core/quote retourneert de core quote blokdefinitie.

Plugins

Met dit nieuwe endpoint kan je plugins beheren:

• GET /wp/v2/plugins retourneert een lijst met alle geïnstalleerde plugins.
• GET /wp/v2/plugins/plugin-name/plugin-name retourneert informatie over de gespecificeerde plugin.
• POST /wp/v2/plugins { slug: "plugin-name" } installeert de gespecificeerde plugin vanuit de pluginbibliotheek
• PUT /wp/v2/plugins/plugin-name/plugin-name { status: "active" } activeert de gespecificeerde plugin
• DELETE /wp/v2/plugins/plugin-name/plugin-name verwijdert een inactieve plugin.

Block directory

Met dit nieuwe endpoint kan je de blokdirectory doorzoeken:

• GET /wp/v2/block-directory/search?term=block-name zoekt in de blokdirectory naar block-name

Bewerken afbeeldingen

In combinatie met de nieuwe inline functie voor het bewerken van afbeeldingen, kan je met dit endpoint afbeeldingsbijlagen bewerken in de mediabibliotheek:

POST /wp/v2/media/5/edit bewerkt de afbeelding met ID 5

Bekijk de WordPress Core dev-notes voor meer informatie over alle wijzigingen aan de REST API die je kan verwachten met WordPress 5.5.

Samenvatting

We zijn erg enthousiast over al deze nieuwe functies en verbeteringen die allemaal verpakt zitten in deze WordPress 5.5 release.

Het laat zien dat er achter de schermen hard wordt gewerkt. We waarderen dan ook alle inspanningen en toewijding van iedereen die een bijdrage levert aan de WordPress Core.

Als je geen genoeg kan krijgen van deze wijzigingen en echt álles wil weten over de nieuwe update, dan kan je hier wat extra verbeteringen vinden die met WordPress 5.5 worden geleverd:

• 65 nieuwe iconen toegevoegd aan het Dashicons icoonlettertype in WordPress Core
• Verbeteringen toegankelijkheid van links in widgets
• Nieuwe CSS stijlen voor uitgeschakelde knoppen
• Opcode cache invalidation
• Betere controle over redirect_guess_404_permalink()
• PHP gerelateerde verbeteringen
• Veranderingen aan de codebase
• Veranderingen aan de custom logo functions en filter
• Updates aan de Block API
• Headingsfilters voor archiefpagina
• Iconen toegevoegd aan Twenty Twenty
• En nog veel meer

Zorg dat je deelneemt aan onze gratis webinar, volledig gewijd aan WordPress 5.5!

Nu is het jouw beurt. Wat zijn de features en verbeteringen waar jij het meest naar uitkijkt voor WordPress 5.5? En welke features wil jij het liefste zien in WordPress 5.6? Laat het ons weten in de reacties hieronder!