Hvordan vise egendefinerte felter i WordPress (2026-guide)

Egendefinerte felter (Custom Fields), teknisk kjent som Post Meta, er funksjonen som forvandler WordPress fra en enkel bloggplattform til et kraftig innholdsstyringssystem (CMS). De lar deg tildele vilkårlig ekstra informasjon til et innlegg, som “Filmvurdering”, “Produktpris”, “Arrangementsdato” eller “Relatert video-ID”.

I denne omfattende guiden for utviklere (2026-utgave) skal vi ikke bare lære å vise felter. Vi skal forstå Metadata API-arkitekturen, lære å skrive effektive spørringer, og oppdage når vi ikke skal bruke egendefinerte felter.

#Hvordan hente og lagre post meta med get_post_meta()

WordPress tilbyr et sett med funksjoner for å administrere metadata, kjent som CRUD (Create, Read, Update, Delete).

#Hente et felt med get_post_meta()

Dette er den mest brukte funksjonen.

// Syntaks
$verdi = get_post_meta( $post_id, $nokkel, $single );

• $post_id: Innleggs-ID (bruk get_the_ID() inne i løkken).
• $nøkkel: Navnet på feltet i databasen (f.eks. ‘produkt_pris’).
• $single:
  • true: Returnerer en enkelt verdi (streng/heltall).
  • false (standard): Returnerer en tabell (array) med verdier. Dette er en vanlig felle!

Eksempel:

$pris = get_post_meta( get_the_ID(), 'produkt_pris', true );
if ( $pris ) {
    echo 'Pris: ' . esc_html( $pris ) . ' NOK';
}

#Opprette eller oppdatere et felt med update_post_meta()

Denne funksjonen er smart: hvis feltet ikke eksisterer, oppretter den det. Hvis det eksisterer, oppdaterer den det.

update_post_meta( $post_id, 'produkt_pris', '99.00' );

Hvis du lagrer en tabell, vil WordPress automatisk serialisere den:

$data = ['farge' => 'rod', 'størrelse' => 'XL'];
update_post_meta( $post_id, 'varianter', $data );
// Lagres i DB som: a:2:{s:5:"farge";s:3:"rod"...}

#Slette et felt med delete_post_meta()

delete_post_meta( $post_id, 'produkt_pris' );

#Serialiserte arrayer i post meta og ytelse

Som standard returnerer get_post_meta() med $single = false en tabell av tabeller, noe som er uintuitivt.

Hvis du har et felt “farge” med verdien “bla”:

$val = get_post_meta( $id, 'farge', false );
// Returnerer: Array ( [0] => "bla" )

Derfor bruker vi i 99% av tilfellene $single = true.

#Hvorfor serialiserte arrayer gjør SQL-søk trege

WordPress serialiserer automatisk PHP-tabeller og objekter i databasen. Dette er praktisk, MEN: Du kan ikke effektivt søke eller sortere etter serialiserte data i SQL.

Hvis du lagrer data som ['alder' => 25, 'by' => 'Oslo'] i et enkelt metafelt, må en SQL-spørring som søker etter “folk fra Oslo” bruke en treg LIKE %Oslo%, som dreper ytelsen på store databaser.

Gylden regel: Hvis du trenger å søke eller sortere etter noe (ORDER BY), lagre det i et eget metafelt, ikke inne i en tabell.

#Filtrere innlegg på egendefinert felt med meta_query

Den virkelige kraften viser seg i WP_Query. Du kan hente innlegg basert på feltverdiene deres.

#Filtrere innlegg på tallverdi med meta_query

$args = [
    'post_type'  => 'produkt',
    'meta_query' => [
        [
            'key'     => 'pris',
            'value'   => 100,
            'compare' => '>',
            'type'    => 'NUMERIC' // Viktig for riktig tallsorting!
        ]
    ]
];
$query = new WP_Query( $args );

#Kombinere flere felter i meta_query med AND eller OR

$args = [
    'post_type'  => 'produkt',
    'meta_query' => [
        'relation' => 'AND', // eller 'OR'
        [
            'key'     => 'pris',
            'value'   => 100,
            'compare' => '>',
            'type'    => 'NUMERIC'
        ],
        [
            'key'     => 'farge',
            'value'   => 'rod'
        ]
    ]
];

Ytelsesadvarsel: meta_query-forespørsler genererer JOINs til wp_postmeta-tabellen. Hvert ekstra kriterium er en ny JOIN. Med millioner av innlegg kan dette være ekstremt tregt. Hvis nettstedet ditt er tregt, sjekk om du misbruker meta_query. I slike tilfeller bør du vurdere egendefinerte databasetabeller.

#Vise egendefinerte felter med ACF eller ren PHP

Programtillegget Advanced Custom Fields (ACF) er bransjestandarden. Det forenkler opprettelsen av brukergrensesnitt for felter i admin-panelet.

#Hente et ACF-felt med get_field()

$pris = get_field('pris'); // Gjør get_post_meta automatisk

#Metaboks uten plugin med add_meta_box()

Hvis du ikke vil ha en programtillegg-avhengighet, kan du opprette en metaboks manuelt ved hjelp av add_meta_box(), men det krever mye kode (HTML-skjema, nonce, lagring save_post).

I 2026 er en hybrid tilnærming vanlig: bruk ACF til å opprette felter (UI), men hent dem via get_post_meta() i koden hvis du vil ha “renhet” og unngå ACF API-overhead i enkle tilfeller.

#Skjule egendefinerte felter med understrek-prefiks

Har du lagt merke til at noen felter ikke vises i listen “Egendefinerte felter” i innleggsredigering? Dette skjer når nøkkelnavnet starter med en understrek _.

• pris -> Synlig for brukeren i standard UI.
• _pris -> Skjult (Beskyttet).

Programtillegg som Yoast SEO eller WooCommerce bruker _ (f.eks. _yoast_wpseo_title) slik at brukeren ikke ødelegger disse dataene manuelt. Som utvikler bør du også bruke denne konvensjonen for systemdata.

#Sanitere og escape egendefinerte felter i WordPress

Dette er den viktigste delen. Stol aldri på data, selv fra databasen.

#Sanitere data ved lagring med sanitize_text_field()

Før du legger data i databasen (update_post_meta), rens dem.

$ny_pris = sanitize_text_field( $_POST['pris'] );
update_post_meta( $post_id, 'pris', $ny_pris );

Andre nyttige funksjoner: sanitize_email(), absint() (for heltall).

#Escape utdata med esc_html, esc_url og esc_attr

Før du sender data til nettleseren (echo), sørg for at de ikke inneholder skadelig JS (XSS).

// DÅRLIG
echo get_post_meta($id, 'url', true);

// BRA
echo esc_url( get_post_meta($id, 'url', true) );

// TEKST
echo esc_html( get_post_meta($id, 'by', true) );

// HTML-ATTRIBUTTER
echo '<div class="' . esc_attr( $klasse ) . '">';

#Blokkattributter eller post meta i Gutenberg

I 2026, når vi bruker Block Editor (Gutenberg), oppstår spørsmålet: Hvor skal data lagres? I blokkattributter eller post meta?

• Blokkattributter: Lagret i innleggsinnholdet (HTML). Rask å lese ved gjengivelse, men umulig å spørre etter i SQL (du kan ikke gjøre “vis innlegg med en blokk som har farge rød”).
• Post Meta: Lagret i wp_postmeta-tabellen. Tregere (krever separat spørring), men tillater filtrering og sortering (f.eks. i arkiver).

Beste praksis: Hvis data gjelder utseendet til et spesifikt element på siden -> Blokkattributt. Hvis data beskriver hele innlegget og du vil filtrere etter det -> Post Meta.

Du kan også kombinere begge: En Gutenberg-blokk kan lagre attributtene sine til Post Meta slik at de er tilgjengelige for WP_Query.

#Oppsummering

Funksjonen get_post_meta() er bare toppen av isfjellet. For å være en bevisst WordPress-utvikler i 2026:

1. Forstå forskjellen mellom $single=true og false.
2. Unngå å serialisere data du trenger å søke etter.
3. Vær oppmerksom på meta_query-ytelse (databaseindekser).
4. Bruk alltid (ALLTID) escaping-funksjoner (esc_html, esc_url).
5. Velg klokt mellom blokkattributter og metafelter.