Slik rydder du opp i WordPress-headeren (fjern RSS, emojis, shortlinks)

Åpne kildekoden til nettstedet ditt (Ctrl+U på Windows, Cmd+Option+U på Mac) og bla ned til <head>-seksjonen. Mellom charset, viewport og temaets CSS ligger det ofte et dusin <link>-, <meta>- og <script>-linjer som ingen i redaksjonen har bedt om: kommentarfeeder, en RSD-discovery-lenke, en blokk med emoji-innstillinger, en shortlink med ?p=123 og en generator-meta-tag med core-versjonen.

Disse restene kommer fra wp_head(). Core kobler callbacks til denne hooken, og remove_action() tar ut igjen det prosjektet ditt ikke trenger. Denne guiden går gjennom alle de typiske restene, en trygg fjerningsliste kontrollert mot wp-includes/default-filters.php i WordPress 7.1.3, det du bør la være, forskjellen mellom emoji-skriptet og emoji-stilene, shortlink kontra canonical, headere på HTTP-nivå og valget mellom en must-use plugin og temaets functions.php.

Målet er mindre støy i HTML-koden og i nettverkspanelet. Å fjerne disse taggene flytter ikke en Lighthouse-score alene, men det gjør dokumentet lesbart igjen og tetter noen små informasjonslekkasjer. Er lastetid målet, kan en Core Web Vitals-revisjon være riktig sted å begynne.

#Hva wp_head skriver ut i WordPress-headeren

wp_head er en action hook. Klassiske temaer kaller wp_head() i header.php, mens blokktemaer får kallet fra cores template canvas. Core og plugins registrerer callbacks på den med prioriteter. Fjerner du en callback, fjerner du bare den callbackens output. Selve hooken kjører fortsatt.

Typiske core-callbacks i front-endens <head> i WordPress 7.1, med prioritet fra default-filters.php:

To rader som eldre kodesnutter fortsatt nevner, er borte fra denne listen. wlwmanifest_link ble avviklet i WordPress 6.3 og er ikke lenger koblet til, og adjacent_posts_rel_link_wp_head har ikke vært brukt av core siden 5.6. Emoji-stilene flyttet fra print_emoji_styles til wp_enqueue_emoji_styles i 6.4. Hver av disse endringene er forklart nedenfor.

Tabellen erstatter gjetting. Før den første remove_action, se kildekoden til en side på staging og sammenlign den med denne listen.

#Slik rydder du WordPress-headeren med remove_action

Funksjonen nedenfor er kjernen i oppryddingen. Den kjører på init, så callbackene du fjerner, er allerede registrert. Prioriteten du sender med, må stemme med den opprinnelige registreringen: feed_links er registrert med 2, feed_links_extra med 3 og emoji-deteksjonsskriptet med 7. remove_action() tar tre parametere (hook, callback, prioritet). Det fjerde argumentet mange kodesnutter sender med, blir ignorert.

/**
 * Rydd opp i head-seksjonen i WordPress.
 * Fjerner utdaterte lenker, generatoren, emoji-ressurser og shortlinks.
 */
function wppoland_cleanup_head() {
	// RSS: hovedfeed- og ekstra feed-lenker ut av head.
	remove_action( 'wp_head', 'feed_links', 2 );
	remove_action( 'wp_head', 'feed_links_extra', 3 );

	// Really Simple Discovery (EditURI-lenke).
	remove_action( 'wp_head', 'rsd_link' );

	// Generator-meta-taggen og generatoren i feeder.
	remove_action( 'wp_head', 'wp_generator' );
	add_filter( 'the_generator', '__return_empty_string' );

	// Emoji: deteksjonsskript, stiler, konvertering i feed og e-post.
	remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
	remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
	remove_action( 'embed_head', 'print_emoji_detection_script' );
	remove_action( 'wp_print_styles', 'print_emoji_styles' );
	remove_action( 'admin_print_styles', 'print_emoji_styles' );
	remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
	remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
	remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );

	// Shortlink i HTML-headen og i HTTP-headeren Link.
	remove_action( 'wp_head', 'wp_shortlink_wp_head', 10 );
	remove_action( 'template_redirect', 'wp_shortlink_header', 11 );
}
add_action( 'init', 'wppoland_cleanup_head' );

Merknader om bruken:

• Hvis nyhetsbrevverktøy eller eksterne aggregatorer leser hovedfeeden din, behold feed_links og slå bare av feedene du ikke trenger, med filtrene som er beskrevet i RSS-delen nedenfor.
• rsd_link kan fjernes på praktisk talt alle offentlige nettsteder. Fjernpublisering over XML-RPC er uansett et eget risikotema.
• the_generator gjelder også feed-XML. En tom streng fjerner versjonsnummeret der også.

#Hvilke remove_action-linjer gjør ingenting på WordPress 7

Oppryddingssnutter kopiert fra forum inneholder linjer som ikke lenger treffer noe i core. De ødelegger ikke nettstedet, fordi remove_action() bare returnerer false når callbacken ikke er registrert. Men de lurer neste utvikler til å tro at linjen gjør en jobb.

• remove_action( 'wp_head', 'wlwmanifest_link' ): manifest-lenken for Windows Live Writer ble avviklet i WordPress 6.3. Funksjonen gir nå bare en avviklingsmelding, og core kobler den ikke lenger til. Behold linjen bare hvis du fortsatt støtter nettsteder under 6.3.
• remove_action( 'wp_head', 'adjacent_posts_rel_link_wp_head', 10 ): funksjonen finnes fortsatt, men dens egen docblock sier at den ikke har vært brukt i core siden 5.6. Ser du rel="prev" og rel="next" på enkeltinnlegg, er det et tema eller en plugin som legger dem til.
• start_post_rel_link, index_rel_link, parent_post_rel_link: avviklet i WordPress 3.3. Ingen moderne installasjon kobler dem til.
• remove_filter( 'wp_resource_hints', 'wp_dependencies_emoji_styles' ): det finnes ingen slik funksjon i core. DNS-prefetch til s.w.org, som denne linjen var ment å stoppe, ble fjernet fra wp_resource_hints() i WordPress 6.1.
• add_filter( 'rest_enabled', '__return_false' ): filteret har vært avviklet siden 4.7. Core viser til rest_authentication_errors i stedet, og REST API kan ikke lenger slås av på denne måten.

Når du sletter disse linjene, blir filen kortere og gjennomgangen enklere. Kildekoden til default-filters.php i 7.1.3 er referansen du sammenligner med.

#Hvilke wp_head-oppføringer du ikke bør fjerne

Oppryddingen slutter der core og editoren fortsatt må fungere. Fire grupper hører hjemme på listen over det du beholder.

#REST API-discovery

rest_output_link_wp_head skriver en lenke til /wp-json/, og rest_output_link_header sender den samme lenken som en HTTP-header. Blokkeditoren, nettstedseditoren, mange skjema-plugins og headless WordPress-front ends er avhengige av REST API. Fjerner du discovery-lenken, går ingenting i stykker med en gang, men klientene finner endepunktet dårligere, og du løser et problem som ikke finnes. Vil du sikre REST API, begrenser du autentisering og ruter i stedet for å skjule lenken.

#CSS fra tema og plugins

Stilark kommer via wp_enqueue_style og skrives ut av wp_print_styles med prioritet 8. Tømmer du wp_head helt eller dreper alle stiler, ødelegger du layouten. Oppryddingen er rettet mot utdaterte core-callbacks, ikke mot wp_enqueue_*. Det samme gjelder skript som temaet og plugins legger i kø: avregistrer dem bare når du kjenner avhengigheten.

#Canonical, Open Graph og meta-tagger

rel_canonical blir stående. Uten canonical risikerer du signaler om duplisert innhold på varianter med query strings, paginering eller sporingsparametere. Open Graph og sosiale tagger fra SEO-plugins lar du være, så lenge pluginen setter dem riktig.

#Tittel, robots, ikoner og egendefinert CSS

_wp_render_title_tag og wp_robots kjører med prioritet 1 og skriver ut <title> og robots-meta. wp_site_icon skriver ut favicon på 99, og wp_custom_css_cb skriver ut tilleggs-CSS fra Customizer på 101. Ingen av dem er overflødige.

Kort sagt: ekstra feeder, RSD, generatoren, emoji-ressurser og shortlinks er kandidater. REST, CSS, canonical, tittel, robots og ikoner er infrastruktur.

#Slik slår du av emojis i WordPress uten plugin

Mange kodesnutter fjerner bare deteksjonsskriptet og glemmer stilene, eller omvendt. Core holder de to sporene adskilt, og begge har endret seg i nyere versjoner.

print_emoji_detection_script er koblet til wp_head med prioritet 7 og til admin_print_scripts. Siden WordPress 6.9 skrives det ikke lenger ut inline i head. Det planlegger _print_emoji_detection_script på wp_print_footer_scripts, som skriver ut en JSON-blokk med innstillinger (id="wp-emoji-settings") og emoji-loaderen som et type="module"-skript før </body>. Loaderen tester om nettleseren tegner emoji selv, og lagrer resultatet i sessionStorage. Først når testen feiler, legger den til wp-emoji-release.min.js, som bytter ut emoji med bilder fra s.w.org. I en oppdatert nettleser er kostnaden de inline innstillingene og loader-koden (den uminifiserte loader-kildekoden er på rundt 13 KB), ikke nedlasting av en hel polyfill.

Stilene tok en annen vei. print_emoji_styles ble avviklet i 6.4 og erstattet av wp_enqueue_emoji_styles, som legger en inline-stil i kø under handle wp-emoji-styles. Av hensyn til bakoverkompatibilitet kobler core fortsatt print_emoji_styles til wp_print_styles, og den nye funksjonen returnerer tidlig hvis den hooken er fjernet. Derfor virker remove_action( 'wp_print_styles', 'print_emoji_styles' ) fortsatt på 7.1. En likeverdig og mer direkte linje er remove_action( 'wp_enqueue_scripts', 'wp_enqueue_emoji_styles' ).

Filtrene wp_staticize_emoji (på the_content_feed og comment_text_rss) og wp_staticize_emoji_for_email (på wp_mail) gjør om emoji til bilder i feeder og e-post. På redaksjonelle nettsteder uten emoji-tunge nyhetsbrev kan du fjerne dem også. Hvis varslings-e-postene dine er avhengige av emoji, beholder du e-postfilteret og rydder bare front end.

Fjern også admin-hookene, ellers blir emoji-ressursene liggende i dashbordet. En opprydding bare i front end sparer bytes for besøkende, ikke for redaktører.

#Slik hoster du WordPress-emojibilder selv

Fjerning er ett alternativ. Vil du beholde emoji-støtte for gamle nettlesere, men unngå forespørsler til et tredjepartsdomene, peker du basis-URL-ene for bildene mot din egen server. Core har to filtre for dette: emoji_url for PNG-settet og emoji_svg_url for SVG-settet. I WordPress 7.1 er standardverdiene https://s.w.org/images/core/emoji/17.0.2/72x72/ og https://s.w.org/images/core/emoji/17.0.2/svg/.

add_filter( 'emoji_url', function () {
	return content_url( '/emoji/17.0.2/72x72/' );
} );
add_filter( 'emoji_svg_url', function () {
	return content_url( '/emoji/17.0.2/svg/' );
} );

Versjonsdelen i stien endres når core oppdaterer emoji-settet sitt, så en egenhostet kopi må fornyes ved hovedversjoner. wp_staticize_emoji bruker det samme emoji_url-filteret for feeder, så én endring dekker begge stedene.

#Slik fjerner du WordPress-shortlinken, men beholder canonical

wp_shortlink_wp_head skriver <link rel="shortlink" href="https://example.com/?p=42" />. I tillegg kjører wp_shortlink_header på template_redirect med prioritet 11 og sender en HTTP-header Link: <...>; rel=shortlink. Begge er en bekvemmelighet for gamle delingsverktøy. Søkemotorer følger canonical, ikke shortlinken.

rel_canonical peker på den kanoniske permalenken. Shortlinken og canonical motsier ikke hverandre direkte, men to URL-signaler for samme ressurs gir støy. Shortlink ut, canonical inn: en tydelig preferanse for den pene permalenken.

Hvis en redirect-plugin eller et CDN vedlikeholder korte URL-er, sjekker du response headers én gang etter oppryddingen i DevTools (Network, deretter dokumentforespørselen, deretter Response Headers). Link-headeren med rel=shortlink skal være borte. Canonical i HTML-koden er fortsatt synlig.

#Slik fjerner du X-Pingback og andre HTTP-headere i WordPress

<head> er bare halvparten av det WordPress legger til. Tre response headers kommer fra core.

• X-Pingback: siden WordPress 4.4 legger WP::send_headers() den bare til på enkeltvisninger av innlegg som tar imot pings. Den peker på xmlrpc.php.
• Link: <...>; rel=shortlink: sendes av wp_shortlink_header og fjernes med shortlink-koden ovenfor.
• Link: <...>; rel="https://api.w.org/": sendes av rest_output_link_header. Behold den av de samme grunnene som REST-lenken i HTML-koden.

Alle headere som WP::send_headers() samler, går gjennom filteret wp_headers (tilgjengelig siden 2.8), så X-Pingback kan fjernes der:

add_filter( 'wp_headers', function ( $headers ) {
	unset( $headers['X-Pingback'] );
	return $headers;
} );

Er pings stengt på et innlegg, sendes headeren ikke i det hele tatt. Core kobler ingen <link rel="pingback">-tag til wp_head. Ser du en slik i kildekoden, kommer den fra temaets header.php.

#Bør header-oppryddingen ligge i en mu-plugin eller i functions.php

Begge steder fungerer. Det driftsmessige spørsmålet er om koden overlever.

functions.php i et child theme er raskt: SFTP eller temaeditoren, lagre, ferdig. Ulempen er at et temabytte eller et nytt child theme sletter logikken. Byråer som bytter tema hos kunder, mister oppryddingen uten at noen merker det.

En must-use plugin i wp-content/mu-plugins/wppoland-clean-head.php lastes automatisk, uten noe aktiveringsklikk. Et temabytte endrer ingenting. Deploy via Git eller rsync er fortsatt enkelt, fordi filen ligger utenfor temaet. Opprett mappen én gang og versjonér filen sammen med resten av prosjektet.

Anbefaling for produksjonsnettsteder: en mu-plugin. Til enkeltstående eksperimenter på staging er et child theme greit, så lenge du flytter funksjonen senere. Unngå å redigere foreldretemaet, for oppdateringer overskriver det.

Et skjelett for mu-pluginen:

<?php
/**
 * Plugin Name: WPPoland Clean Head
 * Description: Removes legacy wp_head artefacts.
 * Author: wppoland.com
 * Version: 1.0.0
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

require_once __DIR__ . '/includes/cleanup-head.php';

Selve funksjonen wppoland_cleanup_head ligger da i includes/cleanup-head.php. Oppstartsfilen holdes kort og testbar. Legg en kommentar ved siden av hver fjerning som sier hvorfor den er der:

// Fjern emoji-deteksjon: alle støttede nettlesere viser emoji selv.
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );

#Rydd wp_head bare i front end eller for headless

Noen fjerninger hører bare hjemme i bestemte sammenhenger. Eksemplet nedenfor beholder REST-lenken når en egen konstant markerer nettstedet som headless.

function wppoland_conditional_head_cleanup() {
	// WPPOLAND_HEADLESS er en prosjektkonstant satt i wp-config.php.
	if ( ! defined( 'WPPOLAND_HEADLESS' ) || ! WPPOLAND_HEADLESS ) {
		remove_action( 'wp_head', 'rest_output_link_wp_head', 10 );
	}
}
add_action( 'init', 'wppoland_conditional_head_cleanup' );

#Gjør hver del av oppryddingen valgbar

På nettsteder der integrasjonene varierer mellom miljøer, pakker du hver gruppe fjerninger inn i en konstant fra wp-config.php. En gruppe kjører med mindre konstanten er definert som false:

/**
 * Konfigurer i wp-config.php, for eksempel:
 * define( 'WPPCLEANUP_FEED_LINKS', false );
 */
function wppoland_advanced_cleanup_head() {
	if ( ! defined( 'WPPCLEANUP_FEED_LINKS' ) || WPPCLEANUP_FEED_LINKS ) {
		remove_action( 'wp_head', 'feed_links', 2 );
		remove_action( 'wp_head', 'feed_links_extra', 3 );
	}
	if ( ! defined( 'WPPCLEANUP_RSD' ) || WPPCLEANUP_RSD ) {
		remove_action( 'wp_head', 'rsd_link' );
	}
	if ( ! defined( 'WPPCLEANUP_GENERATOR' ) || WPPCLEANUP_GENERATOR ) {
		remove_action( 'wp_head', 'wp_generator' );
		add_filter( 'the_generator', '__return_empty_string' );
	}
	if ( ! defined( 'WPPCLEANUP_EMOJIS' ) || WPPCLEANUP_EMOJIS ) {
		remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
		remove_action( 'wp_print_styles', 'print_emoji_styles' );
		remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
	}
	if ( ! defined( 'WPPCLEANUP_SHORTLINKS' ) || WPPCLEANUP_SHORTLINKS ) {
		remove_action( 'wp_head', 'wp_shortlink_wp_head', 10 );
		remove_action( 'template_redirect', 'wp_shortlink_header', 11 );
	}
}
add_action( 'init', 'wppoland_advanced_cleanup_head' );

Da kan staging beholde feedene mens produksjon fjerner dem, uten to versjoner av plugin-filen.

#Slik sjekker du den ryddede headeren i kildekoden

Etter deploy åpner du en offentlig URL i et privat vindu og sjekker tre lag.

1. Kildekoden (Ctrl+U): søk etter EditURI, emoji, shortlink, generator og alternate. Siden WordPress 6.9 ligger emoji-innstillingene før </body>, så søk i hele dokumentet, ikke bare i head. De utdaterte treffene skal mangle. Canonical, stilark og nødvendige plugin-tagger blir stående.
2. Network i DevTools: filtrer på s.w.org og wp-emoji. Etter emoji-oppryddingen skal ingen forespørsel dukke opp. Sammenlign forespørslene fra head før og etter endringen på samme URL.
3. Response headers: ingen Link-header med rel=shortlink, og ingen X-Pingback hvis du fjernet den. Noen sikkerhetsplugins setter egne headere, og de påvirkes ikke.

Sjekkliste for godkjenningsrunden:

• Test staging og produksjon hver for seg, og tøm objektcachen og sidecachen.
• Sjekk et enkeltinnlegg, en arkivside og forsiden (ekstra feeder oppfører seg forskjellig på hver av dem).
• Sjekk en WooCommerce-produktside for seg: plugins legger ofte til tagger der som ikke kommer fra denne kodesnutten.
• Åpne blokkeditoren én gang og lagre et innlegg: REST API må svare.
• Kjør gjerne PageSpeed Insights eller WebPageTest og sammenlign HTML-bytes og tredjepartsdomener. Forvent mindre støy, ikke en ny score.

Dukker det fortsatt opp et emoji-skript etter oppryddingen, sjekker du hvilken plugin som laster det. remove_action på core-hooks stopper ikke en plugin som legger sin egen kopi i kø, så les kildekoden i stedet for å stole på kodesnutten.

#Slik fjerner du RSS-feed-lenker fra WordPress-headen

RSS er ikke dødt. Podcaster, import til nyhetsbrev og overvåkingsverktøy leser fortsatt /feed/. Kommentarfeeder og feeder per taksonomi gir derimot sjelden trafikk og fyller opp head på arkivsider.

Pragmatiske nivåer:

1. Bare kommentarfeeder (feed_links_show_comments_feed returnerer false). Hovedfeeden blir stående.
2. Ekstra feeder av (fjern feed_links_extra). Kategorier og tagger mister autodiscovery i head, men feed-URL-ene fungerer fortsatt for alle som kjenner dem.
3. Alle feed-lenker ut av head (feed_links og feed_links_extra). Endepunktene er fortsatt tilgjengelige, det er bare autodiscovery som forsvinner.

Nivå 1 eller 2 holder for de fleste bedriftsnettsteder. Nivå 3 bare hvis ingen abonnerer på feeden og du vil ha det slik med vilje.

feed_links() skriver ingenting ut med mindre temaet erklærer add_theme_support( 'automatic-feed-links' ). Viser et nettsted ingen feed-lenker i det hele tatt, sjekker du temaet før du legger til kode for å fjerne dem.

#Behold hovedfeeden og fjern bare noen ekstra feeder

Å fjerne feed_links_extra er alt eller ingenting. Core har finere brytere. feed_links_show_posts_feed og feed_links_show_comments_feed finnes siden WordPress 4.4. WordPress 6.1 la til ett filter per type ekstra feed: feed_links_extra_show_post_comments_feed, feed_links_extra_show_post_type_archive_feed, feed_links_extra_show_category_feed, feed_links_extra_show_tag_feed, feed_links_extra_show_tax_feed, feed_links_extra_show_author_feed og feed_links_extra_show_search_feed. Siden 6.7 filtrerer feed_links_args skilletegnet og titlene på feed-lenkene.

// Behold innleggsfeeden og kategorifeedene, fjern resten av de ekstra feedene.
add_filter( 'feed_links_show_comments_feed', '__return_false' );
add_filter( 'feed_links_extra_show_tag_feed', '__return_false' );
add_filter( 'feed_links_extra_show_author_feed', '__return_false' );
add_filter( 'feed_links_extra_show_search_feed', '__return_false' );

feed_links_extra_show_post_comments_feed tar verdien av feed_links_show_comments_feed som standard, så når du slår av den globale kommentarfeeden, forsvinner også lenken til kommentarfeeden per innlegg, med mindre du returnerer true for den separat. Referanseoppføringen for feed_links_extra_show_category_feed lister opp parameterne.

#Slik skjuler du WordPress-versjonen i kildekoden

wp_generator skriver core-versjonen inn i HTML-koden. Det er ikke et sikkerhetsbrudd, men skannere prioriterer versjoner med kjente CVE-er. Fjern meta-taggen og tøm the_generator. Versjonen lekker også andre steder:

1. Query strings på ressurser: core-stiler og -skript har ?ver= med core-versjonen, for eksempel på wp-emoji-release.min.js.
2. readme.html: filen ligger i WordPress-roten (/readme.html), ikke i wp-content, og gjenopprettes ved hver core-oppdatering. Blokker den på webserveren hvis det betyr noe for deg.
3. Plugins: mange plugins skriver ut sin egen versjon i kommentarer eller ressurs-URL-er.

Header-opprydding alene er ikke et sikkerhetsprogram, den fjerner ett signal. Det er oppdatering av core og plugins som tetter CVE-ene en skanner leter etter.

#Fjern ver-parameteren fra CSS- og JS-URL-er

Filtrene style_loader_src og script_loader_src får hver URL til ressurser i kø, så argumentet ver kan fjernes der:

function wppoland_remove_version_from_assets( $src ) {
	if ( $src && strpos( $src, 'ver=' ) !== false ) {
		$src = remove_query_arg( 'ver', $src );
	}
	return $src;
}
add_filter( 'style_loader_src', 'wppoland_remove_version_from_assets', 9999 );
add_filter( 'script_loader_src', 'wppoland_remove_version_from_assets', 9999 );

Parameteren tvinger også nettleser- og CDN-cacher til å hente på nytt etter en oppdatering. Uten den kan en endret fil bli servert fra cache under samme URL, så behold dette filteret bare når deployen eller CDN-et ditt håndterer cache-invalidering på en annen måte.

#Gir rel prev og next fortsatt SEO-fordeler

rel="prev" og rel="next" mellom enkeltinnlegg hjalp en gang med serier. For enkeltinnlegg har core ikke skrevet dem ut siden 5.6, så på et oppdatert nettsted kommer de fra temaet eller en SEO-plugin. For moderne crawlere er effekten ubetydelig. På magasinnettsteder med lange artikkelkjeder kan du beholde dem. På tjeneste- og butikknettsteder fjerner du dem i pluginen som legger dem til. Interne lenker i innholdet og fornuftige sitemaps veier tyngre.

#Header-opprydding med WP Rocket og sidecache

Autoptimize, FlyingPress, WP Rocket og lignende verktøy endrer rekkefølgen på og kombinasjonen av ressurser. remove_action-snutten din bør virke før HTML-cachen, altså i PHP, ikke som en senere strengerstatning i optimaliseringsverktøyet. Hvis et optimaliseringsverktøy legger emoji-skript inn igjen eller tillater tredjepartsdomener, sjekker du innstillingene i det.

En objektcache lagrer ikke output fra wp_head på en måte som gjør remove_action virkningsløs. En sidecache gjør det: gamle HTML-kopier beholder de ekstra taggene til cachen er tømt. Å tømme cachen etter deploy er obligatorisk.

#Hvorfor remove_action i wp_head ikke virker

Feil prioritet: remove_action( 'wp_head', 'feed_links' ) uten prioritet 2 treffer ikke callbacken. Core registrerer med en prioritet, og fjerningen din må ha det samme tallet.

Hooken kjører for tidlig: kjører du remove_action på toppnivå i en plugin-fil, er noen callbacks ennå ikke registrert. init eller wp_loaded er tryggere enn kode på toppnivå.

Foreldretemaet er redigert: oppdateringen kommer, og oppryddingen er borte. Bruk et child theme eller en mu-plugin.

REST fjernet via kopierte lister: editoren slutter å virke, eller headless-apper finner ikke /wp-json/. Lister fra forumtråder fra 2014 er risikable uten kontroll. Sammenlign dem med tabellen i denne artikkelen.

Utdaterte callback-navn: linjen treffer en funksjon som core ikke lenger kobler til, slik det står i delen om linjer som ikke gjør noe. Taggen du prøver å fjerne, kommer da fra et annet sted.

Bare front end er testet: admin beholder emoji-ressursene. Besøkende merker det ikke, men redaktører på trege forbindelser gjør det. Ta med admin-hookene hvis teamet er enig.

#Oppsummering

wp_head samler output fra core, tema og plugins. Utdaterte rester (RSD, ekstra feeder, generatoren, emoji-ressurser, shortlinken) kan fjernes med remove_action og noen få filtre. REST-discovery, CSS og JS i kø, tittel, robots, ikoner og canonical blir stående. Behandle emoji-skriptet og emoji-stilene hver for seg, og vit at skriptet skrives ut i footeren siden 6.9. Fjern shortlinken i HTML-koden og i HTTP-headeren, og behold canonical. Dropp linjene for wlwmanifest_link og lenkene til tilstøtende innlegg på nåværende versjoner. Logikken hører hjemme i en mu-plugin, ikke i foreldretemaet. Kontrollen skjer gjennom søk i kildekoden, nettverkspanelet og response headers, pluss tømming av cachen.

Referanser fra Developer Handbook: wp_head, remove_action, feed_links, feed_links_extra, print_emoji_detection_script, wp_enqueue_emoji_styles, wp_shortlink_wp_head, wp_shortlink_header, wp_generator, rsd_link, wlwmanifest_link, rel_canonical, wp_headers.

Trenger du hjelp til å ta dette i bruk på staging og produksjon? En WordPress-spesialist går gjennom wp_head sammen med resten av den kritiske render-stien.