Shopify Scripts stopte op 30 juni 2026 met werken. Dit is wat u nu moet doen.
Als uw winkel een aangepast Script had voor kortingen, BOGO of bundels, stopte dit op 30 juni 2026 stilletjes met werken. Geen foutmelding, geen waarschuwing, niets in uw logs. Hier leest u precies wat er is gebeurd, wat migreren naar Shopify Functions werkelijk inhoudt, en een eerlijk antwoord op wat Stackable voor u kan herbouwen.
- Shopify Scripts stopte op 30 juni 2026 met werken, voor elke winkel die het nog gebruikte.
- Elke aangepaste logica voor kortingen, BOGO of bundels die in een Script was ondergebracht, werd vanaf die datum niet meer toegepast.
- Deze storing is bewust stil: een Shopify Function waarvan de voorwaarden niet overeenkomen met een winkelwagentje wordt simpelweg nooit geactiveerd. Er verschijnt geen foutmelding en Shopify stuurt geen melding.
Handelaren die deze migratie doorlopen, beschrijven op de Shopify community forums allemaal hetzelfde gevaar:
“Mijn oude Script stopte stilletjes met het toepassen van een korting en ik kwam er alleen achter doordat een klant klaagde dat hij de volle prijs had betaald. Er was geen foutmelding, geen waarschuwing, niets in de bestellogs. Ik draaide al weken op een kapotte configuratie voordat ik het merkte.”
Dat is het kernrisico van de overstap van Scripts naar Functions: een Function draait correct of is verkeerd geconfigureerd en zwijgt. Een zichtbare tussentoestand bestaat niet, dus een niet-kloppende voorwaarde, een typefout in een drempelwaarde, of een regel die aan de verkeerde collectie is gekoppeld, levert precies dezelfde stilte op als een Function die wel goed werkt. De enige manier om dit op te sporen is doelbewust in beide richtingen te testen voordat u erop vertrouwt in een live omgeving.
Vier dingen die het waard zijn om te weten voordat u begint
Eén Script wordt vaak drie migraties
Eén enkel Script-bestand kon tegelijk kortingslogica, verzendtarieven en betalingsaanpassingen raken. Functions splitst dit op in aparte Function-types, discount, delivery en payment, elk afzonderlijk geconfigureerd en uitgerold. "Mijn Script migreren" betekent meestal het migreren van maximaal drie verschillende dingen, en dit is de klacht die handelaren het vaakst uiten over de overstap.
No-code builders dekken meestal alleen kortingen en BOGO
Als uw Script ook verzendtarieven of betaalmethoden raakte, komt een no-code builder voor discount-Functions, inclusief Stackable, daar niet bij. Aanpassingen voor delivery en payment vereisen een ontwikkelaar die die Function rechtstreeks schrijft.
Bewaar nu uw oude Script-broncode
Zodra de Script Editor volledig wordt uitgefaseerd, is de opgeslagen code niet meer terug te halen. Exporteer of kopieer uw oude Script-broncode vandaag nog, ook als u nog niet klaar bent om te migreren, zodat u een referentie heeft voor wat het ook vervangt.
Test een winkelwagentje dat wel moet activeren en een dat niet moet activeren
Voordat u een nieuwe Function vertrouwt, stelt u twee testwinkelwagentjes samen: een die de Function wel moet activeren, en een die dat doelbewust niet moet doen. Een Function die afgaat terwijl dat niet zou moeten, is net zo kostbaar als een die stilletjes nooit afgaat.
De drie dingen die elke migratiebeslissing verklaren
Bijna elke discussie over wat wel en niet kan worden herbouwd, komt neer op drie feiten: Scripts kwamen in drie types met elk één slot, Functions splitsen die drie types op over vier verschillende API's, en een Function moet elk stukje data dat hij ooit leest vooraf declareren voordat hij draait. Zodra u die drie feiten kent, is de rest van deze pagina rekenwerk.
Shopify Scripts kwamen in drie types
De Script Editor liet u eerst een type kiezen voordat u een regel Ruby schreef, en dat type bepaalde waar uw code aan mocht komen.
Regelitem-scripts
Degene die bepaalden wat producten kostten. Ze doorliepen de winkelwagen regel voor regel en herprijsden die, en dat is waar elke gestaffelde korting, BOGO, bundelprijs en afprijzing zat.
Verzendscripts
Degene die met verzendtarieven werkten. Ze konden een tarief korten, verbergen, hernoemen, of de volgorde van de lijst die de koper zag wijzigen. Alleen de eerste van die vier is een korting.
Betaalscripts
Degene die met betaalmethoden werkten, met dezelfde vier acties: een methode verbergen, hernoemen, de volgorde wijzigen, of in de praktijk vooral verbergen voor bepaalde winkelwagens.
Dan nu de beperking die elk echt Script dat u ooit zult lezen heeft gevormd: er kon maar één Script van elk type tegelijk gepubliceerd zijn. Eén regelitem-slot voor de hele winkel. Een handelaar met een VIP-korting, een opruimingsprijs, een bestedingsdrempel en een seizoenspromotie schreef dus geen vier Scripts. Ze schreven één bestand waarin alle vier samengevoegd waren, meestal met een handmatig gebouwde regel onderaan die bepaalde "kies degene die de beste prijs geeft". Daarom zien echte Scripts er verward uit. Het zijn geen slecht geschreven regels, het zijn meerdere regels die nooit apart mochten zijn.
Bekijk een echt Script met vier campagnes samengevoegd in één bestandVier Function-API's namen hun plaats in
Shopify verving Scripts niet door één ding. Het verving ze door vier, opgesplitst naar wat de code mag wijzigen in plaats van naar waar in de winkelwagen het draait.
Discount Function API
Geld eraf. Productkortingen, bestellingskortingen en verzendkortingen zitten nu allemaal hier, in één uniforme API. Als uw Script een prijs wijzigde, komt dat hier terecht.
Documentatie van ShopifyDelivery Customization API
Verzendopties verbergen, hernoemen en herordenen. Shopify is expliciet dat dit de enige API is die verzendopties bij de checkout kan aanpassen, dus een kortingsapp kan hier niet bij, hoe die ook gebouwd is.
Documentatie van ShopifyPayment Customization API
Betaalmethoden verbergen, hernoemen en herordenen, plus betalingstermijnen en of een bestelling controle nodig heeft. De betaalhelft van de oude Script Editor, op één plek.
Documentatie van ShopifyCart and Checkout Validation API
De checkout blokkeren met een bericht. Aankooplimieten, leeftijdscontroles en regels voor minimumbestellingen komen hier terecht. Deze API geeft foutmeldingen terug, dus ze kan een bestelling stoppen maar niet stilletjes wijzigen.
Documentatie van ShopifyStackable is een Discount Function-app, en niets anders. Wij bouwen discount functions, dus we kunnen alles herbouwen wat uw Script deed met een prijs, inclusief verzendkortingen. Wij leveren geen delivery customization, geen payment customization en geen validation function, dus het verbergen van een verzendtarief, het hernoemen van een betaalmethode of het begrenzen van een aankoophoeveelheid wijzen we niet af omdat we het niet gebouwd hebben. Het is een ander soort app.
Voeg de twee helften samen en u krijgt de zin die handelaren op de harde manier ontdekken: één Script wordt vaak drie migraties. Een regelitem-Script dat ook een verzendtarief verborg en een betaalmethode blokkeerde, is nu een discount function, een delivery customization en een payment customization, elk apart geschreven en uitgerold. Wij lezen dit liever hier dan dat u het na de herbouw ontdekt.
Bekijk een verzend-Script dat helemaal geen korting blijkt te zijnFunctions zijn puur, en elk veld wordt vooraf gedeclareerd
Een Script draaide als gewone Ruby tegen wat de winkelwagen op dat moment ook bevatte. Een Function draait gesandboxed, en Shopify garandeert dat die geen van het volgende heeft:
- Geen netwerk. Een Function kan uw ERP, uw loyaliteitsprovider of enige andere dienst niet aanroepen terwijl een koper aan het afrekenen is.
- Geen klok. Een Function kan niet vragen hoe laat het is, dus "halve prijs op dinsdag" moet een geplande korting worden in plaats van een voorwaarde in de code.
- Geen willekeur. Niets kan een dobbelsteen gooien voor één op de tien kopers.
- Geen bestandssysteem, en geen toegang tot een veld dat niet vooraf is opgevraagd. Elk stukje data dat een Function leest, moet vooraf worden genoemd in een input query, en die query heeft een harde kostengrens die door Shopify is vastgesteld.
Die laatste regel kost handelaren het meest, en het loont om precies te zijn over wie dat kost. Het is niet dat Shopify de data verbergt. Onze eigen checkout query zit al op de maximale kosten die Shopify toestaat, dus om nóg een veld op te vragen moeten we een ander veld opgeven. Negen van de Script-vormen die we vandaag weigeren, weigeren we precies om die reden en niets anders, waaronder het overslaan van al afgeprijsde artikelen, het uitlezen van een provincie of postcode, en het controleren hoeveel bestellingen een klant heeft geplaatst. Shopify biedt al deze velden aan. Wij hebben er alleen nog geen ruimte voor gemaakt. Dat is ons eigen gat, en het een platformbeperking noemen zou een leugen zijn.
Slechts twee weigeringen in de hele bibliotheek zijn echte Shopify-beperkingen, en beide komen voort uit hetzelfde feit: elke discount function in een winkel draait op hetzelfde moment, en geen enkele kan zien wat de andere heeft gedaan. Een Script dat vroeg "is dit artikel al gekort?" of een drempel afmat tegen een al verlaagd subtotaal, kan dus door ons noch door wie dan ook worden herbouwd, vandaag, tegen welke prijs dan ook. Al het andere op onze weigerlijst is aan ons om op te lossen, en we labelen het als zodanig in de app en op elke pagina van de bibliotheek.
Lees de twee weigeringen die echt Shopify-beperkingen zijnEen prijs instellen is niet hetzelfde als geld eraf halen
Als u maar één ding leest voordat u een Script handmatig herbouwt, laat het dit zijn. Twee bestanden kunnen dezelfde methode aanroepen, met dezelfde constante en hetzelfde bericht, en toch het tegenovergestelde betekenen. Beide onderstaande gevallen zijn echt, beide komen vaak voor, en het verschil ertussen is een minteken.
Dit STELT de prijs IN op $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.cartBij een artikel van $79.00 is de korting $69.01 en betaalt de koper $9.99. Herbouwd als een volume-aanbieding met een vaste prijs als beloning, geteld per variant en herhalend, zodat elke eenheid opnieuw wordt geprijsd.
Het uitgewerkte voorbeeld, met de winkelwagen en de instellingenDit haalt $9.99 ERAF
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.cartBij hetzelfde artikel van $79.00 is de korting $9.99 en betaalt de koper $69.01. Herbouwd als een volume-aanbieding met een bedrag-korting per eenheid als beloning, geteld per product en eenmalig geactiveerd.
Het uitgewerkte voorbeeld, met de winkelwagen en de instellingenZelfde methode, zelfde $9.99, dezelfde bewoording in het bericht. Het enige verschil is dat het tweede bestand aftrekt van `line_item.line_price` voordat het toewijst. Leest u het verkeerd om bij een artikel van $79.00, dan zit u er $59.02 naast op één enkele eenheid, in welke richting dat ook pijn doet. En de twee herbouwde versies verschillen niet alleen in het bedrag: de ene telt per variant en herhaalt, de andere telt per product en activeert eenmalig, dus ze lopen ook uiteen zodra de koper er twee koopt.
Dit is de fout die het gebruikelijke advies niet opvangt. Een herbouwde aanbieding die het bestand verkeerd om leest, activeert nog steeds bij een winkelwagen die dat zou moeten doen en blijft nog steeds stil bij een winkelwagen die dat niet zou moeten doen, dus testen in beide richtingen laat hem er gewoon doorheen. Scripts Rescue sluit dat gat door een andere vraag te stellen: voordat u mag publiceren, wil het het bedrag weten dat uw oude Script rekende voor een winkelwagen die u nog kunt reproduceren, en vergelijkt dat met wat de herbouwde aanbieding berekent. Eén cent verschil en publiceren blijft dicht. Van de vijf apps die vandaag Scripts-migratie verkopen, vond ons onderzoek er geen enkele die een handelaar vraagt het bedrag te bewijzen.
Wat elk stukje Ruby wordt in een campagne
Een herbouw gaat steeds op dezelfde paar plekken mis, en dat zijn bijna nooit de voor de hand liggende. De beloning is meestal makkelijk. Tellen en herhaling zijn waar het geld stilletjes verschuift, omdat een Script dat in rekenkunde uitdrukt en een campagne in een instelling.
| In uw Script | In een campagne | Waar het misgaat |
|---|---|---|
change_line_price(PRICE * qty) | Een volume-aanbieding met een vaste-prijs-beloning. | Toewijzing, geen aftrekking. Dit is de valkuil hierboven. De eenheidsprijs wordt de constante, zodat een artikel van $79 verkocht wordt voor $9.99. |
line_price - (AMOUNT * qty) | Een volume-aanbieding met een bedrag-korting-per-eenheid-beloning. | De aftrekking is het hele signaal. Dezelfde constante als de rij hierboven, een compleet andere rekening. |
line_price * 0.9 | Een percentagebeloning van 10. | De vermenigvuldigingsfactor is wat de koper overhoudt, niet wat hij bespaart. Rechtstreeks ingevoerd als 90 geeft dat negen tiende van de catalogus weg. |
next unless line_item.quantity >= 3 | Een niveau met een minimumaantal van 3. | Niveaus zijn inclusief bij de grens en alleen het hoogste behaalde niveau wordt geactiveerd. Scripts die de ene regel bovenop de andere stapelden, hebben geen equivalent in één aanbieding en hebben elk hun eigen aanbieding nodig. |
line_items.size > 1 | Een minimumaantal van 2. | Niet dezelfde regel. Scripts telden hier aparte winkelwagenregels, campagnes tellen eenheden, dus één regel met twee keer hetzelfde artikel komt nu in aanmerking waar het Script dat negeerde. |
sets = quantity / (BUY + GET) | Koop X Krijg Y waarbij de gratis eenheden als extra worden geteld. | Delen door alleen KOOP maakt de gratis eenheden in plaats daarvan inclusief. Bij negen eenheden van een koop 3 krijg 1 is dat twee gratis of drie gratis. Eén teken verschil, anderhalf keer zoveel weggegeven. |
customer.tags.include?("vip") | Klanttoelaatbaarheid afgebakend op tags. | Shopify matcht tags exact, hoofdletters inbegrepen, terwijl veel Script-varianten beide kanten eerst naar kleine letters omzetten. Controleer de spelling vóór het publiceren, niet erna. |
product.tags / product_type / vendor | Doelbereik ingesteld op tags, producttypes of leveranciers. | Een gemiste scope-regel is de duurste fout in deze tabel, omdat het "20% korting op de sale-tag" verandert in 20% korting op alles wat u verkoopt. |
Eén ding dat u niet in deze tabel vindt, is collecties. Een Script kon de tags, het type en de leverancier van een product uitlezen, maar nooit de collecties ervan, dus elke Ruby die beweerde een collectie te controleren, deed niet wat het leek te doen. Campagnes kunnen collecties targeten; uw oude Script kon dat niet.
Zoek uw Script op in plaats van erover te redeneren
Elke Script-vorm die we hebben gecatalogiseerd heeft een eigen pagina: de originele Ruby, waarvoor het herkend wordt, de exacte configuratie die het wordt, een winkelwagen uit onze publieke demowinkel met de korting die de echte engine ervoor berekent, en de winkelwagen die stil moet blijven. De weigeringen zijn op dezelfde manier uitgeschreven, elk gelabeld als een Shopify-beperking, ons eigen gat, of een klus voor een ander soort app. Het is de referentie die wij wilden toen we begonnen, dus hij is openbaar.
- Script-vormen
- 42
- Nu herbouwd
- 38
- Geweigerd, met reden
- 21
Een eerlijk antwoord over de reikwijdte
Stackable herbouwt regelgebaseerde kortingslogica op native Shopify Functions. Het voert geen willekeurige aangepaste code uit.
Dit herbouwt Stackable
- Gestaffelde / volumekortingen (bijv. "koop 3+, bespaar 15%")
- Buy X Get Y en BOGO-logica, inclusief herhaalbare staffels
- Expliciete regels voor het stapelen van kortingen tussen aanbiedingen
- Geplande start- en einddatum, en direct pauzeren van elke campagne
Hiervoor heeft u nog steeds een developer nodig
- Willekeurige aangepaste code die uw oude Script uitvoerde (op maat gemaakte prijsformules, eenmalige voorwaarden die geen enkele builder dekt)
- Aanpassingen voor verzending / delivery (een apart Function-type)
- Aanpassingen voor betalingen / payment (een apart Function-type)
- Alles wat niet is terug te brengen tot een regelgebaseerde kortingsconfiguratie
Als uw oude Script iets uit deze lijst deed, kan een no-code bouwer, Stackable inbegrepen, dat niet bereiken. Dat is een door een developer geschreven Function, geen configuratiescherm.
Veelgestelde vragen
Zijn mijn oude Scripts verdwenen?
Scripts stopte op 30 juni 2026 met werken, maar dat is niet per se hetzelfde moment waarop de opgeslagen broncode in de Script Editor wordt verwijderd. Exporteer of kopieer uw oude Script-code hoe dan ook nu al: zodra Shopify de editor volledig uitfaseert, is deze niet meer terug te halen.
Krijg ik een foutmelding als een Function verkeerd is geconfigureerd?
Nee. Een Function waarvan de voorwaarden niet overeenkomen met een winkelwagentje wordt simpelweg nooit geactiveerd, stilletjes, zonder foutmelding of waarschuwing. Test altijd met een winkelwagentje dat de Function wel moet activeren en een die dat niet moet doen, voordat u erop vertrouwt in productie.
Vervangt Stackable alles wat mijn oude Script deed?
Alleen het regelgebaseerde deel: gestaffelde en volumekortingen, BOGO, het stapelen van kortingen en planning, allemaal herbouwd op native Shopify Functions. Stackable voert geen willekeurige aangepaste code uit. Deed uw Script iets echt op maat, zoals een aangepaste prijsformule of een voorwaarde die geen enkele builder dekt, dan is daar nog steeds een ontwikkelaar voor nodig om die Function rechtstreeks te schrijven.
En de verzend- of betaallogica die mijn Script afhandelde?
Dat zijn aparte Function-typen (delivery en payment) waar Stackable niet aankomt. Een ontwikkelaar moet die los van uw kortingslogica migreren.
Op welk abonnement zit Scripts Rescue?
Scripts Rescue, de tool die uw oude Ruby leest en herbouwt, zit op het Pro-abonnement. Stackable zelf is gratis te installeren, en de kernkortingsengine, inclusief volumeniveaus, Koop X Krijg Y, bestedingsdoelen, gratis verzending, planning en de simulator, is gratis op elk abonnement. Specifiek de Ruby-rescue is dat niet: die zit samen met meerdere winkels en Shopify Flow op Pro.
Hoe weet ik dat de herbouwde korting hetzelfde bedrag rekent als de oude?
Omdat u het moet bewijzen voordat u kunt publiceren. Een winkelwagen testen die wel moet activeren en een die dat niet moet doen, is het standaardadvies, en dat vangt de ergste fout niet op: een aanbieding die correct activeert voor het verkeerde bedrag. Scripts Rescue vraagt u om het bedrag dat uw oude Script rekende voor een winkelwagen die u nog kunt reproduceren, vergelijkt dat met wat de herbouwde aanbieding berekent, en houdt publiceren dicht totdat de twee tot op de cent overeenkomen. Ons onderzoek naar de vijf apps die vandaag Scripts-migratie verkopen, vond er geen enkele die daarom vraagt.
Waarom zag mijn Script er zo ingewikkeld uit?
Omdat er maar één Script van elk type tegelijk gepubliceerd kon zijn. Een winkel met vier promoties kon geen vier Scripts schrijven, dus schreef hij één bestand waarin alle vier samengevoegd waren, met een regel onderaan die bepaalde welke won. De meeste Ruby die onleesbaar oogt, is in werkelijkheid meerdere eenvoudige regels die één slot delen, en elk daarvan is meestal apart prima te herbouwen.
Waar kan ik het volledige migratieverslag lezen?
Onze eerste blogpost gaat uitgebreider in op de uitfasering van Scripts en het migratiepad, en de bibliotheek met Script-voorbeelden heeft per Script-vorm een pagina met de originele Ruby en de exacte herbouw.
Gerelateerde functies
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.
Installeer Stackable en herbouw uw regelgebaseerde kortingen
Volumestaffels, BOGO, stapelen en planning, draaiend op native Shopify Functions vanaf dag één.
Scripts Rescue zit op het Pro-abonnement. Stackable zelf is gratis te installeren, zonder dat een creditcard nodig is.