WooCommerce-utvidelser: hvilke du faktisk trenger og hvilke som bare tynger butikken

WooCommerce er ikke et eget system, bare en utvidelse til WordPress som av seg selv gjør en nettside om til en butikk. Alt det andre, altså betaling, frakt, faktura og markedsføring, er flere utvidelser lagt oppå. Og nettopp denne modellen, genial i sin fleksibilitet, er også stedet der de fleste butikker velter: ikke på mangel på funksjoner, men på overflod av dem.

Denne guiden handler om hvilke WooCommerce-utvidelser du faktisk trenger, hvilke som tilfører verdi og hvilke som bare tetter igjen handlekurven og drar inn sikkerhetsrisiko. Ingen “topp 50”-liste, for en slik liste er bløff. I stedet konkrete problemklasser og hvordan du løser dem.

#Hva en WooCommerce-utvidelse egentlig er

Det er verdt å skille to ting som hele tiden flyter sammen i samtaler. WooCommerce er én utvidelse, i dag vedlikeholdt av Automattic, som legger til produkter, handlekurv, kasse og bestillinger i WordPress. En “WooCommerce-utvidelse” i den andre betydningen er en utvidelse du bolter på denne motoren: en betalingsløsning, en fraktkalkulator, en integrasjon med regnskapssystemet.

Denne forskjellen har praktiske konsekvenser. En oppdatering av WooCommerce-kjernen kan ødelegge en utvidelse som forutsatte den gamle formen på handlekurven. Derfor spør man ikke “fungerer denne utvidelsen” med en seriøs butikk, men “henger utvikleren med på kjerneendringene, og med hvilken forsinkelse”. Det er det første filteret, og det kutter halvparten av kandidatene fra katalogen.

#Slik sjekker du om en utvidelse er kompatibel med din WooCommerce-versjon

WooCommerce gir utviklere av utvidelser to topptekstlinjer for akkurat dette spørsmålet. WC requires at least oppgir minste WooCommerce-versjon utvidelsen trenger for å fungere, og WC tested up to oppgir nyeste WooCommerce-versjon utvikleren har testet den med (WooCommerce-dokumentasjon for utviklere). Begge står i kommentarblokken øverst i utvidelsens hoved-PHP-fil, så du kan lese dem før installasjon ved å åpne den filen i ZIP-pakken.

Verdien i WC tested up to betyr mer enn den ser ut til, fordi WooCommerce beveger seg raskt. Ifølge utgivelseskalenderen kommer nye versjoner vanligvis i en femukerssyklus, og versjonsnumrene skiller ikke mellom store og små utgivelser (WooCommerce-utgivelseskalender). Den 15. oktober 2026 var 11.2.1 gjeldende versjon i WordPress.org-katalogen. En utvidelse der WC tested up to ligger flere versjoner bak, er ikke nødvendigvis ødelagt, men ingen har sjekket den mot koden du er i ferd med å kjøre. Denne linjen slår også på advarslene i neste avsnitt: WooCommerce sjekker funksjonskompatibilitet bare for utvidelser som i det hele tatt oppgir WC tested up to.

WordPress 6.5 la til en annen, mer generell mekanisme: toppteksten Requires Plugins. En utvidelse lister kommaseparert de WordPress.org-slugene den er avhengig av, for eksempel Requires Plugins: woocommerce. WordPress nekter da å aktivere den avhengige utvidelsen før avhengighetene er aktive, og nekter å deaktivere eller slette WooCommerce så lenge en avhengig utvidelse er aktiv eller installert (Make WordPress Core, 5. mars 2024). To begrensninger er verdt å kjenne før du stoler på det. Toppteksten har ingen versjonskrav, så den sier at WooCommerce må finnes, ikke hvilken versjon. Og en utvidelse som ligger på WordPress.org kan bare oppgi avhengigheter som også ligger der; en utvidelse kjøpt et annet sted kan oppgi en avhengighet, men WordPress viser ingen installasjonslenke for den.

#Er WooCommerce-utvidelser kompatible med HPOS og blokkassen

To endringer i WooCommerce-kjernen fra 2023 skiller vedlikeholdte utvidelser fra forlatte raskere enn noen stjernevurdering.

#Høyytelses ordrelagring (HPOS)

Fra WooCommerce 8.2, utgitt i oktober 2023, er høyytelses ordrelagring (HPOS) slått på som standard i nye installasjoner. Ordrer ligger ikke lenger i de generelle tabellene posts og postmeta, men i fire egne: wc_orders, wc_order_addresses, wc_order_operational_data og wc_orders_meta, hver med databaseprefikset foran (HPOS-dokumentasjon). En utvidelse som leser ordrer rett fra postmeta, ser et tomt eller utdatert bilde i en slik butikk.

En utvidelse erklærer kompatibilitet i hovedfilen med ett enkelt kall på kroken before_woocommerce_init:

add_action( 'before_woocommerce_init', function () {
	if ( class_exists( \Automattic\WooCommerce\Utilities\FeaturesUtil::class ) ) {
		\Automattic\WooCommerce\Utilities\FeaturesUtil::declare_compatibility( 'custom_order_tables', __FILE__, true );
	}
} );

Med false i stedet for true erklærer den inkompatibilitet. WooCommerce advarer da en administrator som prøver å slå på HPOS mens utvidelsen er aktiv, og viser en advarsel i utvidelseslisten (HPOS-oppskriftsbok for utvidelser). En advarsel blokkerer ingenting, så den er lett å klikke forbi. En rask sjekk før kjøp: søk i utvidelsens kode etter custom_order_tables. Mangler strengen, har ikke utvikleren tatt tak i endringen.

#Blokker for handlekurv og kasse

WooCommerce 8.3, utgitt 14. november 2023, gjorde blokkene for handlekurv og kasse til standard i nye butikker, mens eksisterende butikker beholder varianten de allerede bruker (WooCommerce-utviklerbloggen). Utvidelser erklærer kompatibilitet på samme måte, med funksjonsnavnet cart_checkout_blocks. Betalingsutvidelser merker dette mest. En betalingsløsning må registrere seg både på serveren og i fronten av blokkassen, og en løsning som mangler i frontlisten, behandler WooCommerce som inkompatibel. En utvidelse som ikke erklærer noe, dukker kanskje ikke opp i blokkassen i det hele tatt, eller får den til å feile. I en ny butikk er derfor første test av enhver utvidelse for betaling, frakt eller kassefelt en testordre gjennom blokkassen, ikke gjennom den klassiske kortkodesiden.

#WooCommerce-utvidelser for betaling, frakt og faktura

Nesten alle butikker trenger den samme kjernen av utvidelser, uavhengig av bransje.

Betaling. Kundene forventer sine vante raske metoder i kassen, ikke å taste inn et kortnummer for hånd. Standarden her er løsninger som Vipps, Klarna og kort. Hver har en offisiell WooCommerce-utvidelse, men de skiller seg i hvordan de håndterer refusjoner, delbetaling, gjentakende betalinger og hvor rent de rapporterer transaksjoner tilbake til kontrollpanelet. Valget av betalingsløsning er en forretningsbeslutning om gebyrer og kontantstrøm, ikke bare en teknisk.

Frakt. Uten en skikkelig integrasjon med transportører og hentepunkter lekker en butikk konvertering på siste steg. Posten, Bring og PostNord tilbyr egne utvidelser med satsberegning og etikettutskrift rett fra bestillingen, og meglerverktøy lar deg sammenligne transportører og generere etiketter fra bestillingsvisningen. Dette er en av de funksjonene der en god utvidelse reelt forkorter ordrehåndteringen og en dårlig genererer adressefeil og reklamasjoner.

Faktura. Automatisk, regelriktig fakturering ordnes av integrasjoner med regnskapsplattformer som Fiken eller Tripletex. Dette er området der gratis halvløsninger hevner seg raskest: å skrive ut fakturaer for hånd ved hundre bestillinger om dagen er en heltidsstilling, ikke en innsparing. I tillegg må regnskapsintegrasjonen kunne levere SAF-T-eksport etter bokføringsloven, ellers blir et bokettersyn fra Skatteetaten en manuell jobb. Selger du også inn i det polske markedet, dekkes polsk faktura- og kassakrav separat: Polski for WooCommerce legger til NIP-feltet med GUS-oppslag, mens Polski PRO lager PDF-fakturaer og sender dem til Polens KSeF-system.

Først over denne kjernen legger man til resten: markedsføring, anmeldelser, produktvarianter, B2B. Men hvis disse tre klassene ikke går rent, vil ingen markedsføringsutvidelse ta det igjen.

#Gjør mange utvidelser WooCommerce tregt

Den vanligste myten lyder: “Jeg har for mange utvidelser, derfor er butikken treg.” Det er en forenkling. Det som teller er ikke antallet, men den samlede kostnaden ved å kjøre kode og databasespørringer ved hver forespørsel.

To reelle saker fra praksis viser forskjellen. En butikk med tretti utvidelser og en time to first byte på 1,8 sekunder, der synderen var én tung page builder som lastet sitt eget rammeverk på hver underside. Og en annen, på Elementor, som brøt sammen under Black Friday-trafikken fordi cache- og bildeoptimaliseringsutvidelsene var dårlig konfigurert, ikke fordi det var mange av dem. I begge tilfeller var medisinen ikke “slett halvparten av utvidelsene”, men “finn de to som koster mest”.

Til diagnose brukes Query Monitor, som viser hvor mange databasespørringer og hvor mye PHP-tid hver utvidelse spiser. Med måling i stedet for gjetting slutter optimalisering av WooCommerce-butikkens ytelse å være spådom. Sidecache, objektcache og fornuftig bildehåndtering gir som regel et større hopp enn noen som helst funksjonskutting.

#Sikkerhet i WooCommerce-utvidelser og angrep på leverandørkjeden

En WooCommerce-utvidelse har full tilgang til databasen og PHP-miljøet. Det betyr at én ondsinnet eller kapret utvidelse leser kundedata, endrer bestillinger og injiserer kode. I 2026 sluttet dette å være teori.

I løpet av én måned stengte WordPress.org-katalogen flere utvidelser med innsmuglede bakdører, i noen tilfeller etter at en utviklerkonto var overtatt eller et forlatt prosjekt kjøpt opp. Det viser hvor risikoen virkelig ligger: ikke i antallet utvidelser, men i hvem du stoler på til å vedlikeholde den koden.

Det praktiske hygieneminimumet er enkelt og kjedelig. Installer utvidelser bare fra offisielle kilder, aldri fra “nulled”-pakker. Sjekk dato for siste oppdatering og utviklerens respons på meldinger. Hold et register over hva du har installert og hvem som står bak, for ved en compliance-revisjon (for eksempel under DORA for regulerte aktører) er leverandøren av betalingsutvidelsen formelt en tredjepart. Last bare ned oppdateringer fra den opprinnelige leverandøren, ikke fra den første lenken i et søkemotor.

#Hva utvidelsessiden på WordPress.org forteller deg før installasjon

Hver utvidelse i katalogen leverer de samme metadataene gjennom det offentlige utvidelses-API-et, og utvidelsessiden viser de samme feltene. Slik svarte API-et 15. oktober 2026 for fire utvidelser som går igjen i nesten hver WooCommerce-revisjon:

Tre kolonner fortjener en nærmere titt. Datoen for siste oppdatering er det billigste tegnet på vedlikehold, og den leses best opp mot WooCommerce sin femukerssyklus. “Testet opp til” gjelder WordPress, ikke WooCommerce; motstykket for WooCommerce er toppteksten WC tested up to beskrevet over, som katalogen ikke viser. Og begge betalingsutvidelsene oppgir woocommerce som påkrevd utvidelse, så de bruker allerede avhengighetsteksten fra WordPress 6.5. Aktive installasjoner måler popularitet, ikke kvalitet: Query Monitor har en firedel av installasjonene til WooPayments og er likevel standardverktøyet for ytelsesdiagnosen beskrevet tidligere.

#Slik går du gjennom installerte WooCommerce-utvidelser med WP-CLI

Registeret over installerte utvidelser fra sikkerhetsavsnittet trenger ikke være et regneark du fører for hånd. WP-CLI bygger det på serveren med én kommando:

wp plugin list --fields=name,status,version,update_version,auto_update,wporg_status,wporg_last_updated --format=csv

Feltet wporg_status viser om hver utvidelse fortsatt er tilgjengelig i WordPress.org-katalogen, wporg_last_updated når den sist ble oppdatert der, og auto_update om automatiske oppdateringer er slått på. Med --format=csv eller --format=json blir utdataene en fil du kan legge ved en revisjon (WP-CLI-dokumentasjon). En utvidelse som er stengt i katalogen, er nøyaktig tilfellet fra avsnittet om leverandørkjeden: katalogen slutter å distribuere den, men kopien på serveren din fortsetter å kjøre. Stengninger er ikke sjeldne selv blant betalingsutvidelser: 15. oktober 2026 svarte utvidelses-API-et closed for slugen redsys-gateway-for-woocommerce. Katalogen publiserer ikke grunnen til en stengning, så statusen er en grunn til å undersøke, ikke en dom.

#Bør WooCommerce-utvidelser oppdateres automatisk

WordPress 5.5 la til brytere for automatiske oppdateringer av utvidelser og temaer i kontrollpanelet. De er av som standard, så hver utvidelse blir værende på manuelle oppdateringer til en administrator slår dem på (Make WordPress Core, 15. juli 2020). Filteret auto_update_plugin kan slå på automatiske oppdateringer for alle utvidelser samtidig, også de som installeres senere, og det overstyrer innstillingene i kontrollpanelet uten å vise det i grensesnittet. Det er verdt å sjekke i hver butikk du overtar: hvis bryterne sier av, men utvidelser likevel oppdateres om natten, let etter dette filteret i temaet eller i en must-use-utvidelse.

I en butikk følger fordelingen regelen fra neste avsnitt. Utvidelser langt unna penger og kundedata, for eksempel et galleritillegg eller en widget i kontrollpanelet, kan oppdatere seg selv. WooCommerce selv og utvidelsene for betaling, frakt og faktura bør først gjennom en stagingkopi, fordi en ny WooCommerce-utgivelse kommer omtrent hver femte uke, og hver av dem kan endre det disse utvidelsene bygger på. Etter hver slik oppdatering er en testordre gjennom kassen minstekravet før endringen når kundene.

#WooCommerce-utvidelser gratis eller betalt

En gratis utvidelse fra WordPress.org-katalogen holder til å starte og til de fleste ikke-kritiske funksjoner. Fellen dukker opp ved to ting: skalering og ansvar.

Ved inntektsavhengige funksjoner, altså betaling, frakt og faktura, teller aktiv støtte og jevnlige, signerte oppdateringer. En gratis utvidelse som utvikleren har forlatt, blir din tekniske gjeld: du må lappe den selv eller migrere i all hast når den slutter å virke etter en kjerneoppdatering. En betalt utvidelse med avtale flytter en del av dette ansvaret over på leverandøren, og over et år blir det ofte billigere enn kostnaden av din egen tid til brannslukking.

Hvis du leter etter velprøvde, kommersielle utvidelser med støttegaranti, finner du ferdige WooCommerce-utvidelser i spesialiserte utvidelsesbutikker der koden vedlikeholdes og oppdateres. Det er et fornuftig kompromiss mellom full egenutvikling og risikoen for en forlatt utvidelse fra den gratis katalogen.

Tommelfingerregel: jo nærmere en funksjon ligger penger og kundedata, desto mindre lønner det seg å spare på utvidelsen. Jo lenger unna, for eksempel et kosmetisk galleritillegg, desto roligere kan du bli ved den gratis.

#Betalingsløsning for WordPress og WooCommerce i Norge

En betalingsløsning velges ikke etter funksjonslisten, men etter hvem kundene dine allerede stoler på i kassen. I Norge betyr det i praksis Vipps først, deretter kort og faktura. Vipps har egen offisiell utvidelse for WooCommerce, og den bør som regel settes opp først, ikke sist.

Tre ting avgjør om oppsettet holder over tid. Det første er antall klikk fram til betaling: hver ekstra side mellom handlekurv og bekreftelse koster ordrer, og en løsning som åpner et nytt vindu presterer dårligere på mobil enn en som fullføres i samme flyt. Det andre er hva som skjer når betalingen feiler halvveis, altså om ordren blir liggende som ubetalt og om kunden får en vei tilbake, eller om den bare forsvinner. Det tredje er avstemming mot regnskap: en løsning som ikke kan eksportere transaksjoner slik regnskapsføreren din trenger dem, flytter arbeidet over på deg hver måned.

Praktisk råd fra oppsett jeg har gjort: test alltid en feilet betaling før lansering, ikke bare en vellykket. Den vellykkede veien fungerer nesten alltid. Det er avbruddet, det doble klikket og tidsavbruddet mot bankens side som lager de stille tapene, og de vises ikke i noen rapport før kunden ringer.

#Gratis WooCommerce-utvidelser med åpen kildekode

Dette er våre egne utvidelser. Jeg bygger og vedlikeholder noen små WooCommerce-utvidelser med ett klart formål, gratis og åpen kildekode, laget for hullene en butikk treffer etter hvert som den vokser:

• Peek åpner en produktforhåndsvisning rett fra listen uten sidelasting, noe som korter ned veien fra kategori til handlekurv i store kataloger.
• Reel legger til galleri-zoom og video på produktsiden, det som oftest mangler når kjøpet avgjøres visuelt.
• Swift gir en kjøp nå-knapp som hopper over handlekurven og går rett til kassen; fra versjon 1.1.8 lastes stilark kun på butikksider og ved hurtigkjøp, slik at resten av nettstedet holdes raskt.

Samme familie inkluderer også Migrator for sikkerhetskopi og migrering, Sieve for produktfiltre, Restock for tilbake-på-lager-varsler, Tiers for trinn- og kvantumspriser, Customs for importavgift i EU, Botelix for panteordninger og kasser (Kastenpfand), Pasporto for det digitale produktpasset (ESPR), og polski for samsvar i det polske markedet (KSeF, Omnibus, GPSR). Hver av dem har en steg-for-steg-guide i plogins veiledningssenter.

Oppdatering 1. november 2026. Også disse utvidelsene er våre, gratis på WordPress.org, og hver er satt opp mot problemet i butikken den løser:

#Hvilke WooCommerce-utvidelser du bør unngå

Noen mønstre gjentar seg i hver butikk som havner hos oss til revisjon.

Alt-i-ett-utvidelser som lover markedsføring, SEO, cache og sikkerhetskopier i én pakke. De gjør vanligvis hver av disse tingene middelmådig og er vanskelige å bytte ut fordi de kobler seg inn overalt. Bedre å velge ett godt verktøy per oppgave.

Forlatte utvidelser, altså slike uten oppdatering på mange måneder mens WooCommerce-kjernen aktivt videreutvikles. Det er de første kandidatene til problemer etter neste større oppdatering.

Page builders der de ikke trengs. På en produktside som uansett rendres fra en mal, legger en tung builder til ytelseskostnad uten reell nytte. Trenger du et uvanlig oppsett, er en dedikert utvidelse eller blokk skrevet for det konkrete behovet ofte billigere i drift enn en universell koloss.

#Oppsummering

En god WooCommerce-utvidelsesstabel er ikke den lengste lista, bare den korteste som oppfyller butikkens krav. Begynn med de tre kritiske klassene for ditt marked: betaling, frakt, faktura. Mål effekten på ytelsen i stedet for å gjette. Behandle hver utvidelse som en leverandør du betror kundedata, og velg vedlikeholdt kode framfor det billigste. Resten er finjustering for en konkret salgsmodell, ikke et kappløp om antallet installerte utvidelser.

Sist oppdatert: 15. oktober 2026