Shopify Scripts stopper med at køre den 30. juni 2026, og hver brugerdefineret rabat-, forsendelse- eller betalingsregel, du opbyggede i Script-editoren, stopper med at blive brugt på den dato. Erstatningen er Shopify Functions, som kører din logik server-side inden for checkout. Du har tre veje dertil: hyrer en udvikler til at skrive Functions, betaler et bureau for at gøre det, eller genopbygger regelbaseret rabatlogik i en no-code Functions-app. Det vigtige er, at fejlen er stille. En Script, der stopper med at køre, eller en migreret regel, der ikke matcher en indkøbskurv, kaster ingen fejl og giver dig ingen besked. Det opkræver bare hele prisen uden at sige noget, indtil en kunde klager.
Denne vejledning forklarer, hvad Scripts gjorde, hvorfor Shopify pensionerer dem, hvad Functions egentlig er, hvorfor "migrering af min Script" egentlig er op til tre separate migreringer, den stille-fejl-fælde og præcis hvordan man tester omkring det, hvad en no-code-app kan og ikke kan dække, og en ærlig fordeling af hvornår du stadig har brug for en udvikler.
Hvad sker der med Shopify Scripts, og hvornår?
Shopify Scripts bliver pensioneret. Ifølge Shopifys udvikler-dokumentation ville "Shopify Scripts blive pensioneret den 30. juni 2026. Alle eksisterende Shopify Scripts vil stoppe med at fungere efter denne dato." Der er to datoer, der betyder noget, og den første er allerede passeret:
- 15. april 2026: redigering og udgivelse af nye Shopify Scripts er ikke længere mulig. Ifølge Shopify-udvikler changelog kan du efter denne dato ikke oprette eller ændre en Script overhovedet.
- 30. juni 2026: alle Shopify Scripts holder helt op med at køre. Uanset hvilken rabat-, forsendelse- eller betalingslogik, der lever i en Script, stopper blot med at køre.
Hvis din butik stadig var afhængig af en Script den 1. juli 2026, er den logik allerede offline, mens du læser dette. Tilpasningerne fejlede ikke eller blev rullet tilbage til en sikker standard. De blev tavse. Det er den vigtigste ting at forstå om denne deadline: det er ikke en høj fejl, som du vil bemærke fra en dashboard-besked. Det er en fravær.
Shopify leverer også et værktøj til at hjælpe dig med at begrænse arbejdet. Shopify Scripts tilpasninger-rapporten hjælper dig med at identificere, hvilke af dine nuværende tilpasninger, der kan overføres til Functions eller offentlige apps. Hvis du ikke har kørt den, er det trin et.
BILLEDE PLACEHOLDER (Billede 1): The Scripts sunset timeline
Foreslået visuel: En ren 16:9 vandret tidslinje på en hvid baggrund med tre milestone-markører i violet og dyb guld. Markør et, "15. april 2026 - redigering slutter" i guld. Markør to, "30. juni 2026 - Scripts stopper med at køre" i violet med et lille rødt "stille" tag. En efterfølgende pil mærket "Shopify Functions" fortsætter forbi sidste markør. Flad, minimal, sans-serif-labels, ingen fotografi.
Hvad gjorde Shopify Scripts, og hvorfor pensionerer Shopify dem?
Shopify Scripts var små Ruby-programmer, der blev kørt i Script Editor-appen og tilpassede tre dele af købsstien: indkøbskurv- og linie-rabatter, forsendelsestakster og betalingsmetoder. En forretning på Shopify Plus kunne skrive en Script, der gav en trin-rabat, skjulte en forsendelsesmulighed for bestemte adresser, eller omordnede betalingsmetoder ved checkout. Scripts var kraftfulde, præcist fordi de var vilkårlig kode: hvis du kunne udtrykke det i Ruby, kunne du gøre det.
Shopify erstatter dem med Shopify Functions. Ifølge migrerings-dokumentationen "Med Shopify Functions håndteres disse tilpasninger nu gennem dedikerede Function API'er, der tilbyder bedre ydeevne og fleksibilitet." Functions kører på Shopifys egen infrastruktur inden for checkout-pipelinen, hvilket gør dem hurtigere og mere skalerbare end den ældre Scripts-model, og det betyder, at samme logik gælder uanset om en køber tjekker ud på kurv-siden, checkout-siden eller en accelereret pung som Shop Pay.
Kompromisset er, at Functions ikke er en tekstboks, du indsætter Ruby i. De er udvikler-artefakter: du stillader dem med Shopify CLI, skriver logikken i Rust eller JavaScript, definerer en GraphQL-input-forespørgsel og implementerer dem gennem en app. Det skift, fra "forretning skriver en Script" til "udvikler sender en Function," er hele grunden til, at denne migrering er et projekt og ikke en afkrydsning.
Hvad er Shopify Functions, og hvorfor har de normalt brug for en udvikler?
Shopify Functions lader dig udvide eller erstatte dele af Shopifys backend-logik med brugerdefineret kode, der køres under checkout. Der er dedikerede Function API'er for de ting, Scripts plejede at gøre, herunder en Discount Function API, en Delivery (forsendelse) Customization API og en Payment Customization API.
To egenskaber ved Functions betyder for din migrerings-plan.
Functions køres server-side, én gang
En Function kører inden for Shopifys checkout, ikke i dit tema. Det er en ægte opgradering over rabat-metoder, der beregner en total i tema-JavaScript på kurv-siden og ueniges derefter med det, som checkout opkræver. Fordi Function er den enkelte sandhedskilde, er kurv-forhåndsvisningen og det endelige gebyr den samme beregning. Dette er også hvorfor en korrekt bygget Function gælder identisk på tværs af Shop Pay, Apple Pay og Google Pay, som springer kurv-siden helt over.
Functions er bygget, ikke konfigureret, som standard
At skrive en Function fra bunden er en udvikler-opgave. Du har brug for Shopify CLI, en sprog-værktøjskæde og kendskab til Function-input-forespørgslen og resultat-formen. Der er en nuance værd at kende på plan-tilgængelighed: ifølge Shopifys Functions tilgængelings-dokumentation "Butikker på alle planer kan bruge offentlige apps, der distribueres gennem Shopify App Store og indeholder functions. Kun butikker på en Shopify Plus-plan kan bruge brugerdefinerede apps, der indeholder Shopify Function API'er." Med klare ord: en offentlig app fra App Store kan bringe Functions til enhver plan, men en tilpasset, brugerdefineret Function er en kun-Plus-vej. Den skelnen er det, der gør en no-code Functions-app attraktiv for ikke-Plus-handlende, som plejede at stole på en udvikler.
Det gode nyt er, at når en Function er implementeret inden for en app, konfigurerer forretningen den fra adminen uden at røre kode. Som Shopify sagde da Functions blev lanceret, "sluttegenskaber skal aldrig røre en kode-linje, når de ændrer deres tilpasninger." Koden skrives én gang; indstillingerne lever i admin.
Hvorfor er "migrering af min Script" egentlig tre separate migreringer?
Her er detaljerne, der overrasker mennesker, og det kommer direkte fra, hvordan handlende beskriver arbejdet på Shopify-samfundsfora. En enkelt Script-fil kunne røre rabat-, forsendelse- og betalingslogik på én gang. Functions deler bevidst det op i separate, uafhængige Function-typer.
- Rabatlogik (trindelt priser, BOGO, ordre- og produktrabatter, stabling-regler) kortlægges til Discount Function API. Shopifys samlet Discount Function API kan anvende besparelser på tværs af alle tre rabat-klasser, produkt, ordre og forsendelse, fra en enkelt function.
- Forsendelse- og leveringslogik (omdøbning, omordning eller skjuling af leveringsmuligheder) kortlægges til Delivery Customization Function API, en fuldstændig separat function.
- Betalingslogik (omdøbning, omordning eller skjuling af betalingsmetoder) kortlægges til Payment Customization Function API, en tredje separat function.
Så sætningen "Jeg har brug for at migrere min Script" betyder ofte migrering af op til tre forskellige ting, konfigureret og implementeret uafhængigt. En no-code rabat-app kan genopbygge den første gruppe. Den når ikke forsendelse- og betalings-grupperne, hvilket er præcis hvorfor du skal inventarisere din gamle Script før du antager, at noget enkelt værktøj dækker det. Opdel arbejdet efter flade først, derefter vælg en vej for hver flade.
BILLEDE PLACEHOLDER (Billede 2): One Script becomes three Functions
Foreslået visuel: En 16:9 diagram. Til venstre en enkelt mærket boks "One Shopify Script (Ruby)" i skifergrå. Tre pile fanen ud til højre for tre separate bokse: "Discount Function" i violet, "Delivery Function" i guld, "Payment Function" i skiferblå, hver med et lille "implementeret uafhængigt" billedtekst. Ren fladt vektor, brand-farver violet og guld, ingen fotografi.
Den stille-fejl-fare, og hvordan man tester for den
Det er den del, der koster handlende rigtige penge, og det fortjener sit eget afsnit, fordi det gælder både for deadline selv og for enhver regel, du genopbygger.
En Shopify Function er enten velformet og kører, eller den er misConfigureret og stille. Der er ingen synlig mellemtilstand. En Function, hvis betingelser ikke matcher en given indkøbskurv, kører ikke, fejler ikke og advarer dig ikke. Det er efter design: den samme stilhed, du får fra en Function, der fungerer korrekt (den gjorde korrekt intet for en indkøbskurv, der ikke skulle kvalificere sig), er stilheden, du får fra en Function, der er brudt (en stavefejl i en tærskel, en regel scoped til den forkerte samling, en tier, der aldrig udløser).
Handlende, der arbejder gennem denne migrering, beskriver den samme erfaring på Shopify-samfundsfora: en regel holder stille op med at anvende en rabat, og forretningen finder kun ud af det, fordi en kunde klager over at blive opkrævet fuld pris. Ingen fejl, ingen advarsel, intet i ordre-logs. Butikken var blevet kørt på en brudt opsætning i uger, før nogen bemærkede det.
Det eneste pålidelige forsvar er at teste begge retninger, før du stoler på en regel direkte:
- Byg en skal-køre-indkøbskurv. Saml en rigtig indkøbskurv, der opfylder alle betingelser i reglen, planlæg en kladde- eller test-ordre og læs checkout-sammenfattelsen linje for linje. Bekræft, at den nøjagtige rabat, du forventer, er til stede, på det beløb, du forventer.
- Byg en skal-ikke-køre-indkøbskurv. Saml en indkøbskurv, der bevidst ikke kvalificerer sig, for eksempel ét element under din mængdetærskel, og bekræft, at rabatten korrekt holder sig af.
En Function, der kører, når den ikke burde, er lige så dyr som en, der stille aldrig kører. Du er ikke færdig med test, før du har set reglen både blive brugt og korrekt afslået. Kør skal-køre-indkøbskurven gennem Shop Pay også, så du bekræfter, at den accelererede vej er enig med standard checkout.
Et mere bevarings-trin, mens du er her: hold din gamle Script-kilde nu. Når Script-editoren er fuldt ud pensioneret, bliver dens lagrede kode ugenvendelig fra Shopify. Eksportér eller kopier din Script-kilde i dag, selvom du ikke er klar til at genopbygge den endnu, så du har en reference for, hvad der erstatter den.
Kan en no-code app migrere mine Scripts? Hvad den dækker og hvad den ikke gør
For rabat-fladen specifikt kan en no-code Functions-app absorbere en stor andel af det, handlende brugte Scripts til. Hvis din Script-logik reduceres til regler, det vil sige "når indkøbskurven ser ud som X, anvend rabat Y", en configuration-driven app kan normalt genopbygge det uden en udvikler. Det dækker meget almindeligt område:
- Trindelte og mængderabatter, såsom "køb 3 eller flere, spar 15 procent."
- Buy X Get Y og BOGO-logik, inklusive gentagne tiers som "køb 6 få 2, køb 9 få 3."
- Eksplicit stabling og kombinationsregler mellem tilbud.
- Planlagt start, slutning og øjeblikkelig pause på en kampagne.
Hvad en no-code rabat-app ikke kan gøre er lige så vigtig at sige klart, fordi hvis du antager ellers, er det sådan migreringssfejler stille:
- Vilkårlig brugerdefineret kode. Hvis din Script kørte en tilpasset prissætnings-formel eller en engangs-betingelse, der ikke reduceres til en regel, som nogen bygger udsætter, kan ingen rabat-app udtrykke det. Denne logik har stadig brug for en udvikler til at skrive en brugerdefineret Function.
- Forsendelse- og betalingstilpasninger. Det er separate Function-typer (levering og betaling). En rabat-kun app når dem ikke. En udvikler migrerer dem uafhængigt.
- Noget uden for en regel-baseret rabat-configuration. Hvis det ikke grundlæggende var "betingelser ind, rabat ud," er en configuration-skærm den forkerte form for det.
Den ærlige test er enkel: skriv ned, i én sætning, hvad hver del af din gamle Script gjorde. Hvis sætningen er en regel om rabatter, er en no-code app en stærk kandidat. Hvis det er en formel, en forsendelsesændring, en betalingsændring, eller noget, du ikke kan udtrykke som en regel, budget for en udvikler på den del.
Kør denne migrering pålideligt med Stackable
Hvis din Script's rabatlogik var regel-baseret, tiers, BOGO, stabling og planlægning, Stackable genopbygger præcis den flade på native Shopify Functions uden kode, og det er ærligt omkring sine kanter.
- Det genopbygger regel-baseret rabatlogik, herunder mængde- og trindelt prissætning, BOGO, eksplicit rabat-stabling, og planlagt start, slutning og pause, som configuration, du redigerer i adminen i stedet for Ruby, du vedligeholder.
- Matematikken kører inden for en Shopify Function, så indkøbskurv, checkout og Shop Pay beregner et identisk total. Der er ingen tema-versus-checkout-drift, som er en almindelig fejl-tilstand for ældre rabat-setups.
- En indkøbskurv-simulator lader dig køre både en skal-køre og en skal-ikke-køre indkøbskurv før du går live, så du fanger en stille misConfiguration i et preview i stedet for i en kundebesværing.
- Det er ærligt omkring område. Stackable kører ikke vilkårlig brugerdefineret kode, og det rører ikke forsendelse (levering) eller betalingstilpasninger. Genuint tilpasset logik og de to separate Function-typer har stadig brug for en udvikler.
Installer Stackable gratis og genopbyg din regelbaserede rabatlogik på Shopify Functions, før den stille koster dig et salg, på usestackable.com/pricing. 🚀
Arbejdet eksempel: en migrerings-tjekliste du kan følge i dag
Brug denne rækkefølge for at skrue "min Script brød" i en kontrolleret migrering. Tabellen kortlægger en typisk multipurpose-Script til sine destinationer.
Derefter arbejder du trinene i rækkefølge:
1. Inventarisér den gamle Script før du bygger noget som helst
Åbn Script-editoren, mens du stadig kan, og skriv én sætning pr. adfærd. Kør Shopifys Scripts tilpasnings-rapport for at bekræfte, at intet er skjult. Eksportér Ruby-kildekoden og gem den et sikkert sted, fordi den bliver ugenvendelig, når editoren er pensioneret.
2. Delt inventarisationen efter flade
Sortér hver adfærd i rabat, forsendelse eller betaling. Det fortæller dig øjeblikkeligt, hvilke dele en no-code rabat-app kan tage, og hvilke dele der har brug for en udvikler. Antag ikke, at ét værktøj dækker alle tre.
3. Genopbygge de regel-baserede rabat-dele uden kode
For hver adfærd, der reduceres til "betingelser ind, rabat ud," genskab det i native Shopify rabatter eller en Functions-baseret rabat-app. Indstil kombinationsregler eksplicit, hvis tilbud skal stakeres.
4. Hånd de ikke-regel-dele til en udvikler
Tilpassede formler, leverings-tilpasninger og betalings-tilpasninger går til en udvikler eller bureau til at bygge som deres egne Functions. Giv dem din eksporterede Script-kilde som specifikationen.
5. Test enhver genopbygget regel begge veje
For hver regel, kør en skal-køre indkøbskurv og en skal-ikke-køre indkøbskurv. Læs checkout-sammenfattelsen linje for linje. En regel er ikke migreret, før du har set den både være brugt og korrekt afslået.
6. Bekræft de accelererede checkouts
Kør din skal-køre indkøbskurv gennem Shop Pay. Fordi Functions beregner server-side, gælder en korrekt bygget regel identisk. Det er din sidste kontrol, at intet afhænger af tema-kode, som punge hopper over.
BILLEDE PLACEHOLDER (Billede 3): Test both directions before you trust it
Foreslået visuel: En 16:9 split-illustration. Venstre panel mærket "Skal-køre indkøbskurv" viser en checkout-sammenfattelse med en grøn rabat-linje korrekt til stede. Højre panel mærket "Skal-ikke-køre indkøbskurv" viser en checkout-sammenfattelse med rabatten korrekt fraværende og et grønt flueben. En center-billedtekst læser "En stille regel fejler aldrig - test begge." Brand-farver violet og guld, fladt vektor, ingen fotografi.
Bundlinjen
- Shopify Scripts stopper med at køre den 30. juni 2026, og redigering sluttede allerede den 15. april 2026. Enhver Script, der stadig er i brug, er nu offline.
- Fejlen er stille. En Script, der stoppede, eller en migreret regel, der ikke matcher en indkøbskurv, fejler aldrig og advarer aldrig dig. Det opkræver bare fuld pris.
- Functions er erstatningen, der kører server-side inden for checkout, men at skrive en fra bunden er en udvikler-opgave, og brugerdefinerede Functions er en kun-Plus vej.
- En Script bliver ofte tre migreringer: rabat-, leverings- og betalings-Functions, hver implementeret uafhængigt.
- En no-code Functions-app kan genopbygge regel-baseret rabatlogik (tiers, BOGO, stabling, planlægning). Den kan ikke gøre vilkårlig kode, forsendelse eller betalingstilpasninger.
- Hold din gamle Script-kilde nu. Den bliver ugenvendelig, når Script-editoren er pensioneret.
- Test enhver genopbygget regel med en skal-køre og en skal-ikke-køre indkøbskurv, og læs checkout-sammenfattelsen linje for linje, inklusive gennem Shop Pay.
Relaterede artikler
- Migrering væk fra Shopify Scripts: hele rednings-vejen, hvad der genopbygges uden kode, og hvad der stadig har brug for en udvikler.
- Hvordan rabat-stabling fungerer i Shopify: hvorfor native anvender kun den højeste rabat, og hvordan man korrekt kombinerer tilbud.
- Mængde-rabatter og mængde-brud: genopbygge trindelt prissætning, der tæller det samme produkt, ikke hele samlingen.
- Rabat-stabling, gjort korrekt: de tre pr-klasse-kombinationskontakter, med en live indkøbskurv-simulator.
- Shopifys 100-produkt-grænse på Buy X Get Y: kør 3-for-2 på tværs af et fuldt katalog efter du migrerer.
- Stackable prissætning: planer, det gratis niveau, og hvad hver inkluderer.
