Vanlige feil folk gjør med AI-generert kode i WordPress

AI-verktøy kan bygge raskt. De lager HTML-oppsett, CSS, PHP-kodesnutter, WordPress-hooks, WooCommerce-tilpasninger og hele sidestrukturer på minutter, og den farten er virkelig nyttig. Haken er at WordPress ikke er en mappe med statiske filer. Det er et dynamisk system med ruting, maler, hooks, plugins, AJAX-forespørsler, REST API-endepunkter, cache-lag og innhold fra databasen, og WooCommerce legger handlekurver, kundeøkter og tilbakekall fra betalingsløsninger på toppen. Det er der AI-genererte WordPress-feil pleier å gjemme seg.

Koden kan se riktig ut. Forsiden laster og designet ser polert ut, mens en skjult rutingregel, en utrygg PHP-snutt eller en feilplassert mal i det stille ødelegger kassen, skjemaer, innlogging, søk eller mobilvisningen.

I en WooCommerce-sak vi jobbet med lastet kassen i det uendelige. Årsaken var verken betalingsleverandøren eller WooCommerce. En enkelt linje i .htaccess, lagt inn noen år tidligere for å servere forsiden som en statisk HTML-fil, fanget opp WooCommerce sine AJAX-forespørsler og svarte med forsiden. Ber du et AI-verktøy om en raskere forside, kan du få den samme snarveien, og den ødelegger kassen på samme måte.

Under går vi gjennom 12 vanlige feil folk gjør med AI-generert kode i WordPress, hvorfor hver enkelt betyr noe, og en tryggere måte å jobbe på. Der et tema trenger mer plass, lenker vi til et eget innlegg.

Den egentlige risikoen er kode ingen har gått gjennom

AI-generert kode er ikke dårlig i seg selv. Den er god til sideseksjoner, CSS-oppsett, enkle PHP-snutter, grunnfiler til et tema, forklaringer av feilmeldinger og første utkast til WooCommerce-tilpasninger. Problemene starter når koden går rett inn på et live nettsted. Et ekte WordPress-nettsted har et tema (ofte et barnetema), plugins, WooCommerce, cache, sikkerhetsverktøy, CDN, .htaccess– eller Nginx-regler, egne kodesnutter, betalingslogikk, skjemaer og analyseskript. Kode som virker i et rent demomiljø, kan svikte der, og derfor trenger AI-generert kode gjennomgang, testing og riktig plassering.

Feil 1: Å behandle WordPress som et statisk HTML-nettsted

Noen lager en pen home.html med AI, laster den opp og legger til en rewrite-regel slik at forsiden lastes rett fra den filen. Det virker smart: forsiden er rask og hopper helt over WordPress. Men WordPress gjør langt mer enn å skrive ut sider. Det håndterer query-variabler, permalenker, AJAX, REST API-ruter, innlogging, skjemainnsendinger og sider fra plugins, og ruter du rundt det, kan du blokkere forespørsler som WordPress eller WooCommerce trenger.

Den klassiske WooCommerce-kassen er skoleeksempelet. Når kunden endrer adresse eller fraktmetode, henter kasseskriptet nye totaler herfra:

/?wc-ajax=update_order_review

Når bestillingen sendes, går den til /?wc-ajax=checkout. Begge er forsideadressen med en query-streng, så en rewrite som sender / til home.html, serverer den statiske forsiden til dem også. WooCommerce forventer JSON, får HTML, og kassen stopper. (Kasseblokken, som har vært standard i nye butikker siden WooCommerce 8.3, bruker i stedet Store API under /wp-json/wc/store/.) Vil du beholde designet uten risikoen, gjør det om til en temamal: guiden vår om å konvertere statisk HTML til et WordPress-tema viser hvordan.

Feil 2: Å legge til .htaccess-regler uten å forstå WordPress-ruting

AI skriver .htaccess-regler på sekunder, men Apache bruker dem før WordPress ser forespørselen, så én kort regel kan overstyre WordPress, WooCommerce, skjemaer eller REST API. Denne ser harmløs ut:

RewriteRule ^$ /home.html [L]

I .htaccess fjerner Apache den innledende skråstreken før sammenligningen, så ^$ betyr roten av nettstedet, og mønsteret i en RewriteRule ser aldri query-strengen. For denne regelen er /?wc-ajax=update_order_review bare enda et besøk på forsiden. Besøkende ser en forside som virker, mens kassen feiler i bakgrunnen, og det er det som gjør denne feilen så farlig. Innlegget vårt om AI-genererte .htaccess-regler viser hvilke andre forespørsler en slik regel fanger, og hvordan en tryggere versjon ser ut.

Feil 3: Å returnere HTML der WordPress forventer JSON

AJAX-forespørsler i WordPress og WooCommerce forventer JSON. WordPress sin egen hjelpefunksjon, wp_send_json(), sender svaret med headeren Content-Type: application/json. Får en kasseforespørsel noe annet, ser du en evig spinner, et ordresammendrag som aldri oppdateres, en bestillingsknapp som ikke gjør noe, betalingsmetoder som mangler, eller JavaScript-feil. Og forespørselen kan likevel se vellykket ut:

Status: 200 OK
Content-Type: text/html

WooCommerce sin egen feilsøkingsguide sier hva som gjør JSON om til HTML: et cache-, vedlikeholds- eller sikkerhetslag, en omdirigering, en proxy eller en PHP-advarsel. Feilsøk derfor kassen i Network-fanen i nettleseren, ikke bare i Console. Filtrer på Fetch/XHR, slå på Preserve log og gjenta feilen. Sjekk så adressen, statusen, innholdstypen og innholdet i forespørselen som feiler, også om en advarsel er skrevet ut foran JSON-en. Innlegget vårt om WooCommerce checkout som henger i innlasting går gjennom alle årsakene.

Feil 4: Å kopiere PHP-snutter uten trygge sjekker

AI-generert PHP som limes inn i functions.php eller en snippets-plugin, virker ofte så lenge alle verdier finnes, og svikter i det øyeblikket én mangler:

$id = $_SESSION['redirect_cache'];

Finnes ikke nøkkelen, gir PHP en advarsel (fra PHP 8.0; før var det en notice):

Warning: Undefined array key "redirect_cache"

Vises PHP-feil, fordi WP_DEBUG og WP_DEBUG_DISPLAY er slått på eller serverinnstillingen display_errors er det, skrives teksten rett inn i svaret. WordPress viser aldri feil i sine egne admin-AJAX- og REST-svar, og WooCommerce slår av visningen for wc-ajax-forespørsler på init-hooken, men ikke når feilsøkingsvisningen i WordPress er på, og ikke for advarsler som kommer tidligere. Da havner advarselen foran JSON-en, og kassen stopper. På et live nettsted skal feil logges, aldri vises. En tryggere versjon sjekker først:

$id = isset( $_SESSION['redirect_cache'] ) ? (int) $_SESSION['redirect_cache'] : 0;

// Samme resultat, kortere:
$id = (int) ( $_SESSION['redirect_cache'] ?? 0 );

Operatoren ?? gir, som isset(), ingen advarsel når nøkkelen mangler, og (int) sørger for at resten av koden får et tall. Vær skeptisk til AI-kode som starter PHP-økter i det hele tatt: Nettstedshelse varsler når den finner en åpen økt, fordi en økt startet med session_start() forstyrrer REST API- og loopback-forespørsler. To andre ting å se etter:

• Filtre som ikke returnerer noe. En filterfunksjon må returnere verdien den fikk. Glemmer den det, blir verdien null, og det som ble filtrert, for eksempel en tittel eller en liste med kassefelt, forsvinner.
• Skjema- og AJAX-håndterere uten nonce og tilgangssjekk. Nonces hjelper mot forfalskede forespørsler fra andre nettsteder (CSRF), men WordPress sin dokumentasjon sier tydelig at de aldri er tilgangskontroll alene. Sjekk current_user_can() også.

Sjekklisten vår for AI-generert PHP i WordPress går gjennom sanitering, escaping og resten, med et gjennomarbeidet eksempel.

Feil 5: Å plassere kode på feil sted

Riktig kode kan likevel skape trøbbel i feil fil. Oppsett hører hjemme i temamaler, styling i CSS, skript i JS-filer som lastes inn på riktig måte, forretningslogikk i en liten egen plugin og WooCommerce-endringer i WooCommerce-hooks. Plasseringen har konsekvenser:

• Bare functions.php i det aktive temaet kjøres. Bytter du tema, er funksjonene der borte, og derfor sier WordPress sin temahåndbok at funksjoner som skal overleve designet, hører hjemme i en plugin.
• Kode lagt inn i et foreldretema kan forsvinne når temaet oppdateres. Et barnetema holder den trygg.
• Endringer i WooCommerce sine egne filer forsvinner ved neste oppdatering. Maler overstyres ved å kopiere dem til en woocommerce-mappe i barnetemaet, og systemstatusrapporten varsler når kopiene har blitt utdaterte.

Når alt havner i functions.php, blir hver ny fiks vanskeligere.

Feil 6: Å ikke laste inn CSS og JavaScript riktig

Statisk HTML legger <style>– og <script>-tagger rett inn i siden, og WordPress sin temahåndbok sier at slike tagger aldri skal hardkodes i et tema. Last inn filene med wp_enqueue_style() og wp_enqueue_script() på hooken wp_enqueue_scripts, så tar WordPress seg av avhengigheter, rekkefølge og cache busting (versjonen legges til i filadressen):

function mysite_enqueue_assets() {
    $version = wp_get_theme()->get( 'Version' );

    wp_enqueue_style(
        'mysite-style',
        get_theme_file_uri( 'assets/css/style.css' ),
        array(),
        $version
    );

    wp_enqueue_script(
        'mysite-main',
        get_theme_file_uri( 'assets/js/main.js' ),
        array(),
        $version,
        array( 'in_footer' => true )
    );
}
add_action( 'wp_enqueue_scripts', 'mysite_enqueue_assets' );

Bruk ditt eget prefiks i stedet for mysite: WordPress anbefaler et unikt prefiks på minst fire, helst fem bokstaver, så navnene dine ikke kolliderer med navn i en plugin. get_theme_file_uri() ser i barnetemaet først, og arrayen til slutt (WordPress 6.3 og nyere) tar også en lastestrategi, defer eller async. En vanlig true på samme plass betyr fortsatt «last inn nederst på siden».

Feil 7: Å blande statisk HTML, WordPress-maler og plugin-logikk

Mange AI-assisterte oppsett vokser i lag: en AI-generert HTML-forside, en egen PHP-fil, en temamal, noen snutter i functions.php, et par .htaccess-rewrites og WooCommerce-sider stylet for seg. Det virker helt til noe endres, og da finnes det ingen enkelt fil som forklarer hvorfor kassen, menyen eller et skjema røk. Et forutsigbart tema er langt enklere å holde i gang:

theme/
  style.css
  functions.php
  header.php
  footer.php
  front-page.php
  page.php
  assets/
    css/
    js/
    images/

WordPress bruker front-page.php til forsiden uansett hva som er valgt under Innstillinger > Lesing, så en designet forside hører hjemme der, ikke bak en rewrite til en statisk fil. Bruker nettstedet WooCommerce, la malene til WooCommerce være som de er, med mindre du har en god grunn til å overstyre dem.

Feil 8: Å glemme at WooCommerce er svært dynamisk

WooCommerce er langt mer enn en produktside og et skjema. Tre fakta som AI-snarveier snubler i:

• Noen sider må være dynamiske. WooCommerce sier at handlekurv, kasse og Min konto skal holdes utenfor cachen, og lister opp informasjonskapslene som viser at en besøkende har handlekurv eller økt, som woocommerce_items_in_cart og wp_woocommerce_session_.
• Kassen og Min konto har endepunkter. Ordrebekreftelsen, betalingssiden, ordrer, nedlastinger og glemt passord ligger alle under de to adressene.
• Det finnes to kasser. WooCommerce sin guide til filteret woocommerce_checkout_fields sier at deler av den bare gjelder den klassiske kassen med kortkoden [woocommerce_checkout], og viser brukere av kasseblokken til egen dokumentasjon. En snutt skrevet for den ene kassen kan gjøre ingenting i den andre.

La handlekurven og kassen være slik WooCommerce lager dem, bruk hooks til små endringer og CSS til styling, overstyr maler bare når det trengs, og test hele ordreflyten etter hver endring. De fleste kasseproblemer løses ved å finne det som forstyrrer flyten WooCommerce allerede har, så bygg kassen på nytt bare med en svært god grunn.

Feil 9: Å bare teste forsiden

AI-generert design konsentrerer seg gjerne om forsiden. Før du publiserer, test også menyer, skjemaer, produktsider, handlekurv, kasse, betaling, ordrebekreftelsen, Min konto, søk og 404-siden, både innlogget og utlogget. I en nettbutikk tester du alltid hele flyten:

Produkt → Handlekurv → Kasse → Betaling → Takkeside → E-post

En endring som ikke ser ut til å ha noe med kassen å gjøre, kan likevel ødelegge den.

Feil 10: Å overse mobilvisningen

AI-oppsett ser flotte ut i en skjermdump fra PC-en, mens telefonen viser problemene: menyer som ikke åpner seg, en fast header som dekker innhold, trange kassefelt, knapper som flyter over, popuper over bestillingsknappen. Test på ekte telefoner underveis, ikke som en ettertanke. En kasse som bare virker på PC, er en ødelagt kasse.

Feil 11: Å la AI endre for mye på én gang

En prompt som denne kan gjøre reell skade:

Fiks WordPress-nettstedet mitt og forbedre designet i kassen.

I én omgang kan AI røre temaet, CSS, kassefelt, maler, JavaScript, hooks og markup, og når noe ryker, vet du ikke hvilken endring som gjorde det. Jobb heller i små steg: fiks rotårsaken og test, forbedre strukturen og test, forbedre stylingen og test, forbedre mobilvisningen og test. Små endringer er enklere å gå gjennom og enklere å rulle tilbake.

Feil 12: Å ikke ta backup eller bruke versjonshistorikk

Ta backup før du legger inn AI-generert kode. WordPress sin backupguide sier at en backup har to deler, databasen og filene, at du trenger begge for å gjenopprette nettstedet, og at du bør ha flere ferske kopier på forskjellige steder. For kodearbeid er versjonskontroll enda bedre: Git viser hva som ble endret, hvor og når, og lar deg rulle det tilbake raskt.

En tryggere måte å bruke AI til WordPress-utvikling

Gi AI riktig kontekst. I stedet for «skriv WordPress-kode for dette», sett rammene:

Dette er et WordPress-nettsted med WooCommerce og den klassiske kassen.
Behold WooCommerce sin standardkasse, og ikke endre kjerneoppførselen.
Lag bare styling og trygge hooks, og si hvor hver kodeblokk skal ligge.

Be om små biter: én mal, bare CSS, én hook eller én feilretting av gangen.

Gå gjennom før bruk. Sjekk sanitering, escaping, nonces, tilganger, filplassering, navn og om koden skriver ut noe under AJAX. Slå opp hver funksjon og hook i kodereferansen til WordPress eller WooCommerce: add_action() returnerer true uansett hvilket navn du gir den, så en funksjon koblet til en hook som ikke finnes, kjører rett og slett aldri. På større kodebiter flagger WordPress Coding Standards for PHP_CodeSniffer output uten escaping og input uten sanitering automatisk.

Test på staging, og publiser forsiktig, med ny test av de kritiske reisene etterpå: fra handlekurv til ordrebekreftelse i en nettbutikk, fra kontaktskjema til mottatt e-post på et tjenestenettsted.

Sjekkliste for AI-generert kode i WordPress

• Ruting: Berører den .htaccess eller Nginx? Kan den påvirke AJAX, REST API eller WooCommerce-endepunkter, eller omdirigere forsiden, handlekurven eller kassen?
• PHP: Sjekkes variabler og nøkler før bruk? Saniteres input og escapes output? Sjekker håndtererne nonce og current_user_can()? Skjuler den feil med @, som kodestandardene til WordPress sterkt fraråder?
• WordPress: Lastes filene inn med enqueue? Returnerer filtrene verdien sin? Finnes hookene? Ligger koden i riktig fil, med et unikt prefiks?
• WooCommerce: Er den skrevet for din kassetype? Er kassen fortsatt WooCommerce sin standardkasse? Virker ordresammendraget, takkesiden og e-postene fortsatt?
• Testing: Mobil, innlogget og utlogget, en hel bestilling eller skjemainnsending, og en backup?

Er et svar uklart, trenger koden gjennomgang før den går live. Den fulle sjekklisten vår for gjennomgang av AI-generert WordPress-kode har 20 punkter.

Når du bør be en WordPress-spesialist om hjelp

Hent inn hjelp når kassen laster i det uendelige, betalingsmetoder forsvinner, WooCommerce-AJAX returnerer HTML, bestillingsknappen ikke gjør noe, skjemaer sendes men e-postene aldri kommer frem, PHP-advarsler dukker opp, eller admin virker mens forsiden ryker, særlig rett etter at AI-generert kode ble lagt inn. Dette er som regel fiksbart, men årsaken ligger ofte et annet sted: et kasseproblem kan komme fra .htaccess, en JavaScript-feil fra PHP-output, en layoutfeil fra en global CSS-regel.

Gjennomgang og retting av AI-skrevet WordPress-kode er en del av WordPress-feilrettingen vår. Diagnosen er gratis, du får fast pris skriftlig før vi starter (fra 1 990 kr eks. mva), og det gjelder «Ingen fiks, ingen betaling». PHP-feil tar vi gjennom fiksing av PHP-feil på de samme vilkårene. Send oss saken, så svarer vi innen 30 minutter i arbeidstiden og finner den egentlige årsaken før vi anbefaler noe.

Avsluttende tanker

AI kan gjøre WordPress-utvikling raskere, men det kan ikke erstatte kunnskap om hvordan WordPress fungerer. Problemene starter når noen stoler på generert kode uten å sjekke hva den berører. AI kan hjelpe deg å skrive koden raskere; koden må fortsatt fungere i et ekte WordPress-nettsted.

Kilder

Sist kontrollert 12. november 2026.

• WooCommerce: Endless loading/spinner on the checkout page. Forespørslene i klassisk kasse og kasseblokken, hva som gjør JSON om til HTML, og stegene i Network-fanen.
• WooCommerce på GitHub: class-wc-ajax.php og checkout.js. wc-ajax-adressene på forsideadressen, feilvisningen som slås av på init, og hva som utløser update_order_review.
• WooCommerce: Page Shortcodes. Kortkoden [woocommerce_checkout], og at kasseblokken er standard i nye butikker fra 8.3.
• Apache HTTP Server: mod_rewrite. Mønsteret i RewriteRule ser aldri query-strengen, og i .htaccess sammenlignes det uten innledende skråstrek.
• WordPress Code Reference: wp_send_json(), wp_debug_mode(), add_action() og WP_Site_Health::get_test_php_sessions(). JSON-svar, når feil aldri vises, at add_action() alltid returnerer true, og Nettstedshelse-sjekken av PHP-økter.
• PHP-manualen: Backward Incompatible Changes (PHP 8.0), isset(), Comparison operators og Runtime Configuration (feil). Advarselen for udefinert array-nøkkel, ?? og isset(), og display_errors avslått i produksjon.
• WordPress: Debugging in WordPress. WP_DEBUG_DISPLAY viser feil som standard, og feilsøking hører hjemme på en lokal kopi eller staging.
• WordPress Plugin Handbook: Hooks og Best Practices. Filtre må returnere en verdi, og et unikt prefiks på minst fire eller fem bokstaver.
• WordPress Common APIs Handbook: Security, Sanitizing Data, Escaping Data og Nonces. Stol aldri på input, escape sent, og nonces er ikke tilgangskontroll.
• WordPress Theme Handbook: Theme Functions, Including Assets og Template Hierarchy. Bare det aktive temaets functions.php kjøres, barnetema og plugin, enqueue og cache busting, og front-page.php.
• WordPress Code Reference: wp_enqueue_script(). $args-arrayen med in_footer og strategy fra WordPress 6.3.
• WooCommerce developer docs: Template structure and overriding templates via a theme. woocommerce-mappen i barnetemaet, endringer som forsvinner ved oppdatering, og utdaterte kopier i systemstatus.
• WooCommerce developer docs: How to configure caching plugins for WooCommerce og Understanding WooCommerce endpoints. Sider og informasjonskapsler som holdes utenfor cachen, og endepunktene i kassen og Min konto.
• WooCommerce developer docs: Customizing checkout fields using actions and filters. Filteret woocommerce_checkout_fields, og delene som bare gjelder kortkodekassen.
• WordPress: Backups. Database og filer, før hver oppdatering, flere kopier på forskjellige steder.
• WordPress: PHP Coding Standards og WordPress Coding Standards for PHP_CodeSniffer på GitHub. @-operatoren sterkt frarådet, og automatiske sjekker av escaping og sanitering.