wp_kses() på HTML API: hva du bør teste før WordPress 7.2

#Hva er det egentlig som endres i wp_kses()?

Den gamle implementasjonen skilte markup fra hverandre med regulære uttrykk. Den nye leser det med tokenizeren i HTML API, avgjør per tagg og attributt hva som er tillatt, og skriver resultatet ut på nytt. Pull requesten heter “KSES: Reimplement with Tag Processor” (PR 13271) og hører til Trac-saken 66208. Ifølge PR-en ligger den nye koden i en funksjon som heter wp_sanitize_html_kses().

Hensikten i rapporten er tydelig: wp_kses() skal ikke bli dårligere enn før. Rapporten sier også at plugins og temaer ikke bør trenge endringer. Begge utsagnene kan stemme mens testene dine likevel blir røde, fordi “like trygt” ikke betyr “like bytes”. Ny serialisering er hele poenget, og den endrer strenger.

Kilde: Progress Report: wp_kses(), 7. oktober 2026.

#Hvilke inndata gir annerledes output?

Rapporten viser par av før og etter. Blokken under er modellert etter dem (min egen tabell over tillatte tagger, inndata fra rapporten). Kjør tilfellene på din egen trunk-bygg før du stoler på min gjengivelse.

<?php
// Modelled on the examples in the Make Core progress report.
$allowed = array(
	'a'    => array( 'href' => true ),
	'code' => true,
	'img'  => array( 'src' => true, 'class' => true ),
);

wp_kses( 'Click on my <script>alert(1)</script>!', $allowed );
// legacy: Click on my alert(1)!
// new:    Click on my !

wp_kses( 'The <IMG class=bike class="bo&#x0061;t" src=\'vehicle.png\' /> & the wheels&hellip;', $allowed );
// legacy: The <IMG class="bike" src="vehicle.png" /> &amp; the wheels&hellip;
// new:    The <img class="bike" src="vehicle.png"> &amp; the wheels…

wp_kses( 'Add <code>/?preview=true&section=grilling</code>.', $allowed );
// legacy: Add <code>/?preview=true&amp;section=grilling</code>.
// new:    Add <code>/?preview=true§ion=grilling</code>.

wp_kses( 'Click on the <butto', $allowed );
// legacy: Click on the &lt;butto
// new:    Click on the (trailing space, nothing else)

Rapporten grupperer forskjellene slik:

• Normalisering. Taggnavn blir små bokstaver, attributter får doble anførselstegn, ved duplikate attributter vinner det første, og tegnreferanser skrives på nytt.
• Løse vinkelparenteser. Tekst som <$500 eller >5yo ble tidligere svelget. Nå blir den til < og >, og teksten består.
• Tvetydig ampersand. En navngitt referanse uten semikolon, for eksempel &section i en URL i en tekstnode, dekodes slik nettleseren gjør det. Derfor blir det tredje tilfellet til paragraftegnet.
• Script og style. Når disse elementene ikke er tillatt, forsvinner innholdet sammen med taggene. Den gamle koden lot innholdet stå igjen som synlig tekst.
• Avkortet inndata. En ufullstendig siste tagg forkastes, den escapes ikke.
• Spesielle elementer. Taggliknende tekst inni en tillatt <title> escapes, mens samme tekst inni en <div> forsvinner sammen med den ukjente taggen.
• SVG og MathML. Innhold som krever kompleks parsing gjør at funksjonen stopper og bare returnerer det som kom før. Rapporten viser en <li> med MathML og en nøstet <span> som kuttes der.
• Harde grenser. Enkelte ødelagte kommentarer, NOSCRIPT og forvekslbare elementer avvises nå.
• Ubalanserte tagger. Beholdes med vilje, fordi eksisterende kode er avhengig av det.

På en typisk norsk nettbutikk er de første stedene å lete produktbeskrivelser med mål som “<5 cm” limt inn fra leverandørens regneark, importert leverandør-HTML med store bokstaver i taggene, og sidebyggere som skriver ut inline SVG. Det er en antakelse om hvor du bør lete, ikke en måling.

Jeg fant ikke bekreftet i kildene jeg leste hvordan <script> oppfører seg når du uttrykkelig tillater det i arrayen. Test det tilfellet selv i stedet for å anta et resultat.

#Fungerer min egen allowed-html-array fortsatt?

For det meste, siden tillatelseslogikken er den samme: en tagg eller et attributt står i arrayen eller ikke. Det som endres er hva som kommer ut rundt. Tre mønstre fortjener et blikk.

1. Arrayer som tillater inline script eller style. En shortcode som skriver ut et inline-skript og sender det gjennom wp_kses() med script tillatt, ligger midt i området rapporten berører. Sammenlign gammel og ny output. Vurder også om skriptet heller bør gå via wp_add_inline_script() enn via sanitizeren.
2. Arrayer som tillater svg eller math. Inline ikonsett er det vanlige tilfellet. Hvis regelen fra rapporten gjelder, kan output kuttes ved den første konstruksjonen parseren ikke håndterer. Sammenlign hvert ikon du leverer.
3. Arrayer for <title> og lignende. <title> er et spesielt element, og innholdet behandles som tekst. Derfor eksempelet med escapet <sneaky>.

Tillater arrayen bare a, strong, em, img og noen få attributter, blir effekten trolig kosmetisk: <IMG ... /> blir <img ...>.

#Hva går i stykker i tester som sammenligner renset HTML?

Alt som sjekker en eksakt streng. En test som den første assertionen under består i dag og kan feile etter omskrivingen, selv om markupen betyr det samme. Den andre assertionen tåler normaliseringen.

<?php
// Brittle: pins the exact string the sanitizer happens to emit.
$this->assertSame( '<a href="/x">Read</a>', wp_kses_post( "<A HREF='/x'>Read</A>" ) );

// Sturdier: asserts on what the markup means.
$p = new WP_HTML_Tag_Processor( wp_kses_post( "<A HREF='/x'>Read</A>" ) );
$this->assertTrue( $p->next_tag( 'a' ) );
$this->assertSame( '/x', $p->get_attribute( 'href' ) );

Fest deg til oppførsel, ikke bytes. Fixtures som må forbli strenglike, genererer du én gang på trunk, leser diffen som et menneske og committer den nye forventede verdien med en kommentar om hvilken versjon den endret seg i. Et generelt “oppdater snapshots” er måten en ekte regresjon blir godkjent på.

Visuelle tester og golden-filer trenger samme behandling. E-postmaler du renser før utsending er et typisk sted der en lagret streng sammenlignes med en fersk.

#Hvordan tester jeg på trunk uten å røre produksjon?

Tre veier, alle på staging eller lokalt. Dette er mine forslag, ikke en del av den offisielle rapporten.

Pluginen WordPress Beta Tester. Den kan flytte en staging-side til nattlige bygg og senere til 7.2-betaene. Ifølge tidsplanen kommer Beta 1 20. oktober 2026. Om omskrivingen allerede er med i Beta 1 kunne jeg ikke bekrefte, så sjekk at filteret wp_kses_force_legacy_parser finnes i koden du faktisk installerte.

WP-CLI nightly. På en kopi du kan kaste:

# Staging only, never production.
wp core update --version=nightly --force
wp core version
wp eval-file bin/kses-diff.php > kses-diff.txt
tail -n 1 kses-diff.txt

wp-env. Pek kjernen mot trunk-speilet og monter pluginen:

{
  "core": "WordPress/WordPress#master",
  "plugins": [ "." ]
}

Uansett vei: avslutt med å bekrefte at filteret finnes, for eksempel med grep -rn wp_kses_force_legacy_parser wp-includes/. Finnes det ikke, tester du ikke omskrivingen.

#Hvordan sammenligner jeg renset output på ekte innhold?

Syntetiske tilfeller finner bare feil du allerede har tenkt deg. Den nyttige testen er din egen database. Skriptet under renser hvert publiserte innlegg to ganger, én gang med tvunget gammel parser og én uten, og skriver bare ut innleggene som er forskjellige.

<?php
// bin/kses-diff.php
// Run on a trunk build: wp eval-file bin/kses-diff.php > kses-diff.txt
$ids  = get_posts( array(
	'post_type'   => 'any',
	'post_status' => 'publish',
	'numberposts' => -1,
	'fields'      => 'ids',
) );
$diff = 0;

foreach ( $ids as $id ) {
	$raw = get_post_field( 'post_content', $id );

	add_filter( 'wp_kses_force_legacy_parser', '__return_true' );
	$old = wp_kses_post( $raw );
	remove_filter( 'wp_kses_force_legacy_parser', '__return_true' );

	$new = wp_kses_post( $raw );

	if ( $old !== $new ) {
		++$diff;
		printf( "== %d %s\n--- old\n%s\n+++ new\n%s\n", $id, get_permalink( $id ), $old, $new );
	}
}

printf( "%d of %d posts differ\n", $diff, count( $ids ) );

Kjør det på en kopi av produksjonsdatabasen, siden redaktører limer inn rare ting. Les de første tjue diffene for hånd. Regn med en håndfull gjentakende årsaker (selvlukkende tagger, en løs < i en måleangivelse, inline SVG). Retter du én årsak, retter du mange innlegg samtidig.

Utvid nettet med samme mønster: bytt wp_kses_post() med kallet pluginen din gjør med sin egen array, og mat det med opsjonsverdier, widget-tekst og kommentarer, ikke bare innlegg.

#Når bør jeg bruke opt-out for den gamle parseren?

Filteret heter wp_kses_force_legacy_parser. Returnerer det true, gjeninnføres den gamle parseren. Rapporten beskriver det som en måte for nettstedeiere å slippe å kjøre erstatningskoden, og ordet som teller er midlertidig.

<?php
// wp-content/mu-plugins/kses-legacy-parser.php
// Stopgap only. Delete it once your output diff is clean.
add_filter( 'wp_kses_force_legacy_parser', '__return_true' );

To situasjoner rettferdiggjør det. For det første: du fant en regresjon på en kundeside i testvinduet og må holde siden stabil mens du retter koden eller melder feilen. For det andre: en plugin du ikke styrer slutter å virke, og leverandøren har ikke gitt ut en fiks. Legg filteret i en mu-plugin så det er synlig ett sted, og knytt en sak med slettedato til det.

Ikke lever det som permanent standard. Den gamle implementasjonen har kjente problemer som omskrivingen skal fikse, blant annet PCRE-krasj ved store attributtverdier og skriptinnhold som vises som synlig tekst, ifølge PR-beskrivelsen. Et stille opt-out beholder problemene og skjuler migreringen for neste utvikler.

Jeg fant ingen bekreftet dato for når den gamle parseren fjernes. Behandle opt-out som noe som forsvinner, og planlegg etter det.

#Hva er tidsplanen for WordPress 7.2?

Fra innlegget om 7.2-tidsplanen, alt klokken 15:00 UTC:

Rapporten sier 7.2 eller 7.3. Du kan altså ikke regne med noen av dem, men heller ikke utelukke 7.2. En fornuftig plan: kjør diff-skriptet på staging før Beta 1, igjen etter RC1, og meld alt uventet på Trac-saken mens vinduet er åpent. Akkurat slik tilbakemelding ber forfatteren om.

#Hva bør et byrå gjøre denne uken?

1. Søk i koden etter wp_kses(, wp_kses_post(, wp_kses_data( og egne $allowed-arrayer. List opp hvilke som får HTML fra brukere eller redaktører.
2. Sett opp en trunk-staging via en av veiene over og bekreft at filteret finnes.
3. Kjør diff-skriptet mot en kopi av produksjonsinnholdet. Sorter etter årsak, ikke etter innlegg.
4. Skriv om skjøre tester slik at de sjekker struktur, og generer strengfixtures én gang med menneskelig gjennomgang.
5. Sjekk shortcodes og blokker som sender ut inline script, style, SVG eller MathML.
6. Avgjør per kunde om opt-out trengs, dokumenter det og sett en slettedato.

Ligger det flere år med egen rensekode rundt et plugin-økosystem i prosjektet, passer en slik gjennomgang inn i tjenesten vår for skreddersydd WordPress-utvikling.

#Kilder

• Progress Report: wp_kses(), Make Core, 7. oktober 2026. Eksempler, filternavn, utsagnet om 7.2 eller 7.3.
• Tidsplan for 7.2 release party, Make Core, 6. oktober 2026.
• Pull request 13271, KSES: Reimplement with Tag Processor. Funksjonsnavn, filter, liste over endringer i oppførsel. Trac-sakene 66208 og 65984 er nevnt der.
• Trac-sak 66208. Jeg fikk ikke åpnet saken direkte, så opplysningene om den kommer fra PR-siden.

Sist kontrollert 10. oktober 2026. Oppførselen i trunk kan endre seg før utgivelsen.