Shopify Scripts eindigen op 30 juni 2026: Migreer je kortingen zonder developer

Shopify Scripts stoppen op 30 juni 2026 met uitvoeren, en elke aangepaste korting-, verzend- of betalingsregel die je in de Script Editor hebt gebouwd, stopt op die datum met toepassen. De vervanging is Shopify Functions, die je logica server-side in de checkout uitvoert. Je hebt drie manieren om daar te komen: een developer inhuren om Functions te schrijven, een bureau betalen om het te doen, of op regels gebaseerde kortingslogica in een no-code Functions-app herbouwen. Het urgente deel is dat het mislukken stil is. Een Script dat stopt met afvuren, of een gemigreerde regel die niet in een winkelwagen past, genereert geen fout en meldt je niet. Het berekent gewoon rustig volledige prijs tot een klant klaagt.

Deze gids legt uit wat Scripts deden, waarom Shopify ze uit bedrijf stelt, wat Functions eigenlijk zijn, waarom "mijn Script migreren" eigenlijk tot drie aparte migraties is, de stille-mislukkingsvalkuil en precies hoe je hieromheen test, wat een no-code app kan en niet kan dekken, en een eerlijke uitsplitsing van wanneer je nog steeds een developer nodig hebt.

Wat gebeurt er met Shopify Scripts en wanneer?

Shopify Scripts worden uit bedrijf gesteld. Volgens Shopify's developer documentatie, "Shopify Scripts worden op 30 juni 2026 uit bedrijf gesteld. Alle bestaande Shopify Scripts stoppen na deze datum met functioneren." Er zijn twee datums die ertoe doen, en de eerste is al voorbij:

• 15 april 2026: het bewerken en publiceren van nieuwe Shopify Scripts is niet langer mogelijk. Volgens de Shopify developer changelog, kan je na deze datum geen Script helemaal niet meer maken of wijzigen.
• 30 juni 2026: alle Shopify Scripts stoppen helemaal met uitvoering. Elke korting-, verzend- of betalingslogica die in een Script leeft, stopt gewoon met werken.

Als je winkel op 1 juli 2026 nog steeds op een Script vertrouwde, is die logica al offline terwijl je dit leest. De aanpassingen zijn niet mislukt of teruggedraaid naar een veilige standaard. Ze waren stil. Dat is het allerbelangrijkste om te begrijpen over deze deadline: het is geen luide mislukking die je van een dashboardwaarschuwing zult opmerken. Het is een afwezigheid.

Shopify levert ook een tool om je te helpen het werk in te kaderen. Het Shopify Scripts-aanpassingenrapport helpt je bepalen welke van je huidige aanpassingen kunnen worden gemigreerd naar Functions of openbare apps. Als je dit nog niet hebt uitgevoerd, is dat stap een.

AFBEELDINGSPLAATSHOUDER (Afbeelding 1): De Scripts sunset-tijdlijn

Voorgestelde visual: Een schone 16:9 horizontale tijdlijn op een witte achtergrond met drie mijlpaalmarkeringen in violet en diepgoud. Markering een, "15 april 2026 - bewerken eindigt" in goud. Markering twee, "30 juni 2026 - Scripts stoppen met uitvoering" in violet met een klein rood 'silent' label. Een voortvloeide pijl met het label "Shopify Functions" gaat voorbij de laatste markering. Platte, minimale, sans-serif labels, geen fotografie.

Wat deden Shopify Scripts en waarom stelt Shopify ze uit bedrijf?

Shopify Scripts waren kleine Ruby-programma's die in de Script Editor-app draaiden en drie delen van de koopstroom aanpasten: winkelwagen- en regelkortingen, verzendtarieven en betalingsmethoden. Een merchant op Shopify Plus kon een Script schrijven dat een gestaffelde korting gaf, een verzendoptie voor bepaalde adressen verborg, of betalingsmethoden bij checkout herschreef. Scripts waren krachtig precies omdat ze willekeurige code waren: als je het in Ruby kon uitdrukken, kon je het doen.

Shopify vervangt ze door Shopify Functions. Volgens de migratiedocumentatie, "Met Shopify Functions worden deze aanpassingen nu afgehandeld via speciale Function APIs die betere prestaties en flexibiliteit bieden." Functions draaien op Shopify's eigen infrastructuur in de checkout-pijplijn, wat ze sneller en schaalbaaarder maakt dan het oudere Scripts-model, en het betekent dat dezelfde logica van toepassing is of een koper op de winkelwagenpagina, de checkout-pagina of een versnelde portemonnee zoals Shop Pay uitcheckt.

Het compromis is dat Functions niet een tekstvak zijn waar je Ruby in plakt. Ze zijn developer-artefacten: je bouwt ze op met de Shopify CLI, schrijft de logica in Rust of JavaScript, definieert een GraphQL-invoerquery en zet ze in via een app. Die verschuiving, van "merchant schrijft een Script" naar "developer levert een Function," is de hele reden waarom deze migratie een project is en geen selectievakje.

Wat zijn Shopify Functions en waarom hebben ze meestal een developer nodig?

Shopify Functions laten je delen van Shopify's backend logica uitbreiden of vervangen met aangepaste code die tijdens checkout wordt uitgevoerd. Er zijn speciale Function APIs voor de dingen die Scripts plachten te doen, inclusief een Discount Function API, een Delivery (verzending) Customization API en een Payment Customization API.

Twee eigenschappen van Functions zijn belangrijk voor je migratieplan.

Functions draaien server-side, eenmaal

Een Function draait in Shopify's checkout, niet in je tema. Dat is een echte upgrade ten opzichte van kortingsmethoden die een totaal in thema JavaScript op de winkelwagenpagina berekenen en het vervolgens mee eens zijn met wat checkout aanrekent. Omdat de Function de enkele bron van waarheid is, zijn de winkelwagenvoorbeeldweergave en de uiteindelijke lading dezelfde berekening. Dit is ook waarom een correct gebouwde Function identiek wordt toegepast over Shop Pay, Apple Pay en Google Pay, die de winkelwagenpagina helemaal overslaan.

Functions worden standaard gebouwd, niet geconfigureerd

Het schrijven van een Function vanaf nul is een developer-taak. Je hebt de Shopify CLI, een taalwerkplaats en bekendheid met de invoerquery en resultaatvorm van de Function nodig. Er is een nuance waard om te weten over beschikbaarheid van abonnementen: volgens Shopify's Functions beschikbaarheidsdocumentatie, "Winkels op elk abonnement kunnen openbare apps gebruiken die via de Shopify App Store worden verdeeld en functies bevatten. Alleen winkels op een Shopify Plus-abonnement kunnen aangepaste apps gebruiken die Shopify Function APIs bevatten." In gewone termen: een openbare app uit de App Store kan Functions naar elk abonnement brengen, maar een maatwerk Functions-app is een Plus-only pad. Dat onderscheid is wat een no-code Functions-app aantrekkelijk maakt voor niet-Plus merchants die een developer plachten in te huren.

Het goede nieuws is dat zodra een Function in een app is ingezet, de merchant deze zonder code aan te raken uit de admin configureert. Zoals Shopify het zei toen Functions werd gelanceerd, "merchant eindgebruikers hoeven nooit een code-regel aan te raken bij het wijzigen van hun aanpassingen." De code wordt eenmaal geschreven; de instellingen leven in de admin.

Waarom is "mijn Script migreren" eigenlijk drie aparte migraties?

Dit is het detail dat mensen verrast, en het komt rechtstreeks uit hoe merchants het werk beschrijven op de Shopify-communityforums. Een enkel Script-bestand kon tegelijk discounts, verzending en betalingslogica aanraken. Functions splitsen dit bewust in aparte, onafhankelijke Function-typen.

• Kortingslogica (gestaffelde prijzen, BOGO, order- en productkortingen, stacking-regels) wordt toegewezen aan de Discount Function API. Shopify's unified Discount Function API kan besparingen toepassen op alle drie de kortingsklassen, product, order en verzending, vanuit een enkele function.
• Verzend- en delivery-logica (hernoemen, herschikken of verbergen van leveringsopties) wordt toegewezen aan de Delivery Customization Function API, een volkomen aparte function.
• Betalingslogica (hernoemen, herschikken of verbergen van betalingsmethoden) wordt toegewezen aan de Payment Customization Function API, een derde aparte function.

Dus de zin "Ik moet mijn Script migreren" betekent vaak tot drie verschillende dingen migreren, onafhankelijk geconfigureerd en ingezet. Een no-code korting-app kan het eerste emmertje herbouwen. Het bereikt niet de verzend- en betalingsemmertjes, wat precies waarom je je oude Script moet inventariseren voordat je aanneemt dat enig enkel hulpmiddel het bedekt. Verdeel het werk eerst per oppervlak, en kies dan een pad voor elk oppervlak.

AFBEELDINGSPLAATSHOUDER (Afbeelding 2): Een Script wordt drie Functions

Voorgestelde visual: Een 16:9 diagram. Links, een enkel gelabeld vak "One Shopify Script (Ruby)" in slate. Drie pijlen waaieren naar rechts naar drie afzonderlijke vakken: "Discount Function" in violet, "Delivery Function" in goud, "Payment Function" in slate-blauw, elk met een klein bijschrift "onafhankelijk ingezet". Schoon plat vector, merkkleur violet en goud, geen fotografie.

Het gevaar van stille mislukking en hoe je hiertegen test

Dit is het onderdeel dat merchants echt geld kost, en het verdient zijn eigen sectie omdat het zowel op de deadline zelf als op elke regel die je herbouwt van toepassing is.

Een Shopify Function is goed gevormd en draait, of het is verkeerd geconfigureerd en stil. Er is geen zichtbare tussentoestand. Een Function waarvan de voorwaarden niet in een bepaalde winkelwagen passen, voert niet uit, genereert geen fout en waarschuwt je niet. Dat is met opzet: dezelfde stilte die je krijgt van een Function die correct werkt (het deed juist niets voor een winkelwagen die niet zou mogen kwalificeren) is de stilte die je krijgt van een Function die kapot is (een typfout in een drempel, een regel bereikt voor de verkeerde collectie, een laag dat nooit afgaat).

Merchants die deze migratie doorwerken beschrijven dezelfde ervaring op de Shopify-communityforums: een regel stopt rustig met het toepassen van een korting, en de merchant vindt het alleen uit omdat een klant over volledige prijs in rekening gebracht klaagt. Geen fout, geen waarschuwing, niets in de bestelregisters. De winkel had weken lang op een kapote setup gedraaid voordat iemand het opmerkte.

De enige betrouwbare verdediging is beide richtingen testen voordat je een regel live vertrouwt:

1. Bouw een winkelwagen die moet afvuren. Stel een echte winkelwagen samen die aan elke voorwaarde van de regel voldoet, plaats een conceptorder of testorder en lees de checkout-samenvatting regel voor regel. Bevestig dat de exacte korting die je verwacht aanwezig is, in het bedrag dat je verwacht.
2. Bouw een winkelwagen die niet mag afvuren. Stel een winkelwagen samen die bewust niet kwalificeren, bijvoorbeeld een artikel onder je hoeveelheidslimiet, en bevestig dat de korting correct uitgeschakeld blijft.

Een Function die afvuurt wanneer dit niet nodig is, is net zo kostbaar als een Function die stil nooit afvuurt. Je bent niet klaar met testen totdat je de regel heb zien toepassen en correct afslaan. Voer de afvuurrende winkelwagen ook via Shop Pay uit, zodat je bevestigt dat het versnelde pad het met standaard checkout eens is.

Een bewaring-stap meer terwijl je hier bent: houd je oude Script-bron nu. Zodra de Script Editor volledig uit bedrijf wordt gesteld, wordt zijn opgeslagen code onherstelbaar van Shopify. Exporteer of kopieer je Script-bron vandaag al, zelfs als je nog niet klaar bent om het herbouwen, zodat je een referentie hebt voor wat het vervangt.

Kan een no-code app mijn Scripts migreren? Wat het bedekt en wat niet

Voor het korting-oppervlak specifiek, kan een no-code Functions-app een groot aandeel van wat merchants Scripts voor gebruikten opnemen. Als je Script-logica tot regels aansluit, dat wil zeggen "wanneer de winkelwagen er als X uitziet, korting Y toepassen", een configuratie-gestuurde app kan het meestal zonder developer herbouwen. Dat bedekt veel gemeenschappelijke grond:

• Gestaffelde en volume kortingen, zoals "koop 3 of meer, bespaar 15 procent."
• Buy X Get Y en BOGO logica, inclusief herhalende lagen zoals "koop 6 krijg 2, koop 9 krijg 3."
• Expliciete stacking en combinatieregels tussen aanbiedingen.
• Geplande start, einde en onmiddellijke pauze in een campagne.

Wat een no-code korting-app niet kan doen is even belangrijk duidelijk zeggen, omdat anders aannemen hoe migraties stil mislukken:

• Willekeurige aangepaste code. Als je Script een maatwerk prijsformule of een eenmalige voorwaarde voerde uit die niet tot een regel aansluit die enig builder blootstelt, kan geen korting-app het uitdrukken. Die logica heeft nog steeds een developer nodig om een aangepaste Function te schrijven.
• Verzend- en betalingsaanpassingen. Dit zijn aparte Function-typen (delivery en payment). Een korting-alleen app bereikt ze niet. Een developer migreert die onafhankelijk.
• Alles buiten configuratie voor een op regels gebaseerde korting. Als het niet fundamenteel "voorwaarden in, korting uit," was, is een configuratiescherm de verkeerde vorm ervan.

De eerlijke test is eenvoudig: schrijf op, in een zin, wat elk onderdeel van je oude Script deed. Als de zin een regel over kortingen is, een no-code app is een sterke kandidaat. Als het een formule, verzendverandering, betalingsverandering of iets is wat je niet als regel kunt formuleren, begroting voor een developer op dat onderdeel.

Voer deze migratie betrouwbaar uit met Stackable

Als de kortingslogica van je Script op regels was gebaseerd, lagen, BOGO, stacking en planning, Stackable herbouwt juist dat oppervlak op native Shopify Functions zonder code, en het is eerlijk over zijn randen.

• Het herbouwt op regels gebaseerde kortingslogica, inclusief volume- en gestaffelde prijzen, BOGO, expliciete korting stacking, en geplande start, einde en pauze, als configuratie die je in de admin bewerkt in plaats van Ruby die je onderhoudt.
• De berekening voert zich in een Shopify Function uit, dus winkelwagen, checkout en Shop Pay berekenen een identiek totaal. Er is geen thema-versus-checkout drift, wat een gangbare mislukkingsmodus van oudere korting-setups is.
• Een winkelwagensimulator laat je beide een afvuurrende en een niet-afvuurrende winkelwagen uitvoeren voordat je live gaat, dus je vangt een stille misconfiguratie in een voorbeeld in plaats van in een klachtklacht.
• Het is eerlijk over werkingssfeer. Stackable voert geen willekeurige aangepaste code uit, en het raakt verzending (delivery) of betalingsaanpassingen niet aan. Echt maatwerk logica en die twee aparte Function-typen hebben nog steeds een developer nodig.

Installeer Stackable gratis en bouw je kortingsregels opnieuw op Shopify Functions voordat ze je ongemerkt een verkoop kosten, op usestackable.com/pricing. 🚀

Werkgevend voorbeeld: een migratiecontrolelijst die je vandaag kunt volgen

Gebruik deze volgorde om "mijn Script is kapot" in een beheerde migratie te veranderen. De tabel kaart een typische multi-purpose Script toe aan zijn bestemmingen.

Werk vervolgens de stappen in volgorde:

1. Inventariseer het oude Script voordat je iets bouwt

Open de Script Editor terwijl je nog kunt en schrijf een zin per gedrag. Voer Shopify's Scripts aanpassingenrapport uit om te bevestigen dat niets verborgen is. Exporteer de Ruby-bron en sla deze op een veilige plaats op, omdat deze onherstelbaar wordt zodra de editor is stopgezet.

2. Verdeel de inventaris per oppervlak

Sorteer elk gedrag in korting, verzending of betaling. Dit vertelt je onmiddellijk welke onderdelen een no-code korting-app kan nemen en welke onderdelen een developer nodig hebben. Ga niet ervan uit dat één tool alledrie bedekt.

3. Herbouw de op regels gebaseerde kortingsonderdelen zonder code

Voor elk gedrag dat tot "voorwaarden in, korting uit," aansluit, maak het opnieuw in native Shopify kortingen of een Functions-gebaseerde korting-app. Stel combinatieregels expliciet in als aanbiedingen bedoeld zijn om te stapelen.

4. Geef de niet-regel onderdelen aan een developer

Maatwerk formules, delivery aanpassingen en betalingsaanpassingen gaan naar een developer of bureau om als hun eigen Functions te bouwen. Geef hen je geëxporteerde Script-bron als de specificatie.

5. Test elke herbouwde regel beide wegen

Voor elke regel, voer een afvuurrende winkelwagen en een niet-afvuurrende winkelwagen uit. Lees de checkout-samenvatting regel voor regel. Een regel is niet gemigreerd totdat je het hebt zien toepassen en correct weigeren.

6. Verifieer de versnelde checkouts

Voer je afvuurrende winkelwagen via Shop Pay uit. Omdat Functions server-side berekenen, past een correct gebouwde regel identiek toe. Dit is je laatste controle dat niets afhangt van themmacode die wallets overslaan.

AFBEELDINGSPLAATSHOUDER (Afbeelding 3): Test beide richtingen voordat je het vertrouwt

Voorgestelde visual: Een 16:9 split illustratie. Linkerpaneel met het label "Should-fire cart" toont een checkout samenvatting met een groene kortingslijn correct aanwezig. Rechterpaneel met het label "Shouldn't-fire cart" toont een checkout samenvatting met de korting correct afwezig en een groen vinkje. Een middenonderschrift leest "A silent rule never errors - test both." Merkkleur violet en goud, plat vector, geen fotografie.

De streepje

• Shopify Scripts stoppen op 30 juni 2026 met uitvoering en bewerking is al op 15 april 2026 gestopt. Elk Script dat nog steeds in gebruik is, is nu offline.
• Het mislukken is stil. Een Script dat is gestopt, of een gemigreerde regel die niet in een winkelwagen past, genereert nooit een fout en waarschuwt je nooit. Het berekent gewoon volledige prijs.
• Functions zijn de vervanging, server-side in de checkout draaiend, maar het schrijven van een eerste is een developer-taak, en aangepaste Functions zijn een Plus-only pad.
• Een Script wordt vaak tot drie migraties: discount, delivery en payment Functions, elk onafhankelijk ingezet.
• Een no-code Functions-app kan op regels gebaseerde kortingslogica (lagen, BOGO, stacking, planning) herbouwen. Het kan geen willekeurige code, verzending of betalingsaanpassingen doen.
• Houd je oude Script-bron nu. Het wordt onherstelbaar zodra de Script Editor is stopgezet.
• Test elke herbouwde regel met een afvuurrende en een niet-afvuurrende winkelwagen, en lees de checkout samenvatting regel voor regel, inclusief via Shop Pay.

Gerelateerde artikelen

• Migreren weg van Shopify Scripts: het volledige reddingpad, wat zonder code herbouwt en wat nog steeds een developer nodig heeft.
• Hoe korting-stacking in Shopify werkt: waarom native alleen de hoogste korting toepast en hoe aanbiedingen correct combineren.
• Volume kortingen en hoeveelheidsbreuken: herbouw gestaffelde prijzen die hetzelfde product tellen, niet de hele collectie.
• Korting stacking, correct gedaan: de drie per-klasse combinatie-switches, met een live winkelwagen simulator.
• Shopify's 100-product limiet op Buy X Get Y: voer 3-for-2 over een volledige catalogus uit nadat je migreert.
• Stackable prijzen: plannen, de gratis laag en wat elk bevat.