Hvordan vise egendefinerte felter i WordPress (2026-guide)

I denne guiden for utviklere skal vi ikke bare vise felter. Vi går gjennom Metadata API, den utfasede the_meta(), escaping og sanitering, ACF, blokktemaer med render_block og Block Bindings, effektive spørringer, og når du 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’). Tom nøkkel gir alle feltene til innlegget.
• $single:
  • true: Returnerer en enkelt verdi.
  • 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';
}

Med $single = true gir manglende meta en tom streng. Med false får du alltid en tabell, også med ett element. Kode som gjør if ( $verdi ) oppfører seg ulikt på en streng og en tabell.

Gi nøklene et prefiks med prosjektnavnet (wppoland_arrangement_by, wppoland_sku). Unngå generiske navn som price, date eller city uten navnerom: før eller siden tar WooCommerce eller en SEO-utvidelse samme navn.

#Hva get_post_meta() returnerer for tall, boolske verdier og manglende nøkler

Alt som ligger i wp_postmeta, kommer tilbake som tekst hvis det ikke ble serialisert. Docblocken til get_post_meta() i WordPress-kjernen lister konverteringene: false returneres som tom streng, true som '1', og heltall og desimaltall som strenger. Tabeller og objekter beholder typen, fordi WordPress serialiserer dem ved lagring og pakker dem ut ved lesing.

Grensetilfeller fra samme docblock: en ugyldig innleggs-ID (ikke-numerisk, null eller negativ) gir false. En gyldig ID uten nøkkelen gir '' med $single = true og en tom tabell med $single = false. En default registrert med register_meta() (tilgjengelig siden WordPress 5.5) lagres aldri, og kommer derfor tilbake i den registrerte typen.

update_post_meta( $post_id, 'wppoland_lager', 0 );

$lager = get_post_meta( $post_id, 'wppoland_lager', true );
var_dump( $lager );        // string(1) "0"
var_dump( 0 === $lager );  // bool(false)

$lager = (int) $lager;     // konverter før regning eller streng sammenligning

En streng sammenligning mot et heltall treffer aldri en lagret verdi. Konverter med (int), (float) eller absint() før du regner, og sammenlign med '0' === $value når null betyr noe.

#Hvordan sjekke om et egendefinert felt finnes

En tom streng fra get_post_meta() sier ikke om nøkkelen ble lagret tom eller aldri ble lagret. metadata_exists() (siden WordPress 3.3) svarer på akkurat det, og leser den samme meta-cachen, så den legger ikke til en spørring når innleggets meta allerede er lastet:

if ( metadata_exists( 'post', $post_id, 'wppoland_sku' ) ) {
    $sku = get_post_meta( $post_id, 'wppoland_sku', true );
    // Nøkkelen finnes, selv om verdien er en tom streng.
}

Funksjonen kjører først filteret get_post_metadata, som koden i meta.php viser, så en utvidelse som avskjærer meta-lesing kan endre svaret. Bruk den når «tom» og «ikke satt» skal håndteres ulikt, for eksempel når redaksjonen tømmer et felt med vilje og malen ikke skal falle tilbake til en standardverdi.

#Opprette eller oppdatere et felt med update_post_meta()

Denne funksjonen oppretter feltet hvis det ikke finnes, og oppdaterer det hvis det finnes.

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

Hvis du lagrer en tabell, serialiserer WordPress den automatisk:

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

add_post_meta() med standard $unique = false tillater flere rader under samme nøkkel. Det bør være en bevisst beslutning og ikke en bieffekt av en CSV-import.

#Slette et felt med delete_post_meta()

delete_post_meta( $post_id, 'produkt_pris' );

#get_post_meta() eller the_meta()

the_meta() er utfaset siden WordPress 6.0.2. Et kall utløser _deprecated_function() med get_post_meta() som erstatning, noe som gir en melding når WP_DEBUG er på. Funksjonen skriver ut en <ul class='post-meta'>-liste med alle egendefinerte felter for gjeldende innlegg i løkken. Den escaper nøkler og verdier med esc_html() og hopper over beskyttede nøkler (de som starter med understrek), men tar ingen nøkkel som argument og gir deg ingen kontroll over markup eller hvilke nøkler som vises.

// Utfaset: skriver ut alle ubeskyttede nøkler for gjeldende innlegg
the_meta();

// Anbefalt: les én nøkkel, bestem HTML, escape for konteksten
$orgnr = get_post_meta( get_the_ID(), 'wppoland_orgnr', true );
if ( $orgnr ) {
    echo '<p class="orgnr">' . esc_html( $orgnr ) . '</p>';
}

Behold the_meta() bare i gamle temaer som fortsatt kaller den, eller i en feilsøkingsvisning på staging. I produksjon bør arkivmaler, enkeltmaler for CPT og kort-partials lese eksplisitte nøkler. Da havner ikke intern meta (ERP-ID-er, integrasjonstokener, redaksjonsnotater) som er lagret uten understrek, på den offentlige siden. Koden ligger i post-template.php.

#Hvordan vise et egendefinert felt i temaet

#Vise et felt inne i løkken

<?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>
    <h2><?php the_title(); ?></h2>

    <?php
    $sku = get_post_meta( get_the_ID(), 'wppoland_sku', true );
    if ( $sku ) :
        ?>
        <p class="sku"><?php echo esc_html( $sku ); ?></p>
    <?php endif; ?>

<?php endwhile; endif; ?>

#Hente et felt utenfor løkken

$post_id     = 42;
$forfatter   = get_post_meta( $post_id, 'custom_author', true );
echo esc_html( $forfatter );

I CPT-arkiver bør du ikke stole blindt på den globale $post utenfor løkken: hent ID-en med get_queried_object_id() eller send den inn som argument til partialen. Det er en vanlig årsak til at «meta fra forrige innlegg dukker opp» i lister med felles sidefelt. For gjenbrukbare partials (arrangementskort, boligkort) sender du ID-en som funksjonsargument, så de oppfører seg likt i en Query Loop.

#Serialiserte arrayer i post meta og ytelse

Som standard returnerer get_post_meta() med $single = false en tabell, også når feltet bare har én verdi.

Hvis du har et felt «farge» med verdien «bla»:

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

Derfor bruker vi $single = true for felter med én verdi.

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

WordPress serialiserer automatisk PHP-tabeller og objekter i databasen. Det 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 ett metafelt, må en SQL-spørring som søker etter «folk fra Oslo» bruke en treg LIKE '%Oslo%', som går gjennom hele tabellen på store databaser.

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

#Hvorfor get_post_meta returnerer en tabell i stedet for en streng

get_post_meta( $id, $nokkel, true ) kan returnere en tabell når databasen har en serialisert PHP-tabell fra en gammel migrering. Kode som venter en streng gir notices eller skriver ut ordet «Array». Sjekk typen før esc_html, eller normaliser verdien ved lagring.

Unngå manuell serialize() og unserialize() på brukerdata. WordPress serialiserer sammensatte meta-verdier selv; du sender tabellen til update_post_meta. Ved integrasjoner med eksterne systemer bør du mappe felter til skalare nøkler i stedet for én blob, så meta_query fortsatt fungerer senere.

#Filtrere innlegg på egendefinert felt med meta_query

WP_Query kan hente innlegg basert på feltverdiene.

#Filtrere innlegg på tallverdi med meta_query

$args = [
    'post_type'  => 'produkt',
    'meta_query' => [
        [
            'key'     => 'pris',
            'value'   => 100,
            'compare' => '>',
            'type'    => 'NUMERIC' // nødvendig for å sammenligne som tall
        ]
    ]
];
$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 genererer JOIN mot wp_postmeta-tabellen, og hvert ekstra kriterium er en ny JOIN. På store nettsteder kan dette bli tregt. Er nettstedet tregt, sjekk om du misbruker meta_query; vurder da taksonomier eller egne databasetabeller.

#Meta-cache og update_meta_cache()

I en vanlig WP_Query kaller WordPress update_meta_cache() og laster meta for innleggene i én omgang. Gjentatte get_post_meta()-kall på samme ID i samme forespørsel gir ingen ekstra SELECT, fordi verdiene ligger i objektcachen (vedvarende med Redis eller Memcached, ellers forespørselens minnecache).

Antimønster: et arkiv med 48 kort som kjører en egen WP_Query per kort for å lese én meta-verdi. Bruk heller én spørring med meta_query, eller to steg (hent ID-er, deretter get_posts med meta allerede i cache). Kjernen indekserer meta_key, men ikke meta_value, så unngå ORDER BY meta_value på store tabeller uten indeks.

Sidecache-utvidelser serverer statisk HTML, så meta vurderes først på nytt når siden genereres igjen. Endres meta via cron eller en ERP-webhook, tøm cachen for den URL-en.

#Lagre egendefinerte felter med en metaboks

#Metaboks uten plugin med add_meta_box()

Hvis du ikke vil være avhengig av en utvidelse, oppretter du en metaboks med add_meta_box(). Det krever HTML-skjema, nonce og lagring i save_post:

function wppoland_add_sku_metabox() {
    add_meta_box(
        'product_sku_box',
        'Katalogkode',
        'wppoland_render_sku_metabox',
        'post',
        'side'
    );
}
add_action( 'add_meta_boxes', 'wppoland_add_sku_metabox' );

function wppoland_render_sku_metabox( $post ) {
    wp_nonce_field( 'save_sku', 'sku_nonce' );
    $sku = get_post_meta( $post->ID, 'wppoland_sku', true );
    ?>
    <label for="wppoland_sku">SKU:</label>
    <input type="text" id="wppoland_sku" name="wppoland_sku"
           value="<?php echo esc_attr( $sku ); ?>">
    <?php
}

function wppoland_save_sku_metabox( $post_id ) {
    if ( ! isset( $_POST['sku_nonce'] ) ||
        ! wp_verify_nonce( $_POST['sku_nonce'], 'save_sku' ) ) {
        return;
    }

    if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) {
        return;
    }

    if ( ! current_user_can( 'edit_post', $post_id ) ) {
        return;
    }

    if ( isset( $_POST['wppoland_sku'] ) ) {
        update_post_meta(
            $post_id,
            'wppoland_sku',
            sanitize_text_field( wp_unslash( $_POST['wppoland_sku'] ) )
        );
    }
}
add_action( 'save_post', 'wppoland_save_sku_metabox' );

Nonce, tilgangssjekk og vern mot autolagring er tre ting korte veiledninger hopper over, og som sikkerhetsrevisjoner påpeker først. Kjør også wp_unslash på $_POST-data før sanitering.

#Vise egendefinerte felter med ACF eller ren PHP

Programtillegget Advanced Custom Fields (ACF) er mye brukt. Det forenkler grensesnittet for felter i admin-panelet og felttyper som repeater, flexible content og relationship.

#Hente et ACF-felt med get_field()

$pris  = get_field( 'pris' );
$bilde = get_field( 'hero_image' );
$verdi = get_field( 'field_name', $post_id );

For innlegg lagrer ACF fortsatt verdiene i postmeta, så meta_query bruker ofte de samme nøklene som det native API-et. En vanlig hybrid er å lage feltene i ACF (grensesnittet), men lese dem med get_post_meta() i enkle tilfeller. I store lister bør du unngå get_field på hvert kort uten at meta er lastet i bulk (update_meta_cache eller en WP_Query som allerede laster meta).

Skal temaet fungere med ACF deaktivert, behold en reserve:

$sku = function_exists( 'get_field' )
    ? get_field( 'wppoland_sku', $post_id )
    : get_post_meta( $post_id, 'wppoland_sku', true );

For ACF-bildefelter returnerer get_field en ID, en URL eller en tabell avhengig av feltets returformat. Avstem formatet med det malen venter før du sender verdien til wp_get_attachment_image eller esc_url.

#Er utdata fra the_field() escapet i ACF

Dokumentasjonen for get_field() sier at returnerte verdier må escapes med en passende funksjon før utskrift, fordi ACF ikke vet hvor du bruker dem. Når du skriver echo get_field(), er escaping ditt ansvar.

the_field() oppfører seg annerledes siden ACF 6.2.7. ACF-veiledningen om HTML-escaping sier at fra 6.2.5 går utdata fra ACF-kortkoden gjennom wp_kses(), og fra 6.2.7 gjelder det samme for the_field() og the_sub_field(). Utgivelsesnotatet for sikkerhetsversjonen 6.2.5 advarer om at dette fjerner usikker HTML som skript eller iframes fra textarea- og WYSIWYG-felter. Siden ACF 6.2.6 tar get_field() også et fjerde argument, $escape_html, som gir en escapet verdi og krever at $format_value er true.

// Escapet av ACF (wp_kses) siden 6.2.7
the_field( 'event_summary' );

// Ikke escapet: du velger funksjon for konteksten
echo esc_html( get_field( 'event_summary' ) );

// Siden 6.2.6: be felttypen om en escapet verdi
echo get_field( 'event_summary', false, true, true );

Forsvant en innbygging i et WYSIWYG-felt etter en ACF-oppdatering, er dette som regel årsaken. Avgjør per felt om HTML-en er til å stole på, og skriv den ut med wp_kses_post() eller en egen liste over tillatte tagger i stedet for å skru av escaping globalt.

#Hvordan vise panelet for egendefinerte felt i blokkredigeringen

Den native boksen for egendefinerte felter finnes også i blokkredigeringen, men er skjult som standard hvis den ikke er brukt før. WordPress.org-dokumentasjonen om egendefinerte felter beskriver veien. Med norsk grensesnitt kommer navnene fra den offisielle språkpakken: lagre innlegget først, åpne menyen Alternativer (de tre prikkene i den øverste verktøylinjen), velg Preferanser, åpne fanen Generelt, slå på Egendefinerte felt i delen Avansert og klikk Vis og last siden på nytt. Boksen vises under innholdet, der Skriv ny og Legg til tilpasset felt oppretter en nøkkel og verdien.

#Skjule egendefinerte felter med understrek-prefiks

Noen felter vises ikke i den boksen. Det skjer når nøkkelnavnet starter med understrek _: pris er synlig for brukeren i standardgrensesnittet, mens _pris er 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, men husk at beskyttede nøkler heller ikke kan bindes med Block Bindings (se lenger ned).

ACF fjerner i tillegg den native boksen som standard: ACF-referansen for innstillinger lister remove_wp_meta_box (siden ACF 5.6.0, standard true). Slik får du boksen tilbake med ACF aktivt:

add_filter( 'acf/settings/remove_wp_meta_box', '__return_false' );

Det er nyttig for å feilsøke importer på staging. I produksjon ender redaktører som ser rå nøkler ved siden av ACF-felter ofte med å redigere samme verdi to steder, så la den være av der.

#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( wp_unslash( $_POST['pris'] ) );
update_post_meta( $post_id, 'pris', $ny_pris );

Andre nyttige funksjoner: sanitize_email(), absint() (for heltall). Ikke anta at metaboksen «bare finnes i admin»: REST API og masseredigering skriver også meta.

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

Konteksten velger funksjonen. Synlig tekst: esc_html. Attributt: esc_attr. URL: esc_url. Redaksjonell HTML du stoler på: wp_kses_post. Meta fra et skjema på forsiden (tilbudsforespørsel, søknad) er alltid upålitelig, også på et internt nettsted.

#Vise post meta i et blokktema med render_block

I blokktemaer flytter mye av presentasjonen fra klassisk single.php til HTML-maler og filteret render_block. Meta leses fortsatt i PHP; det er innsettingspunktet som endres.

add_filter( 'render_block', 'wppoland_inject_sku_after_title', 10, 2 );

function wppoland_inject_sku_after_title( $block_content, $block ) {
    if ( ( $block['blockName'] ?? '' ) !== 'core/post-title' ) {
        return $block_content;
    }

    if ( ! is_singular( 'product' ) ) {
        return $block_content;
    }

    $sku = get_post_meta( get_the_ID(), 'wppoland_sku', true );
    if ( ! $sku ) {
        return $block_content;
    }

    $extra = '<p class="sku">' . esc_html( $sku ) . '</p>';
    return $block_content . $extra;
}

I temamønstre bør du ikke hardkode innleggs-ID-er fra staging. Les meta fra gjeldende kontekst (get_the_ID() i Query Loop) eller send blokkattributter.

#Blokkattributter eller post meta i Gutenberg

Når jeg bruker blokkredigeringen (Gutenberg), kommer spørsmålet: hvor skal data lagres, i blokkattributter eller post meta?

• Blokkattributter: Lagret i innleggsinnholdet (HTML). Raske å lese ved gjengivelse, men umulige å spørre etter i SQL (du kan ikke be om «innlegg med en blokk som har farge rød»).
• Post meta: Lagret i wp_postmeta-tabellen. Krever en egen spørring, men tillater filtrering og sortering (f.eks. i arkiver).

Gjelder dataene utseendet til ett element på siden, bruk et blokkattributt. Beskriver de hele innlegget og du vil filtrere på dem, bruk post meta. Du kan også kombinere: en blokk kan lagre attributtene sine i post meta slik at de er tilgjengelige for WP_Query.

#Koble egendefinerte felter til blokker med Block Bindings

Siden WordPress 6.5 kobler Block Bindings API kjerneblokker til verdier i egendefinerte felter uten at du bygger en egen blokk. Kilden core/post-meta leser verdien med get_post_meta() når blokken gjengis.

#Hvilke blokker støtter Block Bindings

Listen over attributter som kan bindes, ligger i kjernen og har vokst for hver versjon, slik versjonsgrenene i wordpress-develop viser:

Kilder: class-wp-block.php i grenen 6.5 og block-bindings.php i grenen 7.1.

#Registrere meta og binde den til et avsnitt

add_action( 'init', function () {
    register_post_meta( 'post', 'wppoland_forfatternotat', [
        'show_in_rest'  => true,
        'single'        => true,
        'type'          => 'string',
        'auth_callback' => function () {
            return current_user_can( 'edit_posts' );
        },
    ] );
} );

<!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"core/post-meta","args":{"key":"wppoland_forfatternotat"}}}}} -->
<p>Reservetekst når meta er tom.</p>
<!-- /wp:paragraph -->

Kilden core/post-meta returnerer ingenting i fire tilfeller: nøkkelen er ikke registrert med show_in_rest, nøkkelen er beskyttet (starter med understrek), innlegget er ikke offentlig og besøkende har ikke lov til å lese det, eller innlegget er passordbeskyttet. En nøkkel som _wppoland_forfatternotat vises derfor aldri gjennom en binding, selv om den er registrert. Bruk nøkler uten understrek for alt du vil binde. Bindings erstatter ikke escaping på serveren for HTML du skriver selv.

#Registrere en egen kilde for Block Bindings

Når verdien må bearbeides (formatert pris, dato i nettstedets format), registrerer du en egen kilde i PHP med register_block_bindings_source() på kroken init. Tilbakekallet får bindingsargumentene, blokkinstansen og attributtnavnet, slik docblocken i block-bindings.php beskriver:

add_action( 'init', function () {
    register_block_bindings_source( 'wppoland/formatted-price', [
        'label'              => __( 'Formatert pris', 'wppoland' ),
        'uses_context'       => [ 'postId' ],
        'get_value_callback' => function ( array $source_args, $block_instance ) {
            $post_id = $block_instance->context['postId'] ?? get_the_ID();
            $raw     = get_post_meta( $post_id, $source_args['key'] ?? '', true );

            return '' === $raw ? null : number_format_i18n( (float) $raw, 2 );
        },
    ] );
} );

Blokkmarkupen bruker da "source": "wppoland/formatted-price" med meta-nøkkelen i args. Kildenavnet trenger et navneromsprefiks som wppoland/ og kan bare inneholde små bokstaver, sifre, bindestreker og skråstreker.

#Egendefinerte felter i REST API

For at meta skal vises i blokkredigeringen og i REST API, registrerer du den:

register_post_meta( 'post', 'wppoland_sku', [
    'show_in_rest'      => true,
    'single'            => true,
    'type'              => 'string',
    'sanitize_callback' => 'sanitize_text_field',
    'auth_callback'     => function () {
        return current_user_can( 'edit_posts' );
    },
] );

Uten show_in_rest ser ikke redigeringens JavaScript feltet. Uten auth_callback kan du åpne skrivetilgang for en større gruppe enn tenkt. type må stemme med de faktiske dataene: number mot en streng i JSON gir stille feil i sidefeltet. For sammensatte felter (objekter, lister) konfigurerer du show_in_rest med et skjema. Sensitive felter (betalingstokener, interne faktura-ID-er) bør ha show_in_rest av; temaet kan lese dem i PHP uten å publisere dem under /wp-json/.

#Hvorfor egendefinerte felter ikke vises i REST API for en egen innholdstype

For en egen innholdstype er det én betingelse til, skrevet i docblocken til register_meta(): innholdstypen må erklære støtte for egendefinerte felter, ellers holdes registrert meta utenfor REST-svaret.

register_post_type( 'arrangement', [
    'public'       => true,
    'show_in_rest' => true,
    'supports'     => [ 'title', 'editor', 'custom-fields' ],
] );

register_post_meta( 'arrangement', 'wppoland_sted', [
    'show_in_rest'      => true,
    'single'            => true,
    'type'              => 'string',
    'sanitize_callback' => 'sanitize_text_field',
    'auth_callback'     => function () {
        return current_user_can( 'edit_posts' );
    },
] );

Samme docblock nevner to nyere argumenter. revisions_enabled (WordPress 6.4) lagrer meta sammen med innleggsrevisjoner og fungerer bare for objekttypen post. label (WordPress 6.7) gir nøkkelen et lesbart navn.

#Vanlige feil med egendefinerte felter i WordPress

1. Skrive ut meta uten esc_html, esc_attr eller esc_url.
2. Lagre fra $_POST uten nonce og uten current_user_can.
3. Samme meta-nøkkel brukt av to utvidelser (eller av WooCommerce og temaet).
4. get_field i en arkivløkke uten meta lastet i bulk.
5. Anta at $single = true alltid gir en streng (serialiserte tabeller fra gamle importer).
6. Bygge en blokk uten register_post_meta: «virker i PHP, feiler i redigeringen».
7. Bruke the_meta() i produksjon og vise interne nøkler på den offentlige siden.
8. Binde en beskyttet _nøkkel med Block Bindings og lure på hvorfor ingenting vises.

#Hvordan navngi meta-nøkler og migrere fra ACF

Når du overtar et gammelt tema, lag en oversikt over nøklene: SELECT meta_key, COUNT(*) FROM wp_postmeta GROUP BY meta_key ORDER BY COUNT(*) DESC LIMIT 50. Du ser med en gang hvilke prefikser som tilhører prosjektet og hvilke som er rester etter utvidelser som er fjernet for lenge siden. Et prosjektprefiks (wppoland_, kunde_) beskytter mot kollisjoner med ACF eller WooCommerce.

Ved migrering fra ACF til native register_post_meta bør du ikke kopiere referanser som field_xxxxx blindt. Behold en lesbar forretningsnøkkel og eventuelt et engangsskript som mapper gamle ID-er til nye. Staging først: sammenlign antall innlegg med ikke-tom meta før og etter.

I multisite jobber get_post_meta alltid på gjeldende nettsted. switch_to_blog rundt meta-lesing uten restore_current_blog i en finally-blokk er en klassisk måte å blande data fra et annet nettsted i nettverket.

Test lagring av meta som redaktør, ikke bare som administrator. En metaboks eller ACF-gruppe bør ha én linje med hjelpetekst: hvor verdien kommer fra, om den er obligatorisk, og hva forsiden viser når den er tom. I malen håndterer du tom tilstand med vilje (skjul seksjonen eller vis en reserve) i stedet for å gjengi tomme tagger.

#Sjekkliste for egendefinerte felter før publisering

1. Hver utskrift bruker esc_html, esc_attr, esc_url eller wp_kses_post etter kontekst.
2. Lagringsrutiner sjekker nonce og current_user_can.
3. Meta i REST har show_in_rest og auth_callback, og egne innholdstyper støtter custom-fields.
4. Ingen ORDER BY meta_value på store arkiver uten grunn og indeks.
5. Gamle nøkler fra utvidelser er dokumentert eller fjernet med et oppryddingsskript testet på staging.
6. Ingen produksjonsmal kaller the_meta() for offentlig innhold.
7. Nøkler som bindes med Block Bindings har ikke understrek først.

#Oppsummering

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

1. Forstå forskjellen mellom $single=true og false, og at tall kommer tilbake som strenger.
2. Unngå å serialisere data du trenger å søke etter.
3. Vær oppmerksom på meta_query-ytelse (databaseindekser og meta-cache).
4. Bruk alltid escaping-funksjoner (esc_html, esc_url), også etter get_field().
5. Velg klokt mellom blokkattributter og metafelter, og bind bare nøkler uten understrek.
6. Erstatt the_meta(), som er utfaset siden 6.0.2.