WooCommerce checkout henger i innlasting? Vanlige årsaker og løsninger

En WooCommerce-checkout som henger i innlasting, er mer enn en irritasjon. Den hindrer kunder i å legge inn bestillinger, kan stoppe betalingsmetodene fra å laste, og tapper i det stille omsetning mens resten av nettstedet ser helt normalt ut. Symptomet er som regel enkelt: kunden når checkouten, fyller inn detaljene sine, og ordresammendraget bare fortsetter å spinne. Noen ganger dukker ikke betalingsmetodene opp, noen ganger slutter bestillingsknappen å reagere («Bekreft ordre» i den klassiske checkouten, «Send inn ordre» i Checkout-blokken, med mindre butikken har endret teksten), og noen ganger skjer det ingenting åpenbart i det hele tatt.

Det vanskelige er at innlastingsproblemer i checkouten kan komme fra flere lag: pluginkonflikter, temaproblemer, caching, AJAX-svikt, PHP-advarsler, konflikter med betalingsløsningen, omskrivingsregler på serveren, sikkerhets- og brannmurregler, ødelagt JavaScript eller ugyldige JSON-svar. Derfor er den beste løsningen ikke å deaktivere plugins tilfeldig eller bygge checkouten på nytt. Den beste løsningen er å finne hvor forespørselen fra checkouten faktisk ryker.

Dette innlegget handler bare om checkouten som spinner og aldri blir ferdig. Virker kassen ikke av andre grunner, for eksempel at Vipps ikke kommer tilbake, at frakten mangler eller at mva blir feil, går den gratis guiden WooCommerce-checkout fungerer ikke gjennom de vanligste årsakene i riktig rekkefølge.

Klassisk checkout eller Checkout-blokken?

Finn ut hvilken checkout butikken bruker før du begynner, for de to sender forskjellige forespørsler i bakgrunnen. Den klassiske checkouten er en side med shortcoden [woocommerce_checkout]. Fra WooCommerce 8.3 får nye butikker Checkout-blokken i stedet, så butikker som ble satt opp før det, kan fortsatt ha den klassiske.

• Klassisk checkout: nettleseren snakker med WooCommerce gjennom /?wc-ajax=update_order_review mens totaler, frakt og betalingsmetoder oppdateres, og gjennom /?wc-ajax=checkout når kunden trykker «Bekreft ordre».
• Checkout-blokken: nettleseren bruker WooCommerce sitt Store API, med adresser under /wp-json/wc/store/v1/, som /wp-json/wc/store/v1/cart og /wp-json/wc/store/v1/checkout.

Du ser det i nettleseren: åpne Network-fanen (steg 2 lenger ned) og se hvilken av de to adressetypene som dukker opp når du fyller inn en adresse. WooCommerce fraråder å bytte fra den ene checkout-typen til den andre som første feilsøkingssteg. Resten av innlegget bruker den klassiske checkouten som eksempel, og sier fra der blokken oppfører seg annerledes.

Hva betyr det at WooCommerce-checkouten henger i innlasting?

WooCommerce-checkout er dynamisk. Når en kunde fyller inn fakturadetaljer, bytter land, legger til en rabattkode, velger frakt eller velger betalingsmetode, sender checkouten forespørsler i bakgrunnen for å oppdatere ordresammendraget. I den klassiske checkouten ser den viktigste slik ut:

/?wc-ajax=update_order_review

Svaret oppdaterer ordretotal, avgift, fraktmetoder, betalingsmetoder, rabattberegninger og meldinger i checkouten. Det skal være JSON, og WooCommerce sender det med innholdstypen application/json.

Mens forespørselen går, legger WooCommerce et hvitt, halvgjennomsiktig lag over ordresammendraget og betalingsdelen, med et lastesymbol som snurrer. Laget fjernes først når svaret kommer tilbake med nye deler av siden, det WooCommerce kaller fragments. Feiler forespørselen, eller kommer det noe annet enn gyldig JSON tilbake, blir laget liggende. Det er spinneren kundene ser.

Spinneren er altså sjelden det egentlige problemet. Den er det synlige tegnet på at svaret aldri kom, kom med en feil, ble stoppet av en sikkerhetsregel, eller ikke var gyldig JSON, for eksempel fordi en cache eller en PHP-advarsel kom i veien.

Regel nummer én: Ikke anta at det er betalingsløsningen

Kunder sier ofte at «betalingen ikke fungerer», og betalingspluginen får skylden først. Det er forståelig, siden checkout og betaling skjer tett på hverandre. Men WooCommerce-checkout kan ryke lenge før betaling er involvert. Før du legger skylden på Stripe, PayPal, Mollie, Klarna, Vipps eller en annen løsning, sjekk om selve forespørselen fra checkouten fungerer. Hvis update_order_review feiler, kan betalingsløsningen bare være et symptom lenger nede i kjeden.

WooCommerce skiller selv mellom feil som kommer mens totalene lastes, og feil som først kommer etter at kunden har trykket på bestillingsknappen. Først i det siste tilfellet hører betalingsløsningen, svindelsjekken, avgiftstjenesten, webhooks og e-postutsendingen med blant de mistenkte. En rask test, helst på en kopi av butikken:

1. Aktiver midlertidig en enkel betalingsmetode, som bankoverføring.
2. Deaktiver hovedbetalingsløsningen.
3. Test checkouten på nytt.
4. Sjekk om spinneren fortsatt dukker opp.

Hvis checkouten fortsatt henger med en enkel metode aktivert, er problemet sannsynligvis ikke betalingsleverandøren.

Årsak 1: AJAX-svaret er ikke JSON

Dette er en av de viktigste årsakene. WooCommerce forventer at svarene fra checkouten er gyldig JSON, men noen ganger returnerer serveren en vanlig HTML-side i stedet. I Network-fanen i nettleseren kan du se:

Status: 200 OK
Content-Type: text/html

Ved første øyekast ser 200 OK vellykket ut. Men når WooCommerce forventer JSON og får HTML, kommer det ingen fragments tilbake, laget over ordresammendraget blir liggende, og resultatet er en evig spinner. Åpner du svaret og ser en hel nettside som denne, har du funnet sporet:

<!DOCTYPE html>
<html>
<head>
  <title>...</title>
</head>
<body>
...
</body>
</html>

Det betyr at noe fanger opp AJAX-forespørselen. WooCommerce nevner selv cache, vedlikeholdsmodus, et sikkerhetslag, en omdirigering, en proxy og PHP-advarsler. Det kan også være en .htaccess-regel, en innloggingsomdirigering eller en tema- eller pluginkonflikt. Derfor er det så viktig å se på selve svaret.

Er svaret bare -1, kan det ifølge WooCommerce bety at en nonce-sjekk feilet, for eksempel fordi noen har cachet en side med en utløpt nonce. I Checkout-blokken gjelder det samme for forespørslene til Store API: de skal også svare med JSON.

Årsak 2: Cache på handlekurv, checkout eller AJAX-forespørsler

Handlekurv og checkout må forbli dynamiske. De skal aldri serveres som statisk bufrede sider. Når caching er feil satt opp, kan WooCommerce vise utdaterte handlekurvdata, feil totaler, ugyldige øktdata eller evig innlasting. Vanlige kilder er en cache-plugin for WordPress, LiteSpeed Cache, WP Rocket, server-cache, Cloudflare, et annet CDN, nettleser-cache eller en optimaliseringsplugin.

WooCommerce sier at handlekurv, checkout og Min konto skal unntas fra side- og kantcache, og at cache, CDN, brannmur og omvendt proxy skal slippe AJAX-forespørsler og Store API-forespørsler gjennom uten å svare med en lagret kopi. I praksis betyr det disse stiene:

/cart/
/checkout/
/my-account/
/?wc-ajax=
/wp-json/wc/store/

Bytt ut de tre første med stiene til dine egne sider. Har butikken norske sidenavn, er stiene norske også. Hvilke sider det er, ser du under WooCommerce → Innstillinger → Avansert.

WooCommerce lister også informasjonskapslene som viser at den besøkende har en aktiv handlekurv, slik at cache-løsningen kan hoppe over cachen når de finnes:

woocommerce_items_in_cart
woocommerce_cart_hash
wp_woocommerce_session_

Hva du bør sjekke

• Er checkout og handlekurv unntatt fra cache?
• Er wc-ajax og /wp-json/wc/store/ unntatt?
• Har du en Cache Rule i Cloudflare som cacher alt? Cloudflare cacher ikke HTML eller JSON uten en slik regel, eller uten at serveren selv sier i svaret at det kan caches.
• Er server-cache aktiv selv når pluginen er deaktivert?
• Minifiserer eller forsinker en optimaliseringsplugin WooCommerce sine skript? WooCommerce anbefaler selv å unngå minifisering av JavaScript.
• Har cachesystemet databasecache? Da sier WooCommerce at det kan hjelpe å unnta _wc_session_.

En cache-plugin kan være av mens server- eller CDN-cache fortsatt påvirker siden, så sjekk alltid hvert lag.

Årsak 3: PHP-advarsler som ødelegger AJAX-svarene

Svarene fra checkouten må være rene. Hvis PHP-advarsler eller -meldinger skrives ut i svaret, ryker JSON-en. Siden PHP 8.0 er det en advarsel, ikke bare en notis, når kode leser en array-nøkkel som ikke finnes. En typisk advarsel:

Warning: Undefined array key "redirect_cache"

Den kommer når egendefinert kode leser en nøkkel uten å sjekke at den finnes:

$id = $_SESSION['redirect_cache'];

En tryggere versjon:

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

Selv en liten advarsel kan forurense et AJAX-svar. På en vanlig side vises advarselen over innholdet; inne i et AJAX-kall kan den gjøre hele svaret ugyldig. Når kunden trykker «Bekreft ordre», prøver den klassiske checkouten å redde et svar med rot foran JSON-en. Ser du «Unable to fix malformed JSON» i konsollen, klarte den det ikke, og noe skriver ut tekst i svaret. Står det «Fixed malformed JSON», klarte WooCommerce å rydde, men årsaken er der fortsatt.

Hva du bør sjekke

Åpne svaret på AJAX-forespørselen og se etter PHP-advarsler, -meldinger, deprecation-meldinger, feiltekst fra plugins, HTML foran JSON-en, debug-output, gjenglemte var_dump() eller print_r(), eller en utilsiktet echo. Dukker noe av dette opp, fiks kilden.

WordPress sine debugverktøy er laget for lokal utvikling og staging, og WordPress fraråder å bruke dem på et live nettsted. Må du likevel feilsøke på den live butikken en kort stund, sørg for at feilene går til en logg og ikke vises for besøkende:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Loggen havner som standard i wp-content/debug.log, og WP_DEBUG_LOG kan få en egen filsti hvis du vil ha den et annet sted. Slå av debugging igjen når du er ferdig. Det hindrer at advarsler ødelegger svarene, men erstatter ikke det å rette koden.

Årsak 4: JavaScript-feil i checkouten

WooCommerce-checkout lener seg tungt på JavaScript. Hvis et annet skript kaster en feil før checkout-skriptene er ferdige, kan checkouten slutte å oppdatere seg. Vanlige årsaker er en feil i temaskriptet, et egendefinert checkout-skript, ødelagt minifisert JS, forsinkede eller utsatte WooCommerce-skript, en konflikt med en optimaliseringsplugin, en manglende avhengighet, en jQuery-konflikt, støy fra nettleserutvidelser, eller et sporingsskript fra en tredjepart.

Hva du bør sjekke

Åpne utviklerverktøyene og se i Console-fanen etter røde feil knyttet til disse navnene fra den klassiske checkouten:

checkout
wc_checkout_params
update_order_review
jQuery
payment_method
fragments

Noter den første relevante feilen. WooCommerce påpeker at senere feil kan være følgefeil av den første. Ikke alle konsollfeil betyr noe, og noen nettleserutvidelser lager støy som ikke har med saken å gjøre. For checkout-problemer er Network-fanen som regel mer avslørende enn Console, men JavaScript-feil er fortsatt verdt å gå gjennom.

Årsak 5: Tema- eller malkonflikter

Checkouten kan ryke når et tema overstyrer WooCommerce-maler feil. Se etter utdaterte maloverstyringer, manglende checkout-hooks, en fjernet meldingsseksjon, et egendefinert oppsett som skjuler påkrevde elementer, egendefinert JavaScript som forstyrrer WooCommerce-hendelser, feil skjemamarkup, eller CSS som skjuler betalingsmetoder eller knapper. Mangler temaet wp_footer(), blir skriptene som skal skrives ut nederst på siden, aldri skrevet ut. WooCommerce-maler er avhengige av hooks, så hvis et tema fjerner eller flytter viktige hooks, blir checkouten ustabil.

Hva du bør sjekke

Gå til WooCommerce → Status og se avsnittet om maler (Templates) i systemstatusrapporten. Der står det hvilke maler temaet overstyrer, og om noen av dem er utdaterte. Overstyringene ligger i temaet, i mappen:

ditt-tema/woocommerce/

Er checkout-maler overstyrt, sammenlign dem med versjonene i dagens WooCommerce. En rask test er å bytte midlertidig til temaet Storefront på en kopi av butikken og teste checkouten på nytt. Ifølge WooCommerce brukes da de originale malfilene. Virker det med Storefront, ligger problemet sannsynligvis i temaet eller maloverstyringene.

Årsak 6: Pluginkonflikter

Pluginkonflikter er vanlige, men de bør testes metodisk, ikke ved gjetting. Plugins som ofte påvirker checkouten, gjelder betaling, frakt, checkout-felt, språk og valuta, avgift og mva, sikkerhet, cache og optimalisering, kodesnutter, anti-spam, sporing og faktura.

Slik tester du trygt

På en kopi av butikken (staging), deaktiver alle plugins som ikke er nødvendige, bortsett fra WooCommerce, og test checkouten. Virker den, aktiver pluginene én etter én til problemet kommer tilbake, og start med de mest sannsynlige:

1. Betalingsplugins
2. Fraktplugins
3. Plugins for checkout-felt
4. Cache- og optimaliseringsplugins
5. Sikkerhetsplugins
6. Egendefinerte kodesnutter
7. Sporings- og analyseplugins

Unngå å gjøre dette direkte i en travel, live butikk med mindre du ikke har noe annet valg og trafikken er lav.

Årsak 7: Omskrivings- eller omdirigeringsregler på serveren

Noen ganger ryker checkouten fordi WordPress aldri mottar forespørselen riktig, på grunn av .htaccess, Nginx, LiteSpeed eller regler i et CDN. En omskrivingsregel kan ved et uhell fange opp en forespørsel som:

/?wc-ajax=update_order_review

Når det skjer, kan WooCommerce få tilbake en statisk forside, en omdirigering, en 403-side, en bufret HTML-fil, en innloggingsside eller en melding fra brannmuren, og det gir evig innlasting selv om WooCommerce i seg selv er i orden. Får forespørselen 404, nevner WooCommerce nettopp omskrivingsregler og proxyruter blant årsakene. Det var dette som skjedde i en checkout-sak vi sporet til en .htaccess-rewrite, der en regel for en statisk forside fanget opp AJAX-forespørselen fra WooCommerce.

Hva du bør sjekke

Gå gjennom .htaccess, Nginx-regler, LiteSpeed-regler, regler i Cloudflare, regler i omdirigeringsplugins, regler for server-cache og logger fra sikkerhetsbrannmuren. Vær spesielt forsiktig med alt som berører:

/
/checkout/
/cart/
/my-account/
/?wc-ajax=
/wp-json/

En liten regel på servernivå kan ødelegge en stor del av WooCommerce.

Årsak 8: Brannmur eller ModSecurity som blokkerer forespørsler

Sikkerhetslag kan blokkere forespørsler fra checkouten når de ser mistenkelige ut, fordi de bærer kundedata, adressefelt, betalingsdata, AJAX-data, nonce-verdier og øktdata. Får forespørselen status 403, peker WooCommerce på en brannmur, en sikkerhetsregel, en utløpt eller manglende nonce, eller en annen tilgangssjekk. En blokkering kan også komme som en brannmurside eller en CAPTCHA i stedet for data.

Bruker du Cloudflare, se etter headeren cf-mitigated: challenge i svaret. Den betyr at Cloudflare svarte med en utfordringsside, og den kommer alltid som HTML, uansett hva nettleseren ba om. For checkouten ser det ut akkurat som årsak 1.

Hva du bør sjekke

Inspiser forespørselen som feiler i Network-fanen, og se etter status 403, HTML fra en brannmur, en CAPTCHA- eller verifiseringsside, eller meldinger som «Access denied». Mistenker du brannmuren, sjekk loggene hos webhotellet, eller spør webhotellet om ModSecurity eller en annen brannmur blokkerte forespørselen. ModSecurity er en åpen brannmurmotor for webapplikasjoner som brukes med Apache, Nginx og IIS, og den står foran WordPress.

Årsak 9: Tilpasninger av checkout-felt

Egendefinerte checkout-felt kan ødelegge checkouten når de legges til feil: påkrevde felt uten validering, ugyldige feltnøkler, egendefinerte felt som ikke renses, adressefelt fjernet på feil måte, dårlig omdøpte faktura- eller leveringsfelt, en konflikt med et verktøy for checkout-felt, eller JavaScript som forventer et felt som ikke lenger finnes. I den klassiske checkouten bør et felt for eksempel fjernes med filteret for checkout-felt, ikke ved å slette markup for hånd:

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

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

    return $fields;
});

Koden hører hjemme i functions.php i et barnetema. Det er langt tryggere enn å redigere WooCommerce sine egne filer, som overskrives ved neste oppdatering, eller å skjule felt med CSS alene. Filteret er laget for den klassiske checkouten. For Checkout-blokken viser WooCommerce til et eget oppsett for ekstra felt.

Årsak 10: Manglende WooCommerce-sider eller feil sideoppsett

WooCommerce er avhengig av bestemte sider for handlekurv, checkout, konto og vilkår, og krever at handlekurv og checkout har en side hver. Mangler de, eller er de feil tilordnet, oppfører checkouten seg uforutsigbart. Sjekk:

WooCommerce → Innstillinger → Avansert

Bekreft at siden for handlekurv, siden for checkout, Min konto-siden og siden for vilkår og betingelser (hvis den brukes) er riktig tilordnet. Bekreft også at checkout-siden inneholder enten Checkout-blokken eller shortcoden:

[woocommerce_checkout]

Årsak 11: Blokkert REST API, feil nettstedsadresse eller blandet innhold

Checkout-blokken henter alt gjennom Store API, og Store API ligger under /wp-json/. Blokkerer en sikkerhetsplugin, en brannmur eller en serverregel REST API-et, får blokk-checkouten ingen brukbare svar. Sjekk at adressene under /wp-json/ svarer på nettstedet ditt.

WooCommerce peker også på adressene. Sammenlign adressen kunden ser i nettleseren med adressen forespørselen går til. Et gammelt domene, en forskjell med eller uten www, eller en http-forespørsel fra en https-side gir blokkerte forespørsler og feil om blandet innhold i konsollen. Merk at WordPress-adressen og nettstedsadressen under Innstillinger → Generelt kan være forskjellige med vilje, når WordPress er installert i en egen mappe. WooCommerce fraråder å gjøre dem like bare for å feilsøke checkouten.

Slik feilsøker du innlasting av WooCommerce-checkout ordentlig

Her er en praktisk prosess.

Steg 1: Gjenskap problemet

Gjør det helst på en kopi av butikken, med betalingsløsningene i testmodus. Åpne checkouten i et privat nettleservindu og kjør hele løypa mens du følger med på ordresammendraget:

Legg til produkt → Handlekurv → Checkout → Fyll ut felt → Følg ordresammendraget

Merk deg nøyaktig når spinneren starter: mens totalene lastes, eller først etter at du har trykket på bestillingsknappen.

Steg 2: Åpne utviklerverktøyene i nettleseren

I Chrome åpner du Network-fanen og velger filteret:

Network → Fetch/XHR

Huk av for Preserve log, så forsvinner ikke forespørslene hvis siden lastes på nytt eller sender deg videre, og for Disable cache, så nettleseren ikke svarer fra sin egen cache. Last checkouten på nytt og se etter ?wc-ajax=update_order_review i den klassiske checkouten, eller forespørsler til /wp-json/wc/store/ i Checkout-blokken.

Steg 3: Sjekk statuskoden

Se etter 200, 302, 403, 404 eller 500. Ifølge WooCommerce peker 403 mot en brannmur, en sikkerhetsregel eller en nonce, 404 mot feil adresse, en omskrivingsregel eller en proxy, og 500 mot en fatal PHP-feil, så se i loggene på samme klokkeslett. En 302 betyr at forespørselen ble sendt et annet sted, for eksempel til en innloggingsside. En 200 er bare grei hvis svaret faktisk er JSON.

Steg 4: Sjekk headerne i svaret

Fanen Headers viser blant annet:

Content-Type
Cache-Control
Server
Location
cf-mitigated

Hvis Content-Type er text/html der du venter application/json, se på selve svaret.

Steg 5: Sjekk selve svaret

I fanen Response ser du hva serveren sendte. Et sunt svar er JSON med nye fragments og ingenting foran. Se etter en hel HTML-side, en PHP-advarsel, en innloggingsside, en blokkering fra brannmuren, en omdirigeringsside, ugyldig JSON, en bufret forside eller et svar som bare er -1.

Steg 6: Sjekk konsollen

Se etter relevante JavaScript-feil, og noter den første. Ignorer åpenbar støy fra nettleserutvidelser med mindre den direkte påvirker checkout-skriptene. Etter et trykk på «Bekreft ordre» i den klassiske checkouten er «Unable to fix malformed JSON» et tydelig spor.

Steg 7: Sjekk loggene

Gå gjennom loggene under WooCommerce → Status → Logger. Fatal-errors føres automatisk, mens loggen til betalingspluginen må slås på i pluginens egne innstillinger. Se også i PHP-feilloggen, debug.log, serverens feillogg og eventuell brannmurlogg, og sjekk de planlagte handlingene (Scheduled Actions) under WooCommerce → Status. Er minnet brukt opp, kan en høyere minnegrense hjelpe, men WooCommerce minner om at det ikke erstatter å finne forespørselen som er treg.

Steg 8: Test tema- og pluginkonflikter

Bruk en kopi av butikken der det er mulig. Bytt tema og reduser antall plugins for å isolere problemet.

Hva du ikke bør gjøre

Når checkouten henger i innlasting, unngå dette:

• Å bygge checkouten på nytt med en gang
• Å bytte mellom klassisk checkout og Checkout-blokken som første tiltak
• Å redigere WooCommerce sine egne filer
• Å skjule feil uten å sjekke årsaken
• Å deaktivere tilfeldige plugins i en live butikk midt i travleste tid
• Å anta at betalingsløsningen er årsaken
• Å tømme cache gang på gang uten å sjekke svaret i Network-fanen
• Å bytte tema før du har sjekket AJAX
• Å legge til flere kodesnutter for å «tvinge» checkouten til å virke
• Å ignorere PHP-advarsler fordi «siden laster jo fortsatt»
• Å endre .htaccess uten å teste de dynamiske forespørslene
• Å gjøre WordPress-adressen og nettstedsadressen like bare for å teste

Den raskeste løsningen kommer som regel av å finne den nøyaktige forespørselen som feiler.

Når du bør be om hjelp

Det er verdt å hente inn hjelp når:

• Checkouten fortsetter å spinne etter grunnleggende feilsøking
• update_order_review returnerer HTML i stedet for JSON
• Betalingsmetodene forsvinner
• Bestillingsknappen ikke reagerer
• Checkouten bare virker av og til
• PHP-advarsler dukker opp i checkouten
• Checkouten ryker etter at ny kode eller en kodesnutt er lagt til, også kode skrevet av en AI-assistent
• Unntak fra cache ikke løser problemet
• Testing av tema- og pluginkonflikter ikke avdekker årsaken
• Serverregler eller brannmuren ser mistenkelige ut

Checkout-problemer lar seg som regel fikse, men gjetting kaster bort tid og kan skape nye problemer.

Avsluttende tanker

En WooCommerce-checkout som henger i innlasting, er sjelden et mysterium når du følger forespørselen. Slutt å stirre på spinneren, og sjekk hva serveren faktisk sender tilbake. Som regel er det ikke WooCommerce som er feil, men noe rundt det, og den tryggeste løsningen er den som gjenoppretter WooCommerce sin egen flyt i stedet for å erstatte den.

---

Henger checkouten fortsatt? Vi kan fikse WooCommerce-kassen for deg: finne forespørselen som feiler og få kassen til å ta imot bestillinger igjen. Vurderingen er gratis, du får fast pris før vi starter, en standard kassefiks starter på 3 990 kr eks. mva, og du får 14 dagers garanti mot at samme feil dukker opp igjen. Send oss saken, så bekrefter vi henvendelsen innen 1 time i arbeidstiden.

Kilder

Sist kontrollert 12. november 2026.

• WooCommerce: Endless loading/spinner on the checkout page. Klassisk checkout mot Checkout-blokken, hvilke forespørsler du skal se etter, hva 403, 404, 500, HTML i stedet for JSON og et svar på -1 betyr, cache-lag, adresser og https, første konsollfeil, logger og minne.
• WooCommerce på GitHub: checkout.js. Laget over ordresammendraget, at det fjernes først når svaret har fragments, og meldingene om ugyldig JSON etter et trykk på bestillingsknappen.
• WordPress.org: WooCommerce oversatt til bokmål. Knappetekstene «Bekreft ordre» (den klassiske checkouten) og «Send inn ordre» (Checkout-blokken).
• WooCommerce på GitHub: class-wc-ajax.php. Adressen ?wc-ajax= og svaret fra update_order_review.
• WooCommerce på GitHub: woocommerce.scss og _mixins.scss. Lastesymbolet som snurrer på laget.
• WordPress Developer Resources: wp_send_json(). Svaret sendes som application/json.
• WooCommerce Developer Docs: Store API. Adressene under /wp-json/wc/store/v1/.
• WooCommerce: Page shortcodes. Shortcoden [woocommerce_checkout], og at Cart- og Checkout-blokkene er standard for nye butikker fra versjon 8.3.
• WooCommerce Developer Docs: Configuring caching plugins. Sidene og informasjonskapslene som skal unntas, minifisering av JavaScript og _wc_session_.
• Cloudflare Docs: Default cache behavior. Når Cloudflare cacher HTML og JSON.
• Cloudflare Docs: Detect a Challenge Page response. Headeren cf-mitigated og at utfordringssider alltid er HTML.
• Chrome for Developers: Network features reference. Fetch/XHR, Headers, Response, Preserve log og Disable cache.
• WordPress Developer Resources: Debugging in WordPress. Debugoppsettet, hvor debug.log havner, og rådet mot debug på live nettsteder.
• PHP Manual: Backward incompatible changes in PHP 8.0. En udefinert array-nøkkel gir en advarsel.
• WordPress Developer Resources: wp_footer(). Skriver ut skript før slutten av siden.
• WooCommerce: Understanding the WooCommerce System Status Report. Maloverstyringer, Storefront som test og loggene.
• WooCommerce Developer Docs: Template structure and overriding templates. Mappen woocommerce/ i temaet.
• WooCommerce Developer Docs: Customising checkout fields. Filteret woocommerce_checkout_fields, laget for den klassiske checkouten, og hvor koden skal ligge.
• WooCommerce: Advanced settings. Sideoppsettet for handlekurv og checkout.
• OWASP ModSecurity på GitHub. Hva ModSecurity er.