Skreddersydd Shopify-utvikling eller tematilpasning: slik velger du

De fleste Shopify-forespørsler kommer formulert som "kan du ikke bare endre temaet?" Noen ganger er svaret ti minutter i temaredigeringsverktøyet. Andre ganger ligger endringen i kassen eller i prislogikken, der temakoden ikke når i det hele tatt, og det reelle valget står mellom en app fra App Store, en egendefinert app med Shopify Functions, en oppgradering av planen, eller å godta at Shopify ikke tillater det. Velger du feil lag, ender du gjerne med å betale for et tema-hack som ryker ved neste oppdatering, eller for en egendefinert app som bare kjører på en plan du ikke har.

Denne guiden sorterer forespørsler etter laget som faktisk kan levere dem. Alle plangrenser, datoer og tall nedenfor kommer fra shopify.dev eller Shopify Help Center og er sjekket 23. oktober 2026.

#Hva kan du endre i et Shopify-tema uten koding

Temaer for Online Store 2.0 bygges av JSON-maler. Shopifys dokumentasjon om JSON-maler beskriver dem som datafiler som lagrer en liste over seksjoner og innstillingene deres, og sier at butikkeiere “kan legge til, fjerne og endre rekkefølgen på disse seksjonene i temaredigeringsverktøyet” (egen oversettelse). En mal kan vise opptil 25 seksjoner, og hver seksjon kan ha opptil 50 blokker.

En stor del av det som kalles tilpasning, er altså konfigurasjon: å flytte en blokk med kundeomtaler høyere opp på siden, legge til en seksjon med størrelsesguide i én produktmal, bygge en landingsside av eksisterende seksjoner, endre farger og skrifttyper i temainnstillingene. Hvis temaet ditt allerede har seksjonen du trenger, må ingen skrive kode. Tråden på r/shopify som stilte akkurat dette spørsmålet 23. oktober 2026, sa det på én linje:

mange “skreddersydde” forespørsler viser seg å være et metafelt pluss en seksjon.

(u/Born_Programmer_1089, r/shopify, 23. oktober 2026, egen oversettelse)

Neste trinn er å redigere Liquid, CSS og JavaScript i selve temaet. Det dekker en ny seksjonstype, en egen produktmal, et metafelt som vises på produktsiden eller et annet oppsett for samlingsfiltre. Shopifys hjelpeside om redigering av temakode er tydelig på hva det koster: du bør bare redigere koden “hvis du ikke kan gjøre endringene du trenger” i redigeringsverktøyet, og hvis endringene ikke er kompatible med en temaoppdatering, “fjernes alle kodeendringene dine i den oppdaterte kopien” (egen oversettelse). Lag en kopi av temaet først, og før en liste over endrede filer, så blir neste oppdatering en sammenslåing og ikke en utgravning.

Like viktig er det temakoden ikke kan gjøre. Den viser nettbutikken. Den kjører ikke i kassen, den endrer ikke hvordan rabatter beregnes, og den kan ikke hindre at en ordre legges inn.

#Når trenger du en app eller en temaapputvidelse

Kundeomtaler, produktpakker, størrelsesveiledere, lojalitetswidgeter og 3D-visninger kommer som regel fra apper. Moderne apper legger det som vises i butikken, i en temaapputvidelse (theme app extension): Liquid-blokker som butikkeieren plasserer i temaredigeringsverktøyet. Shopify beskriver fordelen rett ut: butikkeiere “trenger ikke å redigere temakoden manuelt”, og appene “redigerer ikke temakoden, noe som reduserer risikoen for endringer som ødelegger temaet” (egen oversettelse). Temaapputvidelser fungerer med Online Store 2.0-temaer, så en butikk som fortsatt bruker et eldre tema, mister denne ryddige veien.

For en butikkeier gir det to regler:

• Hvis en app fra App Store gjør jobben og installeres via appblokker, er den som regel billigere og tryggere enn egen temakode, fordi apputvikleren vedlikeholder den og den overlever temaoppdateringer.
• Hvis en utvikler foreslår å lime inn kodebiten til en app manuelt i theme.liquid, spør hvorfor appen ikke har en appblokk. Manuelt innlimte kodebiter blir gjerne liggende i temaet etter at appen er avinstallert.

En egendefinert app gir mening når logikken er spesifikk for virksomheten din (en ERP-synkronisering, en prisregel ingen selger, et godkjenningstrinn for B2B), eller når alternativene i App Store hver dekker halve behovet og kommer i konflikt med hverandre.

#Hva er Shopify Functions, og hvilken plan trenger du

Shopify Functions lar utviklere “tilpasse Shopifys backend-logikk ved å kjøre egen kode under kasseprosessen” (egen oversettelse). Dette er laget for alt som endrer penger, levering eller om en ordre får gå gjennom. De gjeldende Function-API-ene:

• Discount: én funksjon kan gi rabatt på produkter, ordrer og frakt
• Payment Customization: gi nytt navn til, endre rekkefølgen på eller skjule betalingsmåter, og sette betalingsvilkår
• Delivery Customization: gi nytt navn til, sortere eller skjule leveringsalternativer
• Cart and Checkout Validation: blokkere kassen med din egen feilmelding
• Cart Transform: utvide, slå sammen eller oppdatere handlekurvlinjer, for produktpakker
• Fulfillment Constraints og Order Routing
• Pickup Point og Local Pickup Delivery Option Generators

Functions kompileres til WebAssembly, kjører på Shopifys servere og arbeider under strenge grenser for antall instruksjoner og størrelse på inndata og utdata. Planregelen er det butikkeiere oftest overser. Shopifys dokumentasjon sier at “butikker på alle planer kan bruke offentlige apper som distribueres gjennom Shopify App Store og inneholder funksjoner”, men at “bare butikker på en Shopify Plus-plan kan bruke egendefinerte apper som inneholder Shopify Function-API-er” (egen oversettelse).

I praksis: en regel som skjuler betalingsmåter fra en app i App Store, fungerer på Basic. Den samme regelen skrevet som en egendefinert app bare for din butikk krever Plus. Før du bestiller en egen Function, sjekk planen din, eller sjekk om en offentlig app allerede tilbyr den.

Det finnes også grenser per butikk. Shopify tillater maksimalt 25 aktive funksjoner hver for rabatter, tilpasning av betaling, tilpasning av levering og validering. Butikker med mange apper som gjør lignende jobber, kan nå det taket.

Shopify Scripts, det eldre verktøyet Script Editor for rabatt- og fraktlogikk, er historie. Hjelpesiden for Script Editor sier at Shopify Scripts fra 30. juni 2026 “er avviklet”, at publiserte skript “er deaktivert og ikke lenger fungerer” (egen oversettelse), og at erstatningen er Shopify Functions. Hvis trappeprisene dine stille sluttet å virke i sommer, er det grunnen.

#Grossistpriser i Shopify uten app: går det

Grossistsalg er det tydeligste eksempelet på hvorfor du bør sjekke Shopifys innebygde funksjoner før noen skriver kode. 22. oktober 2026 spurte en butikkeier r/shopify om akkurat dette:

jeg prøver å finne ut hvilke alternativer folk her har brukt for å gi grossister en rabattert pris sammenlignet med vanlige kunder. jeg tenkte at jeg kanskje kunne lage en rabattkode som kunden kunne bruke for å få en fast %-rabatt.

(u/GreenGloober, r/shopify, 22. oktober 2026, egen oversettelse)

Svarene dekket to av lagene ovenfor. En utvikler beskrev temaveien: en rabattkode begrenset til et kundesegment for kassen, pluss en Liquid-sjekk på produktsiden.

Merk grossistkundene dine med en tagg (f.eks. “wholesale”), lag et kundesegment fra den taggen, og opprett en prosentrabattkode som er begrenset til det segmentet, så den ikke lekker til vanlige kunder. […] Det fikser du i temaet: en liten Liquid-sjekk på customer.tags som viser grossistprisen ved siden av eller i stedet for veiledende pris for innloggede grossistkunder. Det er bare visning, så det er fortsatt rabatten som gjør selve jobben i kassen.

(u/vladeta, r/shopify, 23. oktober 2026, egen oversettelse)

Det fungerer for en fast prosentsats, og advarselen om at det er “bare visning”, er det viktigste: temaet viser et tall, rabatten bestemmer hva kunden betaler, og de to kan skli fra hverandre. Den samme kommentaren kalte deretter innebygde B2B-prislister en Plus-funksjon. Et annet svar pekte i stedet på den innebygde løsningen:

legg inn grossistene dine som bedrifter, lag en katalog med grossistrabatten i %, og når de logger inn ser de sin egen pris på hvert produkt. uten plus er du begrenset til 3 kataloger men det er mer enn nok hvis du bare har ett grossistnivå

(u/HoneyedVices, r/shopify, 23. oktober 2026, egen oversettelse)

Shopifys dokumentasjon gir det andre svaret rett. Shopify B2B “er tilgjengelig på planene Basic, Grow, Advanced og Shopify Plus” (egen oversettelse), ikke bare på Plus. Du registrerer grossistkunder som bedrifter og tildeler dem kataloger med egne priser.

Sammenligningen av B2B-funksjoner per plan viser hvor planene skiller seg:

En grossist med én forhandlerprisliste og kvantumsrabatter kan altså klare seg uten app og uten egen kode på Basic. En virksomhet med egen prisavtale for hver kunde trenger direkte katalogtildeling, og det betyr Plus, en prisapp eller en egen rabattfunksjon i en offentlig app. Å skrive om priser i handlekurven har sin egen sperre: Cart Transform-API-et sier at bare utviklingsbutikker eller Plus-butikker kan bruke apper med lineUpdate-operasjoner.

WooCommerce-eiere som sammenligner plattformer, kjenner igjen avveiningen fra den andre siden: der er kundespesifikke priser en utvidelse eller egen PHP-kode på hvilket som helst webhotell, uten noe plannivå, men du vedlikeholder det selv. Vår sammenligning av Shopify Plus og headless WooCommerce går gjennom det valget i sin helhet.

#Hva erstattet checkout.liquid

Kassen var tidligere stedet der Plus-butikker kunne redigere Liquid fritt. Det tok slutt i etapper, og Shopify har presise datoer:

• 13. august 2024: tilpasninger i checkout.liquid sluttet å virke på sidene Information, Shipping og Payment. Shopifys endringslogg sa at butikker som ikke rakk fristen, ville bli “automatisk oppgradert til en standard Shopify-kasse uten tilpasninger” (egen oversettelse).
• 28. august 2025: ifølge dokumentasjonen for checkout.liquid ble den faset ut på sidene Thank you og Order status, og script-tagger på de sidene ble faset ut for Plus-butikker. Samme dag ble feltet for tilleggsskript skrivebeskyttet.
• 26. august 2026: fristen for butikker uten Plus til å oppgradere sidene Thank you og Order status. Shopifys hjelpeside sier at oppgraderingen erstatter de sidene og alle eksisterende tilpasninger på dem.

Erstatningen er et sett smalere verktøy. Checkout UI extensions legger til blokker bygd av Shopifys egne komponenter, og de kjører i en isolert sandkasse uten tilgang til “selve kassesiden (HTML eller andre ressurser)” (egen oversettelse). Web-piksler tar seg av sporing. Merkevareinnstillinger og Checkout Branding API tar seg av utseendet. Functions tar seg av logikken.

Planskillet går midt gjennom kassen. Shopifys side om tilpasning av kassen sier at “avanserte funksjoner for tilpasning av kassen er bare tilgjengelige på Shopify Plus-planen” (egen oversettelse), og nevner apper som tilpasser sidene Information, Shipping og Payment samt Checkout Branding API som Plus-funksjoner. Standardtilpasninger er tilgjengelige fra Basic og oppover.

#Hvilke Shopify-funksjoner krever Shopify Plus

Ut fra sidene som er sitert ovenfor, er dette Plus-funksjonene som oftest avgjør et prosjekt:

• Egendefinerte apper som inneholder Shopify Functions (offentlige apper fra App Store med Functions fungerer på alle planer)
• Checkout UI extensions på trinnene Information, Shipping og Payment
• Checkout Branding API
• Cart Transform-operasjonen lineUpdate, som brukes til å overstyre pris, tittel eller bilde på en handlekurvlinje
• Betalingsvilkår satt av en funksjon for tilpasning av betaling, og skjuling av bestemte betalingsplasseringer
• Ubegrenset antall B2B-kataloger, direkte katalogtildeling til bedrifter og krav om depositum

Det som ikke står på listen, kan likevel ha en planforskjell. Shopify endrer disse sidene, så sjekk selve siden den dagen du avgrenser prosjektet, ikke et blogginnlegg fra i fjor, og det gjelder også dette.

#Tillater Shopify i det hele tatt endringen du vil gjøre

Det første svaret i samme tråd la til trinnet de fleste beslutningslister hopper over:

sjekk først om Shopify faktisk tillater endringen du prøver å gjøre. å endre hvordan en produktside ser ut er for eksempel noe helt annet enn å håndheve en kjøpsregel i kassen. det første krever kanskje bare en temaendring, mens det andre kan kreve Shopify Functions eller en kompatibel app.

(u/kunalkhatri12, r/shopify, 23. oktober 2026, egen oversettelse)

Noen forespørsler stopper på plattformens regler før budsjettet i det hele tatt kommer på bordet. Shopify dokumenterer flere av dem:

• Ingen vilkårlig kode i kassen. Checkout UI extensions “er begrenset til bestemte UI-komponenter og API-er som plattformen eksponerer” (egen oversettelse) og kjører i en Web Worker uten tilgang til DOM. Et design som krever et eget skript injisert i betalingstrinnet, lar seg ikke bygge.
• Sortering av levering har et gulv. Delivery Customization-API-et sier at “det billigste fraktalternativet alltid må være det første valgte alternativet” (egen oversettelse).
• Abonnementer blokkerer noe logikk. Cart Transform avviser operasjonene expand, merge og update når handlekurven har en salgsplan, og tilpasning av betaling kan ikke sette betalingsvilkår når handlekurven inneholder abonnementsvarer.
• Nettverkskall fra Functions er begrenset. For rabattfunksjoner er fetch-målet begrenset til egendefinerte apper i Plus- og Enterprise-butikker; for valideringsfunksjoner til egendefinerte apper i Enterprise-butikker.

Ti minutter med lesing av riktig side på shopify.dev før et tilbud forhindrer en kjent feil: en funksjon som er spesifisert, designet og halvveis bygd, før den droppes fordi plattformen aldri tillot den. Når svaret er nei på Shopify, er de ærlige alternativene en annen flyt, et eksternt trinn før kassen, eller en plattform der du eier koden til kassen. Å eie koden har en pris som utviklere ofte undervurderer. I en tråd 18. oktober spurte en erfaren utvikler om han skulle bygge kundebutikker på Shopify eller med egen hosting, og sa at han på Shopify “føler at jeg jobber inne i en boks” (egen oversettelse). Ett svar kom fra en som har ledet mange skreddersydde prosjekter:

i løpet av karrieren har jeg hatt ansvar for massevis av headless- og skreddersydde prosjekter. svært få av dem burde vært gjort på den måten, og i 2026 gjelder det enda mer. det er eksepsjonelle krav som gjør kompleksitet nødvendig.

(u/pjmg2020, r/shopify, 19. oktober 2026, egen oversettelse)

Hvis kravet ditt virkelig er eksepsjonelt, for eksempel kasselogikk Shopify ikke tillater, forklarer vår guide til migrering fra Shopify til WooCommerce hva flyttingen innebærer.

#Temaendring, app, Function eller Plus: beslutningstabell

#Hvordan skrive en god brief til en Shopify-utvikler

Skriv forespørselen som et resultat: “grossistkunder i Tyskland ser nettopriser og må bestille i kartonger med seks” er en brief, mens “legg til et skript i handlekurven” er en gjetning på løsningen. Ta med planen din, appene som allerede er installert, og om du bruker abonnementer eller B2B. Ett svar i beslutningstråden la til en vane som er verdt å kopiere:

før du binder deg, skriv den nøyaktige regelen med vanlige ord sammen med noen testtilfeller.

(u/Muted_Jellyfish_6784, r/shopify, 23. oktober 2026, egen oversettelse)

Be om at tilbudet skiller utviklingen fra løpende vedlikehold. Temakode, Functions og kasseutvidelser trenger alle noen som oppdaterer dem når Shopify bytter API-versjon.

Hvis svaret er temaarbeid, kan en Shopify-utvikler som regel avgrense jobben ut fra listen over maler. Hvis arbeidet berører kassen, prising eller kjøp gjort av agenter, endrer det også hvordan AI-verktøy for netthandel kan lese og kjøpe fra butikken din, og det er det tjenesten vår for AI-handel sjekker. Guiden til Universal Commerce Protocol forklarer hvordan AI-agenter endrer måten folk handler på nett.