Benieuwd wat er nog meer komt? Laten we dieper ingaan op WordPress 7.1.
\n
Mediaverwerking aan de clientzijde<\/h2>\n
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.<\/p>\n
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.<\/p>\n
Deze verandering zou de prestaties van je site flink moeten verbeteren en het verbruik van serverresources moeten verminderen.<\/p>\n
Laten we eens kijken wat er verandert in de afbeeldingsverwerking:
\n
1. Wat is mediaverwerking aan de clientzijde?<\/h3>\n
Waar afbeeldingen voorheen op de server werden verwerkt door PHP met de GD-<\/a> of Imagick-bibliotheken<\/a>, 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 ( Omdat de verwerking in de browser plaatsvindt, ontvangt WordPress niet langer \u00e9\u00e9n 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.<\/p>\n Op het moment van schrijven ondersteunen alleen Chrome 137+ en Microsoft Edge 137+ (desktop) de Architectonisch gezien wordt mediaverwerking aan de clientzijde geregeld via 3 kernpakketten:<\/p>\n 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 Client-Side Media Processing introduceert ook nieuwe REST API-endpoints ( 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.<\/p>\n Een paar voordelen voor gebruikers nu de mediaverwerking naar de client verhuist:<\/p>\n Bovendien kunnen geanimeerde GIF’s automatisch worden omgezet in effici\u00ebntere video’s die automatisch afspelen, kan de browser HEIC-foto’s van iPhones v\u00f3\u00f3r 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).<\/p>\n Developers kunnen de mediaverwerking aan de clientzijde uitschakelen met het nieuwe filter 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.<\/p>\n Bestaande filters lezen instellingen van de server en blijven werken zoals verwacht. Het filter Voor themaontwikkelaars worden afbeeldingsformaten die via Hoewel mediaverwerking aan de clientzijde in de eerste plaats is ontworpen voor prestaties en effici\u00ebntie, biedt het verschillende voordelen die de beveiliging van WordPress sites verbeteren.<\/p>\n Ten eerste verkleint het het aanvalsoppervlak. Zoals eerder genoemd was de afbeeldingsverwerking v\u00f3\u00f3r 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.<\/p>\n 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.<\/p>\n Een ander beveiligingsvoordeel is dat de afbeeldingsverwerking plaatsvindt binnen een ge\u00efsoleerde browseromgeving, via WebAssembly in een Web Worker.<\/p>\n Verwerking aan de clientzijde verkleint ook het risico op Denial-of-Service-aanvallen (DoS), omdat de rekenbelasting bij de client ligt.<\/p>\n Om afbeeldingen aan de clientzijde te verwerken, gebruikt WordPress Om toegang te geven tot Kortom: hoewel Client-Side Media Processing vooral is bedoeld om de prestaties en effici\u00ebntie bij het verwerken van media te verbeteren, levert deze nieuwe feature ook duidelijke winst op voor de beveiliging.<\/p>\n Client-Side Media Processing is uitgebreid gedocumenteerd voor zowel gebruikers als developers. Bekijk de volgende bronnen voor meer informatie:<\/p>\n Notes, voor het eerst ge\u00efntroduceerd in WordPress 6.9<\/a>, kreeg talloze toevoegingen en verbeteringen, waardoor het een completere tool voor samenwerking is geworden.<\/p>\n Om te beginnen voegt WordPress 7.1 ondersteuning voor rich text in Notes<\/a> 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”.<\/p>\n Denk hierbij aan basisopmaak in de tekst, zoals vet (Ctrl\/\u2318 B), cursief (Ctrl\/\u2318 I), links (Ctrl\/\u2318 K) en emoji’s.<\/p>\n Je kunt nu inline notities toevoegen door tekstfragmenten te selecteren in plaats van alleen een heel blok (inline blokcommentaar<\/a>). Het is ook mogelijk om meerdere notities<\/a> aan hetzelfde blok of dezelfde tekstselectie toe te voegen.<\/p>\n WordPress 7.1 introduceert ook @mentions<\/a> 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.<\/p>\n Een andere toevoeging betreft het zichtbare gedeelte van de notities. Lange notities worden nu standaard ingeklapt<\/a>, zodat ze niet te veel schermruimte innemen. Met de schakelaar Show more\/Show less<\/strong> toon of verberg je de volledige tekst.<\/p>\n De volledige lijst met nieuwe features voor Notes in WordPress 7.1 vind je in de Notes-update voor WordPress 7.1<\/a>.<\/p>\n De beheerdersinterface krijgt verschillende updates die de consistentie verbeteren en de navigatie tussen pagina’s vereenvoudigen. V\u00f3\u00f3r 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<\/a>.<\/p>\n Een andere verbetering die alle beheerdersgedeelten consistent maakt: hetzelfde kleurenschema dat je op je instellingenpagina hebt gekozen<\/a>, wordt nu ook in de Site Editor gebruikt. V\u00f3\u00f3r versie 7.1 was de zijbalk van de Site Editor altijd zwart.<\/p>\n 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.<\/p>\n In eerdere versies moest je op het site-icoontje klikken om terug te gaan naar het WordPress beheerdersgedeelte, wat technisch gezien geen terugknop was.<\/p>\n Daardoor staat het site-icoontje nu alleen nog in de adminbalk, terwijl de werkbalk van de editor een duidelijkere terugknop heeft gekregen.<\/p>\n De command palette kreeg verschillende toevoegingen en aanpassingen<\/a> om de bruikbaarheid te verbeteren. Allereerst zijn de beschikbare commands onderverdeeld in secties (recent, suggestions en results), zodat je ze makkelijker vindt.<\/p>\n Het venster is aangepast (512px) en de commands zijn nu makkelijker te lezen.<\/p>\n Onder het menu Design <\/b>in de Site Editor staat nu een nieuw item Identity<\/strong>. Op die pagina stel je de titel en slogan<\/a> en het logo en het pictogram<\/a> van je site in. Zo pas je de identiteitsinstellingen van je site aan zonder de Site Editor te verlaten.<\/p>\n Tot en met WordPress 7.0 kon je oneindig scrollen voor de rasterweergave van de Media Library inschakelen via het filter Vanaf WordPress 7.1<\/a> staat het filter Daarnaast stel je via een nieuwe instelling op de gebruikersprofielpagina in het WordPress beheerdersgedeelte je eigen voorkeur voor oneindig scrollen in.<\/p>\n WordPress slaat de keuze van de gebruiker op in de gebruikersopties met de metasleutel WordPress 7.1 introduceert twee nieuwe blokken en diverse verbeteringen aan bestaande blokken. Met het nieuwe Playlist<\/strong>-blok<\/a> sluit je een eenvoudige afspeellijst in je content in.<\/p>\n 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<\/strong> en Waveform background<\/strong>. Met de instelling Shape<\/strong> wijzig je de audiovisualisatie van de waveform<\/a>.<\/p>\n Het Playlist-blok<\/a> 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.<\/p>\n Het nieuwe standaard Tabs-blok<\/a> 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.<\/p>\n Het Custom HTML-blok kreeg een nieuwe verbetering<\/a>. Je voegt nu bewerkbare blokken rechtstreeks in de HTML-code toe. Zo combineer je statische HTML en bewerkbare blokken in hetzelfde fragment.<\/p>\n 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.<\/p>\n V\u00f3\u00f3r 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.<\/p>\n Deze wijziging gaat samen met de mogelijkheid om statische HTML-code toe te voegen aan blokvarianten. Dankzij de nieuwe ondersteuning voor De waarde Let op: WordPress 7.0 introduceerde een nieuw Icon-blok<\/a> 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.<\/p>\n Om een pictogram of een pictogrammenset te registreren, registreer je eerst een pictogramverzameling door de nieuwe functie 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.<\/p>\n 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.<\/p>\n Om een verzameling te verwijderen, gebruik je de functie Om een afzonderlijk pictogram te registreren, gebruik je de functie In het bovenstaande voorbeeld registreerden we een pictogram met een SVG-string. Je kunt een pictogram ook rechtstreeks vanuit een Goed om te weten: de SVG wordt opgeschoond met Om een pictogram te verwijderen, gebruik je de functie De Icon library is hierop aangepast en heeft nu een zijbalk met de lijst van pictogramverzamelingen die op de site zijn geregistreerd.<\/p>\n 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.<\/p>\n Er zijn ook nieuwe, alleen-lezen REST API-endpoints ge\u00efntroduceerd om pictogramverzamelingen of specifieke pictogrammen op te halen.<\/p>\n Voor pictogramverzamelingen gebruik je de volgende endpoints:<\/p>\n Om pictogrammen te lezen, gebruik je deze endpoints:<\/p>\n Verzoeken moeten worden geverifieerd door een gebruiker met de bevoegdheid edit_posts.<\/p>\n Voor een uitgebreider overzicht van het pictogramsysteem in WordPress 7.1 bekijk je de dev note<\/a>.<\/p>\n Makers en redacteuren krijgen nieuwe, verbeterde ontwerptools waarmee ze contentblokken opmaken zonder eigen CSS te hoeven schrijven. WordPress 7.1 introduceert ondersteuning voor 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.<\/p>\n In WordPress 7.1 is ondersteuning voor Een andere toevoeging in WordPress 7.1 waar designers en themaontwikkelaars blij van worden, is ondersteuning voor de afmeting Themaontwikkelaars voegen ondersteuning voor minimale breedte toe via Je voegt ondersteuning voor minimale breedte ook globaal of per blok toe:<\/p>\n Blokontwikkelaars voegen op dezelfde manier ondersteuning voor De instelling is standaard verborgen in de zijbalk, maar je wijzigt de standaardinstelling via WordPress 7.1 introduceert ondersteuning voor Document-Isolation-Policy<\/code>) ondersteunt om toegang te geven tot SharedArrayBuffer<\/code>.<\/p>\nDocument-Isolation-Policy<\/code> volledig. Safari en Firefox ondersteunen de WASM-pipeline niet, al ondersteunt Safari wel native decodering van HEIC\/HEIF-indelingen<\/a> naar JPG.<\/p>\n![\"Diagram](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/wp-71-client-side-media-upload-flow.png\")
2. Wat zijn de technische kenmerken van Client-Side Media Processing?<\/h3>\n
\n
@wordpress\/vips<\/code> pakket regelt de verwerking aan de clientzijde met de libvips<\/code>\u00a0bibliotheek<\/a>, gecompileerd naar WebAssembly (wasm-vips<\/code>). Deze bibliotheek geldt algemeen als een van de snelste en effici\u00ebntste 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.<\/li>\n@wordpress\/upload-media<\/code> pakket 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.<\/li>\n@wordpress\/media-utils<\/code> pakket regelt het HTTP-verkeer en de REST API-verzoeken.<\/li>\n<\/ul>\n![\"Architectuurdiagram](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/wp-71-client-side-media-processing-architecture-overview.png\")
@wordpress\/video-conversion<\/code> pakket, dat de mediabunny<\/code> bibliotheek<\/a> in een Web Worker verpakt om ondoorzichtige GIF’s (zonder transparante achtergrond) om te zetten in lichte videobestanden.<\/p>\nsideload<\/code>, finalize<\/code> en replace_file<\/code>), samen met 2 nieuwe parameters: generate_sub_sizes<\/code> en convert_format<\/code>.<\/p>\n3. Wat zijn de voordelen voor WordPress gebruikers?<\/h3>\n
\n
PHP memory limit exceeded<\/code>) die voorheen optraden bij het verwerken van grote afbeeldingsbestanden.<\/li>\nlibvips<\/code> bibliotheek 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.<\/li>\n4. Wat verandert er voor developers?<\/h3>\n
wp_client_side_media_processing_enabled<\/code>. Een voorbeeld:<\/p>\nadd_filter( 'wp_client_side_media_processing_enabled', '__return_false' );<\/code><\/pre>\nwp_generate_attachment_metadata<\/code> wordt bijvoorbeeld twee keer uitgevoerd: eerst tijdens de eerste upload (create<\/code>) en een tweede keer nadat het finalize-endpoint is aangeroepen (update<\/code>). Plugins die dit filter gebruiken, blijven werken zoals verwacht.<\/p>\nadd_image_size()<\/code> 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 \u00e9\u00e9n afbeeldingsbestand dat onder beide formaatnamen wordt geregistreerd.<\/p>\n5. Wat zijn de voordelen voor de beveiliging?<\/h3>\n
SharedArrayBuffer<\/code><\/a>, een JavaScript-object waarmee de hoofdthread en Web Workers dezelfde geheugenruimte kunnen delen.<\/p>\nSharedArrayBuffer<\/code>, schakelt WordPress de Document-Isolation-Policy: isolate-and-credentialless<\/code> header<\/a> in. Dat zorgt voor een ge\u00efsoleerde uitvoeringscontext voor de blok-editor in Chromium 137+ -browsers (Chrome 137+ en Edge 137+).<\/p>\n6. Offici\u00eble bronnen<\/h3>\n
\n
Verbeteringen voor Notes<\/h2>\n
![\"Opmaakopties](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/07\/wp-71-notes-formatting-options.png\")
![\"Een](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/07\/Screenshot-2026-07-20-alle-08.02.31.png\")
Verbeteringen aan de beheerdersinterface<\/h2>\n
\nPermanente adminbalk in de bericht-editor en Site Editor<\/h3>\n
![\"De](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/07\/wp-71-admin-toolbar-in-post-editor.png\")
![\"De](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/07\/wp-71-admin-toolbar-in-site-editor.png\")
Het kleurenschema van de gebruiker geldt nu ook voor de Site Editor<\/h3>\n
![\"De](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/07\/wp-71-site-editor-ui.jpg\")
![\"De](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/editor-toolbar-in-wp-70.png\")
![\"De](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/wp-71-editor-toolbar.png\")
Command categories en verbeterde interface van de command palette<\/h3>\n
![\"Secties](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/07\/wp-71-command-palette-sections.png\")
![\"Het](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/07\/wp-71-command-palette-search-results.png\")
Identity pagina in de Site Editor<\/h3>\n
![\"Identity-instellingen](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/07\/identity-settings.png\")
Oneindig scrollen in de rasterweergave van de Media Library<\/h3>\n
media_library_infinite_scrolling<\/code>, dat standaard op false<\/code> stond. Developers konden de standaardinstelling aanpassen door de volgende regel aan hun plugins toe te voegen:<\/p>\nadd_filter( 'media_library_infinite_scrolling', '__return_true' );<\/code><\/pre>\nmedia_library_infinite_scrolling<\/code> op true<\/code>, wat betekent dat oneindig scrollen in de rasterweergave van de Media Library standaard voor alle gebruikers is ingeschakeld.<\/p>\n![\"Optie](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/07\/wp-71-disable-infinite-scrolling.png\")
infinite_scrolling<\/code>. Je haalt de gebruikersvoorkeur zo op:<\/p>\n$infinite_scrolling = get_user_option( 'infinite_scrolling', $user_id );<\/code><\/pre>\nKernblokken en verbeteringen aan blokken<\/h2>\n
\nNieuwe blokken Playlist en Tabs<\/h3>\n
![\"Het](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/07\/wp-71-playlist-block.png\")
![\"Stijlaanpassing](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/07\/wp-71-playlist-block-customized.png\")
![\"Het](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/07\/wp-71-tabs-block.jpg\")
Bewerkbare blokken binnen het Custom HTML-blok<\/h3>\n
![\"Het](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/wp-71-custom-html-block.png\")
innerContent<\/code> registreer je een variant van het HTML-blok, zoals in het onderstaande voorbeeld:<\/p>\nwp.blocks.registerBlockVariation( 'core\/html', {\n\tname: 'custom-image-card',\n\ttitle: 'Custom image card',\n\tdescription: 'A custom HTML block with static header\/footer and an editable image.',\n\tinnerContent: [ \n\t\t'<h2>Static heading<\/h2>\\n', \n\t\tnull, \n\t\t'\\n<footer>Static footer<\/footer>' \n\t],\n\tinnerBlocks: [ \n\t\t[ \n\t\t\t'core\/image', \n\t\t\t{ \n\t\t\t\tid: 419,\n\t\t\t\tsizeSlug: 'medium',\n\t\t\t\tlinkDestination: 'none',\n\t\t\t\turl: 'https:\/\/example.com\/wp-content\/uploads\/...',\n\t\t\t\talt: ''\n\t\t\t} \n\t\t] \n\t],\n} );<\/code><\/pre>\nnull<\/code> in innerContent<\/code> fungeert als placeholder voor het Image-blok.<\/p>\ninnerContent<\/code> is alleen beschikbaar voor het Custom HTML-blok. Pas je dit toe op varianten van andere blokken, dan heeft dat geen effect.<\/p>\nVerbeteringen aan het SVG-pictogramsysteem<\/h2>\n
Pictogrammen registreren en deregistreren<\/h3>\n
wp_register_icon_collection()<\/code> aan de init-actie te koppelen:<\/p>\nfunction custom_icons_register_icon_collection() {\n\twp_register_icon_collection(\n\t\t'my-icon-set',\n\t\tarray(\n\t\t\t'label' => __( 'My awesome icons', 'my-plugin' ),\n\t\t\t'description' => __( 'My personal set of icons.', 'my-plugin' ),\n\t\t)\n\t);\n}\nadd_action( 'init', 'custom_icons_register_icon_collection' );<\/code><\/pre>\nwp_unregister_icon_collection()<\/code>. Verwijder je een verzameling, dan verdwijnen automatisch alle pictogrammen die eraan gekoppeld zijn.<\/p>\nwp_register_icon()<\/code>, zoals in het volgende voorbeeld:<\/p>\nwp_register_icon(\n\t'my-icon-set\/motorbike',\n\tarray(\n\t\t'label' => __( 'Motorbike', 'my-plugin' ),\n\t\t'content' => '<svg xmlns=\"http:\/\/www.w3.org\/2000\/svg\" viewBox=\"0 0 24 24\">...<\/svg>',\n\t)\n);<\/code><\/pre>\n.svg<\/code> bestand registreren:<\/p>\nwp_register_icon(\n\t'my-icon-set\/motorbike',\n\tarray(\n\t\t'label' => __( 'Motorbike', 'my-plugin' ),\n\t\t'file_path' => plugin_dir_path( __FILE__ ) . 'icons\/motorbike.svg',\n\t)\n);<\/code><\/pre>\nwp_kses<\/code>, en momenteel zijn alleen de elementen <svg><\/code>, <path><\/code> en <polygon><\/code> toegestaan. Alle andere elementen worden eruit gefilterd, al wordt de lijst met toegestane elementen in de toekomst mogelijk uitgebreid met extra elementen en attributen.<\/p>\nwp_unregister_icon()<\/code>.<\/p>\nUpdates van de Icon library en blokken<\/h3>\n
![\"De](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/07\/wp-71-icon-collection.png\"){kind=icon}
![\"Een](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/07\/wp-71-custom-icon-collection.png\"){kind=icon}
![\"Instellingen](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/07\/wp-71-icon-block.png\"){kind=icon}
Nieuwe REST API-endpoints voor pictogrammen<\/h3>\n
GET \/wp\/v2\/icon-collections\nGET \/wp\/v2\/icon-collections\/<collection><\/code><\/pre>\nGET \/wp\/v2\/icons - Introduced with WordPress 7.0.\nGET \/wp\/v2\/icons\/<collection>\nGET \/wp\/v2\/icons\/<collection>\/<name><\/code><\/pre>\nNieuwe ontwerptools<\/h2>\n
\nOndersteuning voor achtergrondverlopen<\/h3>\n
background.gradient<\/code><\/a> en een nieuwe interface voor achtergrondverlopen.<\/p>\n![\"Instelling](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/wp-71-background-gradient.jpg\")
background.gradient<\/code> standaard ingeschakeld voor de blokken Group, Accordion, Pullquote, Post Content en Quote. Themaontwikkelaars voegen ondersteuning voor background.gradient<\/code> toe in block.json door een gradient-eigenschap toe te voegen onder styles.background, of per blok, zoals in de volgende code:<\/p>\n{\n\t\"styles\": {\n\t\t\"background\": {\n\t\t\t\"gradient\": \"linear-gradient( 135deg, #1e3c72 0%, #2a5298 100% )\"\n\t\t},\n\t\t\"blocks\": {\n\t\t\t\"core\/group\": {\n\t\t\t\t\"background\": {\n\t\t\t\t\t\"gradient\": \"linear-gradient( 135deg, #f5f7fa 0%, #c3cf8d 100% )\"\n\t\t\t\t}\n\t\t\t}\n\t\t}\n\t}\n}<\/code><\/pre>\nOndersteuning voor minimale breedte<\/h3>\n
minWidth<\/code><\/a>. Dit vult de bestaande ondersteuning voor height<\/code>, minHeight<\/code> en width<\/code> aan, waarmee de set ontwerptools voor afmetingen compleet is.<\/p>\ntheme.json<\/code>, door Appearance Tools in te schakelen of door het veld dimensions.minWidth<\/code> toe te voegen onder settings:<\/p>\n{\n\t\"settings\": {\n\t\t\"dimensions\": {\n\t\t\t\"minWidth\": true\n\t\t}\n\t}\n}<\/code><\/pre>\n![\"Instelling](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/wp-71-min-width.jpg\")
{\n\t\"styles\": {\n\t\t\"dimensions\": {\n\t\t\t\"minWidth\": \"400px\"\n\t\t},\n\t\t\"blocks\": {\n\t\t\t\"core\/group\": {\n\t\t\t\t\"dimensions\": {\n\t\t\t\t\t\"minWidth\": \"400px\"\n\t\t\t\t}\n\t\t\t}\n\t\t}\n\t}\n}<\/code><\/pre>\nminWidth<\/code> toe via block.json<\/code>:<\/p>\n{\n\t\"supports\": {\n\t\t\"dimensions\": {\n\t\t\t\"minWidth\": true\n\t\t}\n\t}\n}<\/code><\/pre>\n__experimentalDefaultControls<\/code>. In Global Styles is de instelling standaard zichtbaar.<\/p>\nOndersteuning voor tekstschaduw in Global Styles<\/h3>\n
text-shadow<\/code> in Global Styles<\/a>. Voorheen had je hiervoor een plugin nodig of moest je uitwijken naar eigen CSS.<\/p>\n