Feilretting og optimalisering av WooCommerce-nettbutikk for Calidad Gourmet
Da en av Norges premium nettbutikker for gourmetprodukter opplevde stadig oftere nedetid, ødelagt funksjonalitet og uforklarlige feilmeldinger, ble vi kontaktet for en grundig diagnose. Det viste seg å være et klassisk tilfelle av teknisk gjeld kombinert med sikkerhetsgjeld, to former for opphopet etterslep som mange WooCommerce-butikker bygger opp uten å merke det før noe brister.
Kunden er kjent for høy kvalitet og kresne kundeopplevelser. Etter flere år med organisk vekst hadde nettbutikken gradvis akkumulert utdaterte plugins, foreldede temakomponenter og uløste konflikter mellom kjernesystemet og tredjepartsutvidelser. Resultatet var redusert ytelse, sårbarheter og tapte salgsmuligheter under nedetid.
Nedenfor finner du en gjennomgang av hvordan vi diagnostiserte og løste hver utfordring, og hva andre butikkeiere kan lære av prosessen.
Utfordringene
Utdaterte plugins og kompatibilitetskonflikter
Nettbutikken kjørte et stort antall plugins som ikke hadde blitt oppdatert på lang tid. Flere av dem var ikke lenger kompatible med nyere versjoner av WordPress eller WooCommerce. Dette førte til funksjonsfeil i avgjørende deler av kjøpsflyten, fra produktvisning til kassen.
Konflikter mellom WooCommerce og Flatsome-temaet
Etter en større oppdatering av både WooCommerce og det Flatsome-baserte temaet oppstod alvorlige konflikter på serversiden. Disse viste seg som PHP-feil i loggene, ødelagte produktsider og en tydelig svekket brukeropplevelse for besøkende.
DNS- og Cloudflare-feil etter servermigrering
Som ledd i en tidligere servermigrering hadde DNS midlertidig blitt pekt mot en sekundær server. Forsøk på å rulle tilbake DNS-innstillingene og samtidig integrere Cloudflare førte til omfattende propagasjonsforsinkelser. Konsekvensene var:
- Endringer som ikke ble synlige før flere timer etter at de var gjennomført
- Vanskelig verifisering av nettstedets faktiske status fra ulike geografiske lokasjoner
- Forlenget nedetid som direkte rammet salget
Akkumulert teknisk gjeld og stabilitetsrisiko
Den underliggende kodebasen inneholdt foreldede biblioteker, avlagt PHP-syntaks og inkonsistent håndtering av WooCommerce-hooks. Hvert lag av gjeld bidro til at hele systemet ble mer skjørt og sårbart for fremtidige oppdateringer.
Vår tilnærming
Vi løste utfordringene systematisk, fra rask stabilisering til langsiktig herding. Hovedprinsippet var enkelt: gjenopprett driften først, fjern roten til problemene etterpå.
1. Strukturert plugin-revisjon
Vi gjennomgikk alle aktive plugins, vurderte hver enkelt for kompatibilitet, sikkerhet og faktisk bruk, og oppdaterte dem i en kontrollert rekkefølge. WordPress’ egne retningslinjer ble lagt til grunn for å sikre at oppdateringene ikke skapte nye konflikter. Plugins som ikke lenger var nødvendige eller ikke lenger ble aktivt vedlikeholdt, ble fjernet.
2. Feilsøking av PHP og temakonflikter
Vi aktiverte detaljert PHP-debugging, sporet feilkilder gjennom logger og isolerte konfliktene mellom Flatsome-temaet og WooCommerce. Foreldede metoder ble erstattet med moderne alternativer, og vi tilpasset temahook-strukturen til gjeldende WordPress-standarder.
3. DNS-håndtering med lokal hosts-omvei
For å unngå å vente på DNS-propagasjon under feilsøking, oppdaterte vi lokale hosts-filer slik at vi kunne teste den nye konfigurasjonen umiddelbart. Dette ga oss et mer presist bilde av nettstedets tilstand uten å være avhengige av globale cache-tider.
4. Cloudflare-konfigurasjon og overvåking
Vi korrigerte DNS-postene i Cloudflare, etablerte korrekt origin-tilkobling og overvåket global propagasjon i sanntid for å bekrefte at endringene gikk ut til alle regioner som forventet.
5. Ytelses- og sikkerhetsherding
Etter at akutte feil var løst, gikk vi videre med å optimalisere caching-strategien, redusere unødig databasebelastning og styrke sikkerheten mot vanlige WooCommerce-angrepsvektorer. Resultatet var ikke bare en nettside som virket, men en nettbutikk som var raskere og mer robust enn før problemene begynte.
Resultater
- Rask gjenoppretting: Nettbutikken ble stabilisert og satt tilbake i full drift i løpet av prosjektets første fase.
- Full kompatibilitet: Plugins, WooCommerce og Flatsome-temaet fungerte sømløst sammen, uten gjenværende PHP-feil i loggene.
- Bedre ytelse: Lastetiden ble redusert, og brukeropplevelsen ble jevnere på tvers av sider.
- Redusert fremtidig risiko: Foreldet kode ble fjernet, og en bedre struktur gjør at neste WordPress- eller WooCommerce-oppdatering ikke skaper de samme problemene.
Teknologi og verktøy
- Plattform: WordPress, WooCommerce, Flatsome-tema
- Infrastruktur: Cloudflare CDN, DNS-administrasjon, lokal hosts-overstyring for testing
- Diagnose og utvikling: PHP-debugging, query-monitor, kompatibilitetstesting, kodeoptimalisering
Hva andre butikkeiere kan lære
Dette prosjektet illustrerer noen mønstre vi ser igjen og igjen i WooCommerce-prosjekter som har vært i drift i flere år:
- Test før du oppdaterer. En test i stagingmiljø før produksjonsoppdateringer ville ha avdekket Flatsome-konflikten før den nådde sluttbrukerne. Selv en enkel staging-kopi kan spare mye nedetid.
- DNS-endringer er ikke trivielle. Selv en velment tilbakerulling til forrige innstilling kan utløse propagasjonsforsinkelser som påvirker driften i timer eller dager. Bruk lokale hosts-filer eller dedikerte DNS-verktøy for å teste før propagasjon.
- Plugin-mengde er en risikofaktor. Hver plugin er et potensielt sikkerhetshull og en mulig konfliktkilde. Færre, godt vedlikeholdte plugins er bedre enn mange plugins man kanskje trenger senere.
- Tydelig kommunikasjon med kunden gjennom hele prosessen reduserer usikkerheten og gjør det lettere å ta riktige beslutninger raskt.
Relaterte kundecaser
Elementor-hamburgermenyen virket ikke: en JavaScript-feil i konsollen
Mobilmenyen var synlig, men ville ikke åpne seg. Det så ut som en bufringsfeil, men nettleserkonsollen avslørte én JavaScript-syntaksfeil fra en Elementor-plugin som brøt alle interaktive elementer på siden. Slik sporet vi den opp, og slik rettes den uten å røre pluginens kjernefiler.
Les artikkelenWordPress lastet uten CSS og bilder: én mappetillatelse var årsaken
Et WordPress-nettsted lastet som stort sett uformatert HTML: designet var borte, bildene ødelagte og navigasjonen redusert til vanlige lenker. Sidene, databasen og admin-området kjørte fortsatt. Årsaken var verken skadevare eller en mislykket oppdatering, men én mappetillatelse på wp-content.
Les artikkelenWordPress Multisite kompromittert: slik undersøkte og gjenopprettet vi nettverket
Det som kom inn som ødelagte sider og manglende stilark, ble til en full sikkerhetshendelse. På tvers av en delt WordPress Multisite-installasjon fant vi uautoriserte omdirigeringer, en endret kjernefil og obfuskert PHP-skadevare. Slik undersøkte vi nettverket og bygde en trygg vei til gjenoppretting.
Les artikkelen