Shopify Scripts slutar att köras 30 juni 2026, och varje anpassad rabatt-, frakt- eller betalningsregel som du byggt i Script Editor slutar att tillämpas på det datumet. Ersättningen är Shopify Functions, som kör din logik på serversidan inuti checkout. Du har tre sätt att komma dit: anställa en utvecklare för att skriva Shopify Functions, betala ett byrå för att göra det, eller återuppbygga regelbaserad rabattlogik i en no-code Functions-app. Det brådskande är att misslyckandet är tyst. Ett Script som slutar att köras, eller en migrerad regel som inte matchar en kundvagn, kastar inte ett fel och meddelar inte dig. Det tar bara upp fullt pris tills en kund klagar.
Den här guiden förklarar vad Shopify Scripts gjorde, varför Shopify drar tillbaka dem, vad Shopify Functions faktiskt är, varför "migrera mitt Script" faktiskt är upp till tre separata migrationer, tystnadsfallgriften och exakt hur du testar omkring den, vad en no-code app kan och inte kan täcka, och en ärlig uppdelning av när du fortfarande behöver en utvecklare.
Vad händer med Shopify Scripts, och när?
Shopify Scripts phasing ut. Enligt Shopify:s utvecklardokumentation, "Shopify Scripts kommer att fasas ut 30 juni 2026. Alla befintliga Shopify Scripts slutar att fungera efter detta datum." Det finns två datum som spelar roll, och det första har redan gått:
- 15 april 2026: redigering och publicering av nya Shopify Scripts är inte längre möjligt. Enligt Shopify:s utvecklingslogg, efter detta datum kan du inte skapa eller ändra ett Script alls.
- 30 juni 2026: all Shopify Scripts slutar helt att köras. Vad som helst rabatt-, frakt- eller betalningslogik som bor i ett Script slutar helt enkelt att köras.
Om din butik fortfarande förlitade sig på ett Script 1 juli 2026 är den logiken redan offline när du läser detta. Anpassningarna gav inte ett fel eller återgick till ett säkert standard. De blev tysta. Det är det enskilt viktigaste att förstå om denna deadline: det är inte ett högt fel som du märker från en instrumentpanelsvarning. Det är en frånvaro.
Shopify levererar också ett verktyg för att hjälpa dig att begränsa arbetet. Shopify Scripts-anpassningsrapporten hjälper dig identifiera vilka av dina nuvarande anpassningar som kan övergå till Shopify Functions eller offentliga appar. Om du inte har kört det är det steg ett.
BILDPLATSHÅLLARE (Bild 1): Tidslinjningen för Shopify Scripts-nedläggningen
Föreslagen visuell: En ren 16:9 horisontell tidslinje på en vit bakgrund med tre milstolpemarkeringar i violett och djup guld. Markering ett, "15 april 2026 - redigering slutar" i guld. Markering två, "30 juni 2026 - Shopify Scripts slutar att köras" i violett med en liten röd "tyst"-tagg. En släpande pil märkt "Shopify Functions" fortsätter förbi den sista markeringen. Platt, minimalist, sans-serif-etiketter, ingen fotografi.
Vad gjorde Shopify Scripts, och varför drar Shopify tillbaka dem?
Shopify Scripts var små Ruby-program som kördes i Script Editor-appen och anpassade tre delar av köpflödet: kundvagn- och radpostrabatter, frakthastigheter och betalningsmetoder. En handlare på Shopify Plus kunde skriva ett Script som gav en tiprissättning, dolde ett fracktalternativ för vissa adresser, eller omsorterade betalningsmetoder vid checkout. Shopify Scripts var kraftfulla preciserade de var godtycklig kod: om du kunde uttrycka det i Ruby kunde du göra det.
Shopify ersätter dem med Shopify Functions. Enligt migreringsdokumentationen, "Med Shopify Functions hanteras dessa anpassningar nu genom dedikerade Function-API:er som erbjuder bättre prestanda och flexibilitet." Shopify Functions körs på Shopify:s egen infrastruktur inuti checkout-pipelinen, vilket gör dem snabbare och mer skalbara än den äldre Shopify Scripts-modellen, och det innebär att samma logik gäller oavsett om en köpare checkar ut på kundvagnssidan, checkout-sidan eller en accelererad plånbok som Shop Pay.
Avvägningen är att Shopify Functions inte är en textbox du klistrar in Ruby i. De är utvecklarartefakter: du scaffoldar dem med Shopify CLI, skriver logiken i Rust eller JavaScript, definierar en GraphQL-indatafråga och distribuerar dem genom en app. Den skiftet, från "handlaren skriver ett Script" till "utvecklare levererar en Shopify Function," är hela anledningen till att denna migrering är ett projekt och inte en kryssruta.
Vad är Shopify Functions, och varför behöver de vanligtvis en utvecklare?
Shopify Functions låter dig utöka eller ersätta delar av Shopify:s backend-logik med anpassad kod som körs under checkout. Det finns dedikerade Function-API:er för de saker som Shopify Scripts brukade göra, inklusive ett Discount Function API, ett Delivery (Shipping) Customization API och ett Payment Customization API.
Två egenskaper av Shopify Functions spelar roll för din migreringsplan.
Shopify Functions körs på serversidan, en gång
En Shopify Function körs inuti Shopify:s checkout, inte i ditt tema. Det är en genuin uppgradering jämfört med rabattmetoder som beräknar ett totalt värde i tema JavaScript på kundvagnssidan och sedan är oense om vad checkout debiterar. Eftersom Shopify Function är den enda sanningen, är kundvagnsförhandsvisningen och den slutliga debiteringen samma beräkning. Det är också varför en korrekt byggd Shopify Function tillämpas identiskt över Shop Pay, Apple Pay och Google Pay, som hoppar över kundvagnssidan helt.
Shopify Functions är byggda, inte konfigurerade, som standard
Att skriva en Shopify Function från början är en utvecklaruppgift. Du behöver Shopify CLI, en språkverktygkedja och bekantskap med Shopify Function:s indatafråga och resultattform. Det finns en nyans värt att veta om planens tillgänglighet: enligt Shopify:s dokumentation om Shopify Functions-tillgänglighet, "Butiker på vilken plan som helst kan använda offentliga appar som distribueras genom Shopify App Store och innehåller Shopify Functions. Endast butiker på en Shopify Plus-plan kan använda anpassade appar som innehåller Shopify Function-API:er." I klartext: en offentlig app från App Store kan ta Shopify Functions till vilken plan som helst, men en skräddarsydd, anpassad Shopify Function är en Plus-only-väg. Det är den skillnaden som gör en no-code Functions-app attraktiv för icke-Plus-handlare som brukade förlita sig på en utvecklare.
Det goda nyheterna är att när en Shopify Function väl är distribuerad inuti en app konfigurerar handlaren den från administratören utan att röra kod. Som Shopify sa det när Shopify Functions lanserades, "handlare slutanvändare behöver aldrig röra en kodrad när de ändrar sina anpassningar." Koden är skriven en gång; inställningarna bor i administratören.
Varför är "migrera mitt Script" faktiskt tre separata migrationer?
Här är detaljen som förvånar människor, och den kommer direkt från hur handlare beskriver arbetet på Shopify:s gemenskapsforum. En enda Script-fil kunde röra rabatter, frakt och betalningslogik allt på en gång. Shopify Functions delar det medvetet upp i separata, oberoende Function-typer.
- Rabattlogik (tiprissättning, BOGO, order- och produktrabatter, staplingssregler) mappar till Discount Function API. Shopify:s enhetliga Discount Function API kan tillämpa besparingar över alla tre rabattklasser, produkt, order och frakt, från en enda funktion.
- Frakt- och leveranslogik (omnamning, omsortering eller dölj leveransalternativ) mappar till Delivery Customization Function API, en helt separat funktion.
- Betalningslogik (omnamning, omsortering eller dölj betalningsmetoder) mappar till Payment Customization Function API, en tredje separat funktion.
Så meningen "Jag behöver migrera mitt Script" betyder ofta migrering av upp till tre olika saker, konfigurerade och distribuerade oberoende. En no-code rabatt-app kan återuppbygga den första hinken. Det når inte frakt- och betalningshinkarna, vilket är exakt varför du måste inventera ditt gamla Script innan du antar att något enskilt verktyg täcker det. Dela upp arbetet efter yta först, sedan välj en väg för varje yta.
BILDPLATSHÅLLARE (Bild 2): Ett Shopify Script blir tre Shopify Functions
Föreslagen visuell: Ett 16:9-diagram. Till vänster, en enda märkt ruta "Ett Shopify Script (Ruby)" i skiffer. Tre pilar sprids ut till höger till tre separata rutor: "Discount Function" i violett, "Delivery Function" i guld, "Payment Function" i skiffer-blå, var och en med en liten "distribuerad oberoende" bildtext. Rent platt vektor, varumärkesfarger violett och guld, ingen fotografi.
Tystnadsfallrisken och hur man testar för den
Det här är delen som kostar handlare riktiga pengar, och det förtjänar sin egen sektion eftersom det gäller både deadline själv och varje regel du bygger om.
En Shopify Function är antingen välformad och körs, eller så är den felkonfigurerad och tyst. Det finns inget synligt mellantillstånd. En Shopify Function vars villkor inte matchar en given kundvagn körs inte, kastar inte ett fel och meddelar inte dig. Det är designat: samma tystnad du får från en Shopify Function som fungerar korrekt (det gjorde korrekt ingenting för en kundvagn som inte borde kvalificeras) är tystnaden du får från en Shopify Function som är bruten (ett stavfel i en tröskel, en regel begränsad till fel samling, en nivå som aldrig utlöses).
Handlare som arbetar igenom denna migrering beskriver samma upplevelse på Shopify:s gemenskapsforum: en regel slutar tyst att tillämpa en rabatt, och handlaren hittar bara ut eftersom en kund klagar på att debiteras fullt pris. Inget fel, ingen varning, ingenting i orderloggarna. Butiken hade körts på en bruten inställning i flera veckor innan någon märkte.
Det enda tillförlitliga försvaret är att testa båda riktningarna innan du litar på en regel live:
- Bygg en kundvagn som bör utlösa. Sätt ihop en riktig kundvagn som uppfyller alla villkor för regeln, lägg en utkast- eller testorder och läs checkout-sammanfattningen rad för rad. Bekräfta att den exakta rabatten du förväntar är närvarande, till det belopp du förväntar.
- Bygg en kundvagn som inte bör utlösa. Sätt ihop en kundvagn som medvetet inte uppfyller villkoren, till exempel en artikel under din kvantitetströskel, och bekräfta att rabatten korrekt förblir av.
En Shopify Function som utlöses när den inte bör är lika kostsam som en som tyst aldrig körs. Du är inte klar med testning tills du har sett regeln både tillämpa och korrekt avvisa. Kör kundvagnen som bör utlösa genom Shop Pay också, så du bekräftar att den accelererade vägen är överens med standard checkout.
Ett till bevarandesteg medan du är här: behåll din gamla Script-källkod nu. När Script Editor helt dras tillbaka blir dess lagrad kod oåterkallelig från Shopify. Exportera eller kopiera din Script-källkod idag, även om du inte är redo att bygga om den ännu, så att du har en referens för vad som helst som ersätter den.
Kan en no-code app migrera mina Shopify Scripts? Vad den täcker och vad den inte gör
För rabattytan specifikt kan en no-code Functions-app absorbera en stor andel av vad handlare brukade använda Shopify Scripts för. Om din Script-logik reduceras till regler, det vill säga "när kundvagnen ser ut som X, tillämpa rabatt Y", kan en konfigurationsstyrd app vanligtvis bygga om den utan en utvecklare. Det täcker mycket gemensamt område:
- Tiprissättning och volymrabatter, såsom "köp 3 eller fler, spara 15 procent."
- Köp X Få Y och BOGO-logik, inklusive upprepad nivåer som "köp 6 få 2, köp 9 få 3."
- Explicit stacking och kombinationsregler mellan erbjudanden.
- Schemalagd start, slut och omedelbar paus på en kampanj.
Vad en no-code rabatt-app inte kan göra är lika viktigt att säga tydligt, eftersom antar annat är hur migrationer misslyckas tyst:
- Godtycklig anpassad kod. Om ditt Script körde en skräddarsydd prisformel eller ett engångstillstånd som inte reduceras till en regel någon byggare exponerar, kan ingen rabatt-app uttrycka det. Den logiken behöver fortfarande en utvecklare för att skriva en anpassad Shopify Function.
- Frakt- och betalningsanpassningar. De är separata Function-typer (leverans och betalning). En rabatt-only-app når dem inte. En utvecklare migrerar dem oberoende.
- Vad som helst utanför en regelbaserad rabattkonfiguration. Om det inte grundläggande var "villkor in, rabatt ut," är en konfigurationsskärm fel form för det.
Det ärliga testet är enkelt: skriv ner, i en mening, vad varje del av ditt gamla Script gjorde. Om meningen är en regel om rabatter är en no-code app en stark kandidat. Om det är en formel, en frakt-ändring, en betalningsändring eller något du inte kan frasen som en regel, budgetera för en utvecklare på den delen.
Kör denna migrering på ett tillförlitligt sätt med Stackable
Om din Script:s rabattlogik var regelbaserad, nivåer, BOGO, stacking och schemaläggning, Stackable bygger om exakt den ytan på interna Shopify Functions utan kod, och den är ärlig om sina gränser.
- Det bygger om regelbaserad rabattlogik, inklusive volym- och tiprissättning, BOGO, explicit rabatt stacking, och schemalagd start, slut och paus, som konfiguration du redigerar i administratören snarare än Ruby du underhåller.
- Matematiken körs inuti en Shopify Function, så kundvagn, checkout och Shop Pay beräknar en identisk total. Det finns ingen tema-kontra-checkout-drift, vilket är ett vanligt felläge för äldre rabattkonfigurationer.
- En kundvagnssimulator låter dig köra både en kundvagn som bör utlösa och en som inte bör utlösa innan du går live, så du fångar en tyst felkonfiguration i en förhandsgranskning istället för i ett kundklagomål.
- Det är ärligt om omfattning. Stackable kör inte godtycklig anpassad kod, och det rör inte frakt- (leverans) eller betalningsanpassningar. Genuint skräddarsydd logik och de två separata Function-typerna behöver fortfarande en utvecklare.
Installera Stackable gratis och bygg om din regelbaserade rabattlogik på Shopify Functions innan den tyst kostar dig en försäljning, på usestackable.com/pricing. 🚀
Arbetande exempel: en migreringschecklista du kan följa idag
Använd denna sekvens för att förvandla "mitt Script är bruten" till en kontrollerad migrering. Tabellen mappar ett typiskt flerändamål Script till dess destinationer.
Arbeta sedan stegen i ordning:
1. Inventera det gamla Scriptet innan du bygger något
Öppna Script Editor medan du fortfarande kan och skriv en mening per beteende. Kör Shopify:s Scripts-anpassningsrapport för att bekräfta att ingenting gömmer sig. Exportera Ruby-källkoden och lagra den någon säker plats, eftersom den blir oåterkallelig när redigeraren dras tillbaka.
2. Dela upp lagret efter yta
Sortera varje beteende i rabatt, frakt eller betalning. Detta säger dig omedelbar vilka bitar en no-code rabatt-app kan ta och vilka bitar som behöver en utvecklare. Anta inte att ett verktyg täcker alla tre.
3. Bygg om de regelbaserade rabattbitarna utan kod
För varje beteende som reduceras till "villkor in, rabatt ut," återskapa det i interna Shopify-rabatter eller en Functions-baserad rabatt-app. Ställ kombinationsregler explicit om erbjudanden är avsedda att staplas.
4. Lämna de icke-regelbaserade bitarna till en utvecklare
Skräddarsydda formler, leveransanpassningar och betalningsanpassningar går till en utvecklare eller byrå för att bygga som sina egna Shopify Functions. Ge dem din exporterade Script-källkod som specifikationen.
5. Testa varje återuppbyggd regel båda sätten
För varje regel, kör en kundvagn som bör utlösa och en som inte bör utlösa. Läs checkout-sammanfattningen rad för rad. En regel är inte migrerad tills du har sett den både tillämpa och korrekt avvisa.
6. Verifiera de accelererade kassor
Kör din kundvagn som bör utlösa genom Shop Pay. Eftersom Shopify Functions beräknas på serversidan tillämpas en korrekt byggd regel identiskt. Det här är din sista kontroll att ingenting beror på temakod som plånböcker hoppar över.
BILDPLATSHÅLLARE (Bild 3): Testa båda riktningarna innan du litar på det
Föreslagen visuell: En 16:9 delad illustration. Vänster panel märkt "Kundvagn som bör utlösa" visar en checkout-sammanfattning med en grön rabattrad korrekt närvarande. Höger panel märkt "Kundvagn som inte bör utlösa" visar en checkout-sammanfattning med rabatten korrekt frånvarande och en grön bockmark. En centerbeskrivning lyder "En tyst regel kastar aldrig ett fel - testa båda." Varumärkesfarger violett och guld, platt vektor, ingen fotografi.
Slutsatsen
- Shopify Scripts slutar att köras 30 juni 2026, och redigering slutade redan 15 april 2026. Alla Shopify Scripts som fortfarande är i bruk är nu offline.
- Misslyckandet är tyst. Ett Script som slutade, eller en migrerad regel som inte matchar en kundvagn, kastar aldrig ett fel och meddelar aldrig dig. Det tar bara upp fullt pris.
- Shopify Functions är ersättningen, körs på serversidan inuti checkout, men att skriva en från början är en utvecklaruppgift, och anpassade Shopify Functions är en Plus-only-väg.
- Ett Script blir ofta tre migrationer: rabatt-, leverans- och betalning Shopify Functions, var och en distribuerad oberoende.
- En no-code Functions-app kan bygga om regelbaserad rabattlogik (nivåer, BOGO, stacking, schemaläggning). Det kan inte göra godtycklig kod, frakt eller betalningsanpassningar.
- Behåll din gamla Script-källkod nu. Den blir oåterkallelig när Script Editor dras tillbaka.
- Testa varje återuppbyggd regel med en kundvagn som bör utlösa och en som inte bör utlösa, och läs checkout-sammanfattningen rad för rad, inklusive genom Shop Pay.
Relaterade artiklar
- Migrera från Shopify Scripts: den fulla räddningsvägen, vad som bygger utan kod, och vad som fortfarande behöver en utvecklare.
- Hur rabatt stacking fungerar i Shopify: varför interna bara tillämpar högsta rabatt, och hur man kombinerar erbjudanden korrekt.
- Volymrabatter och kvantitetsbrytningar: bygga om tiprissättning som räknar samma produkt, inte hela samlingen.
- Rabatt stacking, gjort rätt: de tre per-klass kombinationsbrytare, med en live kundvagnssimulator.
- Shopify:s 100-produktgräns på Köp X Få Y: kör 3-för-2 över en full katalog efter du migrerar.
- Stackable prissättning: planer, den fria nivån och vad var och en inkluderar.
