TimThumb er død! Hvordan håndtere bilder i WordPress (guide 2026)

Hvis du er en WordPress-veteran, husker du sikkert TimThumb. Det var et lite PHP-skript som fantes i nesten hvert eneste “premium theme” rundt 2010. Det gjorde det enkelt å beskjære og skalere bilder fortløpende.

I august 2011 ble det oppdaget en kritisk Zero-Day-sårbarhet i det, som lot angripere laste opp og kjøre PHP-kode på servere med skriptet. Det markerte slutten på “enkelt skript”-æraen.

I dag, i 2026, har WordPress en kraftig motor for mediehåndtering. Hvis du fortsatt ser timthumb.php i temaet ditt, slett det umiddelbart. Denne guiden viser hvordan du gjør det profesjonelt.

#Hvorfor TimThumb var usikkert

TimThumb jobbet fortløpende: det tok et bilde fra en URL, behandlet det og lagret det i en cache. Problemene var mange og alvorlige:

1. Sikkerhet: Det tillot Remote Code Execution (RCE). Mark Maunder gjorde sårbarheten kjent 1. august 2011, etter at hans egen blogg ble angrepet. Skriptet sammenlignet vertsnavnet bare delvis med hvitelisten over domener, så en angriper kunne få det til å laste ned en PHP-fil til cache-mappen og deretter kjøre filen med en direkte forespørsel. Det ga full tilgang til nettstedet og potensielt til hele serveren. Maunder anbefalte også å søke gjennom WordPress-mappen etter funksjonen base64_decode og lange kodede strenger, det typiske sporet etter injisert kode.

2. Ytelse: Det belastet PHP-serveren ved hver nye bildeforespørsel. Hver gang en besøkende åpnet en side med TimThumb-bilder, måtte serveren kjøre PHP, sjekke cachen, behandle bildet hvis det manglet, og sende det. På nettsteder med mye trafikk betydde det mange ekstra PHP-kjøringer som brukte CPU og minne. Bildebehandling er ressurskrevende, og å gjøre det live gjennom PHP var svært lite effektivt sammenlignet med å levere ferdige statiske filer.

3. Ingen integrasjon: Det så ikke WordPress sitt mediebibliotek. TimThumb jobbet helt utenfor WordPress-økosystemet. Det brukte verken hooks eller kjernefunksjoner, lagret ikke behandlede bilder i databasen og fikk ingen nytte av forbedringene WordPress gjorde i mediehåndteringen. TimThumb-bilder dukket ikke opp i mediebiblioteket, kunne ikke administreres fra kontrollpanelet og hadde verken alternativ tekst, beskrivelser eller bildekreditering.

#Tidslinje for sårbarhetene i TimThumb

Historien om skriptet passer i fire datoer, og alle er dokumentert i primærkilder:

Identifikatoren CVE-2011-4106 ble publisert i NVD senere, i oktober 2013, men den offisielle beskrivelsen sier at feilen ble utnyttet i august 2011. Maunder anslo omfanget indirekte den gangen: Google ga over 39 millioner treff på navnet til skriptet. Hans grunnleggende diagnose gjelder fortsatt for enhver bildeskalerer bygget inn i et tema:

“timthumb.php er usikkert av natur, fordi det er avhengig av å kunne skrive filer til en mappe som de besøkende på nettstedet ditt har tilgang til.”

Mark Maunder, 1. august 2011, egen oversettelse

Oppdateringen fra 2011 tettet akkurat det hullet, men endret ikke konstruksjonen. Tre år senere kom WebShot-sårbarheten, som sendte skall-metategn fra parameteren src videre til en systemkommando. Gillbanks skrev i kunngjøringen fra 2014 at han knapt hadde rørt koden på flere år, og at den som fortsatt bruker TimThumb, gjør det på egen risiko. Et tema som fortsatt inneholder filen, hviler altså på kode som ikke har vært vedlikeholdt på over et tiår.

#Hvordan bruke native add_image_size i WordPress

WordPress har hatt funksjonen add_image_size() i årevis. Den lar deg definere formater som systemet genererer automatisk ved opplasting. Det er den mest effektive og sikreste måten å håndtere de ulike bildestørrelsene temaet ditt trenger.

#Registrere bildestørrelser i functions.php

function wppoland_setup_theme() {
    // Aktiver støtte for fremhevede bilder
    add_theme_support( 'post-thumbnails' );

    // Standardstørrelser (myk beskjæring: beholder proporsjonene)
    add_image_size( 'blog-list', 800, 400 );

    // Hard beskjæring (kutter overskudd)
    // WordPress beskjærer nøyaktig midten av bildet
    add_image_size( 'team-member', 300, 300, true );

    // Beskjæring med posisjonering (f.eks. fra toppen, fra venstre)
    add_image_size( 'hero-banner', 1920, 600, ['center', 'top'] );
}
add_action( 'after_setup_theme', 'wppoland_setup_theme' );

Når du definerer egne størrelser med add_image_size(), genererer WordPress alle variantene ved opplasting. Det tunge arbeidet skjer én gang, ved opplasting, og ikke ved hver sidevisning. Derfor er denne tilnærmingen langt raskere enn enhver skalering i farten.

Det lønner seg å kjenne de tre beskjæringsmodusene. Myk beskjæring (soft crop) er standard når du ikke oppgir beskjæringsparameteren. WordPress skalerer bildet slik at det passer innenfor målene, med de opprinnelige proporsjonene, så én av sidene kan bli mindre enn oppgitt. Hard beskjæring (hard crop), som slås på med true som tredje parameter, tvinger frem nøyaktig de oppgitte målene og kutter kantene. Posisjonert beskjæring bestemmer hvilket punkt i bildet beskjæringen tar utgangspunkt i, noe som hjelper på bannere der hovedmotivet som regel ligger øverst.

#Vise bildestørrelsen i malfilen (single.php)

if ( has_post_thumbnail() ) {
    the_post_thumbnail( 'hero-banner', ['class' => 'img-fluid'] );
}

Hvis du allerede har ID-en til vedlegget, gjør wp_get_attachment_image() det samme utenfor løkken:

echo wp_get_attachment_image( $attachment_id, 'blog-list' );

Fordel: Bildene genereres én gang (ved opplasting). De leveres som ferdige statiske filer. Null PHP-belastning ved visning. Statiske filer er også enkle å cache både på serveren og i CDN.

#Hvordan regenerere miniatyrbilder med WP-CLI

Når du legger til nye bildestørrelser i et eksisterende tema, mangler de allerede opplastede bildene de nye variantene. Miniatyrbildene må regenereres, og det mest effektive er WP-CLI:

wp media regenerate --yes

For store biblioteker gir dokumentasjonen for wp media regenerate valg som avgrenser jobben: --only-missing lager bare manglende størrelser, --image_size=<navn> regenererer én størrelse, og --skip-delete beholder gamle miniatyrbilder hvis noen lenker til dem utenfra:

wp media regenerate --only-missing --yes
wp media regenerate --image_size=hero-banner --yes

#Hvilke bildestørrelser WordPress lager som standard

Før du registrerer egne størrelser, er det lurt å vite hvor mange filer kjernen allerede lager ved hver opplasting. Standardverdiene for innstillingene i WordPress-skjemaet er:

De to siste legges til av den interne funksjonen _wp_add_additional_image_sizes(), og en kommentar i kjernekoden fraråder å endre dem fordi navnet speiler målene. Hver add_image_size() i temaet ditt kommer i tillegg, så én opplasting gir fort ti filer eller flere.

WordPress 5.3 innførte også en terskel for store bilder. Hvis originalen er over 2560 piksler i bredde eller høyde, lager kjernen en nedskalert kopi med suffikset -scaled og bruker den som størrelsen “full”; originalen beholdes, og navnet lagres i metadataene til vedlegget (original_image). Verdien endres eller slås av med filteret big_image_size_threshold:

// Hev terskelen til 4000 px
add_filter( 'big_image_size_threshold', fn() => 4000 );

// Slå den helt av
add_filter( 'big_image_size_threshold', '__return_false' );

For srcset finnes en tilsvarende grense: filteret max_srcset_image_width utelater i dagens kjernekode kandidater som er bredere enn 2048 piksler. Trenger et tema større kandidater for skjermer med høy pikseltetthet, er det dette filteret som skal justeres, ikke et skaleringsskript.

#Hvordan skalere WordPress-bilder via CDN

Native størrelser har en ulempe: Hvis du bytter tema, må du regenerere miniatyrbildene (f.eks. med utvidelsen Regenerate Thumbnails), noe som tar evigheter med et bibliotek på 100 GB.

I 2026 er serverne raske og CDN-ene billige. Vi bruker ofte en hybrid tilnærming eller eksterne tjenester som behandler bilder ved kanten av nettet, nær brukeren.

#Skalere bilder med URL-parametre i CDN

I stedet for å belaste PHP-serveren bruker du URL-parametre, og CDN-et tar seg av behandlingen. Den nøyaktige syntaksen avhenger av leverandøren; skjematisk:

<img src="https://dittnettsted.no/wp-content/uploads/bilde.jpg?width=400&height=300&format=avif">

Originalen ligger på serveren din, mens CDN-et skalerer den, konverterer formatet og leverer den optimaliserte versjonen. Du trenger ikke et PHP-skript på serveren din for dette.

Fordelene er tydelige. For det første trenger du ikke regenerere miniatyrbilder for nye størrelser, fordi CDN-et lager hvilken som helst størrelse ved behov. For det andre skjer formatkonverteringen automatisk: CDN-et kan levere AVIF til nettlesere som støtter det, og WebP som reserve. For det tredje havner hver transformasjon i kant-cachen, så kostnaden betales bare én gang.

#Cloudflare Image Resizing

Hos Cloudflare ber du om transformasjonen direkte i URL-en, i formatet https://<sone>/cdn-cgi/image/<valg>/<originalbilde>, for eksempel /cdn-cgi/image/width=400,format=auto/wp-content/uploads/2026/10/foto.jpg. Ifølge Cloudflare-dokumentasjonen fungerer dette i soner med transformasjoner slått på, og format=auto leverer det mest effektive formatet nettleseren støtter. Det trengs ingen Worker til dette; Workers er nyttige når du vil ha egne regler, for eksempel automatisk omskriving av URL-ene under /wp-content/uploads/.

#Hvordan sette srcset og sizes for responsive bilder

WordPress genererer automatisk srcset-attributtet for bildene dine, slik at nettleseren kan velge riktig størrelse for enheten (mobil vs. 4K-skjerm). Funksjonen kom i WordPress 4.4 og har blitt videreutviklet siden.

<!-- WordPress genererer dette automatisk: -->
<img src="bilde-800x400.jpg"
     srcset="bilde-300x150.jpg 300w,
             bilde-800x400.jpg 800w,
             bilde-1024x512.jpg 1024w"
     sizes="(max-width: 600px) 100vw, 800px">

Attributtet srcset lister alle tilgjengelige varianter av bildet med bredden i piksler. Nettleseren kombinerer denne informasjonen med attributtet sizes og velger filen som passer best til skjermstørrelse, pikseltetthet og bredden på viewporten.

Ifølge utviklernotatet for WordPress 4.4 tilsvarer standardverdien for sizes uttrykket (max-width: {bredde}px) 100vw, {bredde}px, og hvis HTML-en i innholdet allerede har srcset eller sizes, lar WordPress dem være. Din jobb som utvikler er å definere sizes riktig med filteret wp_calculate_image_sizes. Med det beskriver du hvordan bildet vises ved bruddpunktene i layouten, slik at nettleseren kan velge best mulig:

add_filter( 'wp_calculate_image_sizes', function( $sizes, $size, $image_src, $image_meta ) {
    // For bilder i artikler
    if ( is_singular() ) {
        return '(max-width: 768px) 100vw, (max-width: 1200px) 75vw, 800px';
    }
    return $sizes;
}, 10, 4 );

#Hvilke lasteattributter WordPress legger til bilder

Siden WordPress 5.5 legges attributtet loading="lazy" til bilder automatisk. Bilder utenfor den første visningen lastes ikke ned før brukeren ruller dit, noe som gjør den første sidelastingen raskere.

WordPress 6.1 la til attributtet decoding="async" i wp_get_attachment_image(), slik at nettleseren kan dekode bilder uten å blokkere gjengivelsen. Siden WordPress 6.3 avgjør én funksjon alle tre attributtene, wp_get_loading_optimization_attributes(). Den gir det første store nok bildet fetchpriority="high" (standardterskelen er 50 000 piksler i areal, filteret wp_min_priority_img_pixels) og gir det ikke loading="lazy", fordi ett element aldri bør ha begge deler. Kommer LCP-bildet ditt fra en blokk eller en CSS-bakgrunn som funksjonen ikke ser, må du merke det selv.

#Hvordan bruke WebP og AVIF i WordPress

I 2026 er JPG og PNG relikvier for fotografier. WordPress støtter WebP nativt (siden versjon 5.8) og AVIF (siden versjon 6.5), så lenge bildebiblioteket på serveren (Imagick eller GD) støtter formatet. Under Verktøy > Nettstedshelse, fanen Info, delen for mediehåndtering, ser du hvilke formater serveren din støtter.

Du trenger ingen utvidelser. Bare last opp en AVIF-fil, så håndterer WordPress den. Eller bruk utvidelsen Modern Image Formats fra ytelsesteamet i WordPress, som lager mellomstørrelser i AVIF av opplastede JPEG-filer (eller i WebP hvis serveren ikke støtter AVIF) og beholder originalen.

#Hvor mye WebP og AVIF sparer sammenlignet med JPG

De offisielle tallene fra kjernen er:

• WebP: i snitt rundt 30% mindre enn tilsvarende JPEG eller PNG, ifølge notatet for WordPress 5.8.
• AVIF: opptil 50% mindre enn JPEG med samme kvalitet, ifølge notatet for WordPress 6.5.

AVIF komprimerer som regel bedre enn WebP, særlig fotografier med myke overganger. WebP har litt bredere støtte i eldre nettlesere, så en vanlig strategi er AVIF som førstevalg og WebP som reserve.

#Hvordan bruke picture-elementet med AVIF og WebP

For full kontroll over hvilke formater som leveres, kan du bruke HTML-elementet <picture>:

<picture>
    <source srcset="bilde.avif" type="image/avif">
    <source srcset="bilde.webp" type="image/webp">
    <img src="bilde.jpg" alt="Beskrivelse av bildet">
</picture>

I de fleste tilfeller er det likevel mer praktisk og enklere å vedlikeholde om WordPress og CDN-et tar seg av formatforhandlingen.

#Hvordan endre kvalitet og utdataformat i WordPress

Hver mellomstørrelse WordPress lager, går gjennom klassen WP_Image_Editor, og to filtre styrer resultatet.

Det første gjelder kvaliteten. I dagens kildekode for klassen er standardkvaliteten 82 for JPEG og 86 for WebP; andre formater får 82. Filteret wp_editor_set_quality får kvaliteten og MIME-typen, så du kan justere hvert format for seg. For JPEG bruker kjernen deretter det eldre filteret jpeg_quality, som har siste ord hvis en utvidelse bruker det:

add_filter( 'wp_editor_set_quality', function( $quality, $mime_type ) {
    if ( 'image/avif' === $mime_type ) {
        return 70;
    }
    return $quality;
}, 10, 2 );

Det andre gjelder utdataformatet. Filteret image_editor_output_format knytter hver MIME-type på inngangen til formatet mellomstørrelsene lagres i. Notatet for WordPress 6.5 bruker akkurat dette eksempelet for at opplastede JPEG-filer skal gi mellomstørrelser i AVIF:

add_filter( 'image_editor_output_format', function( $formats ) {
    $formats['image/jpeg'] = 'image/avif';
    return $formats;
} );

Siden WordPress 6.7 bruker kjernen samme mekanisme som standard for HEIC-bilder fra iPhone: Hvis serveren kan lese dem, konverteres de til JPEG ved opplasting. Formatendringen gjelder bare nye eller regenererte bilder, så etter at filteret er slått på, må du kjøre wp media regenerate.

#Hvordan fjerne TimThumb trygt fra WordPress

Se vår WordPress-sikkerhetsrevisjon.

Hvis du har arvet et gammelt prosjekt, fjern TimThumb trygt og fullstendig:

1. Skann: Søk i wp-content-mappen etter timthumb.php eller thumb.php. Se også etter tilhørende cache-mapper.
2. Slett: Slett filen og tilhørende cache-mappe (vanligvis en mappe cache i temamappen).
3. Reparer: Finn stedene i koden der den ble kalt:

   // GAMMEL KODE (DÅRLIG)
   <img src="<?php echo get_template_directory_uri(); ?>/timthumb.php?src=..." />
   
   // ERSTATT MED (BRA)
   <?php the_post_thumbnail( 'min-storrelse' ); ?>

4. Regenerer: Installer WP-CLI og kjør wp media regenerate.
5. Kontroller: Gå gjennom alle viktige sider etter migreringen og sjekk at bildene vises riktig. Vær særlig oppmerksom på arkivsider, widgets i sidefeltet og bunnteksten, der TimThumb kan ha vært brukt.

#Hvordan finne TimThumb-referanser med grep

Det holder ikke å slette filen. Du må finne alle referansene i koden:

# Søk i alle PHP-filer i temaet
grep -r "timthumb" wp-content/themes/ditt-tema/
grep -r "thumb.php" wp-content/themes/ditt-tema/

# Søk også i egne utvidelser
grep -r "timthumb" wp-content/plugins/

# Spor etter injisert kode som Maunder anbefalte å sjekke
grep -rl "base64_decode" wp-content/

Hver referanse du finner, erstatter du med tilsvarende native WordPress-funksjon. Som regel betyr det the_post_thumbnail() eller wp_get_attachment_image() med riktig størrelse. Et treff på base64_decode beviser ikke en infeksjon, fordi noen legitime utvidelser bruker funksjonen, men hver forekomst i et tema bør leses.

#Hvordan måle bildeytelsen i WordPress

Når du har gått fra TimThumb til native metoder, bør du sjekke at ytelsen faktisk ble bedre. Bruk Google PageSpeed Insights, Lighthouse og WebPageTest til å måle lastetidene før og etter migreringen.

#Hvilke bildemålinger du bør følge: LCP, CLS og TTFB

• Largest Contentful Paint (LCP): Hovedbildet er som regel LCP-elementet. Med ferdige native størrelser, fetchpriority="high" og et CDN bør LCP bli bedre.
• Cumulative Layout Shift (CLS): Sørg for at alle bilder har width og height, slik at layouten ikke hopper under lasting. Vedleggsfunksjonene i WordPress legger dem til selv.
• Time to First Byte (TTFB) for bilder: Uten skalering i PHP venter ikke svaret for hvert bilde lenger på PHP eller GD.

#Serveroppsett for WordPress-bilder

For god bildeytelse i WordPress i 2026 omfatter anbefalt oppsett:

• Nettleser-cache med lange Cache-Control-headere for bildefiler (minst ett år)
• CDN med bildetransformasjoner og automatisk formatkonvertering
• Preload av LCP-bildet med <link rel="preload"> når bildet ikke dukker opp tidlig i HTML-en

#Alternativer til TimThumb for bildehåndtering i WordPress

Historien om TimThumb er en leksjon i ydmykhet. Bekvemmelighet (skalering i farten) kan ikke stå over sikkerhet. I 2026 har vi native add_image_size(), responsive srcset, og CDN-er som behandler bilder i skyen. Det er ingen grunn til å gå tilbake til løsninger fra 15 år siden.

Moderne bildehåndtering i WordPress hviler på tre pilarer: generering av størrelser ved opplasting med add_image_size(), responsiv levering med srcset og sizes, og formatoptimalisering med WebP/AVIF. Sammen med et CDN for leveringen gir de raske, sikre og vedlikeholdbare bilder på ethvert WordPress-nettsted.