Før du limer AI-generert PHP inn i WordPress, sjekk disse tingene

AI-verktøy skriver PHP-kodesnutter for WordPress på sekunder. Fjerne et felt i kassen, legge til tekst på takkesiden, sende brukere videre etter innlogging, lage en shortcode: AI lager noe for alt sammen. Men PHP som limes inn uten gjennomgang, kan ødelegge et nettsted like raskt. En manglende sjekk, feil hook, en utrygg omdirigering eller en feilplassert echo kan gi PHP-advarsler, ødelagte AJAX-svar, hvit skjerm eller en kasse som slutter å virke.

AI-generert PHP er ikke dårlig i seg selv. Problemet er at WordPress har kontekst, fra temaer og plugins til caching, økter og omdirigeringer, som en kodesnutt skrevet isolert ikke vet noe om. Sjekk disse tingene før du limer inn. For CSS, JavaScript, .htaccess og selve utrullingen, se sjekklisten vår for gjennomgang av AI-generert WordPress-kode.

Hvorfor AI-genererte PHP-kodesnutter kan være risikable i WordPress

Et WordPress-nettsted er ikke en tom PHP-fil. Det har hooks, AJAX- og REST-forespørsler, økter, innloggede og utloggede besøkende, caching og serverregler, så en kodesnutt kan virke i én situasjon og feile i din. Dette ser harmløst ut:

$id = $_SESSION['redirect_cache'];

Finnes ikke øktnøkkelen, gir PHP 8:

Warning: Undefined array key "redirect_cache"

På en server som viser feil, skrives den advarselen inn i det forespørselen returnerer: over innholdet på en vanlig side, og inne i JSON-en på en AJAX-forespørsel fra WooCommerce, der kassen så venter på et svar den ikke kan lese. Vi fant akkurat denne linjen i en sak med WooCommerce-kassen: ved siden av rewrite-regelen som stanset kassen, skrev den usikrede øktlesingen advarselstekst inn i AJAX-svarene.

Feil 1: Å lime kode rett inn i functions.php

Mange AI-kodesnutter slutter med «legg dette i temaets functions.php». Greit for en liten temaendring, men WordPress sin temahåndbok peker på haken: functions.php kjører bare mens temaet er aktivt, så funksjoner som skal virke uansett hvordan nettstedet ser ut, hører hjemme i en plugin. Kode lagt inn i filene til et foreldretema forsvinner også ved neste temaoppdatering, og det er nettopp det child-temaer er til for. En overfylt functions.php blander dessuten urelaterte kodesnutter, doble navn og forretningslogikk med design.

For kasseoppførsel, skjemabehandling, omdirigeringer eller ordredata er en liten egen plugin som regel et tryggere hjem. Den kan være så liten som dette, i en egen fil under wp-content/plugins/:

<?php
/**
 * Plugin Name: Tilpasninger for nettbutikken
 * Requires Plugins: woocommerce
 */

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

// Kodesnuttene dine her, ett formål per snutt, med en kommentar om hvorfor.

Headeren Requires Plugins lister pluginene den er avhengig av, og ABSPATH-sjekken hindrer at fila kjøres direkte, slik plugin-håndboken anbefaler.

Feil 2: Å ikke sjekke om en variabel finnes

AI antar ofte at en variabel finnes:

$user_id = $_GET['user_id'];

Dette gir en advarsel hvis user_id mangler. Tryggere:

$user_id = isset($_GET['user_id']) ? absint($_GET['user_id']) : 0;

Et annet risikabelt eksempel, med den tryggere versjonen under:

$email = $_POST['email'];

$email = isset($_POST['email']) ? sanitize_email(wp_unslash($_POST['email'])) : '';

Før du bruker en verdi, spør om nøkkelen finnes, om den er av forventet type, om den må saniteres eller escapes, og hva som skal skje hvis den mangler. Dette er viktigst for $_GET, $_POST, $_REQUEST, $_SESSION, $_COOKIE, ordremeta, brukermeta, plugin-innstillinger og array-nøkler fra eksterne API-er.

Feil 3: Å ikke sanitere brukerinput

Data fra brukere, URL-er, skjemaer, cookies eller eksterne forespørsler er utrygge til de er renset, og WordPress sin håndbok sier at validering, der du kan bruke det, slår sanitering. Dårlig:

$name = $_POST['name'];
update_option('minbutikk_kundenavn', $name);

Bedre:

$name = isset($_POST['name']) ? sanitize_text_field(wp_unslash($_POST['name'])) : '';
update_option('minbutikk_kundenavn', $name);

Tilpass funksjonen til datatypen:

$email = sanitize_email($email);
$page_id = absint($page_id);
$url = sanitize_url($url);
$title = sanitize_text_field($title);
$content = wp_kses_post($content);

To feller: sanitize_title() høres riktig ut for en tittel, men gjør en streng om til en slug, og AI skriver fortsatt esc_url_raw(), som siden WordPress 6.1 bare er et alias for sanitize_url(). wp_unslash() står der fordi WordPress legger til skråstreker i $_GET, $_POST og $_COOKIE.

Feil 4: Å ikke escape output

Sanitering skjer når data kommer inn; escaping skjer når data går ut. Skriver en kodesnutt dynamiske data inn i HTML, skal den escape dem. Dårlig:

echo '<p>' . $message . '</p>';

Bedre, med riktig funksjon for hver sammenheng:

echo '<p>' . esc_html($message) . '</p>';
echo '<a href="' . esc_url($url) . '">Besøk siden</a>';
echo '<input value="' . esc_attr($value) . '">';
echo wp_kses_post($content);

Regelen i WordPress er å escape så sent som mulig, helst på linjen som skriver ut verdien. Output som ikke escapes, er veien inn for cross-site scripting (XSS), og AI-kodesnutter hopper over escaping fordi de er skrevet som raske eksempler. I produksjonskode er escaping ikke valgfritt.

Feil 5: Å bruke feil WordPress-hook

WordPress kjører gjennom en rekke hooks i fast rekkefølge, og feil hook får en kodesnutt til å kjøre for tidlig, for sent eller i feil sammenheng. Dårlig:

WC()->cart->empty_cart();

WooCommerce setter bare opp handlekurven for frontend- og AJAX-forespørsler, fra init og utover. Kjører dette tidligere, eller i wp-admin eller en cron-jobb, er WC()->cart null, og PHP stopper med «Call to a member function empty_cart() on null». Bedre:

add_action('template_redirect', function() {
    if (function_exists('WC') && WC()->cart) {
        WC()->cart->empty_cart();
    }
});

Selv da bør det bare kjøre under nøye betingelser. Betingede tagger har også sin timing: WooCommerce sin dokumentasjon påpeker at is_page(), is_checkout() og lignende først virker når WordPress har kjørt hovedspørringen, og før det gir de bare false, uten noen advarsel. På en frontend-side kjører de vanlige hookene i denne rekkefølgen:

init
wp_loaded
template_redirect
wp_enqueue_scripts
wp_head
wp_footer

Gir AI deg en kodesnutt på init, wp_head eller template_redirect, sjekk at hooken faktisk passer til jobben.

Feil 6: Å kjøre kode overalt i stedet for betinget

En kodesnutt bør som regel bare kjøre der den trengs. Dårlig:

add_action('wp_head', function() {
    echo '<script>alert("Hello");</script>';
});

Dette kjører på hver eneste frontend-side. Bedre:

add_action('wp_head', function() {
    if (!function_exists('is_checkout') || !is_checkout()) {
        return;
    }

    echo '<script>console.log("Bare i kassen");</script>';
});

Til et ekte skript laster du heller inn en fil med wp_enqueue_script() bak den samme sjekken, i stedet for å skrive ut en script-tagg. Andre nyttige kontekstvakter:

if (!is_admin()) {
    return; // bare admin-forespørsler
}

if (is_admin()) {
    return; // bare frontend
}

if (wp_doing_ajax()) {
    return; // hopp over AJAX-forespørsler
}

Vit to ting om is_admin(): den gir også true på forespørsler til admin-ajax.php, og den sier ingenting om hvem brukeren er, så plugin-håndboken advarer om at den aldri erstatter en rettighetssjekk.

Feil 7: Å skrive ut tekst under AJAX- eller REST API-forespørsler

Denne er alvorlig. WooCommerce, skjemaer og plugins bruker AJAX- og REST-forespørsler som forventer ren JSON, og all tekst, HTML, advarsler eller debug-output ødelegger svaret. Dårlig:

add_action('init', function() {
    echo 'Debugging...';
});

Dette skriver tekst inn i hver forespørsel som laster WordPress, også AJAX. Glemte var_dump()– og print_r()-kall gjør det samme: nyttige lokalt, farlige på et live nettsted. Når du feilsøker, skriv til loggen i stedet:

error_log(print_r($data, true));

På en staging-kopi fanger debug-loggen i WordPress advarsler som skjer utenfor synsfeltet, under AJAX-forespørsler eller cron-kjøringer:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

WordPress fraråder å bruke debug-verktøyene sine på live nettsteder; feil 13 handler om produksjon. Og skal koden hoppe over REST-forespørsler: WordPress definerer REST_REQUEST først under parse_request, så en sjekk på init svarer alltid nei.

Feil 8: Å lage omdirigeringsløkker

AI-genererte omdirigeringer er vanlige, og lette å gjøre feil:

add_action('template_redirect', function() {
    wp_redirect(home_url('/login/'));
    exit;
});

template_redirect kjører bare når frontend-sider lastes, så wp-admin og REST-kall slipper unna (på init ville de ikke gjort det), men alle frontend-adresser blir omdirigert: handlekurven, kassen, ordrebekreftelsen en gjest ser etter å ha betalt, og /login/ selv, som nå går i løkke. En tryggere omdirigering trenger tydelige vakter:

add_action('template_redirect', function() {
    if (is_user_logged_in() || is_page('login')) {
        return;
    }

    // I en nettbutikk: la gjester nå handlekurv, kasse og ordrebekreftelse.
    if (function_exists('is_checkout') && (is_cart() || is_checkout() || is_wc_endpoint_url('order-received'))) {
        return;
    }

    wp_safe_redirect(home_url('/login/'));
    exit;
});

wp_safe_redirect() sender bare videre til tillatte verter, som standard din egen, og i likhet med wp_redirect() stopper den ikke skriptet, så exit følger rett etter. Test likevel innlogging, handlekurv, kasse, kontosider og en hel gjestebestilling før du stoler på den.

Feil 9: Å endre WooCommerce uten å bevare den innebygde flyten

WooCommerce har mange hooks og filtre, men kassen er sårbar. Å gjøre telefonfeltet påkrevd er enkelt i den klassiske kassen:

add_filter('woocommerce_checkout_fields', function($fields) {
    if (isset($fields['billing']['billing_phone'])) {
        $fields['billing']['billing_phone']['required'] = true;
    }

    return $fields;
});

Det er også enkelt å fjerne adresselinje 2:

add_filter('woocommerce_checkout_fields', function($fields) {
    unset($fields['billing']['billing_address_2']);
    return $fields;
});

Legg merke til return $fields;. Et filter må returnere verdien det fikk inn: PHP returnerer null fra en funksjon uten return-setning, og WooCommerce jobber da videre med null i stedet for feltlisten.

Sjekk så hvilken kasse butikken bruker. WooCommerce dokumenterer dette filteret for shortcode-kassen, og butikker satt opp etter WooCommerce 8.3 bruker kasseblokken som standard. Der er det en innstilling i blokkredigeringen å skjule feltene for firma, adresselinje 2 og telefon (Company, Address line 2 og Phone), eller gjøre dem valgfrie eller påkrevde, helt uten kode, og nye felt legges til via Additional Checkout Fields API. I butikker med HPOS (standard siden 8.2) lagrer du ordredata med $order->update_meta_data() og $order->save(), ikke update_post_meta().

Ikke rediger filene i selve WooCommerce (WooCommerce advarer om at slike endringer forsvinner ved neste oppdatering), bygg kasseskjemaet på nytt for hånd eller slå av kasseskriptene. Skjulte felt betyr noe: skjemaet i den klassiske kassen har et nonce-felt, woocommerce-process-checkout-nonce, og mister et ombygd skjema det, feiler hver bestilling med WooCommerce-meldingen «We were unable to process your order, please try again.» Hold deg til kassen slik WooCommerce leverer den, og legg inn en hel testbestilling etter hver endring.

Feil 10: Å ikke sjekke for konflikter i funksjonsnavn

AI genererer ofte generiske funksjonsnavn:

function custom_checkout_fields() {
    // kode
}

Har en annen kodesnutt eller plugin allerede deklarert det navnet, krasjer nettstedet. Slik formulerer PHP 8.5 det:

Fatal error: Cannot redeclare function custom_checkout_fields() (previously declared in ...)

Bruk et unikt prefiks. Plugin-håndboken ber om minst fire bokstaver, helst fem, og ikke et vanlig engelsk ord, så i stedet for fix_checkout():

function minbutikk_fix_checkout_phone_field() {
}

Anonyme funksjoner unngår navnekollisjoner, men de er vanskelige å hekte av senere: remove_action() virker bare når den får samme callback og prioritet som ble lagt til. Til alt du kan komme til å ville slå av, bruk en navngitt funksjon med prefiks.

Feil 11: Å ikke sjekke plugin- eller temaavhengigheter

AI-generert PHP kan kalle funksjoner som bare finnes når en plugin er aktiv:

WC()->cart->get_cart();

Dette krever WooCommerce. En tryggere vakt:

if (!function_exists('WC')) {
    return;
}

WooCommerce-betingelser som is_product() finnes ikke når WooCommerce er inaktiv, og et kall stopper da nettstedet med «Call to undefined function». Sjekk først:

if (function_exists('is_product') && is_product()) {
    // kode
}

For en hel blokk med WooCommerce-kode foreslår WooCommerce sin utviklerdokumentasjon hooken woocommerce_init, som bare kjører når WooCommerce er aktiv. Uansett hva du velger: en plugin som er deaktivert en stund eller er midt i en oppdatering, tar ikke lenger nettstedet med seg i fallet.

Feil 12: Å ignorere nonces og tillatelser

Behandler en kodesnutt skjemainnsendinger eller admin-handlinger, trenger den både en rettighetssjekk og en nonce, og de gjør ulike jobber: WordPress sier at en nonce bekrefter hensikten og hjelper mot cross-site request forgery (CSRF), men aldri skal brukes som tillatelsessjekk. Dårlig:

if (isset($_POST['save_settings'])) {
    update_option('my_setting', $_POST['my_setting']);
}

Bedre, hektet slik at den bare kjører på admin-forespørsler, med wp_nonce_field('minbutikk_lagre_innstillinger') i skjemaet:

add_action('admin_init', function() {
    if (!isset($_POST['minbutikk_lagre_innstillinger'])) {
        return;
    }

    check_admin_referer('minbutikk_lagre_innstillinger');

    if (!current_user_can('manage_options')) {
        return;
    }

    $value = isset($_POST['minbutikk_innstilling']) ? sanitize_text_field(wp_unslash($_POST['minbutikk_innstilling'])) : '';
    update_option('minbutikk_innstilling', $value);
});

Bruk nonce-verifisering i frontend-skjemaer også, men kjenn begrensningen: som standard gir WordPress alle utloggede besøkende den samme nonce-en, så for gjester stopper den ikke falske innsendinger alene.

Feil 13: Å skjule problemer i stedet for å fikse dem

Noen ganger demper folk PHP-advarsler ved å slå av feilrapporteringen:

error_reporting(0);

Det er ingen løsning. På et live nettsted skal feil aldri vises for besøkende, men de skal fortsatt logges, og det er en jobb for PHP selv, ikke for debug-modusen i WordPress: PHP-manualen sier at display_errors aldri skal være på i produksjon, og anbefaler sterkt log_errors i stedet. Gjenskap problemet på staging med WP_DEBUG-innstillingene fra feil 7, og fiks så årsaken. Meldinger som disse peker alle på noe ekte (slik PHP 8.5 skriver dem):

Warning: Undefined array key "redirect_cache"
Warning: Trying to access array offset on null
Warning: Cannot modify header information - headers already sent
Fatal error: Uncaught Error: Call to undefined function is_checkout()
Deprecated: ...

En advarsel som skrives ut, trenger ikke være synlig for å gjøre skade. Inne i et AJAX-, REST- eller feed-svar ødelegger den JSON-en eller XML-en, og output før PHP har sendt headerne sine, stopper senere omdirigeringer og cookies: det er det «headers already sent» betyr.

Feil 14: Å ikke teste etter at kodesnutten er lagt til

Etter at du har lagt til PHP, test området som er berørt og de kritiske flytene. På et vanlig nettsted: forsiden, kontaktskjemaet, navigasjonen, mobilmenyen, admin-tilgang, innlogging og utlogging, og sideredigering. I WooCommerce: produktsiden, legg i handlekurv, handlekurven, kassen, valg av betalingsmetode, bestilling, takkesiden, e-postvarsler og både innlogget kasse og gjestekasse. På medlems- eller kursnettsteder: innlogging, registrering, kontoområdet, beskyttet innhold og betalings- eller abonnementsflyten. En kodesnutt kan virke på én side og ødelegge en annen.

En tryggere sjekkliste før du limer AI-PHP inn i WordPress

Plassering

• Hvor skal denne koden ligge?
• Er functions.php virkelig riktig sted, eller bør det være en liten egen plugin?

Sikkerhet

• Sjekkes variabler før bruk?
• Valideres eller saniteres input, og escapes output?
• Sjekkes rettigheter, og trengs en nonce?

WordPress-kontekst

• Bruker den riktig hook, og kjører den bare der det trengs?
• Sjekker den plugin-avhengigheter?
• Kan den påvirke admin, AJAX, REST API eller cron?

WooCommerce-kontekst

• Er den skrevet for kassen denne butikken faktisk bruker?
• Bevarer den den innebygde kasseflyten og de skjulte feltene?
• Ble en testbestilling fullført?

Feilsøking

• Skriver den ut noe uventet eller gir den PHP-advarsler?
• Består den php -l, og er feilvisning slått av i produksjon?
• Finnes det en backup før du legger den til?

Kan du ikke svare på disse, trenger kodesnutten gjennomgang før den går live.

Eksempel: Å gjøre en utrygg AI-kodesnutt om til tryggere WordPress-kode

Se for deg at AI gir deg dette:

add_action('wp_head', 'show_customer_id');

function show_customer_id() {
    $id = $_GET['id'];
    echo '<div>Customer ID: ' . $id . '</div>';
}

Den kjører på hver side, antar at id finnes, saniterer ikke input og escaper ikke output, skriver en div inn i <head>, og har et navn uten prefiks. En tryggere versjon:

add_action('wp_footer', 'minbutikk_show_customer_id_notice');

function minbutikk_show_customer_id_notice() {
    if (!is_page('kundeinfo')) {
        return;
    }

    $id = isset($_GET['id']) ? absint($_GET['id']) : 0;

    if (!$id) {
        return;
    }

    echo '<div class="customer-id-notice">';
    echo 'Kunde-ID: ' . esc_html($id);
    echo '</div>';
}

Det er fortsatt bare et eksempel, men det viser tankesettet: sjekk kontekst, valider data, escape output og unngå globale bivirkninger.

Hva du gjør hvis AI-PHP har ødelagt WordPress-nettstedet ditt

1. Fjern den siste kodesnutten. Deaktiver den i snippets-pluginen, eller fjern den fra functions.php via filbehandleren hos webhotellet eller over SFTP. Har en fatal feil stengt deg ute? Siden WordPress 5.2 får administratoren en e-post med lenke til gjenopprettingsmodus, der du kan logge inn mens den ødelagte pluginen eller temaet er satt på pause.
2. Sjekk feilloggen for fatale feil, udefinerte funksjoner, syntaksfeil og uventet output.
3. Gjenopprett en backup hvis skaden er alvorlig.
4. Test de kritiske flytene: frontend, admin, skjemaer, og kassen hvis WooCommerce er aktiv.
5. Skriv kodesnutten om ordentlig i stedet for å lime en ny tilfeldig snutt oppå.

Når du bør be om hjelp

Få en WordPress-utvikler til å gå gjennom AI-generert PHP når den:

• Påvirker kassen i WooCommerce
• Berører innlogging eller omdirigeringer
• Endrer brukerroller eller tillatelser
• Behandler skjemainnsendinger
• Endrer ordredata
• Bruker økter eller cookies
• Legger til .htaccess– eller serverlogikk
• Gir PHP-advarsler eller bryter AJAX eller REST API
• Gjør deg usikker på hvor koden skal ligge

Avsluttende tanker

Behandle AI-generert PHP som et første utkast. En god kodesnutt er riktig plassert, avgrenset til der den trengs, trygg når verdier mangler, sanitert, escapet, bevisst på hooks, testet og lett å fjerne, og en kort gjennomgang før du limer inn er langt billigere enn en krisereparasjon etterpå.

---

Har en AI-kodesnutt allerede ødelagt noe? Vi fikser WordPress til fastpris fra 1 990 kr eks. mva., diagnosen er gratis, og det er ingen fiks, ingen betaling. Gjelder det fatale feil, hvit skjerm eller advarsler, se fikse PHP-feil. Har kodesnutten ikke gått live ennå, send den til oss: vi sjekker hvordan den oppfører seg i ditt faktiske oppsett, og du får et skriftlig tilbud med fast pris før vi starter.

Kilder

Sist kontrollert 12. november 2026.

• WordPress Developer Resources: Validating Data, Sanitizing Data og Escaping Data. Validering framfor sanitering, funksjonene, escaping sent.
• WordPress Developer Resources: Nonces, User Roles and Capabilities og Common Vulnerabilities. Nonces er ingen tillatelsessjekk, gjester deler én nonce, manage_options, XSS.
• WordPress Code Reference: wp_unslash(), wp_magic_quotes(), esc_url_raw() og sanitize_title(). Skråstreker i forespørselsdata, aliaset for sanitize_url(), slugs.
• WordPress Plugin Handbook: Best Practices og Header Requirements. Prefikser, ABSPATH-sjekken, is_admin() er ingen rettighetssjekk, headeren Requires Plugins.
• WordPress Theme Handbook: Theme Functions. functions.php mot en plugin, og child-temaer.
• WordPress Developer Resources: Action Reference, template_redirect og Plugin Handbook: Hooks. Rekkefølgen på hookene, omdirigeringer bare i frontend, filtre må returnere en verdi.
• WordPress Code Reference: wp_safe_redirect() og remove_action(). Tillatte verter og exit; å hekte av krever samme callback og prioritet.
• WordPress Code Reference: wp_is_serving_rest_request() og admin-ajax.php på GitHub. REST_REQUEST først fra parse_request; admin-ajax.php definerer WP_ADMIN.
• WordPress: Debugging in WordPress. WP_DEBUG-innstillingene, logging med error_log(), og ingen debug-verktøy på live nettsteder.
• Make WordPress Core: Fatal Error Recovery Mode in 5.2. E-posten med lenke til gjenopprettingsmodus.
• PHP Manual: Runtime configuration for errors. display_errors av i produksjon, log_errors på.
• PHP Manual: Backward incompatible changes in PHP 8.0, Returning values og header(). Advarsel ved udefinert array-nøkkel, null uten return, headere før output.
• WooCommerce Developer Docs: Customizing checkout fields og Additional checkout fields. Feltene billing_phone og billing_address_2, merknaden om shortcode-kassen, felt-API-et for kasseblokken.
• WooCommerce: Customizing the Cart and Checkout Pages og Checkout block. Blokkene som standard fra 8.3, innstillingen Address Fields.
• WooCommerce Developer Docs: HPOS recipe book og Template structure. Ordremeta via ordreobjektet; endringer i plugin-filer går tapt ved oppdatering.
• WooCommerce Developer Docs: How to check if WooCommerce is active og Conditional tags. woocommerce_init; betingede tagger gir false når de brukes for tidlig.
• WooCommerce: Endless loading/spinner on the checkout page. PHP-advarsler som erstatter JSON-en kassen venter på.
• WooCommerce på GitHub: class-woocommerce.php, checkout/payment.php og class-wc-checkout.php. Når handlekurven lastes; nonce-feltet i kassen og feilmeldingen når det mangler.