BruktTech: nettbutikken vi bygger og driver selv
BruktTech er vår egen nettbutikk for brukte bedrifts-PC-er i Oslo. Vi bygde den ikke for en kunde og leverte den fra oss. Vi bygde den, vi driver den hver dag, og vi fikser det som ryker. Hver ordre, betaling og sending går gjennom kode vi har skrevet eller satt opp.
Derfor er den vår mest nyttige kundecase. Den viser hvordan en WooCommerce-butikk bygges, og hva som skal til for at den fortsetter å selge etter lansering.
Hva butikken går på
- Betaling slik nordmenn forventer. Vipps, Klarna, kort, Apple Pay og Google Pay i samme kasse.
- Frakt med hentesteder. Kunden velger et PostNord-hentested i kassen, eller henter gratis i Oslo.
- Mva etter avansesystemet. Brukte varer selges etter avansesystemet. Butikkens admin regner ut avgiften på hvert salg og gjør klar tallene for hver mva-termin.
- Samtykkebasert sporing. Et informasjonskapselbanner spør først, og Google Analytics og Google Ads lastes først når besøkende har sagt ja.
- Produktsider som svarer på spørsmål. Hver maskin har sin egen side med tilstand, spesifikasjoner og pris, og katalogen kan filtreres på modell, spesifikasjoner og pris.
- Publisering med hjelp av KI. Opplysningene om én maskin blir til en produktside og annonser for andre salgskanaler, uten å skrive alt på nytt.
- En fast prosess for endringer. Endringer testes på en kopi av butikken først og kommer ut i nettbutikken gjennom en automatisk publiseringsløype, med sikkerhetskopier lagret et annet sted.
Problemer vi fant og løste i drift
Å drive en nettbutikk betyr å møte problemene som aldri dukker opp i en demo. Noen fra de siste månedene:
1. Roboter som gikk gjennom filtersidene
Omtrent halvparten av alle forespørsler kom fra en robot som prøvde kombinasjon etter kombinasjon av katalogfiltre. Det ga bare belastning. Vi stengte de adressene med regler i robots.txt og en regel i Cloudflare, og lot klikk fra Google Ads slippe gjennom, så betalt trafikk aldri ble stoppet.
2. Et informasjonskapselbanner som dekket det meste av mobilskjermen
Den første versjonen av banneret tok 57 % av en mobilskjerm. Kortere tekst og knapper på én rad tok det ned til 32 %, så kunden ser produktet før samtykkespørsmålet.
3. En reservasjon i kassen som fikk PC-er til å se solgt ut
Hver PC finnes i ett eksemplar. Et ubetalt forsøk i kassen holdt maskinen av i 60 minutter og viste den som solgt for alle andre, også for samme kunde på en annen enhet. Vi kortet ned reservasjonen til 20 minutter og endret teksten, samme dag som vi fant feilen.
4. Svar som havnet i feil innboks
En innstilling i en e-postutvidelse kopierte en omskrevet avsenderadresse inn i Reply-To, så kunder som svarte på en ordre-e-post nådde feil postkasse. Vi rettet det i koden og sjekket alle typer e-post butikken sender.
Slik holder vi den i gang
- Testmiljø først. Hver endring testes på en kopi av butikken før den går ut.
- Sjekk etter hver publisering. Viktige sider, kassen og hver betalingsmåte testes når en ny versjon er ute.
- Sikkerhetskopier utenfor serveren. Hele nettstedet sikkerhetskopieres et annet sted, ikke bare på samme maskin.
Teknologi vi bruker
WooCommerce, Flatsome, Vipps, Klarna, Stripe (kort, Apple Pay og Google Pay), PostNord, Complianz, Google Analytics 4, Google Ads, WP Rocket, Cloudflare og GitHub Actions.
Hva det betyr for din nettbutikk
Når du bruker oss til å bygge en WooCommerce-butikk, rette feil eller ta vare på den over tid, får du utviklere som håndterer oppdateringer av betalingsutvidelser, regler for informasjonskapsler, fraktvalg og mva-ordninger i sin egen butikk hver uke. Har butikken din et problem som de over, ta kontakt, så ser vi på det sammen med deg.
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