WordPress 7.1 komt op 19 augustus uit en belooft een mooie update te worden voor developers, professionals, bureaus en bloggers in het hele ecosysteem.
Deze tweede grote release van het jaar brengt een breed scala aan updates mee die vrijwel elk aspect van het CMS raken. Van alle nieuwe features zijn we het meest enthousiast over Client-Side Media Processing. Niet zo gek: bij Kinsta zijn we gek op webprestaties en sitesnelheid, en deze nieuwe media-architectuur is een flinke stap vooruit. Het levert merkbaar efficiënter servergebruik en snellere laadtijden van pagina’s op.
Naast de omgang met media brengt WordPress 7.1 ook flinke verbeteringen voor team-samenwerking, waaronder nieuwe features voor Notes, en diverse verbeteringen in de beheerdersinterface, zoals een permanente adminbalk en de nieuwe Identity pagina in de Site Editor. De release bevat nieuwe en verbeterde blokken, uitgebreide ontwerptools en een breed scala aan updates voor developers.
Benieuwd wat er nog meer komt? Laten we dieper ingaan op WordPress 7.1.
Mediaverwerking aan de clientzijde
Tot en met WordPress 7.0 gebeurde het genereren van afbeeldingsafmetingen en thumbnails voor de frontend, het converteren van bestandsindelingen en het verwerken van afbeeldingsrotatie allemaal server-side via PHP.
WordPress 7.1 introduceert een nieuwe architectuur voor mediaverwerking: het aanpassen van afbeeldingsafmetingen, het converteren van bestandsindelingen, EXIF-rotatie en het genereren van thumbnails gebeurt nu aan de clientzijde, direct in de browser van de gebruiker.
Deze verandering zou de prestaties van je site flink moeten verbeteren en het verbruik van serverresources moeten verminderen.
Laten we eens kijken wat er verandert in de afbeeldingsverwerking:
1. Wat is mediaverwerking aan de clientzijde?
Waar afbeeldingen voorheen op de server werden verwerkt door PHP met de GD- of Imagick-bibliotheken, vinden het genereren van afbeeldingen in verschillende afmetingen, conversie van bestandsindelingen en EXIF-rotatie nu rechtstreeks plaats in de browser van de gebruiker, mits de browser de DIP-header (Document-Isolation-Policy) ondersteunt om toegang te geven tot SharedArrayBuffer.
Omdat de verwerking in de browser plaatsvindt, ontvangt WordPress niet langer één afbeelding, maar alle resulterende afbeeldingsbestanden uit de verwerkingspipeline. Dat heeft twee belangrijke gevolgen: een lager CPU- en RAM-gebruik op de server, en meer HTTP-verzoeken om de afzonderlijke thumbnails te uploaden.
Op het moment van schrijven ondersteunen alleen Chrome 137+ en Microsoft Edge 137+ (desktop) de Document-Isolation-Policy volledig. Safari en Firefox ondersteunen de WASM-pipeline niet, al ondersteunt Safari wel native decodering van HEIC/HEIF-indelingen naar JPG.
2. Wat zijn de technische kenmerken van Client-Side Media Processing?
Architectonisch gezien wordt mediaverwerking aan de clientzijde geregeld via 3 kernpakketten:
- Het nieuwe
@wordpress/vipspakket regelt de verwerking aan de clientzijde met delibvipsbibliotheek, gecompileerd naar WebAssembly (wasm-vips). Deze bibliotheek geldt algemeen als een van de snelste en efficiëntste bibliotheken voor afbeeldingsverwerking die er zijn. Hij draait parallel binnen een Web Worker, waardoor de interface niet vastloopt en de prestaties flink beter zijn dan bij puur JavaScript. - Het
@wordpress/upload-mediapakket regelt de uploadpipeline, inclusief het beheer van uploadwachtrijen, gelijktijdige uploads (maximaal 5 gelijktijdige uploads en 2 bewerkingen voor afbeeldingsverwerking), automatische nieuwe pogingen, het hervatten van onderbroken uploads en offline ondersteuning. - Het
@wordpress/media-utilspakket regelt het HTTP-verkeer en de REST API-verzoeken.
Naast afbeeldingsverwerking introduceert deze nieuwe feature ook automatische conversie van geanimeerde GIF’s naar MP4/WebM-video’s. De conversie wordt afgehandeld door het nieuwe @wordpress/video-conversion pakket, dat de mediabunny bibliotheek in een Web Worker verpakt om ondoorzichtige GIF’s (zonder transparante achtergrond) om te zetten in lichte videobestanden.
Client-Side Media Processing introduceert ook nieuwe REST API-endpoints (sideload, finalize en replace_file), samen met 2 nieuwe parameters: generate_sub_sizes en convert_format.
3. Wat zijn de voordelen voor WordPress gebruikers?
Client-Side Media Processing verplaatst de afbeeldingsverwerking van de server naar de client. De server hoeft niet langer het zware werk te doen: thumbnails in verschillende afmetingen genereren, afbeeldingen draaien en bestandsindelingen converteren gebeurt nu rechtstreeks in de browser van de gebruiker.
Een paar voordelen voor gebruikers nu de mediaverwerking naar de client verhuist:
- Minder PHP-fouten door onvoldoende geheugen: Client-Side Media Processing voorkomt geheugenfouten (
PHP memory limit exceeded) die voorheen optraden bij het verwerken van grote afbeeldingsbestanden. - Minder CPU- en RAM-gebruik: Een ander groot voordeel voor de server is een flinke afname van het CPU- en RAM-gebruik van de host, waardoor er resources vrijkomen voor andere taken.
- Betere prestaties van de site: De
libvipsbibliotheek gebruikt geavanceerde compressiealgoritmen die afbeeldingen opleveren die gemiddeld zo’n 15% kleiner zijn dan die van GD of Imagick. Dat zorgt voor lichtere afbeeldingen en snellere laadtijden van pagina’s. - Betrouwbaarder uploaden: Elke afbeelding die je uploadt, vereist een apart HTTP-verzoek. Dat leidt weliswaar tot meer HTTP-verzoeken, maar zorgt er ook voor dat elke afbeelding afzonderlijk wordt verwerkt. Mislukte verzoeken worden automatisch gepauzeerd en opnieuw geprobeerd.
Bovendien kunnen geanimeerde GIF’s automatisch worden omgezet in efficiëntere video’s die automatisch afspelen, kan de browser HEIC-foto’s van iPhones vóór het uploaden omzetten naar JPG (waarmee je mogelijke compatibiliteitsproblemen met de server omzeilt), en werkt AVIF-ondersteuning nu zelfs zonder AVIF-mogelijkheden aan de serverkant (de MIME-typecontrole wordt overgeslagen voor uploads die door de client zijn gedecodeerd).
4. Wat verandert er voor developers?
Developers kunnen de mediaverwerking aan de clientzijde uitschakelen met het nieuwe filter wp_client_side_media_processing_enabled. Een voorbeeld:
add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );Verder zijn er geen grote veranderingen voor pluginontwikkelaars. Hooks die met mediaverwerking te maken hebben, worden nog steeds geactiveerd, net alsof de afbeeldingen op de server worden verwerkt.
Bestaande filters lezen instellingen van de server en blijven werken zoals verwacht. Het filter wp_generate_attachment_metadata wordt bijvoorbeeld twee keer uitgevoerd: eerst tijdens de eerste upload (create) en een tweede keer nadat het finalize-endpoint is aangeroepen (update). Plugins die dit filter gebruiken, blijven werken zoals verwacht.
Voor themaontwikkelaars worden afbeeldingsformaten die via add_image_size() zijn geregistreerd, nu aan de clientzijde gegenereerd. Definieert een thema een afbeeldingsformaat met afmetingen die identiek zijn aan een standaard WordPress formaat, dan worden de afbeeldingen gededupliceerd tot één afbeeldingsbestand dat onder beide formaatnamen wordt geregistreerd.
5. Wat zijn de voordelen voor de beveiliging?
Hoewel mediaverwerking aan de clientzijde in de eerste plaats is ontworpen voor prestaties en efficiëntie, biedt het verschillende voordelen die de beveiliging van WordPress sites verbeteren.
Ten eerste verkleint het het aanvalsoppervlak. Zoals eerder genoemd was de afbeeldingsverwerking vóór WordPress 7.1 afhankelijk van server-side bibliotheken zoals GD en Imagick. In de loop der jaren zijn deze bibliotheken getroffen door verschillende beveiligingskwetsbaarheden rond het decoderen van afbeeldingen.
Met afbeeldingsverwerking aan de clientzijde heeft de server GD of Imagick niet meer nodig, omdat hij voorverwerkte afbeeldingen ontvangt. Dat vermindert de hoeveelheid gevoelige code die op de server draait aanzienlijk.
Een ander beveiligingsvoordeel is dat de afbeeldingsverwerking plaatsvindt binnen een geïsoleerde browseromgeving, via WebAssembly in een Web Worker.
Verwerking aan de clientzijde verkleint ook het risico op Denial-of-Service-aanvallen (DoS), omdat de rekenbelasting bij de client ligt.
Om afbeeldingen aan de clientzijde te verwerken, gebruikt WordPress SharedArrayBuffer, een JavaScript-object waarmee de hoofdthread en Web Workers dezelfde geheugenruimte kunnen delen.
Om toegang te geven tot SharedArrayBuffer, schakelt WordPress de Document-Isolation-Policy: isolate-and-credentialless header in. Dat zorgt voor een geïsoleerde uitvoeringscontext voor de blok-editor in Chromium 137+ -browsers (Chrome 137+ en Edge 137+).
Kortom: hoewel Client-Side Media Processing vooral is bedoeld om de prestaties en efficiëntie bij het verwerken van media te verbeteren, levert deze nieuwe feature ook duidelijke winst op voor de beveiliging.
6. Officiële bronnen
Client-Side Media Processing is uitgebreid gedocumenteerd voor zowel gebruikers als developers. Bekijk de volgende bronnen voor meer informatie:
- Client-Side Media Processing in WordPress 7.1 (dev note)
- Architectuur van Client-Side Media Processing (handboek voor de blok-editor)
- Client-Side Media Processing (handleidingen)
- Filters en parameters voor Client-Side Media Processing (hooks-referentie)
Verbeteringen voor Notes
Notes, voor het eerst geïntroduceerd in WordPress 6.9, kreeg talloze toevoegingen en verbeteringen, waardoor het een completere tool voor samenwerking is geworden.
Om te beginnen voegt WordPress 7.1 ondersteuning voor rich text in Notes toe, waardoor notities “expressiever, prettiger leesbaar en beter afgestemd zijn op wat gebruikers gewend zijn van tools als Google Docs, Figma, GitHub en andere samenwerkingseditors”.
Denk hierbij aan basisopmaak in de tekst, zoals vet (Ctrl/⌘ B), cursief (Ctrl/⌘ I), links (Ctrl/⌘ K) en emoji’s.
Je kunt nu inline notities toevoegen door tekstfragmenten te selecteren in plaats van alleen een heel blok (inline blokcommentaar). Het is ook mogelijk om meerdere notities aan hetzelfde blok of dezelfde tekstselectie toe te voegen.
WordPress 7.1 introduceert ook @mentions om je medewerkers in notities te taggen, waardoor Notes meer gaat lijken op populaire samenwerkingstools. Typ je het @-teken, dan verschijnt er een paneel met de gebruikers van je site, zodat je makkelijk iemand kunt kiezen. De persoon die je vermeldt, krijgt een e-mailmelding met een link naar het artikel.
Een andere toevoeging betreft het zichtbare gedeelte van de notities. Lange notities worden nu standaard ingeklapt, zodat ze niet te veel schermruimte innemen. Met de schakelaar Show more/Show less toon of verberg je de volledige tekst.
De volledige lijst met nieuwe features voor Notes in WordPress 7.1 vind je in de Notes-update voor WordPress 7.1.
Verbeteringen aan de beheerdersinterface
De beheerdersinterface krijgt verschillende updates die de consistentie verbeteren en de navigatie tussen pagina’s vereenvoudigen.
Permanente adminbalk in de bericht-editor en Site Editor
Vóór WordPress 7.1 werd de adminbalk niet weergegeven in de bericht-editor en de Site Editor. Dat was niet logisch: de adminbalk is het meest gebruikte onderdeel van de beheerdersinterface, en het ontbreken ervan in de editors was verre van optimaal. Vanaf WordPress 7.1 is dat veranderd en is de adminbalk wel zichtbaar in de bericht-editor en de Site Editor.
Het kleurenschema van de gebruiker geldt nu ook voor de Site Editor
Een andere verbetering die alle beheerdersgedeelten consistent maakt: hetzelfde kleurenschema dat je op je instellingenpagina hebt gekozen, wordt nu ook in de Site Editor gebruikt. Vóór versie 7.1 was de zijbalk van de Site Editor altijd zwart.
De zijbalk van de editor krijgt met WordPress 7.1 ook een update. Het site-icoontje is verwijderd uit de werkbalk van de editor en staat nu in de WordPress werkbalk.
In eerdere versies moest je op het site-icoontje klikken om terug te gaan naar het WordPress beheerdersgedeelte, wat technisch gezien geen terugknop was.
Daardoor staat het site-icoontje nu alleen nog in de adminbalk, terwijl de werkbalk van de editor een duidelijkere terugknop heeft gekregen.
Command categories en verbeterde interface van de command palette
De command palette kreeg verschillende toevoegingen en aanpassingen om de bruikbaarheid te verbeteren. Allereerst zijn de beschikbare commands onderverdeeld in secties (recent, suggestions en results), zodat je ze makkelijker vindt.
Het venster is aangepast (512px) en de commands zijn nu makkelijker te lezen.
Identity pagina in de Site Editor
Onder het menu Design in de Site Editor staat nu een nieuw item Identity. Op die pagina stel je de titel en slogan en het logo en het pictogram van je site in. Zo pas je de identiteitsinstellingen van je site aan zonder de Site Editor te verlaten.
Oneindig scrollen in de rasterweergave van de Media Library
Tot en met WordPress 7.0 kon je oneindig scrollen voor de rasterweergave van de Media Library inschakelen via het filter media_library_infinite_scrolling, dat standaard op false stond. Developers konden de standaardinstelling aanpassen door de volgende regel aan hun plugins toe te voegen:
add_filter( 'media_library_infinite_scrolling', '__return_true' );Vanaf WordPress 7.1 staat het filter media_library_infinite_scrolling op true, wat betekent dat oneindig scrollen in de rasterweergave van de Media Library standaard voor alle gebruikers is ingeschakeld.
Daarnaast stel je via een nieuwe instelling op de gebruikersprofielpagina in het WordPress beheerdersgedeelte je eigen voorkeur voor oneindig scrollen in.
WordPress slaat de keuze van de gebruiker op in de gebruikersopties met de metasleutel infinite_scrolling. Je haalt de gebruikersvoorkeur zo op:
$infinite_scrolling = get_user_option( 'infinite_scrolling', $user_id );Kernblokken en verbeteringen aan blokken
WordPress 7.1 introduceert twee nieuwe blokken en diverse verbeteringen aan bestaande blokken.
Nieuwe blokken Playlist en Tabs
Met het nieuwe Playlist-blok sluit je een eenvoudige afspeellijst in je content in.
Je past verschillende aspecten van het uiterlijk van het blok aan, zoals de typografie, achtergrond, afmetingen, rand en elementen. Specifieke stijlinstellingen voor dit blok zijn onder andere Waveform & Play button en Waveform background. Met de instelling Shape wijzig je de audiovisualisatie van de waveform.
Het Playlist-blok ondersteunt alle audiobestanden die compatibel zijn met je WordPress installatie. Voeg je ondersteuning voor een nieuw MIME-type toe, dan neemt het blok dat automatisch over.
Het nieuwe standaard Tabs-blok is ontworpen om content in tabbladen te ordenen. Elk tabblad kan elk willekeurig blok bevatten, wat het vooral handig maakt voor content per onderwerp, veelgestelde vragen of vergelijkingen van producten en diensten.
Bewerkbare blokken binnen het Custom HTML-blok
Het Custom HTML-blok kreeg een nieuwe verbetering. Je voegt nu bewerkbare blokken rechtstreeks in de HTML-code toe. Zo combineer je statische HTML en bewerkbare blokken in hetzelfde fragment.
Hoewel ze bewerkbaar zijn, kun je bewerkbare blokken niet verplaatsen of verwijderen, en kun je via de visuele editor ook geen extra blokken toevoegen. De onderliggende code blijft wel volledig bewerkbaar in de code-editor.
Vóór WordPress 7.1 moest content ofwel volledig uit statische HTML bestaan, ofwel volledig uit blokken. Nu combineer je HTML en blokken vrij, wat vooral handig is bij het genereren van content met AI-modellen.
Deze wijziging gaat samen met de mogelijkheid om statische HTML-code toe te voegen aan blokvarianten. Dankzij de nieuwe ondersteuning voor innerContent registreer je een variant van het HTML-blok, zoals in het onderstaande voorbeeld:
wp.blocks.registerBlockVariation( 'core/html', {
name: 'custom-image-card',
title: 'Custom image card',
description: 'A custom HTML block with static header/footer and an editable image.',
innerContent: [
'<h2>Static heading</h2>\n',
null,
'\n<footer>Static footer</footer>'
],
innerBlocks: [
[
'core/image',
{
id: 419,
sizeSlug: 'medium',
linkDestination: 'none',
url: 'https://example.com/wp-content/uploads/...',
alt: ''
}
]
],
} );De waarde null in innerContent fungeert als placeholder voor het Image-blok.
Let op: innerContent is alleen beschikbaar voor het Custom HTML-blok. Pas je dit toe op varianten van andere blokken, dan heeft dat geen effect.
Verbeteringen aan het SVG-pictogramsysteem
WordPress 7.0 introduceerde een nieuw Icon-blok en een Icon library. Met WordPress 7.1 krijgt het pictogramsysteem een openbare API, waarmee je pictogrammen programmatisch registreert, weergeeft en verwijdert, en ook via de REST API ophaalt.
Pictogrammen registreren en deregistreren
Om een pictogram of een pictogrammenset te registreren, registreer je eerst een pictogramverzameling door de nieuwe functie wp_register_icon_collection() aan de init-actie te koppelen:
function custom_icons_register_icon_collection() {
wp_register_icon_collection(
'my-icon-set',
array(
'label' => __( 'My awesome icons', 'my-plugin' ),
'description' => __( 'My personal set of icons.', 'my-plugin' ),
)
);
}
add_action( 'init', 'custom_icons_register_icon_collection' );Een verzameling heeft een unieke naam, waardoor die te onderscheiden is van de standaardpictogrammen en andere pictogrammensets die door plugins van derden zijn geregistreerd. De naam van de verzameling moet beginnen en eindigen met een kleine letter en mag kleine letters, cijfers, koppeltekens en underscores bevatten.
Het tweede argument van de functie is een array met het label van de verzameling zoals dat in de Icon library verschijnt, en een optionele beschrijving.
Om een verzameling te verwijderen, gebruik je de functie wp_unregister_icon_collection(). Verwijder je een verzameling, dan verdwijnen automatisch alle pictogrammen die eraan gekoppeld zijn.
Om een afzonderlijk pictogram te registreren, gebruik je de functie wp_register_icon(), zoals in het volgende voorbeeld:
wp_register_icon(
'my-icon-set/motorbike',
array(
'label' => __( 'Motorbike', 'my-plugin' ),
'content' => '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">...</svg>',
)
);In het bovenstaande voorbeeld registreerden we een pictogram met een SVG-string. Je kunt een pictogram ook rechtstreeks vanuit een .svg bestand registreren:
wp_register_icon(
'my-icon-set/motorbike',
array(
'label' => __( 'Motorbike', 'my-plugin' ),
'file_path' => plugin_dir_path( __FILE__ ) . 'icons/motorbike.svg',
)
);Goed om te weten: de SVG wordt opgeschoond met wp_kses, en momenteel zijn alleen de elementen <svg>, <path> en <polygon> toegestaan. Alle andere elementen worden eruit gefilterd, al wordt de lijst met toegestane elementen in de toekomst mogelijk uitgebreid met extra elementen en attributen.
Om een pictogram te verwijderen, gebruik je de functie wp_unregister_icon().
Updates van de Icon library en blokken
De Icon library is hierop aangepast en heeft nu een zijbalk met de lijst van pictogramverzamelingen die op de site zijn geregistreerd.
Het Icon-blok is ook bijgewerkt. Standaard toont het blok nu het Info-pictogram in plaats van een lege placeholder, zoals in eerdere versies. Daarnaast spiegel je met twee nieuwe knoppen in de werkbalk van het blok het pictogram verticaal en horizontaal.
Nieuwe REST API-endpoints voor pictogrammen
Er zijn ook nieuwe, alleen-lezen REST API-endpoints geïntroduceerd om pictogramverzamelingen of specifieke pictogrammen op te halen.
Voor pictogramverzamelingen gebruik je de volgende endpoints:
GET /wp/v2/icon-collections
GET /wp/v2/icon-collections/<collection>Om pictogrammen te lezen, gebruik je deze endpoints:
GET /wp/v2/icons - Introduced with WordPress 7.0.
GET /wp/v2/icons/<collection>
GET /wp/v2/icons/<collection>/<name>Verzoeken moeten worden geverifieerd door een gebruiker met de bevoegdheid edit_posts.
Voor een uitgebreider overzicht van het pictogramsysteem in WordPress 7.1 bekijk je de dev note.
Nieuwe ontwerptools
Makers en redacteuren krijgen nieuwe, verbeterde ontwerptools waarmee ze contentblokken opmaken zonder eigen CSS te hoeven schrijven.
Ondersteuning voor achtergrondverlopen
WordPress 7.1 introduceert ondersteuning voor background.gradient en een nieuwe interface voor achtergrondverlopen.
In de zijbalk met blokinstellingen vind je een nieuw paneel Background met aparte instellingen voor Image, Color en Gradient. Hiermee experimenteer je met verschillende combinaties van achtergrondafbeeldingen, kleuren en verlopen, zonder dat er conflicten ontstaan.
In WordPress 7.1 is ondersteuning voor background.gradient standaard ingeschakeld voor de blokken Group, Accordion, Pullquote, Post Content en Quote. Themaontwikkelaars voegen ondersteuning voor background.gradient toe in block.json door een gradient-eigenschap toe te voegen onder styles.background, of per blok, zoals in de volgende code:
{
"styles": {
"background": {
"gradient": "linear-gradient( 135deg, #1e3c72 0%, #2a5298 100% )"
},
"blocks": {
"core/group": {
"background": {
"gradient": "linear-gradient( 135deg, #f5f7fa 0%, #c3cf8d 100% )"
}
}
}
}
}Ondersteuning voor minimale breedte
Een andere toevoeging in WordPress 7.1 waar designers en themaontwikkelaars blij van worden, is ondersteuning voor de afmeting minWidth. Dit vult de bestaande ondersteuning voor height, minHeight en width aan, waarmee de set ontwerptools voor afmetingen compleet is.
Themaontwikkelaars voegen ondersteuning voor minimale breedte toe via theme.json, door Appearance Tools in te schakelen of door het veld dimensions.minWidth toe te voegen onder settings:
{
"settings": {
"dimensions": {
"minWidth": true
}
}
}
Je voegt ondersteuning voor minimale breedte ook globaal of per blok toe:
{
"styles": {
"dimensions": {
"minWidth": "400px"
},
"blocks": {
"core/group": {
"dimensions": {
"minWidth": "400px"
}
}
}
}
}Blokontwikkelaars voegen op dezelfde manier ondersteuning voor minWidth toe via block.json:
{
"supports": {
"dimensions": {
"minWidth": true
}
}
}De instelling is standaard verborgen in de zijbalk, maar je wijzigt de standaardinstelling via __experimentalDefaultControls. In Global Styles is de instelling standaard zichtbaar.
Ondersteuning voor tekstschaduw in Global Styles
WordPress 7.1 introduceert ondersteuning voor text-shadow in Global Styles. Voorheen had je hiervoor een plugin nodig of moest je uitwijken naar eigen CSS.
Let op: dit is een eerste versie. Er moeten nog een paar belangrijke beslissingen worden genomen, zoals welk UI-besturingselement tekstschaduwen in de editor gaat aanpassen, en of text-shadow beschikbaar moet zijn als preset. Voorlopig definieer je text-shadow alleen op een van de volgende manieren in je theme.json:
{
"$schema": "https://schemas.wp.org/wp/6.7/theme.json",
"version": 3,
"settings": {},
"styles": {
"typography": {
"textShadow": "1px 1px 2em white, 0 0 2em yellow, 0 0 0.2em red;"
},
"blocks": {
"core/paragraph": {
"typography": {
"textShadow": "1px 1px 2px red, 0 0 1em red, 0 0 0.2em red"
}
}
},
"elements": {
"h2": {
"typography": {
"fontSize": "var:preset|font-size|x-large",
"textShadow": "1px 1px 2em white, 0 0 2em yellow, 0 0 0.2em red;"
}
}
}
}
}De volgende afbeelding laat het resultaat van de bovenstaande definities zien.
Updates voor developers
De updates die WordPress 7.1 voor thema- en pluginontwikkelaars meebrengt, zijn de moeite waard. De vele toevoegingen en verbeteringen aan de Abilities API en het designsysteem voor thema’s springen er wat ons betreft het meest uit.
Theming via het designsysteem
WordPress 7.1 introduceert een nieuw designsysteem waarmee pluginontwikkelaars de stijl van elementen in de beheerdersinterface aanpassen. Het nieuwe systeem bestaat uit twee delen: design tokens en een nieuwe ThemeProvider React-component.
Design tokens
WordPress design tokens zijn CSS custom properties die een vast patroon volgen. Dit is bijvoorbeeld het patroon voor de Color-tokenfamilie:
--wpds-color-<property>-<target>-<tone>[-<emphasis>][-<state>]Op basis van het bovenstaande patroon bepaalt de volgende variabele de achtergrondkleur voor oppervlakken met normale nadruk:
--wpds-color-background-surface-neutral-strongVanaf WordPress 7.1 kan elke plugin die elementen van de beheerdersinterface genereert design tokens gebruiken, dankzij een nieuw stylesheet wp-theme dat een volledige set semantische design tokens bevat en beschikbaar is als afhankelijkheid van de plugin. Je plaatst een eigen stylesheet dat gebruikmaakt van wp-theme zo in de wachtrij:
function myplugin_enqueue_admin_assets( $hook_suffix ) {
wp_enqueue_style(
'myplugin-admin-style',
plugin_dir_url( __FILE__ ) . 'assets/css/admin.css',
array( 'wp-theme' ),
'1.0.0'
);
}
add_action( 'admin_enqueue_scripts', 'myplugin_enqueue_admin_assets' );Het voordeel van design tokens is dat ze hardgecodeerde CSS-waarden vervangen. Bekijk het volgende voorbeeld uit de dev note:
.card {
background-color: var(--wpds-color-background-surface-neutral-strong);
color: var(--wpds-color-foreground-content-neutral);
border: var(--wpds-border-width-xs) solid var(--wpds-color-stroke-surface-neutral-weak);
border-radius: var(--wpds-border-radius-lg);
padding: var(--wpds-dimension-padding-2xl);
}Design tokens kun je samen met de ThemeProvider-component gebruiken om het uiterlijk van specifieke delen van de beheerpagina aan te passen.
ThemeProvider
Je overschrijft de standaardwaarden van de design tokens uit het stylesheet wp-theme door de content van het beheerdersgedeelte in de nieuwe React-component ThemeProvider te plaatsen, zoals in het volgende voorbeeld uit de dev note:
import { ThemeProvider } from '@wordpress/theme';
import { Card } from '@wordpress/ui';
function Application() {
return (
<ThemeProvider
color={
{
primary: '#3858e9',
background: '#11004d'
}
}
cornerRadius="pronounced"
>
<Card.Root>
<Card.Content>
Card content
</Card.Content>
</Card.Root>
</ThemeProvider>
);
}Op basis van een primaire kleur en een achtergrondkleur genereert de component automatisch een harmonieus en consistent kleurenpalet dat zorgt voor voldoende contrast tussen de interface-elementen.
Met de ThemeProvider laten pluginontwikkelaars hun merkidentiteit zien binnen interfacegebieden, terwijl ze consistent blijven met de algehele stijl van de WordPress beheerdersinterface.
Voor een diepgaandere analyse raadpleeg je de dev note en de officiële documentatie over design tokens en ThemeProvider.
Verbeteringen aan de Abilities API
Met de release van WordPress 7.1 krijgt de Abilities API een aantal toevoegingen die de functionaliteit uitbreiden.
Nieuwe uitvoeringscyclus voor de Abilities API
Allereerst is de uitvoeringscyclus uitgebreid met 4 nieuwe filters die vóór, tijdens en na de uitvoering van een ability draaien.
Het filter wp_pre_execute_ability draait aan het begin van WP_Ability::execute() en wordt gebruikt om de uitvoering van een ability te onderscheppen en te onderbreken, nog voordat WordPress die begint te verwerken. Retourneert het filter een andere waarde dan de standaardwaarde $pre (een fout, gegevens of een booleaanse waarde), dan stopt WordPress onmiddellijk, slaat het de controles over en retourneert het die waarde.
Dit filter leent zich voor interessante toepassingen, zoals het uitschakelen van een ability tijdens onderhoud aan de site, het beperken van het aantal verzoeken vanaf hetzelfde IP-adres, of het simuleren van de respons van een ability (unit tests).
Het filter wp_ability_normalize_input draait direct nadat de standaardwaarden zijn toegepast en vóór de formele schemavalidatie en machtigingscontroles. Het wordt gebruikt om binnenkomende gegevens voor te bereiden of te transformeren voordat de ability ze valideert en verwerkt, bijvoorbeeld door contextuele metadata toe te voegen, gegevens te normaliseren vóór validatie, een AI-prompt te verrijken of de uitvoering van de ability te stoppen bij een fout.
Met het filter wp_ability_permission_result pas je het resultaat aan van de machtigingscontroles die vóór het uitvoeren van een ability draaien. Je gebruikt het om gedetailleerdere autorisatieregels toe te voegen, een eigen machtigingssysteem te maken of machtigingen in specifieke gevallen te omzeilen.
Let op: gebruik dit filter met de nodige voorzichtigheid:
Plugins moeten extra voorzichtig zijn met dit filter, omdat het retourneren van
trueeen weigering van de oorspronkelijkepermission_callbackvan de ability kan overschrijven.
Het filter wp_ability_execute_result draait na de uitvoeringscallback van de ability en vóór de validatie van de uitvoer, waardoor je het uiteindelijke resultaat van een ability kunt aanpassen. Hiermee wijzig je het antwoord dat de verwerking van de ability genereert, voordat het naar de aanroeper wordt teruggestuurd.
Abilities filteren en bewerken
Vóór WordPress 7.1 moest je, om geregistreerde abilities te filteren, handmatig door het register lopen met array_filter(). Vanaf WordPress 7.1 accepteert wp_get_abilities() een optionele array met argumenten om geregistreerde abilities te filteren op category, namespace, meta of een combinatie daarvan.
Het volgende voorbeeld laat zien hoe je abilities uit een specifieke categorie ophaalt:
$abilities = wp_get_abilities(
array(
'category' => 'content-generation',
)
);Je kunt ook meerdere parameters combineren:
$abilities = wp_get_abilities(
array(
'category' => 'content-generation',
'meta' => array(
'public' => true,
),
)
);Voor geavanceerdere filtering biedt de API de parameters item_include_callback en result_callback: twee callbacks waarmee je abilities toevoegt aan of uitsluit uit de array, en de resultatenset sorteert of bewerkt voordat die wordt teruggestuurd.
Naast de updates voor wp_get_abilities() introduceert WordPress 7.1 twee nieuwe globale filters:
wp_get_abilities_item_include: Draait voor elke ability die door de declaratieve filters enitem_include_callbackkomt. Je gebruikt dit filter om specifieke abilities sitebreed op te nemen of uit te sluiten.wp_get_abilities_result: Draait naresult_callback. Je gebruikt dit om de volledige resultatenset van abilities sitebreed te bewerken.
Raadpleeg de dev note voor een uitgebreider overzicht van de updates aan wp_get_abilities() en de bijbehorende filters.
Nieuwe vlag voor openbare toegang
WordPress 7.1 introduceert ook een nieuwe metadatavlag om aan te geven dat een ability toegankelijk is voor externe clients, zoals de REST API, MCP-adapters en AI-agents.
Bij het registreren van een ability gebruik je nu meta.public om je ability vindbaar en aanroepbaar te maken via de REST-endpoints voor abilities. Voorheen moest je de zichtbaarheid voor elk kanaal apart instellen, bijvoorbeeld met ‘show_in_rest’ => true om een ability via REST zichtbaar te maken.
Andere verbeteringen aan de Abilities API
Naast de bovenstaande updates introduceert WordPress 7.1 nog meer verbeteringen aan verschillende aspecten van de API.
Twee nieuwe filters, wp_ability_validate_input en wp_ability_validate_output, laten plugins invoer- en uitvoergegevens valideren met complexere regels dan met het WordPress JSON-schema mogelijk is. Het eerste filter draait nadat de invoer is voorbereid en de eerste schemavalidatie is doorlopen. Het tweede filter draait nadat de ability is uitgevoerd en voordat het eindresultaat wordt teruggestuurd.
De actie wp_ability_invoked draait aan het begin van WP_Ability::execute() en kan worden gebruikt om elke poging om een ability aan te roepen bij te houden en te loggen. Je haakt op deze actie in om toegangspogingen tot een specifieke ability te loggen, de serverbelasting te meten, dagelijkse of maandelijkse gebruiksstatistieken bij te houden en brute-force-aanroeppogingen te detecteren.
Wees wel voorzichtig:
De actie ontvangt onbewerkte, niet-genormaliseerde invoer. Plugins moeten daarom vermijden om invoer zomaar te loggen, omdat die inloggegevens, persoonlijke informatie of andere gevoelige gegevens kan bevatten.
Meer updates voor developers
De updates voor developers houden hier niet op. WordPress 7.1 brengt een indrukwekkend aantal verbeteringen en toevoegingen mee, waardoor je beschikt over nieuwe en betrouwbaardere ontwikkeltools. In deze nieuwe release vind je ook:
- Vier nieuwe filters om de pagina’s van de Site Editor te configureren
- De bericht-editor wordt altijd in een iframe weergegeven
- Updates voor editorcomponenten
- jQuery UI bijgewerkt naar 1.14.2
- Voorbereiding op JSON-schema voor compatibiliteit met clients.
- Gebruikers kunnen nu stijlen toepassen op pseudo-states.
- Responsieve blokstijlen en instelbare viewports
- Nieuwe features voor het weergeven van tooltips en informatieve hulp
Next-gen hosting voor next-gen WordPress
WordPress 7.1 betekent op verschillende fronten een grote stap vooruit voor het CMS.
Mediaverwerking aan de clientzijde is een keerpunt in het beheer van afbeeldingen. De verwerking gebeurt nu aan de clientzijde, wat zorgt voor efficiënter gebruik van serverresources en snellere paginaprestaties.
Op het gebied van AI is WordPress 7.1, na de baanbrekende updates in 6.9 en 7.0, een moment van consolidatie. De Abilities API krijgt nieuwe mogelijkheden waarmee developers betrouwbaardere en veiligere AI-integraties bouwen.
Een andere sterke toevoeging die developers en bureaus zullen waarderen, is de ThemeProvider. Hiermee laten plugins hun merkidentiteit zien in het beheerdersgedeelte, terwijl ze consistent blijven met de interface van het WordPress dashboard.
Er zijn ook verbeteringen aan Notes, nieuwe blokken, een krachtiger SVG-pictogramsysteem en nog veel meer. Kortom, WordPress gaat nog lang niet op zijn retour en is toekomstgerichter dan ooit.
Voor een steeds geavanceerder CMS is het essentieel om een hostingprovider te kiezen die moderne technologieën bijhoudt. Kinsta biedt de ideale omgeving voor WordPress sites van de volgende generatie: gecontaineriseerde cloudinfrastructuur, uitstekende prestaties, solide beveiliging en snelle, uitstekend beoordeelde support.
Heb je onze hosting nog niet geprobeerd? Maak dan gebruik van de gratis proefperiode voor geselecteerde pakketten of neem contact met ons op voor meer informatie.
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.
