Slik fikset vi uendelig WooCommerce checkout-lasting for HostHorizon

HostHorizon, en nederlandsk hostingleverandør, tok kontakt da hver eneste kunde traff den samme veggen: WooCommerce-checkouten lastet i det uendelige, og ingen bestilling ble fullført. Årsaken lå ikke i WooCommerce. Den lå i en enkelt linje med .htaccess fra noen år tilbake, som fanget opp AJAX-forespørsler og returnerte HTML der det skulle vært JSON.

Denne casen går gjennom feilsøkingen, den egentlige årsaken, og hvorfor det å gjenopprette vanlig WordPress-ruting var den riktige løsningen i stedet for å bygge checkouten på nytt.

Kort om oppdraget

• Kunde: HostHorizon, en nederlandsk hostingleverandør som tar imot bestillinger direkte i nettbutikken
• Plattform: WordPress og WooCommerce, med en spesialdesignet forside og standard handlekurv og checkout
• Symptom: checkouten lastet i det uendelige, og ingen bestilling kom gjennom
• Årsak: en gammel .htaccess-regel som sendte WooCommerce sine AJAX-kall til en statisk forside
• Tid: fra første henvendelse til ferdig løsning innenfor samme uke

Kunden

HostHorizon er en nederlandsk hostingleverandør som kjører WordPress og WooCommerce. De har en spesialdesignet forside kombinert med standard WooCommerce for handlekurv og checkout. Bedriften tar imot hostingbestillinger direkte gjennom nettbutikken, så nedetid i checkouten går rett på inntektene.

Problemet: hver checkout lastet i det uendelige

Checkout-siden satt fast i en evig lastetilstand under gjennomgangen av bestillingen. Kundene kunne legge produkter i handlekurven, gå til checkout og fylle inn fakturainformasjonen sin, men selve bestillingsgjennomgangen ble aldri fullført. Spinneren bare gikk og gikk. «Legg inn bestilling»-knappen ble upålitelig. Ingen bestilling kom gjennom.

Symptomene kunden meldte fra om:

• Uendelig lastespinner i checkouten
• Bestillingsgjennomgangen oppdaterte seg aldri etter at fakturainfo var fylt inn
• «Legg inn bestilling»-knappen reagerte ujevnt
• AJAX-forespørslene i checkouten returnerte feil svar
• Handlekurven fungerte fint, men det stoppet opp mellom kurv og betaling

Det som gjorde dette ekstra vanskelig å feilsøke: problemet vedvarte selv etter at vi skrudde av betalingsløsningen, deaktiverte alle ikke-nødvendige plugins og byttet til et standard WordPress-tema. Det utelukket de vanlige mistenkte. Problemet lå ikke i WooCommerce-pluginene, temaet eller noen tredjepartsintegrasjon.

Feilsøkingen

Vi jobbet oss gjennom de vanlige feilsøkingslagene i rekkefølge:

1. Feil i nettleserkonsollen. JavaScript meldte fra om uventede svar fra WooCommerce sine AJAX-endepunkter.
2. Inspeksjon av AJAX-forespørslene. Spesielt update_order_review-kallet som kjører når en kunde fyller inn fakturadetaljene sine.
3. Analyse av serversvar. Hva WooCommerce faktisk fikk tilbake fra serveren.
4. Temastruktur. Bekreftet at ingen maloverstyringer ødela markeringen i checkouten.
5. Rewrite-regler. .htaccess-fila og all egendefinert ruting.
6. Egendefinert session-håndtering. PHP-session-logikk som kunne forstyrre WooCommerce sine sessions.

Punkt 1 til 4 kom tilbake rene nok til at vi fortsatte å eliminere. Punkt 5 var der årsaken dukket opp.

Den egentlige årsaken: en forside-rewrite som kapret AJAX

Nettstedet hadde en egendefinert .htaccess-regel fra noen år tilbake som tvang forsiden til å bli servert som en statisk HTML-fil:

# Den opprinnelige problematiske rewriten
RewriteRule ^$ /home.html [L]

Hensikten var fornuftig da den ble lagt inn: servere en ferdig generert forside for å hoppe over WordPress på den mest besøkte URL-en, og dermed spare lastetid. Problemet var hva den gjorde med WooCommerce.

WooCommerce sine AJAX-kall under checkout bruker et URL-mønster som dette:

/?wc-ajax=update_order_review

Forespørselsstien starter fortsatt med /. Rewrite-regelen skilte ikke mellom et vanlig forsidebesøk og et AJAX-kall fra WooCommerce. Begge traff ^$-mønsteret på Apache-nivå. Så i stedet for at WordPress håndterte AJAX-forespørselen, fanget serveren den opp og sendte tilbake home.html.

WooCommerce forventet et JSON-svar fra dette endepunktet:

{
  "result": "success",
  "messages": "...",
  "fragments": { ... }
}

Det den fikk, var den statiske forsiden:

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

JavaScripten i checkouten prøver å tolke det svaret som JSON, feiler stille, og fortsetter bare å vente på gyldige data som aldri kommer. Derav den evige spinneren. Checkouten var ikke ødelagt. Den ble fratatt svarene den trengte, av serveren selv.

Et sekundært problem: usikker session-tilgang

Mens vi gikk gjennom forespørselsflyten, fant vi et beslektet problem i egendefinert PHP som rørte ved $_SESSION:

// Opprinnelig kode som gir en PHP-warning når nøkkelen mangler
$id = $_SESSION['redirect_cache'];

Session-nøkkelen ble lest uten å sjekke om den fantes. PHP ga en warning hver gang nøkkelen manglet, og warning-teksten ble skrevet inn i svaret under WooCommerce sine AJAX-kall. Selv etter at rutingproblemet var løst, ville dette ha forurenset JSON-svarene med løs HTML og gitt sporadiske JavaScript-feil i checkouten.

Løsningen

Tre endringer fikk checkouten i orden igjen. Vi holdt dem bevisst små og reverserbare. Målet var å fikse problemet, ikke å bygge om nettstedet.

1. Fjernet forside-rewriten

Vi fjernet .htaccess-regelen som tvang fram home.html. Vanlig WordPress-ruting overtok forsiden igjen. Effekten på lastetid var ubetydelig, fordi forsiden allerede var cachebar og hostingen klarte å servere den raskt uten snarveien via en statisk fil.

Med rewriten borte nådde WooCommerce sine AJAX-forespørsler til /?wc-ajax=update_order_review fram til WordPress slik de skulle, ble håndtert av WooCommerce sine AJAX-håndterere, og returnerte gyldig JSON.

2. Trygg session-tilgang med fallback

Vi erstattet den usikre session-lesingen med validert tilgang og en definert fallback:

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

Dette mønsteret hindrer PHP-warningen, gjør verdien om til et heltall for trygg videre bruk, og gir resten av koden en ren standardverdi å forholde seg til.

3. Ryddet opp i checkout og kvitteringsside

Med checkouten i gang igjen ryddet vi noen omkringliggende skjær i sjøen som kunden hadde levd med:

• Feltoppsettet i checkouten ble brakt i tråd med resten av nettstedet
• Kvitteringssiden (order-received) ble stilet til å matche profilen
• Nederlandske tekster i checkouten ble gjort konsistente
• Mobiloppsettet i checkouten ble testet på faktiske enheter og strammet opp

Hvorfor vi ikke bygde WooCommerce på nytt

Det hadde vært fristende å argumentere for en full ombygging av checkouten, å erstatte WooCommerce, bygge en egen flyt, eller flytte til en annen plattform. Det gjorde vi ikke, fordi ingen av delene ville løst det egentlige problemet.

WooCommerce fungerte som det skulle. Serveren foran fanget opp forespørslene før WooCommerce rakk å svare på dem. Å bytte ut motoren i en bil løser ikke en blokkering i drivstoffslangen.

Dette er et mønster som går igjen i arbeid med WordPress og WooCommerce: symptomet ser ut som at én komponent er ødelagt, men årsaken er et samspill med noe tidligere eller lavere i stacken. Disiplinen ligger i å følge forespørselsstien metodisk, ikke å anta at den mest synlige komponenten er den ødelagte.

Resultatet

Etter at endringene var ute:

• Fullført checkout var tilbake på forventet nivå. Kundene kunne legge i produkter, fylle inn fakturainfo, gjennomføre betaling og nå kvitteringssiden
• AJAX-svarene fra WooCommerce returnerte gyldig JSON hver gang
• PHP-warningene fra session-tilgangen var borte
• Kvitteringssiden var i stil med resten av nettstedet
• Mobilopplevelsen i checkouten ble bedre på mindre skjermer

Total tid fra første henvendelse til ferdig løsning lå innenfor samme uke, som er det vanlige vinduet for denne typen sak.

Hva denne casen viser

Tre poeng verdt å merke seg om du ser lignende symptomer:

1. Uendelig lasting i checkouten betyr vanligvis et feil svar, ikke et manglende et. Nettleseren venter på et svar den kan tolke, men som aldri kommer. Det første du bør sjekke, er hva serveren faktisk sender tilbake til AJAX-endepunktene, ikke hva WordPress-admin sier at den skal sende.
2. Ruting på servernivå kan overstyre forventningene på applikasjonsnivå i det stille. Gamle .htaccess-regler, Nginx-konfigurasjon, CDN-regler og caching-plugins ligger alle foran WordPress. Hvilken som helst av dem kan fange opp en forespørsel før WordPress ser den.
3. Den minste endringen som løser det faktiske problemet. Et nettsted med nede checkout trenger ikke en ombygging. Det trenger at den konkrete blokkeringen fjernes. Større inngrep gir mer risiko, tar lengre tid, og treffer sjelden det som faktisk var galt.

---

Hvis du ser lignende symptomer

Vil du lete selv først, går den gratis guiden WooCommerce-checkout fungerer ikke gjennom de vanligste årsakene, i den rekkefølgen du bør sjekke dem. Innlegget WooCommerce checkout henger i innlasting? viser hvordan du finner forespørselen som feiler.

Vil du heller at vi ser på det, kan vi fikse WooCommerce-kassen for deg. 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 adressen til nettstedet og en kort beskrivelse av hva som skjer i kassen, så bekrefter vi henvendelsen innen 1 time i arbeidstiden.