Shopify Scripts slutade fungera den 30 juni 2026. Så här gör du nu.
Om din butik hade ett anpassat Script för rabatt, BOGO eller paket, slutade det köras den 30 juni 2026, tyst. Inget fel, ingen varning, inget i dina loggar. Här är exakt vad som hände, vad migrering till Shopify Functions faktiskt innebär, och ett ärligt svar på vad Stackable kan återskapa åt dig.
- Shopify Scripts slutade köras den 30 juni 2026, för varje butik som fortfarande använde dem.
- All anpassad logik för rabatt, BOGO eller paket som fanns i ett Script slutade tillämpas det datumet.
- Felet är tyst av design: en Shopify Function vars villkor inte matchar en given varukorg utlöses helt enkelt aldrig. Den kastar inget fel, och Shopify meddelar dig inte.
Handlare som arbetar sig igenom den här migreringen beskriver samma fara på Shopifys community-forum:
“Mitt gamla Script slutade tyst tillämpa en rabatt och jag fick bara reda på det för att en kund klagade på att ha debiterats fullt pris. Det fanns inget fel, ingen varning, inget i orderloggarna. Jag hade kört på en trasig uppsättning i veckor innan jag märkte det.”
Det är kärnrisken med att flytta från Scripts till Functions: en Function är antingen välformad och körs, eller den är felkonfigurerad och tyst. Det finns inget synligt mellanläge, så ett felmatchat villkor, ett stavfel i ett tröskelvärde, en regel avgränsad till fel kollektion, ger exakt samma tystnad som en Function som fungerar korrekt. Det enda sättet att upptäcka det är att medvetet testa åt båda hållen innan du litar på den i skarp drift.
Fyra saker värda att veta innan du börjar
Ett Script blir ofta tre migreringar
En enda Script-fil kunde röra rabattlogik, fraktpriser och betalningsanpassning samtidigt. Functions delar upp det i separata Function-typer, rabatt, leverans och betalning, var och en konfigurerad och driftsatt oberoende av varandra. Att migrera "mitt Script" innebär vanligtvis att migrera upp till tre olika saker, och det är den klagan handlare oftast för fram om den här förändringen.
No-code-byggare täcker vanligtvis bara rabatter och BOGO
Om ditt Script också rörde fraktpriser eller betalningsmetoder når en no-code-byggare för rabatt-Functions, Stackable inkluderat, inte dit. Anpassningar för leverans och betalning kräver en utvecklare som skriver den Functionen direkt.
Spara din gamla Script-källkod nu
När Script Editor väl är helt avvecklad blir dess sparade kod oåterkallelig. Exportera eller kopiera din gamla Script-källkod idag, även om du inte är redo att migrera än, så att du har en referens för vad som än ersätter den.
Testa en varukorg som ska utlösa och en som inte ska
Innan du litar på en ny Function, bygg två testvarukorgar: en som ska utlösa den, och en som medvetet inte ska. En Function som utlöses när den inte ska är lika kostsam som en som tyst aldrig utlöses.
De tre sakerna som förklarar varje migreringsbeslut
Nästan varje argument om vad som kan och inte kan återskapas handlar om tre fakta: Scripts fanns i tre typer med en plats var, Functions delar upp de tre typerna över fyra olika API:er, och en Function måste deklarera varje databit den någonsin kommer att läsa innan den körs. När du har dessa är resten av den här sidan bara aritmetik.
Shopify Scripts fanns i tre typer
Script Editor bad dig välja en typ innan du skrev en enda rad Ruby, och typen avgjorde vad din kod fick röra.
Orderradsscript
De som ändrade vad produkter kostade. De gick igenom varukorgen rad för rad och omprissatte den, vilket är där varje nivårabatt, BOGO, paketpris och nedsättning fanns.
Fraktscript
De som arbetade med leveranspriser. De kunde rabattera ett pris, dölja det, döpa om det, eller ändra ordningen på listan kunden såg. Bara den första av dessa fyra är en rabatt.
Betalningsscript
De som arbetade med betalningsmetoder, med samma fyra verb: dölja en metod, döpa om den, ändra ordningen på listan, eller i praktiken oftast dölja den för vissa varukorgar.
Nu till begränsningen som formade varje verkligt Script du någonsin kommer läsa: bara ett Script av varje typ kunde publiceras åt gången. En plats för orderradsscript för hela butiken. Så en handlare som körde en VIP-rabatt, ett reapris, en köpgräns och en säsongskampanj skrev inte fyra Scripts. De skrev en fil med alla fyra sammanslagna, oftast med en handkodad regel längst ner som behöll det pris som var bäst för kunden. Det är därför verkliga Scripts ser hoptrasslade ut. De är inte en regel dåligt skriven, de är flera regler som aldrig fick vara separata.
Se ett verkligt Script med fyra kampanjer sammanslagna i en filFyra Function-API:er ersatte dem
Shopify ersatte inte Scripts med en enda sak. De ersattes med fyra, uppdelade efter vad koden får ändra snarare än var i varukorgen den körs.
Discount Function API
Pengar av. Produktrabatter, orderrabatter och fraktrabatter finns alla här nu, i ett enhetligt API. Om ditt Script ändrade ett pris är det hit det hör.
Shopifys dokumentationDelivery Customization API
Dölja, döpa om och ändra ordning på leveransalternativ. Shopify är tydliga med att det här är det enda API:et som kan anpassa leveransalternativ i kassan, så en rabattapp kan inte nå det oavsett hur den är byggd.
Shopifys dokumentationPayment Customization API
Dölja, döpa om och ändra ordning på betalningsmetoder, plus betalningsvillkor och om en order behöver granskas. Betalningshalvan av det gamla Script Editor, på ett ställe.
Shopifys dokumentationCart and Checkout Validation API
Blockera kassan med ett meddelande. Köpgränser, ålderskontroller och regler för minsta order hamnar här. Det returnerar fel, så det kan stoppa en order men kan inte tyst ändra en.
Shopifys dokumentationStackable är en Discount Function-app, och bara det. Vi bygger rabattfunktioner, så vi kan återskapa allt ditt Script gjorde med ett pris, inklusive fraktrabatter. Vi levererar ingen leveransanpassning, betalningsanpassning eller valideringsfunktion, så att dölja ett fraktpris, döpa om en betalningsmetod eller begränsa en köpkvantitet är inget vi avstår från i brist på att bygga det. Det är en annan sorts app.
Sätt ihop de två halvorna och du får meningen handlare får lära sig den hårda vägen: ett Script blir ofta tre migreringar. Ett orderradsscript som även dolde ett fraktpris och blockerade en betalningsmetod är nu en rabattfunktion, en leveransanpassning och en betalningsanpassning, skrivna och driftsatta separat. Vi vill hellre att du läser det här än upptäcker det efter ombygget.
Se ett fraktscript som visar sig inte vara en rabatt allsFunctions är rena, och varje fält deklareras i förväg
Ett Script kördes som vanlig Ruby mot vad varukorgen än råkade innehålla. En Function körs i en sandlåda, och Shopify garanterar att den saknar följande:
- Inget nätverk. En Function kan inte anropa ditt ERP-system, din lojalitetsleverantör eller någon annan tjänst medan en kund handlar i kassan.
- Ingen klocka. En Function kan inte fråga vad klockan är, så "halva priset på tisdagar" måste bli en schemalagd rabatt istället för ett villkor inne i koden.
- Ingen slump. Inget kan singla slant för en kund av tio.
- Inget filsystem, och ingen möjlighet att hämta ett fält den inte bad om. Varje databit en Function läser måste namnges i förväg, i en indata-fråga, och den frågan har ett hårt kostnadstak satt av Shopify.
Den sista regeln är den som kostar handlare mest, och det är värt att vara exakt om vem den kostar. Det är inte så att Shopify döljer datan. Vår egen kassafråga ligger på den maximala kostnad Shopify tillåter, så att be om ett fält till innebär att ge upp ett annat. Nio av de Script-mönster vi avvisar idag avvisas av precis den anledningen och ingen annan, inklusive att hoppa över redan nedsatta varor, läsa ett län eller postnummer, och kontrollera hur många ordrar en kund har lagt. Shopify erbjuder alla dessa. Vi har inte gjort plats för dem än. Det är vårt gap, och att kalla det en plattformsbegränsning vore en lögn.
Bara två avvisningar i hela biblioteket är genuina Shopify-begränsningar, och båda kommer från samma faktum: varje rabattfunktion i en butik körs vid samma ögonblick och ingen av dem kan se vad de andra gjorde. Så ett Script som frågade "är den här varan redan rabatterad?" eller mätte en gräns mot en redan nedsatt delsumma kan inte återskapas av oss eller av någon annan, idag, till något pris. Allt annat på vår avvisningslista är vårt att åtgärda, och vi märker det så i appen och på varje sida i biblioteket.
Läs de två avvisningarna som verkligen är Shopify-begränsningarAtt sätta ett pris är inte samma sak som att dra av pengar
Om du bara läser en sak innan du återskapar ett Script för hand, läs den här. Två filer kan anropa samma metod, med samma konstant och samma meddelande, och betyda motsatta saker. Båda exemplen nedan är verkliga, båda är vanliga, och skillnaden mellan dem är ett minustecken.
Det här SÄTTER priset till $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 vara för $79.00 är rabatten $69.01 och kunden betalar $9.99. Återskapat som ett volymerbjudande vars belöning är ett fast pris, räknat per variant och upprepande, så att varje enhet omprissätts.
Det genomräknade exemplet, med varukorgen och inställningarnaDet här drar AV $9.99
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å samma vara för $79.00 är rabatten $9.99 och kunden betalar $69.01. Återskapat som ett volymerbjudande vars belöning är ett belopp av per enhet, räknat per produkt och som utlöses en gång.
Det genomräknade exemplet, med varukorgen och inställningarnaSamma metod, samma $9.99, samma formulering i meddelandet. Det enda tecknet är att den andra filen drar av från `line_item.line_price` innan den tilldelar. Läs det åt fel håll på en vara för $79.00 och du missar med $59.02 på en enda enhet, i vilken riktning det än gör mest ont. Och de två ombyggena skiljer sig inte bara i siffran: den ena räknar per variant och upprepas, den andra räknar per produkt och utlöses en gång, så de går isär så fort kunden köper två.
Det här är felet som det vanliga rådet inte kan fånga. Ett återskapat erbjudande som läser filen bakvänt utlöses ändå på en varukorg som ska trigga det och förblir tyst på en som inte ska, så att testa åt båda hållen släpper igenom det. Scripts Rescue stänger den luckan genom att ställa en annan fråga: innan den låter dig publicera vill den ha beloppet ditt gamla Script tog ut för en varukorg du fortfarande kan återskapa, och jämför det med vad det återskapade erbjudandet beräknar. En cent i skillnad och publiceringen förblir stängd. Bland de fem apparna som säljer Scripts-migrering idag hittade vår undersökning ingen som ber en handlare bevisa pengarna alls.
Vad varje bit Ruby blir i en kampanj
Ett ombygge går fel på samma få ställen varje gång, och de är nästan aldrig de uppenbara. Belöningen är oftast enkel. Räkning och upprepning är där pengarna tyst flyttas, eftersom ett Script uttrycker dem i aritmetik och en kampanj uttrycker dem i en inställning.
| I ditt Script | I en kampanj | Var det går fel |
|---|---|---|
change_line_price(PRICE * qty) | Ett volymerbjudande med ett fast pris som belöning. | Tilldelning, inte subtraktion. Det här är fällan ovan. Enhetspriset blir konstanten, så en vara för $79 säljs för $9.99. |
line_price - (AMOUNT * qty) | Ett volymerbjudande med ett belopp av per enhet som belöning. | Subtraktionen är hela signalen. Samma konstant som raden ovan, en helt annan summa att betala. |
line_price * 0.9 | En procentbelöning på 10. | Multiplikatorn är vad kunden behåller, inte vad de sparar. Skrivs den in rakt av som 90 ger den bort nio tiondelar av katalogen. |
next unless line_item.quantity >= 3 | En nivå med ett minsta antal på 3. | Nivåer är inkluderande vid gränsen och bara den högsta uppfyllda nivån utlöses. Scripts som lade en regel ovanpå en annan har ingen motsvarighet i ett enda erbjudande, och behöver ett erbjudande var. |
line_items.size > 1 | Ett minsta antal på 2. | Inte samma regel. Scripts räknade separata varukorgsrader här, kampanjer räknar enheter, så en rad som innehåller två av samma vara kvalificerar nu där Scriptet ignorerade den. |
sets = quantity / (BUY + GET) | Köp X få Y där gratisenheterna räknas som extra. | Att dela med enbart KÖP istället gör gratisenheterna inkluderande. På nio enheter av köp 3 få 1 blir det två gratis eller tre gratis. Ett tecken isär, hälften till bortgivet. |
customer.tags.include?("vip") | Kundbehörighet avgränsad till taggar. | Shopify matchar taggar exakt, versaler inkluderat, medan många Script-dialekter gjorde båda sidor till gemener först. Kontrollera stavningen innan publicering, inte efter. |
product.tags / product_type / vendor | Målomfång satt till taggar, produkttyper eller leverantörer. | En missad omfångsrad är det dyraste misstaget i den här tabellen, för det gör om "20 % rabatt på rea-taggen" till 20 % rabatt på allt du säljer. |
En sak du inte hittar i den här tabellen är kollektioner. Ett Script kunde läsa en produkts taggar, typ och leverantör men aldrig dess kollektioner, så all Ruby som påstod sig kontrollera en kollektion gjorde inte det den såg ut att göra. Kampanjer kan rikta mot kollektioner; ditt gamla Script kunde inte.
Slå upp ditt Script istället för att resonera dig fram
Varje Script-mönster vi har katalogiserat har sin egen sida: den ursprungliga Rubyn, vad den känns igen som, den exakta konfigurationen den blir, en varukorg från vår publika demobutik med rabatten den riktiga motorn beräknar för den, och varukorgen som måste förbli tyst. Avvisningarna skrivs ut på samma sätt, var och en märkt som en Shopify-begränsning, vårt eget gap, eller ett jobb för en annan sorts app. Det är referensen vi själva ville ha när vi började, så den är publik.
- Script-former
- 42
- Ombyggda i dag
- 38
- Avslagna, med skäl
- 21
Ett ärligt svar om omfattning
Stackable återskapar regelbaserad rabattlogik med native Shopify Functions. Det kör ingen godtycklig anpassad kod.
Det här återskapar Stackable
- Nivåbaserade / volymrabatter (t.ex. "köp 3+, spara 15 %")
- Köp X få Y och BOGO-logik, inklusive upprepade nivåer
- Explicita staplingsregler mellan erbjudanden
- Schemalagd start, slut och omedelbar paus på vilken kampanj som helst
Det här behöver du fortfarande en utvecklare för
- Godtycklig anpassad kod som ditt gamla Script körde (skräddarsydda prisformler, engångsvillkor ingen byggare täcker)
- Anpassningar för frakt/leverans (en separat Function-typ)
- Betalningsanpassningar (en separat Function-typ)
- Allt som inte kan reduceras till en regelbaserad rabattkonfiguration
Om ditt gamla Script gjorde något på den här listan kan en no-code-byggare, Stackable inkluderat, inte nå det. Det är en utvecklarskriven Function, inte en konfigurationsskärm.
Vanliga frågor
Är mina gamla Scripts borta?
Scripts slutade köras den 30 juni 2026, men det är inte nödvändigtvis samma ögonblick som Script Editors sparade källkod raderas. Exportera eller kopiera din gamla Script-kod nu oavsett: när Shopify helt avvecklar editorn blir den oåterkallelig.
Får jag ett felmeddelande om en Function är felkonfigurerad?
Nej. En Function vars villkor inte matchar en varukorg utlöses helt enkelt aldrig, tyst, utan fel och utan varning. Testa alltid med en varukorg som ska utlösa den och en som inte ska innan du litar på den i produktion.
Ersätter Stackable allt mitt gamla Script gjorde?
Bara den regelbaserade delen: nivåbaserade och volymrabatter, BOGO, rabattstapling och schemaläggning, alla återuppbyggda på inbyggda Shopify Functions. Stackable kör ingen godtycklig anpassad kod. Om ditt Script gjorde något genuint skräddarsytt, en anpassad prisformel eller ett villkor ingen byggare täcker, behöver det fortfarande en utvecklare som skriver Functionen direkt.
Vad händer med frakt- eller betalningslogiken mitt Script hanterade?
Det är separata Function-typer (leverans och betalning) som Stackable inte rör. En utvecklare behöver migrera dem oberoende av din rabattlogik.
Vilket abonnemang ingår Scripts Rescue i?
Scripts Rescue, verktyget som läser din gamla Ruby och återskapar den, ingår i Pro-abonnemanget. Stackable i sig är gratis att installera, och kärnrabattmotorn, inklusive volymnivåer, Köp X få Y, köpmål, fri frakt, schemaläggning och simulatorn, är gratis på alla abonnemang. Ruby-räddningen specifikt är det inte: den ligger tillsammans med flerbutik och Shopify Flow på Pro.
Hur vet jag att den återskapade rabatten tar samma belopp som den gamla gjorde?
För att du tvingas bevisa det innan du kan publicera. Att testa en varukorg som ska utlösa erbjudandet och en som inte ska är standardrådet, och det fångar inte det värsta felet, vilket är ett erbjudande som utlöses korrekt för fel belopp. Scripts Rescue ber dig om beloppet ditt gamla Script tog ut på en varukorg du fortfarande kan återskapa, jämför det med vad det återskapade erbjudandet beräknar, och håller publiceringen stängd tills de två stämmer överens till cent. Vår undersökning av de fem apparna som säljer Scripts-migrering hittade ingen som ber om det.
Varför såg mitt Script så komplicerat ut?
Eftersom bara ett Script av varje typ kunde publiceras åt gången. En butik som körde fyra kampanjer kunde inte skriva fyra Scripts, så den skrev en fil med alla fyra sammanslagna och en regel längst ner som avgjorde vilken som vann. Det mesta Ruby som ser oläsligt ut är egentligen flera enkla regler som delar en plats, och var och en av dem går oftast att återskapa rent för sig.
Var kan jag läsa hela migreringsgenomgången?
Vårt första blogginlägg går igenom avvecklingen av Scripts och migreringsvägen mer detaljerat, och Script-exempelbiblioteket har en sida per Script-mönster med den ursprungliga Rubyn och den exakta ombyggnaden.
Relaterade 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.
Installera Stackable och återskapa dina regelbaserade rabatter
Volymnivåer, BOGO, stapling och schemaläggning, som körs på native Shopify Functions från dag ett.
Scripts Rescue ingår i Pro-abonnemanget. Stackable i sig är gratis att installera, inget kort krävs.