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.

1. Metadata API: Fundamenter (crud)

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

Hente data: 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).
• $nokkel: 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';
}

Lagre og oppdatere: 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', 'storrelse' => 'XL'];
update_post_meta( $post_id, 'varianter', $data );
// Lagres i DB som: a:2:{s:5:"farge";s:3:"rod"...}

Slette: Delete_post_meta()

delete_post_meta( $post_id, 'produkt_pris' );

2. Ytelsesfelle: Tabeller og serialisering

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.

Serialiseringsproblemet

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.

3. Meta query: Filtrere innlegg etter felter

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

Enkel spørring (hent produkter dyrere enn 100 KR)

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

Komplekse relasjoner (pris > 100 og farge = rød)

$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.

4. Vise data: ACF vs ren PHP

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

ACF (enkel metode)

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

Ren PHP (for purister og ytelse)

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.

5. Skjulte metafelter (underscore-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.

6. Sikkerhet: Rensing og escaping

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

Ved lagring (sanitize)

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).

Ved visning (escape)

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 ) . '">';

7. Egendefinerte felter i Gutenberg-æraen (fse)

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.