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 case-studien 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.
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:
- Feil i nettleserkonsollen. JavaScript meldte fra om uventede svar fra WooCommerce sine AJAX-endepunkter.
- Inspeksjon av AJAX-forespørslene. Spesielt
update_order_review-kallet som kjører når en kunde fyller inn fakturadetaljene sine. - Analyse av serversvar. Hva WooCommerce faktisk fikk tilbake fra serveren.
- Temastruktur. Bekreftet at ingen template-overstyringer ødela checkout-markeringen.
- Rewrite-regler.
.htaccess-fila og all egendefinert ruting. - 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 WooCommerce AJAX-kall. 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, caster verdien til 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 WordPress- og WooCommerce-arbeid: 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
- WooCommerce sine AJAX-svar returnerte gyldig JSON konsekvent
- 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 det vanlige vinduet på samme uke for denne typen sak.
Hva denne case-studien viser
Tre poeng verdt å merke seg om du ser lignende symptomer:
- 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.
- 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. - 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
Send oss URL-en til nettstedet og en kort beskrivelse av hva som skjer i checkouten. Vi stiller diagnose gratis i arbeidstiden og gir fast pris før noe arbeid settes i gang. De fleste WooCommerce checkout-problemene vi ser løses samme dag.
Relaterte kundecaser
Sikkerhetspluginen meldte nettstedet rent – vi fant tre skjulte bakdører i WordPress
Bookingskjemaer sviktet, sidebyggeren ville ikke laste, og feilloggen var tom – men sikkerhetspluginen meldte nettstedet som rent. Vi verifiserte installasjonen fil for fil mot offisielle kilder og fant tre skjulte bakdører, hver bygget for å overleve akkurat den skanningen som allerede hadde friskmeldt nettstedet.
Les artikkelWordPress lastet uten CSS og bilder: én mappetillatelse var årsaken
Et WordPress-nettsted kan se fullstendig ødelagt ut selv om både sidene, databasen og admin-området fortsatt virker. Dette nettstedet lastet som stort sett uformatert HTML: designet var borte, bildene ødelagte, navigasjonen redusert til vanlige lenker, og deler av kontrollpanelet manglet styling. Årsaken var verken skadevare eller en mislykket oppdatering. Det var én enkelt mappetillatelse på wp-content […]
Les artikkelGjenopprettet et eldre WordPress-nettsted etter PHP-feil og shortcode-problemer
Et eldre WordPress-nettsted begynte å vise fatale feil etter en PHP-oppdatering. Vi gjenopprettet admin-tilgang, løste kritiske PHP-feil, håndterte pluginkonflikter og fikk shortcode-seksjonen til å fungere igjen uten full redesign.
Les artikkel