Shopify Scripts stoppede med at virke den 30. juni 2026. Her er, hvad du skal gøre nu.
Hvis din butik havde en tilpasset rabat-, BOGO- eller bundle-Script, stoppede den stille med at køre den 30. juni 2026. Ingen fejl, ingen advarsel, intet i dine logs. Her er præcis, hvad der skete, hvad en migrering til Shopify Functions egentlig indebærer, og et ærligt svar på, hvad Stackable kan genopbygge for dig.
- Shopify Scripts stoppede med at køre den 30. juni 2026 for alle butikker, der stadig brugte dem.
- Enhver tilpasset rabat-, BOGO- eller bundle-logik, der lå i en Script, holdt op med at blive anvendt på den dato.
- Fejlen er stille af design: en Shopify Function, hvis betingelser ikke matcher en given kurv, udløses simpelthen aldrig. Den kaster ikke en fejl, og Shopify giver dig ikke besked.
Forhandlere, der arbejder sig igennem denne migrering, beskriver den samme fare på Shopifys community-forummer:
“Min gamle Script holdt stille op med at give rabat, og jeg opdagede det først, fordi en kunde klagede over at være blevet opkrævet fuld pris. Der var ingen fejl, ingen advarsel, intet i ordrelogget. Jeg havde kørt med en defekt opsætning i ugevis, før jeg opdagede det.”
Det er kernerisikoen ved at skifte fra Scripts til Functions: en Function er enten velformet og kører, eller også er den fejlkonfigureret og stille. Der findes ingen synlig mellemtilstand, så en betingelse, der ikke matcher, en tastefejl i en tærskelværdi eller en regel, der er afgrænset til den forkerte collection, giver præcis den samme stilhed som en Function, der fungerer korrekt. Den eneste måde at opdage det på er bevidst at teste begge retninger, før du stoler på den i drift.
Fire ting værd at vide, før du starter
Én Script bliver ofte til tre migreringer
En enkelt Script-fil kunne berøre rabatlogik, fragtpriser og betalingstilpasning på samme tid. Functions opdeler det i separate Function-typer, rabat, levering og betaling, som hver især konfigureres og udrulles uafhængigt. At migrere "min Script" betyder som regel at migrere op til tre forskellige ting, og det er den klage, forhandlere oftest rejser om skiftet.
No-code-byggere dækker som regel kun rabatter og BOGO
Hvis din Script også berørte fragtpriser eller betalingsmetoder, når en no-code discount-Function-bygger, Stackable inklusive, ikke ud til dem. Tilpasninger af levering og betaling kræver, at en udvikler skriver den Function direkte.
Gem din gamle Script-kildekode nu
Når Script Editor er fuldt udfaset, bliver den gemte kode umulig at gendanne. Eksportér eller kopiér din gamle Script-kildekode i dag, også selvom du endnu ikke er klar til at migrere, så du har en reference til det, der erstatter den.
Test en kurv, der bør udløse, og en kurv, der ikke bør udløse
Før du stoler på en ny Function, skal du opbygge to testkurve: én, der bør udløse den, og én, der bevidst ikke bør. En Function, der udløses, når den ikke bør, er lige så bekostelig som en, der stille aldrig udløses.
De tre ting, der forklarer enhver migreringsbeslutning
Næsten enhver diskussion om, hvad der kan og ikke kan genopbygges, kommer ned til tre kendsgerninger: Scripts fandtes i tre typer med én plads hver, Functions opdeler de tre typer på tværs af fire forskellige API'er, og en Function skal erklære hvert eneste stykke data, den nogensinde vil læse, før den kører. Når du har de tre ting på plads, er resten af denne side regnestykker.
Shopify Scripts fandtes i tre typer
Script Editor bad dig vælge en type, før du skrev en linje Ruby, og typen afgjorde, hvad din kode måtte røre ved.
Varelinje-scripts
Dem, der ændrede, hvad produkter kostede. De gennemgik kurven linje for linje og omprisede den, og det er her, alle trinvise rabatter, BOGO, pakke-priser og nedsættelser lå.
Fragt-scripts
Dem, der arbejdede med leveringspriser. De kunne give rabat på en pris, skjule den, omdøbe den eller ændre rækkefølgen på den liste, kunden så. Kun den første af de fire er en rabat.
Betalings-scripts
Dem, der arbejdede med betalingsmetoder, med de samme fire handlinger: skjule en metode, omdøbe den, ændre rækkefølgen på listen, eller i praksis mest skjule den for bestemte kurve.
Så er der begrænsningen, der formede enhver ægte Script, du nogensinde vil læse: kun én Script af hver type kunne udgives ad gangen. Én varelinje-plads for hele butikken. Så en forhandler, der kørte en VIP-rabat, en udsalgspris, en forbrugstærskel og en sæsonkampagne, skrev ikke fire Scripts. De skrev én fil med alle fire flettet sammen, som regel med en hjemmelavet "behold den, der giver den bedste pris"-regel i bunden. Det er derfor, ægte Scripts ser rodede ud. De er ikke én regel skrevet dårligt, de er flere regler, der aldrig fik lov til at være adskilte.
Se en ægte Script med fire kampagner flettet ind i én filFire Function-API'er erstattede dem
Shopify erstattede ikke Scripts med én ting. De erstattede dem med fire, opdelt efter, hvad koden må ændre, frem for hvor i kurven den kører.
Discount Function API
Penge af prisen. Produktrabatter, ordrerabatter og fragtrabatter ligger nu alle her, i ét samlet API. Hvis din Script ændrede en pris, er det her, den hører til.
Shopifys dokumentationDelivery Customization API
Skjule, omdøbe og ændre rækkefølgen på leveringsmuligheder. Shopify er tydelig omkring, at dette er det eneste API, der kan tilpasse leveringsmuligheder ved kassen, så en rabat-app kan ikke nå det, uanset hvordan den er bygget.
Shopifys dokumentationPayment Customization API
Skjule, omdøbe og ændre rækkefølgen på betalingsmetoder, samt betalingsbetingelser og om en ordre kræver gennemgang. Betalingshalvdelen af den gamle Script Editor, samlet ét sted.
Shopifys dokumentationCart and Checkout Validation API
Blokere kassen med en besked. Købsgrænser, alderstjek og regler for minimumsordrer hører til her. Det returnerer fejl, så det kan stoppe en ordre, men det kan ikke stille ændre en.
Shopifys dokumentationStackable er en Discount Function-app, og kun det. Vi bygger discount-functions, så vi kan genopbygge alt, hvad din Script gjorde ved en pris, herunder fragtrabatter. Vi leverer ikke en delivery customization, en payment customization eller en validation function, så at skjule en fragtpris, omdøbe en betalingsmetode eller sætte et loft over en købsmængde er ikke noget, vi afviser, fordi vi ikke har bygget det. Det er en anden slags app.
Sæt de to halvdele sammen, og du får den sætning, forhandlere lærer på den hårde måde: én Script bliver ofte til tre migreringer. En varelinje-Script, der også skjulte en fragtpris og blokerede en betalingsmetode, er nu en discount function, en delivery customization og en payment customization, skrevet og udrullet hver for sig. Vi vil hellere have, at du læser det her, end at du opdager det efter genopbygningen.
Se en fragt-Script, der viser sig slet ikke at være en rabatFunctions er rene, og hvert felt erklæres på forhånd
En Script kørte som almindelig Ruby mod, hvad kurven end indeholdt. En Function kører i en sandkasse, og Shopify garanterer, at den ikke har noget af følgende:
- Intet netværk. En Function kan ikke kalde dit ERP-system, din loyalitetsudbyder eller nogen anden service, mens en kunde er ved at gå til kassen.
- Intet ur. En Function kan ikke spørge, hvad klokken er, så "halv pris om tirsdagen" må blive en planlagt rabat i stedet for en betingelse inde i koden.
- Ingen tilfældighed. Intet kan slå plat eller krone for én ud af ti kunder.
- Intet filsystem, og ingen adgang til et felt, den ikke har bedt om. Hvert stykke data, en Function læser, skal navngives på forhånd i en input-forespørgsel, og den forespørgsel har et fast omkostningsloft sat af Shopify.
Den sidste regel er den, der koster forhandlere mest, og det er værd at være præcis om, hvem den koster. Det er ikke, fordi Shopify skjuler dataene. Vores egen checkout-forespørgsel ligger på det maksimale omkostningsniveau, Shopify tillader, så at bede om ét felt mere betyder at give afkald på et andet. Ni ud af de Script-former, vi afviser i dag, afvises af præcis den grund og ingen anden, herunder at springe allerede nedsatte varer over, at læse en region eller et postnummer, og at tjekke hvor mange ordrer en kunde har afgivet. Shopify tilbyder hver eneste af dem. Vi har bare ikke skabt plads til dem endnu. Det er vores egen begrænsning, og at kalde det en platformbegrænsning ville være en løgn.
Kun to afvisninger i hele biblioteket er reelle Shopify-begrænsninger, og begge stammer fra samme kendsgerning: hver discount function på en butik kører på samme tidspunkt, og ingen af dem kan se, hvad de andre har gjort. Så en Script, der spurgte "er denne vare allerede blevet nedsat?" eller målte en tærskel mod en allerede reduceret subtotal, kan ikke genopbygges af os eller nogen andre, i dag, for nogen pris. Alt andet på vores afvisningsliste er vores eget at rette, og vi markerer det sådan i appen og på hver side i biblioteket.
Læs de to afvisninger, der reelt er Shopify-begrænsningerAt sætte en pris er ikke det samme som at give rabat
Hvis du kun læser én ting, før du genopbygger en Script i hånden, så læs denne. To filer kan kalde den samme metode, med den samme konstant og den samme besked, og betyde det stik modsatte. Begge de følgende er ægte, begge er almindelige, og forskellen mellem dem er et minustegn.
Denne SÆTTER prisen til $9.99
FIXED_PRICE = Money.new(cents: 999)
Input.cart.line_items.each do |line_item|
next unless line_item.variant.product.product_type == "Clearance"
line_item.change_line_price(FIXED_PRICE * line_item.quantity, message: "Clearance $9.99 each")
end
Output.cart = Input.cartPå en vare til $79.00 er rabatten $69.01, og kunden betaler $9.99. Genopbygget som et volumentilbud, hvis belønning er en fast pris, talt pr. variant og gentagende, så hver enhed omprises.
Det gennemregnede eksempel, med kurven og indstillingerneDenne trækker $9.99 FRA
DISCOUNT = Money.new(cents: 999)
Input.cart.line_items.each do |line_item|
next unless line_item.variant.product.product_type == "Clearance"
new_price = line_item.line_price - (DISCOUNT * line_item.quantity)
line_item.change_line_price(new_price, message: "$9.99 off each")
end
Output.cart = Input.cartPå den samme vare til $79.00 er rabatten $9.99, og kunden betaler $69.01. Genopbygget som et volumentilbud, hvis belønning er et beløb i rabat pr. enhed, talt pr. produkt og udløses én gang.
Det gennemregnede eksempel, med kurven og indstillingerneSamme metode, samme $9.99, samme ordlyd i beskeden. Det eneste tegn er, at den anden fil trækker fra `line_item.line_price`, før den tildeler. Læs den forkert på en vare til $79.00, og du er $59.02 ved siden af på en enkelt enhed, i hvilken retning det end gør ondt. Og de to genopbygninger adskiller sig ikke kun i tallet: den ene tæller pr. variant og gentager, den anden tæller pr. produkt og udløses én gang, så de afviger også, så snart kunden køber to.
Det er den fejl, som den sædvanlige anbefaling ikke kan opdage. Et genopbygget tilbud, der læser filen bagvendt, udløses stadig på en kurv, der bør udløse det, og forbliver stille på en kurv, der ikke bør, så at teste begge retninger lader det passere. Scripts Rescue lukker det hul ved at stille et andet spørgsmål: før det lader dig udgive, vil det have det beløb, din gamle Script opkrævede for en kurv, du stadig kan genskabe, og det sammenligner det med, hvad det genopbyggede tilbud beregner. Én cent ved siden af, og udgivelse forbliver lukket. Blandt de fem apps, der i dag sælger Scripts-migrering, fandt vores research ingen, der beder en forhandler om at bevise pengene overhovedet.
Hvad hvert stykke Ruby bliver til i en kampagne
En genopbygning går galt de samme få steder hver gang, og det er næsten aldrig de oplagte. Belønningen er som regel let. Optælling og gentagelse er dér, hvor pengene stille flytter sig, fordi en Script udtrykker dem i regnestykker, og en kampagne udtrykker dem i en indstilling.
| I din Script | I en kampagne | Hvor det går galt |
|---|---|---|
change_line_price(PRICE * qty) | Et volumentilbud med en belønning i form af fast pris. | Tildeling, ikke subtraktion. Det er fælden ovenfor. Enhedsprisen bliver til konstanten, så en vare til $79 sælges for $9.99. |
line_price - (AMOUNT * qty) | Et volumentilbud med en belønning i form af beløb i rabat pr. enhed. | Subtraktionen er hele signalet. Samme konstant som rækken ovenfor, en helt anden regning. |
line_price * 0.9 | En procentbelønning på 10. | Multiplikatoren er, hvad kunden beholder, ikke hvad de sparer. Tastet direkte ind som 90 giver den ni tiendedele af kataloget væk. |
next unless line_item.quantity >= 3 | Et niveau med et minimumsantal på 3. | Niveauer er inklusive ved grænsen, og kun det højeste opfyldte niveau udløses. Scripts, der lagde én regel oven på en anden, har ingen tilsvarende i ét enkelt tilbud og kræver ét tilbud hver. |
line_items.size > 1 | Et minimumsantal på 2. | Ikke den samme regel. Scripts talte separate kurvlinjer her, kampagner tæller enheder, så én linje med to af den samme vare nu kvalificerer, hvor Scriptet ignorerede den. |
sets = quantity / (BUY + GET) | Køb X, få Y, hvor de gratis enheder tælles som ekstra. | At dividere med kun KØB gør i stedet de gratis enheder inklusive. På ni enheder af et køb 3, få 1 er det to gratis eller tre gratis. Ét tegn fra hinanden, og der foræres halvanden gange så meget væk. |
customer.tags.include?("vip") | Kundeberettigelse afgrænset til tags. | Shopify matcher tags præcist, store bogstaver inklusive, mens mange Script-dialekter først lavede begge sider om til små bogstaver. Tjek stavningen, før du udgiver, ikke bagefter. |
product.tags / product_type / vendor | Målgruppe sat til tags, produkttyper eller leverandører. | En manglende afgrænsningslinje er den dyreste fejl i denne tabel, fordi den gør "20% rabat på sale-tagget" til 20% rabat på alt, du sælger. |
Én ting, du ikke finder i denne tabel, er kollektioner. En Script kunne læse en vares tags, type og leverandør, men aldrig dens kollektioner, så al Ruby, der hævdede at tjekke en kollektion, gjorde ikke det, det så ud til. Kampagner kan målrette kollektioner; det kunne din gamle Script ikke.
Slå din Script op i stedet for at ræsonnere dig frem til den
Hver Script-form, vi har katalogiseret, har sin egen side: den oprindelige Ruby, hvad den genkendes som, den præcise konfiguration, den bliver til, en kurv fra vores offentlige demo-butik med den rabat, den rigtige motor beregner for den, og kurven, der skal forblive stille. Afvisningerne er skrevet ud på samme måde, hver enkelt mærket som en Shopify-begrænsning, vores egen begrænsning, eller en opgave for en anden slags app. Det er den reference, vi selv ønskede os, da vi startede, så den er offentlig.
- Script-typer
- 42
- Genopbygget i dag
- 38
- Afvist, med årsag
- 21
Et ærligt svar om omfang
Stackable genopbygger regelbaseret rabatlogik på native Shopify Functions. Det kører ikke vilkårlig brugerdefineret kode.
Stackable genopbygger dette
- Trin- / mængderabatter (fx "køb 3+, spar 15%")
- Buy X Get Y og BOGO-logik, herunder gentagne trin
- Eksplicitte regler for stabling af rabatter mellem tilbud
- Planlagt start, slut og øjeblikkelig pause på enhver kampagne
Du får stadig brug for en udvikler til dette
- Vilkårlig tilpasset kode, som din gamle Script kørte (skræddersyede prisformler, engangsbetingelser, som ingen bygger dækker)
- Forsendelses- / leveringstilpasninger (en separat Function-type)
- Betalingstilpasninger (en separat Function-type)
- Alt, der ikke kan reduceres til en regelbaseret rabatkonfiguration
Hvis dit gamle Script gjorde noget på denne liste, kan en kodefri bygger, Stackable inklusive, ikke nå det. Det er en udviklerskrevet Function, ikke en konfigurationsskærm.
Almindelige spørgsmål
Er mine gamle Scripts væk?
Scripts stoppede med at køre den 30. juni 2026, men det er ikke nødvendigvis det samme tidspunkt, som Script Editors gemte kildekode bliver slettet. Eksportér eller kopiér din gamle Script-kode nu alligevel: når Shopify fuldt ud udfaser editoren, bliver den umulig at gendanne.
Får jeg en fejl, hvis en Function er fejlkonfigureret?
Nej. En Function, hvis betingelser ikke matcher en kurv, udløses simpelthen aldrig, stille, uden fejl og uden advarsel. Test altid med en kurv, der bør udløse den, og en, der ikke bør, før du stoler på den i produktion.
Erstatter Stackable alt det, min gamle Script gjorde?
Kun den regelbaserede del: trin- og mængderabatter, BOGO, stabling af rabatter og planlægning, alt sammen genopbygget på native Shopify Functions. Stackable kører ikke vilkårlig tilpasset kode. Hvis din Script gjorde noget reelt skræddersyet, en tilpasset prisformel eller en betingelse, som ingen bygger dækker, kræver det stadig, at en udvikler skriver den Function direkte.
Hvad med forsendelses- eller betalingslogikken, som min Script håndterede?
Det er separate Function-typer (levering og betaling), som Stackable ikke rører. En udvikler skal migrere dem uafhængigt af din rabatlogik.
Hvilken plan er Scripts Rescue på?
Scripts Rescue, værktøjet der læser din gamle Ruby-kode og genopbygger den, er på Pro-planen. Stackable selv er gratis at installere, og den centrale rabatmotor, herunder volumenniveauer, Køb X, få Y, kurvmål, gratis fragt, planlægning og simulatoren, er gratis på alle planer. Ruby-redningen er specifikt ikke det: den ligger sammen med flere butikker og Shopify Flow på Pro.
Hvordan ved jeg, at den genopbyggede rabat opkræver det samme som den gamle?
Fordi du bliver bedt om at bevise det, før du kan udgive. At teste en kurv, der bør udløse, og en, der ikke bør, er standardrådet, og det opfanger ikke den værste fejl, som er et tilbud, der udløses korrekt for det forkerte beløb. Scripts Rescue beder dig om det beløb, din gamle Script opkrævede på en kurv, du stadig kan genskabe, sammenligner det med, hvad det genopbyggede tilbud beregner, og holder udgivelse lukket, indtil de to matcher til øren. Vores research på tværs af de fem apps, der sælger Scripts-migrering, fandt ingen, der beder om det.
Hvorfor så min Script så kompliceret ud?
Fordi kun én Script af hver type kunne udgives ad gangen. En butik, der kørte fire kampagner, kunne ikke skrive fire Scripts, så den skrev én fil med alle fire flettet sammen og en regel i bunden, der afgjorde, hvilken der vandt. Det meste Ruby, der ser ulæseligt ud, er i virkeligheden flere simple regler, der deler en plads, og hver af dem genopbygges som regel rent for sig selv.
Hvor kan jeg læse hele migreringsgennemgangen?
Vores første blogindlæg gennemgår udfasningen af Scripts og migreringsvejen mere detaljeret, og Script-eksempelbiblioteket har en side pr. Script-form med den oprindelige Ruby og den præcise genopbygning.
Relaterede funktioner
Discount Stacking
How to stack discounts in Shopify comes down to settings the platform hides by default: every discount belongs to a class (product, order, or shipping), and whether two discounts combine is decided per offer, per class. Stackable puts those combine switches on every offer, so a volume tier, a spend goal, and free shipping add up exactly the way you configured them, every time.
BOGO / Buy X Get Y
Running BOGO beyond the 100-product cap isn't possible with Shopify's native Buy X Get Y discount: it stops letting you add eligible products once you pass 100, and it only applies once per order. Stackable removes both limits and adds cheapest-item-free logic on top.
Scheduled Sales
Shopify scheduled sales fail two ways in the wild: campaigns that silently never start, and live campaigns with no pause button. Stackable's scheduler runs on the same reliability guarantee as its checkout math, and pausing takes effect storefront-wide in under a minute.
Installer Stackable og genopbyg dine regelbaserede rabatter
Volumentrin, BOGO, stabling og planlægning, der kører på native Shopify Functions fra dag ét.
Scripts Rescue er på Pro-planen. Stackable selv er gratis at installere, uden krav om betalingskort.