Sjekkliste for gjennomgang av AI-generert WordPress-kode

AI kan hjelpe deg å bygge WordPress-funksjoner raskere. Den genererer PHP-kodesnutter, CSS-fikser, JavaScript, WooCommerce-hooks, .htaccess-regler, egendefinerte maler, til og med hele temastrukturer. Men AI-generert kode bør ikke gå rett inn i et live nettsted uten gjennomgang. En kodesnutt kan se riktig ut og likevel bryte checkout, skjemaer, omdirigeringer, AJAX, REST API, innlogging, mobiloppsettet eller plugin-kompatibilitet, og risikoen øker når koden berører WooCommerce, serverregler, brukerdata, betalinger eller temastruktur.

Denne sjekklisten gir deg en praktisk måte å gjennomgå AI-generert WordPress-kode på før den kommer i nærheten av functions.php, en snippets-plugin, en egen plugin, .htaccess, WooCommerce-hooks, temamaler eller JS-en og CSS-en din. Målet er ikke å slutte å bruke AI. Det er å bruke den trygt.

Hvorfor AI-generert WordPress-kode trenger gjennomgang

Et ekte WordPress-nettsted er sjelden enkelt. Det kjører som regel et tema eller child-tema, flere plugins, ofte WooCommerce, kontaktskjemaer, caching, en SEO-plugin, en sikkerhetsplugin, egendefinerte kodesnutter, serverregler, REST API, AJAX-forespørsler, brukerroller, innloggingsoppførsel, mobiloppsett og tredjeparts-skript. AI kan generere kode som fungerer i et rent eksempel og feiler inne i det ekte oppsettet: en PHP-kodesnutt som gir advarsler under checkout-AJAX, en omdirigering som løkker, en .htaccess-regel som blokkerer WooCommerce-forespørsler, JavaScript som kolliderer med WooCommerce-skript, CSS som skjuler checkout-felt, en mal som mangler wp_head() eller wp_footer(), eller et funksjonsnavn som kolliderer med en annen plugin. En rask gjennomgang sparer deg for timer med krisehåndtering senere.

1. Forstå hva koden skal gjøre

Før du legger til noe, skriv hensikten i én setning:

Gjør WooCommerce-telefonfeltet påkrevd.

Hvis du ikke kan forklare hensikten så tydelig, ikke legg til koden ennå. Spør hvilket konkret problem den løser, hvilken side eller funksjon den skal påvirke, hvilke filer den endrer, om det er en design-, funksjonalitets- eller serverendring, hvem den påvirker (besøkende, admins, kunder eller alle), 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». Det er ikke alltid det beste svaret, og plassering betyr noe.

Temarelatert kode

Bruk temafiler til oppsett, malstruktur, frontend-design, menyplasseringer, temastøtte og innlasting av ressurser: header.php, footer.php, front-page.php, page.php, functions.php og assets/-mappene.

Forretningslogikk

Bruk en liten egen plugin til forretningsregler for checkout, ordremetadata, egendefinerte omdirigeringer, skjemabehandling, brukerrollelogikk, egendefinerte innholdstyper og gjenbrukbar funksjonalitet.

WooCommerce-endringer

Bruk WooCommerce-hooks og -filtre til checkout-felt, tekst på ordrebekreftelsessiden, e-postmetadata, endringer i produktvisning og handlekurv-oppførsel.

Serverregler

Bruk .htaccess kun når endringen virkelig hører hjemme på servernivå. Før du legger til kode, spør om dette er temaoppførsel eller nettstedsfunksjonalitet, om det forsvinner hvis temaet endres, om det er tryggere som en egen plugin, og om det er et problem på servernivå eller WordPress-nivå. Feil plassering gjør nettstedet vanskeligere å vedlikeholde.

3. Sjekk om koden bruker WordPress-hooks riktig

WordPress-kode kjører som regel gjennom hooks. Vanlige:

init
wp_loaded
wp_enqueue_scripts
template_redirect
wp_head
wp_footer
admin_init
save_post

WooCommerce-hooks inkluderer:

woocommerce_checkout_fields
woocommerce_before_checkout_form
woocommerce_after_checkout_form
woocommerce_thankyou
woocommerce_email_order_meta
woocommerce_checkout_update_order_meta

Hooken styrer når koden kjører. Feil hook gjør at den kjører for tidlig, for sent, på feil side, under AJAX, under admin-forespørsler, før WooCommerce er tilgjengelig, eller etter at output allerede har startet. Denne omdirigeringen er for bred:

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

En tryggere versjon trenger betingelser:

add_action('template_redirect', function() {
    if (is_admin() || wp_doing_ajax()) {
        return;
    }

    if (is_user_logged_in()) {
        return;
    }

    if (is_page('login')) {
        return;
    }

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

Før du bruker AI-hook-kode, sjekk at hooken passer, at den kjører bare der det trengs, at den ikke påvirker AJAX, REST API eller admin, at den ikke er avhengig av at WooCommerce er lastet for tidlig, og at den ikke skriver ut noe før den skal.

4. Sjekk variabelsikkerhet

AI-generert PHP antar ofte at data finnes:

$id = $_GET['id'];

Dette gir en advarsel hvis id mangler. Tryggere:

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

Sjekk hver eksterne datakilde: $_GET, $_POST, $_REQUEST, $_SESSION, $_COOKIE, $order->get_meta(), get_option() og get_user_meta(). Spør om nøkkelen finnes, hva som skjer hvis den mangler, om verdien er av forventet type, om det finnes en fallback, og om det kan skape en PHP-advarsel. Små advarsler kan bryte AJAX og WooCommerce checkout-responser.

5. Sjekk sanitering

Sanitering betyr å rense input før den lagres eller brukes. Vanlige funksjoner:

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

Dårlig:

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

Bedre:

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

Tilpass funksjonen til datatypen, og før du bruker AI-kode, spør om den behandler brukerinput, lagrer data, leser fra URL-parametere eller skjemadata, og saniterer basert på type. Hvis ikke, gå gjennom den før utrulling.

6. Sjekk escaping

Escaping gjør output trygg før den vises. Dårlig:

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

Bedre:

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

For attributter, bruk esc_attr(); for URL-er, bruk esc_url():

echo '<a href="' . esc_url($url) . '">Besøk siden</a>';

For begrenset trygg HTML, bruk wp_kses_post(). Spør om koden skriver ut dynamiske data, om outputen escapes, om escaping-funksjonen passer, og om brukerinput kan skrives ut på siden. AI-eksempler hopper over escaping for enkelhets skyld; produksjonskode skal ikke det.

7. Sjekk funksjonsnavn

AI genererer ofte generiske navn som custom_checkout_fields(), som kan kollidere med en annen plugin eller kodesnutt og forårsake:

Fatal error: Cannot redeclare custom_checkout_fields()

Bruk unike prefikser, for eksempel webnorly_custom_checkout_fields() eller et prosjektspesifikt wn_fix_checkout_phone_field(). Sjekk at funksjonsnavn, klassenavn og konstanter er unike, at CSS-klasser neppe kolliderer, og at globale JavaScript-variabler unngås.

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

WooCommerce-betingelser som is_product() finnes kanskje ikke hvis WooCommerce er deaktivert, så sjekk først:

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

Sjekk om koden er avhengig av WooCommerce, Elementor, Contact Form 7, ACF, WPML eller Polylang, medlemskapsplugins, betalingsplugins eller egendefinerte innholdstyper, og hva som skjer hvis den pluginen deaktiveres eller oppdateres. Dette forhindrer fatale feil.

9. Sjekk AJAX- og REST API-sikkerhet

Dette er kritisk for WordPress og WooCommerce. Noen forespørsler forventer JSON, så kode som skriver ut HTML, advarsler eller debug-tekst under dem, kan bryte funksjonen. Unngå dette:

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

Og ikke la disse bli liggende i live kode:

var_dump($data);
print_r($order);
die();

Foretrekk loggen:

error_log(print_r($data, true));

Sjekk om koden skriver ut noe globalt, om den kan kjøre under AJAX- eller REST API-forespørsler, og om den kan legge til advarsler før JSON-output. Nyttige vakter:

if (wp_doing_ajax()) {
    return;
}

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

Bruk disse bare når det passer, men tenk alltid på dynamiske forespørsler.

10. Sjekk omdirigeringslogikk

Omdirigerings-kodesnutter kan være farlige. Denne omdirigerer alt:

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

Den kan bryte forsiden, innloggingssiden, adminområdet, checkout, handlekurv, AJAX, REST API, retur fra betalingsgateway og takkesider. En tryggere omdirigering har klare unntak:

add_action('template_redirect', function() {
    if (is_admin() || wp_doing_ajax()) {
        return;
    }

    if (is_user_logged_in()) {
        return;
    }

    if (is_page('login')) {
        return;
    }

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

Sjekk at den bruker wp_safe_redirect(), kaller exit etterpå, ekskluderer admin og AJAX og målsiden, ikke påvirker checkout eller retur-URL-er fra betaling, og ikke kan lage en løkke.

11. Sjekk .htaccess-regler nøye

AI-generert .htaccess fortjener ekstra forsiktighet, fordi en liten rewrite påvirker hver forespørsel før WordPress lastes:

RewriteRule ^$ /home.html [L]

Dette kan tvinge forsiden til en statisk fil og forstyrre dynamiske forespørsler avhengig av den fulle regelkonteksten. Akkurat det mønsteret sporet vi i en checkout-sak der rewriten fanget opp WooCommerce-AJAX. Sjekk om regelen kan påvirke:

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

Før du endrer .htaccess, ta en backup, endre én ting av gangen, test permalenker, innlogging og checkout hvis WooCommerce finnes, tøm cache, og bekreft at det ikke er omdirigeringsløkker. For mange problemer er en WordPress-nativ løsning tryggere enn en server-rewrite.

12. Sjekk CSS-omfang

AI-generert CSS kan se fin ut, men nå for langt:

button {
    display: none;
}

Det kan skjule knapper på hele nettstedet, inkludert checkout. Denne er også risikabel:

input {
    width: 100%;
    border: none;
}

Den kan påvirke søk, checkout, innlogging og andre skjemaer. Avgrens den i stedet:

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

Sjekk om selektorene er for brede, om de påvirker WooCommerce, skjemaer eller mobil, om de skjuler viktige elementer, og om de skaper horisontal scrolling. CSS bør avgrenses til seksjonen eller siden den skal endre.

13. Sjekk JavaScript-avhengigheter

AI-JavaScript kan anta at elementer finnes eller at biblioteker er lastet. Dårlig:

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

Hvis .menu-button ikke finnes, kaster dette en feil. Tryggere:

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

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

Sjekk om skriptet verifiserer at elementer finnes, om det er avhengig av jQuery og om jQuery er tilgjengelig, om det kjører før eller etter DOM-en, om det kolliderer med WooCommerce-skript, og om det er enqueue-et riktig. Bruk wp_enqueue_script() i stedet for å hardkode skript inn i maler.

14. Sjekk WooCommerce-spesifikk påvirkning

WooCommerce er sensitivt fordi checkouten er dynamisk. Før du legger til AI-kode, sjekk om den påvirker handlekurv-økten, checkout-felt, betalings- eller fraktmetoder, ordretotal, rabattkoder, ordreopprettelse, takkesiden, e-poster eller kontosider. For endringer i checkout-felt, bruk filteret:

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

For meldinger på takkesiden, bruk hooken med en vakt og escaping:

add_action('woocommerce_thankyou', function($order_id) {
    if (!$order_id) {
        return;
    }

    echo '<div class="custom-thankyou-message">';
    echo esc_html__('Thank you for your order.', 'textdomain');
    echo '</div>';
});

Etter at du har lagt til WooCommerce-kode, test alltid hele løypa, ikke bare om checkout-siden laster:

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

15. Sjekk ytelsespåvirkning

AI-kode kan fungere, men likevel gjøre nettstedet tregere. Se opp for databasespørringer på hver side, eksterne API-kall ved sidelasting, store inline-skript, ressurser lastet overalt, tunge løkker, gjentatte get_posts()– eller WP_Query-kall, og dyre operasjoner uten caching. Dette er et dårlig mønster:

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

Spør om den kjører på hver side, om den spør databasen eller laster eksterne ressurser, om den kan begrenses til én side, om resultatene kan caches, og om utloggede brukere i det hele tatt trenger den. Koden bør løse problemet uten å gjøre nettstedet tregere.

16. Sjekk sikkerhet og tillatelser

Hvis koden endrer innstillinger, lagrer data, behandler skjemaer eller utfører admin-handlinger, trenger den tillatelsessjekker (ofte current_user_can('manage_options')) og nonce-verifisering. Dårlig:

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

Bedre:

if (isset($_POST['save_settings'])) {
    check_admin_referer('save_my_settings');

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

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

Spør om hvilken som helst besøkende kan utløse den, om den krever innlogging eller en admin-rettighet, om en nonce trengs, og om input saniteres og output escapes. AI skriver ofte forenklede eksempler som hopper over disse detaljene.

17. Sjekk oversettelsesklarhet

På flerspråklige eller ikke-engelske nettsteder skaper hardkodet tekst problemer. Dårlig:

echo 'Thank you for your order.';

Bedre:

echo esc_html__('Thank you for your order.', 'webnorly');

For dynamisk tekst:

printf(
    esc_html__('Order number: %s', 'webnorly'),
    esc_html($order_number)
);

Sjekk om frontend-tekst er hardkodet, om nettstedet bruker flere språk, om text domain er riktig, og om teksten heller bør være redigerbar i admin. (Kildestrengen skrives på engelsk og oversettes via språkfiler, slik WordPress sin i18n er ment å fungere.)

18. Sjekk feilhåndtering

God kode feiler trygt. Spør hva som skjer hvis data mangler, hvis et API feiler, hvis pluginen er inaktiv, hvis brukeren ikke er innlogget, hvis handlekurven er tom, eller hvis ordre-ID-en er ugyldig. Dårlig:

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

Hvis $order er false, ryker dette. Bedre:

$order = wc_get_order($order_id);

if (!$order) {
    return;
}

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

AI-kode antar ofte den lykkelige stien. Ekte WordPress-kode bør også håndtere feilstiene.

19. Test på staging først

Det tryggeste stedet å teste AI-generert kode er et staging-nettsted, der du kan fange PHP-feil, layoutendringer, checkout-problemer, mobilproblemer, pluginkonflikter, omdirigeringer og cache-oppførsel uten å risikere det live nettstedet. For WooCommerce betyr dette mest, fordi checkout-problemer koster ekte ordrer. Før du ruller ut til live: ta backup av filer og database, test på staging, dokumenter de endrede filene, distribuer i lavtrafikk, tøm cache, og test de kritiske flytene på nytt.

20. Ha en plan for tilbakerulling

Før du legger til AI-kode, vit hvordan du angrer den: en full backup av nettstedet, en Git-commit, en kopi av den gamle filen, en deaktivert kodesnutt, eller en backup av .htaccess. For små endringer, behold en kopi som:

functions-before-ai-snippet.php
.htaccess-backup-before-ai-rule

For større prosjekter, bruk Git. En plan for tilbakerulling gjør en risikabel endring om til en kontrollert en.

Rask sjekkliste for gjennomgang av AI-WordPress-kode

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 saniteres.
• Output escapes.
• Funksjonsnavn er unike.
• 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.
• WooCommerce-flyten er bevart.
• Ytelsespåvirkningen er akseptabel.
• Tillatelser og nonces brukes der det trengs.
• Tekst er oversettelsesklar der det er relevant.
• Feil håndteres trygt.
• Den ble testet på staging, og det finnes en plan for tilbakerulling.

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

Hva du gjør hvis AI-kode allerede ødela nettstedet ditt

Hvis nettstedet ryker etter at du la til AI-generert kode, jobb deg gjennom det i rekkefølge:

1. Fjern eller deaktiver den siste endringen.
2. Gjenopprett den forrige filen om nødvendig.
3. Sjekk PHP-feilloggene.
4. Tøm cache.
5. Test den ødelagte flyten på nytt.
6. Gå gjennom koden før du legger den til igjen.
7. Unngå å stable flere AI-kodesnutter oppå den ødelagte.

Vanlige steder å sjekke:

functions.php
Code Snippets plugin
custom plugin files
.htaccess
theme templates
assets/js/
assets/css/

Hvis adminområdet er utilgjengelig, bruk hostingleverandørens File Manager eller FTP for å fjerne koden manuelt.

Avsluttende tanker

AI-generert WordPress-kode kan være nyttig, men den bør gjennom den samme gjennomgangen som all annen kode, og jo raskere den genereres, jo viktigere blir gjennomgangen. En god gjennomgang sjekker plassering, sikkerhet, hooks, kontekst, sikkerhet, plugin-kompatibilitet, WooCommerce-påvirkning, ytelse, mobiloppførsel og planen for tilbakerulling. AI hjelper deg å bygge raskere, men WordPress trenger fortsatt struktur, testing og nøye implementering.

---

Hvis du har AI-generert WordPress-kode og er usikker på om den er trygg, kan Webnorly gå gjennom den, rydde opp i den og hjelpe deg å bruke den uten å ødelegge nettstedet ditt. Send oss koden, så sjekker vi den mot ditt faktiske oppsett før den går live.