Sjekkliste for gjennomgang av AI-generert WordPress-kode

AI skriver en WordPress-funksjon for deg på sekunder: PHP-kodesnutter, CSS-fikser, JavaScript, WooCommerce-hooks, .htaccess-regler, til og med hele maler. Koden kan se riktig ut og likevel bryte kassen, skjemaer, omdirigeringer, AJAX, REST API, innloggingen eller mobiloppsettet, og risikoen øker når den berører WooCommerce, serverregler, brukerdata eller betalinger.

Denne sjekklisten gir deg en praktisk måte å gå gjennom AI-generert kode på før den kommer i nærheten av functions.php, en snippets-plugin, en egen plugin, .htaccess, temamaler eller JS-en og CSS-en din. Bruk gjerne AI videre, men se over det du får før kundene dine ser det. Gjelder det PHP-kodesnutter spesielt, går vi dypere i hva du bør sjekke før du limer AI-generert PHP inn i WordPress.

Hvorfor AI-generert WordPress-kode trenger gjennomgang

Et ekte nettsted kjører et tema, en rekke plugins, ofte WooCommerce, caching, AJAX, REST API og tredjepartsskript. AI skriver for et rent eksempel, og avstanden viser seg som advarsler i kassen, omdirigeringsløkker, blokkerte forespørsler eller funksjonsnavn som kolliderer. En rask gjennomgang er billigere enn krisefeilsøking.

1. Forstå hva koden skal gjøre

Skriv hensikten i én setning:

Gjør WooCommerce-telefonfeltet påkrevd.

Klarer du ikke det, så vent med koden. Vær tydelig på hvilken side eller funksjon den skal påvirke, hvilke filer den endrer, om det er en design-, funksjonalitets- eller serverendring, hvem den påvirker, og om den må kjøre overalt eller bare på én side. God kode har et klart omfang.

2. Sjekk hvor koden skal ligge

AI sier ofte «legg dette i functions.php». WordPress sin temahåndbok forklarer avveiningen: functions.php i et tema kjører bare mens temaet er aktivt, så bytter du tema, forsvinner funksjonen med det, og funksjoner som skal virke uansett hvordan nettstedet ser ut, hører hjemme i en plugin. En praktisk fordeling:

• Temafiler til oppsett, maler, menyer og innlasting av ressurser. Har du ikke skrevet temaet selv, bruk et child-tema, så neste temaoppdatering ikke sletter endringen din.
• En liten egen plugin til forretningslogikk: regler i kassen, ordremetadata, omdirigeringer, skjemabehandling, brukerroller og egendefinerte innholdstyper.
• WooCommerce-hooks og -filtre til kassefelt, e-poster og handlekurven, når du vet hvilken kasse butikken bruker (punkt 14).
• .htaccess bare til endringer som virkelig hører hjemme på servernivå.

3. Sjekk om koden bruker WordPress-hooks riktig

WordPress-kode kjører gjennom hooks, og hooken avgjør når koden kjører. De seks første under kjører i denne rekkefølgen når en side lastes i frontend; admin_init hører til admin-forespørsler og save_post til lagring av innhold:

init
wp_loaded
template_redirect
wp_enqueue_scripts
wp_head
wp_footer
admin_init
save_post

WooCommerce-hooks AI liker å bruke (kasse-hookene hører til den klassiske kassen, se punkt 14):

woocommerce_checkout_fields
woocommerce_before_checkout_form
woocommerce_after_checkout_form
woocommerce_thankyou
woocommerce_email_order_meta
woocommerce_checkout_update_order_meta

Feil hook kjører koden for tidlig, for sent, på feil side, under AJAX- eller admin-forespørsler, eller før WooCommerce er klar. Denne omdirigeringen er hektet altfor bredt:

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

init kjører både på frontend-sider og i wp-admin, og før WordPress svarer på et REST API-kall, så dette sender alle sammen, også /login/, til /login/. Nettstedet går i løkke, og wp-admin blir utilgjengelig. En sjekk som is_page('login') redder det heller ikke: betingede tagger virker først når WordPress har kjørt spørringen sin, og før det gir de bare false, uten noen advarsel. WordPress sin dokumentasjon peker på template_redirect som hooken for omdirigeringer; punkt 10 viser en trygg versjon.

4. Sjekk variabelsikkerhet

AI-generert PHP antar ofte at data finnes:

$id = $_GET['id'];

Mangler id, gir PHP 8 advarselen Warning: Undefined array key "id". Tryggere:

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

Behandle $_POST, $_SESSION, $_COOKIE, ordremeta, innstillinger og brukermeta på samme måte: finnes nøkkelen, er verdien av forventet type, og hva skjer hvis den mangler? Der bare noen få verdier gir mening, valider mot en liste. WordPress foretrekker validering framfor sanitering og anbefaler en streng in_array()-sjekk til dette. Små advarsler betyr noe: en PHP-advarsel som skrives inn i et AJAX-svar fra WooCommerce, er en av årsakene WooCommerce selv lister opp når kassen aldri blir ferdig med å laste.

5. Sjekk sanitering

Sanitering renser input før du lagrer eller bruker den. Vanlige funksjoner:

sanitize_text_field()
sanitize_email()
sanitize_key()
sanitize_title()
absint()
sanitize_url()
wp_kses_post()

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

To detaljer AI ofte bommer på. WordPress legger til skråstreker i $_GET, $_POST og $_COOKIE, så fjern dem med wp_unslash() før du saniterer. Og velg funksjon etter data: sanitize_title() gjør en streng om til en slug, så den passer ikke til en produkttittel, mens sanitize_url() (esc_url_raw() er et alias) er riktig for en URL du skal lagre.

6. Sjekk escaping

Escaping gjør output trygg i det øyeblikket den skrives ut. Dårlig:

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

Bedre:

echo '<p>' . esc_html($message) . '</p>';

Bruk esc_attr() for attributter, esc_url() for URL-er og wp_kses_post() for begrenset HTML. Regelen i WordPress er å escape så sent som mulig, helst på linjen som skriver ut verdien, så den som går gjennom koden ser med én gang at den er trygg. Output som ikke escapes, er veien inn for cross-site scripting (XSS), og AI-eksempler hopper ofte over escaping for å holde seg korte.

7. Sjekk funksjonsnavn

AI liker generiske navn som custom_checkout_fields(). Har en annen plugin allerede deklarert den funksjonen, stopper PHP med en fatal feil. Slik formulerer PHP 8.5 det:

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

Plugin-håndboken til WordPress ber deg sette prefiks på alt som er globalt (funksjoner, klasser, globale variabler, innstillinger og transients), med minst fire bokstaver, helst fem, og ikke et vanlig engelsk ord: minbutikk_fix_checkout_phone_field(), ikke et prefiks på to bokstaver. Se også opp for AI som pakker hver funksjon inn i if (!function_exists(...)). Håndboken kaller det en fatal svakhet: lastes en funksjon med samme navn først, blir din aldri definert, og koden din ryker.

8. Sjekk plugin-avhengigheter

AI-kode kan kalle plugin-funksjoner som bare finnes når pluginen er aktiv:

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

Sett en vakt rundt den:

if (!function_exists('WC') || !WC()->cart) {
    return;
}

Begge delene trengs. WooCommerce kan være deaktivert, og WooCommerce laster handlekurven bare for frontend- og AJAX-forespørsler, fra init og utover, så i wp-admin og i cron-jobber er WC()->cart null. Betingelser som is_product() finnes heller ikke uten WooCommerce, så sjekk function_exists('is_product') først. For en kodeblokk som bare gir mening med WooCommerce, foreslår WooCommerce sin utviklerdokumentasjon hooken woocommerce_init, som bare kjører når WooCommerce er aktiv.

9. Sjekk AJAX- og REST API-sikkerhet

AJAX- og REST-forespørsler forventer ren JSON, så kode som skriver ut HTML, advarsler eller debug-tekst under dem, bryter funksjonen. Unngå dette:

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

La aldri var_dump(), print_r() eller die() bli liggende i live kode. Logg i stedet:

error_log(print_r($data, true));

Nyttige vakter, når koden ikke skal kjøre under slike forespørsler:

if (wp_doing_ajax()) {
    return;
}

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

Vit hva de dekker. wp_doing_ajax() gir true for forespørsler til admin-ajax.php og, fra init og utover, for ?wc-ajax=-forespørslene den klassiske kassen bruker. REST-sjekken virker først fra parse_request og utover, der WordPress definerer REST_REQUEST; på init er den alltid false. wp_is_serving_rest_request() (WordPress 6.5) har samme tidsregel. Det betyr noe for kasseblokken, som snakker med WooCommerce gjennom Store API under /wp-json/wc/store/.

10. Sjekk omdirigeringslogikk

En omdirigering kan være farlig selv på riktig hook. Denne har ingen betingelser:

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

template_redirect kjører bare når en frontend-side skal lastes, så wp-admin og REST API-kall når aldri fram dit. Alle frontend-adresser gjør det: handlekurven, kassen, ordrebekreftelsen en gjest lander på etter å ha betalt, og /login/ selv, som nå går i løkke. En tryggere versjon:

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 (alt annet havner i wp-admin), og ingen av omdirigeringsfunksjonene stopper skriptet selv, så exit må følge rett etter. Sjekk at alle unntakene nettstedet trenger, er med, og at ingenting kan gå i løkke.

11. Sjekk .htaccess-regler nøye

På Apache avgjør .htaccess-reglene hvordan en forespørsel serveres før WordPress får håndtere den, så én AI-generert linje kan treffe hver eneste forespørsel:

RewriteRule ^$ /home.html [L]

Akkurat den regelen sporet vi i en kassesak der rewriten fanget opp WooCommerce-AJAX. Den var ment for en statisk forside, men traff også forespørslene den klassiske kassen sender til rota av nettstedet (/?wc-ajax=update_order_review), så kassen fikk HTML i stedet for JSON. Test enhver ny regel mot:

/wp-admin/
/wp-login.php
/wp-json/
/cart/
/checkout/
/my-account/
/?wc-ajax=

Ta backup av fila, endre én ting av gangen, tøm cache og sjekk for løkker. Innlegget vårt om hvordan AI-genererte .htaccess-regler kan ødelegge WordPress går gjennom de vanlige feilene én for én.

12. Sjekk CSS-omfang

AI-generert CSS kan nå for langt:

button {
    display: none;
}

Det skjuler alle knapper på nettstedet, også i kassen. Avgrens reglene til seksjonen de skal endre:

.woocommerce-checkout .form-row input {
    width: 100%;
}

Se etter selektorer som er for brede, skjuler viktige elementer eller gir horisontal scrolling på mobil.

13. Sjekk JavaScript-avhengigheter

AI-JavaScript kan anta at elementer finnes. Dårlig:

document.querySelector('.menu-button').addEventListener('click', function() {
    document.querySelector('.menu').classList.toggle('open');
});

querySelector() returnerer null når ingenting matcher, så på hver side uten .menu-button kaster dette en feil, og resten av skriptet stopper. Tryggere:

const menuButton = document.querySelector('.menu-button');
const menu = document.querySelector('.menu');

if (menuButton && menu) {
    menuButton.addEventListener('click', function() {
        menu.classList.toggle('open');
    });
}

Last inn skript med wp_enqueue_script() på hooken wp_enqueue_scripts, med jQuery eller andre biblioteker i avhengighetslisten, i stedet for å hardkode en script-tagg inn i en mal.

14. Sjekk påvirkningen på WooCommerce

Sjekk om koden berører handlekurv-økten, kassefelt, betalings- eller fraktmetoder, totaler, rabattkoder, ordreopprettelse, takkesiden eller e-poster. Sjekk deretter hvilken kasse butikken bruker, for AI skriver som regel for den klassiske. Butikker satt opp etter WooCommerce 8.3 (november 2023) får handlekurv- og kasseblokkene som standard, mens filteret AI griper etter først, er dokumentert for shortcode-kassen:

add_filter('woocommerce_checkout_fields', function($fields) {
    return $fields;
});

I kasseblokken 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, og nye felt legges til via Additional Checkout Fields API. WooCommerce skriver også at tilpasninger som bruker hooks i handlekurven og kassen, som regel krever ekstra arbeid for å virke med blokkene. Test derfor en kodesnutt skrevet for den klassiske kassen på den kassen kundene dine faktisk ser.

Ordredata har en lignende felle. AI lagrer ofte ordredetaljer med update_post_meta(), men siden WooCommerce 8.2 lagrer nye butikker ordrer i egne tabeller (High-Performance Order Storage, HPOS), og WooCommerce advarer om at det å skrive rett til de gamle innleggstabellene kan oppdatere en ordre som aldri blir lest. Bruk $order->update_meta_data() og $order->save(). Test hele løypa etter hver WooCommerce-endring:

Produkt → Handlekurv → Kasse → Betaling → Ordre mottatt → E-post

15. Sjekk ytelsespåvirkning

Kode kan fungere og likevel gjøre nettstedet tregere: spørringer eller API-kall på hver side, ressurser lastet overalt, tunge løkker, ingen caching. Et dårlig mønster:

add_action('wp_footer', function() {
    $orders = wc_get_orders(array('limit' => -1));
    // skriv ut noe
});

I wc_get_orders() betyr en grense på -1 ingen grense: hver eneste ordre i butikken, på hver sidevisning. WooCommerce anbefaler å begrense og paginere ordrespørringer og cache resultatene der det gir mening. Spør om koden i det hele tatt må kjøre på hver side.

16. Sjekk sikkerhet og tillatelser

Kode som endrer innstillinger, lagrer data, behandler skjemaer eller utfører admin-handlinger, trenger to separate sjekker: en rettighetssjekk (for innstillinger som regel current_user_can('manage_options')) og en nonce. WordPress er tydelig på at en nonce bekrefter at brukeren faktisk mener handlingen 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') skrevet ut 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);
});

Bygger koden sin egen SQL, må hver variabel gjennom $wpdb->prepare(), og der en WordPress-funksjon allerede gjør jobben, bruk funksjonen. AI-eksempler hopper over slike detaljer fordi de er skrevet for å være korte.

17. Sjekk oversettelsesklarhet

Hardkodet tekst skaper problemer på flerspråklige nettsteder. Pakk den inn i en oversettelsesfunksjon med pluginens tekstdomene, som WordPress krever er lik pluginens slug, og forklar plassholderne for oversetterne. Selve kildestrengen skrives på engelsk (håndboken ber om «decent English style»), og den norske teksten kommer fra språkfilene:

printf(
    /* translators: %s: order number */
    esc_html__('Order number: %s', 'min-plugin'),
    esc_html($order_number)
);

18. Sjekk feilhåndtering

God kode feiler trygt når data mangler, et API feiler, en plugin er inaktiv, handlekurven er tom eller en ID er ugyldig. Dårlig:

$order = wc_get_order($order_id);
echo $order->get_billing_email();

wc_get_order() returnerer false når ordren ikke finnes, og neste linje stopper siden med «Call to a member function get_billing_email() on false». Bedre:

$order = wc_get_order($order_id);

if (!$order) {
    return;
}

echo esc_html($order->get_billing_email());

19. Test på staging først

En staging-kopi lar deg fange PHP-feil, layoutendringer, kasseproblemer, pluginkonflikter, omdirigeringer og cache-oppførsel uten å sette ekte ordrer på spill. WordPress sin egen feilsøkingsguide starter med samme råd: bruk et staging-miljø eller ta backup før du endrer noe. Rull så ut i en rolig periode, tøm cache og test de kritiske flytene på nytt.

20. Ha en plan for tilbakerulling

Vit hvordan du angrer endringen før du gjør den: en full backup, en Git-commit, en kopi av den gamle filen, en deaktivert kodesnutt eller en lagret kopi av .htaccess. For alt som er større enn en kodesnutt, bruk Git. En plan for tilbakerulling gjør en risikabel endring om til en kontrollert en.

La verktøyene ta første runde

To gratis sjekker fanger mye før noen leser en eneste linje. php -l fil.php sjekker syntaksen uten å kjøre koden: en manglende parentes eller et semikolon, men ikke feil som først viser seg når koden kjører, som et kall til en funksjon som ikke finnes. Kjør deretter PHP_CodeSniffer med WordPress Coding Standards (vendor/bin/phpcs --standard=WordPress fil.php). Reglene flagger output som ikke escapes, skjemabehandling uten nonce-sjekk, input som ikke saniteres, omdirigeringer som burde bruke wp_safe_redirect() og globale navn uten prefiks.

Rask sjekkliste for gjennomgang av AI-kode i WordPress

Før du legger til AI-kode, bekreft:

• Jeg forstår hva koden gjør.
• Jeg vet hvor koden skal ligge.
• Den bruker riktig WordPress-hook.
• Den kjører bare der det trengs.
• Variabler sjekkes før bruk.
• Brukerinput valideres eller saniteres.
• Output escapes.
• Funksjonsnavn har et unikt prefiks.
• Plugin-avhengigheter sjekkes.
• Den skriver ikke ut noe under AJAX- eller REST-forespørsler.
• Omdirigeringer har trygge betingelser.
• .htaccess-endringer er sikkerhetskopiert og testet.
• CSS-selektorer er avgrenset.
• JavaScript sjekker elementer før de brukes.
• Den virker med kassen butikken faktisk bruker.
• Ytelsespåvirkningen er akseptabel.
• Rettigheter og nonces sjekkes der det trengs.
• Tekst er oversettelsesklar der det er relevant.
• Feil håndteres trygt.
• Den har bestått php -l og PHPCS, er testet på staging, og det finnes en plan for tilbakerulling.

Er selv ett viktig punkt uklart, stopp og gå gjennom koden før den går live.

Hva du gjør hvis AI-kode allerede har ødelagt nettstedet

1. Fjern eller deaktiver den siste endringen, og gjenopprett den forrige filen om nødvendig.
2. Sjekk PHP-feilloggen.
3. Tøm cache og test den ødelagte flyten på nytt.
4. Gå ordentlig gjennom koden før du legger den inn igjen, i stedet for å stable en ny AI-kodesnutt oppå.

De vanlige mistenkte er functions.php, en snippets-plugin, egne plugin-filer, .htaccess, temamaler og temaets JS og CSS. Har en fatal feil stengt deg ute av wp-admin? 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. Ellers fjerner du koden via filbehandleren hos webhotellet eller over SFTP.

Avsluttende tanker

AI-generert kode fortjener den samme gjennomgangen som all annen kode, og jo raskere den kommer, jo viktigere blir gjennomgangen.

---

Har AI-skrevet kode 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 eller hvit skjerm, se fikse PHP-feil. Har koden ikke gått live ennå, send den til oss først: vi sjekker den mot 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 og Sanitizing Data. Validering først, streng in_array(), saniteringsfunksjonene.
• WordPress Developer Resources: Escaping Data. Escaping-funksjonene og å escape sent.
• WordPress Developer Resources: Nonces, User Roles and Capabilities og Common Vulnerabilities. Nonces er ingen tillatelsessjekk; manage_options; XSS; $wpdb->prepare().
• 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. Prefiks på minst fire bokstaver og function_exists()-fella.
• WordPress Plugin Handbook: How to Internationalize Your Plugin. Tekstdomene, oversetterkommentarer og engelske kildestrenger.
• WordPress Theme Handbook: Theme Functions. functions.php mot en plugin, og child-temaer.
• WordPress Developer Resources: Action Reference og template_redirect. Rekkefølgen på hookene, admin-forespørsler og hooken for omdirigeringer.
• WordPress Code Reference: wp_safe_redirect(). Bare tillatte verter, reserveadressen i wp-admin og exit etterpå.
• WordPress Code Reference: wp_doing_ajax(), wp_is_serving_rest_request() og rest_api_loaded(). Hva vaktene tester, og når REST_REQUEST finnes.
• WordPress Code Reference: wp_enqueue_script(). Avhengigheter og hooken wp_enqueue_scripts.
• WordPress: Debugging in WordPress. Staging eller backup først; error_log(print_r($data, true)).
• WordPress: Apache HTTPD / .htaccess. Hvordan WordPress bruker .htaccess med Apache.
• Make WordPress Core: Fatal Error Recovery Mode in 5.2. E-posten med lenke til gjenopprettingsmodus.
• WordPress Coding Standards for PHP_CodeSniffer med reglene for sikkerhet og navngiving. phpcs-kommandoen og hva reglene sjekker.
• PHP Manual: Backward incompatible changes in PHP 8.0 og Command line options. Advarsel ved udefinert array-nøkkel; php -l sjekker bare syntaks.
• WooCommerce Developer Docs: Customizing checkout fields og Additional checkout fields. Filteret for shortcode-kassen og felt-API-et for kasseblokken.
• WooCommerce: Customizing the Cart and Checkout Pages og Checkout block. Blokkene som standard fra 8.3, og innstillingen Address Fields.
• WooCommerce Developer Docs: High-Performance Order Storage og recipe book. Standard fra 8.2; ordremeta via ordreobjektet.
• WooCommerce Developer Docs: How to check if WooCommerce is active og Conditional tags. Hooken woocommerce_init; is_cart(), is_checkout(), endepunkter, og betingede tagger som gir false når de brukes for tidlig.
• WooCommerce: Endless loading/spinner on the checkout page. PHP-advarsler i AJAX-svar; wc-ajax- og Store API-forespørsler.
• WooCommerce Developer Docs: wc_get_orders() og kodereferansen for wc_get_order(). Grense -1 er ubegrenset; wc_get_order() kan gi false.
• WooCommerce på GitHub: class-woocommerce.php og class-wc-ajax.php. Når handlekurven lastes; DOING_AJAX for wc-ajax.
• MDN Web Docs: Document.querySelector(). Gir null når ingenting matcher.