Shopify Scripts ha smesso di funzionare il 30 giugno 2026. Ecco cosa fare adesso.
Se il tuo negozio aveva uno Script personalizzato per sconti, BOGO o bundle, ha smesso di essere eseguito il 30 giugno 2026, in modo silenzioso. Nessun errore, nessun avviso, nulla nei log. Ecco esattamente cosa è successo, cosa comporta davvero la migrazione a Shopify Functions e una risposta onesta su cosa può ricostruire Stackable per te.
- Shopify Scripts ha smesso di essere eseguito il 30 giugno 2026 per tutti i negozi che lo utilizzavano ancora.
- Qualsiasi logica personalizzata di sconto, BOGO o bundle contenuta in uno Script ha smesso di essere applicata da quella data.
- L'interruzione è silenziosa per progettazione: una Shopify Function le cui condizioni non corrispondono a un determinato carrello semplicemente non si attiva. Non genera un errore e Shopify non La avvisa.
I merchant che affrontano questa migrazione descrivono lo stesso rischio sui forum della community Shopify:
“Il mio vecchio Script ha smesso silenziosamente di applicare uno sconto e me ne sono accorto solo perché un cliente si è lamentato di aver pagato il prezzo pieno. Non c'era alcun errore, nessun avviso, nulla nei log degli ordini. Avevo un'impostazione non funzionante da settimane prima di accorgermene.”
Questo è il rischio principale del passaggio da Scripts a Functions: una Function è ben formata e in esecuzione, oppure è configurata male e resta silenziosa. Non esiste uno stato intermedio visibile, quindi una condizione non corrispondente, un errore di battitura in una soglia, una regola applicata alla collezione sbagliata, producono esattamente lo stesso silenzio di una Function che funziona correttamente. L'unico modo per accorgersene è testare deliberatamente entrambe le direzioni prima di considerarla affidabile in produzione.
Quattro cose da sapere prima di iniziare
Uno Script spesso diventa tre migrazioni
Un singolo file Script poteva toccare contemporaneamente la logica degli sconti, le tariffe di spedizione e la personalizzazione dei pagamenti. Le Function suddividono tutto questo in tipi di Function separati, sconto, consegna e pagamento, ciascuno configurato e distribuito in modo indipendente. Migrare “il mio Script” di solito significa migrare fino a tre cose diverse, ed è la lamentela che i commercianti sollevano più spesso a proposito di questo passaggio.
I builder no-code di solito coprono solo sconti e BOGO
Se il Suo Script toccava anche le tariffe di spedizione o i metodi di pagamento, un builder no-code per Function di sconto, Stackable incluso, non arriva a coprire quegli ambiti. Le personalizzazioni di consegna e pagamento richiedono che uno sviluppatore scriva direttamente quella Function.
Conservi subito il codice sorgente del Suo vecchio Script
Una volta che lo Script Editor sarà completamente dismesso, il codice memorizzato al suo interno diventerà irrecuperabile. Esporti o copi oggi stesso il codice sorgente del Suo vecchio Script, anche se non è ancora pronto a migrare, così avrà un riferimento per qualsiasi cosa lo sostituisca.
Testi un carrello che deve attivarsi e uno che non deve farlo
Prima di considerare affidabile una nuova Function, crei due carrelli di prova: uno che deve attivarla e uno che deliberatamente non deve farlo. Una Function che si attiva quando non dovrebbe è tanto costosa quanto una che non si attiva mai in silenzio.
Le tre cose che spiegano ogni decisione di migrazione
Quasi ogni discussione su cosa può essere ricostruito e cosa no si riduce a tre fatti: gli Script esistevano in tre tipi con un solo slot ciascuno, le Function suddividono questi tre tipi in quattro API diverse, e una Function deve dichiarare in anticipo ogni dato che leggerà prima di essere eseguita. Una volta chiariti questi punti, il resto di questa pagina è aritmetica.
Shopify Scripts esisteva in tre tipi
Lo Script Editor Le chiedeva di scegliere un tipo prima di scrivere anche solo una riga di Ruby, e il tipo determinava cosa il Suo codice poteva toccare.
Script riga carrello
Quelli che modificavano il costo dei prodotti. Scorrevano il carrello riga per riga e ne rifissavano il prezzo, ed è lì che viveva ogni sconto a livelli, BOGO, prezzo bundle e ribasso.
Script di spedizione
Quelli che agivano sulle tariffe di consegna. Potevano scontare una tariffa, nasconderla, rinominarla o riordinare l’elenco visto dal cliente. Solo la prima di queste quattro azioni è uno sconto.
Script di pagamento
Quelli che agivano sui metodi di pagamento, con gli stessi quattro verbi: nascondere un metodo, rinominarlo, riordinare l’elenco o, in pratica, per lo più nasconderlo per determinati carrelli.
Ecco ora il vincolo che ha plasmato ogni Script reale che leggerà mai: poteva essere pubblicato un solo Script per ciascun tipo alla volta. Un solo slot line item per l’intero negozio. Quindi un commerciante che gestiva uno sconto VIP, un prezzo di liquidazione, una soglia di spesa e una promozione stagionale non scriveva quattro Script. Scriveva un unico file con tutti e quattro uniti insieme, di solito con una regola artigianale del tipo “tieni il prezzo migliore” in fondo. Ecco perché gli Script reali sembrano intricati. Non sono una regola scritta male, sono diverse regole a cui non è mai stato permesso di essere separate.
Veda uno Script reale con quattro campagne unite in un unico fileQuattro API di Function le hanno sostituite
Shopify non ha sostituito gli Script con un’unica cosa. Li ha sostituiti con quattro, suddivisi in base a cosa il codice può modificare piuttosto che a dove nel carrello viene eseguito.
Discount Function API
Sconto in denaro. Sconti prodotto, sconti ordine e sconti sulla spedizione vivono tutti qui ora, in un’unica API unificata. Se il Suo Script modificava un prezzo, è qui che va.
La documentazione di ShopifyDelivery Customization API
Nascondere, rinominare e riordinare le opzioni di consegna. Shopify precisa esplicitamente che questa è l’unica API che può personalizzare le opzioni di consegna al checkout, quindi un’app di sconti non può raggiungerla, comunque sia costruita.
La documentazione di ShopifyPayment Customization API
Nascondere, rinominare e riordinare i metodi di pagamento, oltre alle condizioni di pagamento e alla necessità o meno che un ordine venga revisionato. La metà “pagamento” del vecchio Script Editor, in un unico posto.
La documentazione di ShopifyCart and Checkout Validation API
Bloccare il checkout con un messaggio. Qui rientrano i limiti di acquisto, i controlli sull’età e le regole di ordine minimo. Restituisce errori, quindi può fermare un ordine ma non può modificarlo silenziosamente.
La documentazione di ShopifyStackable è un’app Discount Function, e solo questo. Costruiamo funzioni di sconto, quindi possiamo ricostruire qualsiasi cosa il Suo Script facesse a un prezzo, compresi gli sconti sulla spedizione. Non offriamo una personalizzazione di consegna, una personalizzazione di pagamento o una funzione di validazione, quindi nascondere una tariffa di spedizione, rinominare un metodo di pagamento o limitare una quantità d’acquisto non è qualcosa che rifiutiamo per non averlo costruito. È un tipo di app diverso.
Metta insieme le due metà e ottiene la frase che i commercianti scoprono a proprie spese: uno Script diventa spesso tre migrazioni. Uno Script di riga carrello che nascondeva anche una tariffa di spedizione e bloccava un metodo di pagamento diventa ora una funzione di sconto, una personalizzazione di consegna e una personalizzazione di pagamento, scritte e distribuite separatamente. Preferiamo che lo legga qui piuttosto che lo scopra dopo la ricostruzione.
Veda uno Script di spedizione che non è affatto uno scontoLe Function sono pure, e ogni campo è dichiarato in anticipo
Uno Script veniva eseguito come normale Ruby su qualsiasi cosa il carrello contenesse in quel momento. Una Function viene eseguita in sandbox, e Shopify garantisce che non ha nessuno dei seguenti elementi:
- Nessuna rete. Una Function non può chiamare il Suo ERP, il Suo fornitore di loyalty o qualsiasi altro servizio mentre un cliente sta effettuando il checkout.
- Nessun orologio. Una Function non può chiedere che ore sono, quindi “metà prezzo il martedì” deve diventare uno sconto programmato invece di una condizione dentro il codice.
- Nessuna casualità. Nulla può tirare un dado per un cliente su dieci.
- Nessun filesystem, e nessuna possibilità di accedere a un campo che non ha richiesto. Ogni dato letto da una Function deve essere indicato in anticipo, in una query di input, e quella query ha un tetto di costo rigido stabilito da Shopify.
Quest’ultima regola è quella che costa di più ai commercianti, ed è importante essere precisi su chi ne paga il prezzo. Non è che Shopify nasconda i dati. La nostra query di checkout è già al costo massimo consentito da Shopify, quindi chiedere un campo in più significa rinunciarne a un altro. Nove delle tipologie di Script che oggi rifiutiamo sono rifiutate esattamente per questo motivo e per nessun altro, tra cui saltare gli articoli già scontati, leggere una provincia o un codice postale, e verificare quanti ordini un cliente ha già effettuato. Shopify offre tutte queste possibilità. Non abbiamo ancora fatto spazio per loro. Questo è un nostro limite, e definirlo un limite della piattaforma sarebbe una bugia.
Solo due rifiuti in tutta la libreria sono limiti autentici di Shopify, ed entrambi derivano dallo stesso fatto: ogni funzione di sconto su un negozio viene eseguita nello stesso istante e nessuna può vedere cosa hanno fatto le altre. Quindi uno Script che chiedeva “questo articolo è già stato scontato?” o misurava una soglia su un subtotale già ridotto non può essere ricostruito né da noi né da nessun altro, oggi, a nessun prezzo. Tutto il resto del nostro elenco di rifiuti è un limite nostro da correggere, e lo etichettiamo così nell’app e in ogni pagina della libreria.
Legga i due rifiuti che sono davvero limiti di ShopifyFissare un prezzo non è la stessa cosa che togliere denaro
Se legge una sola cosa prima di ricostruire uno Script a mano, legga questa. Due file possono chiamare lo stesso metodo, con la stessa costante e lo stesso messaggio, e significare cose opposte. Entrambi i casi seguenti sono reali, entrambi sono comuni, e la differenza tra loro è un segno di sottrazione.
Questo FISSA il prezzo a $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.cartSu un articolo da $79.00, lo sconto è di $69.01 e il cliente paga $9.99. Ricostruito come un’offerta a volume il cui premio è un prezzo fisso, conteggiato per variante e ripetuto, così ogni unità viene riprezzata.
L’esempio pratico, con il carrello e le impostazioniQuesto TOGLIE $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.cartSullo stesso articolo da $79.00, lo sconto è di $9.99 e il cliente paga $69.01. Ricostruito come un’offerta a volume il cui premio è un importo di sconto su ogni unità, conteggiato per prodotto e attivato una sola volta.
L’esempio pratico, con il carrello e le impostazioniStesso metodo, stesso $9.99, stessa formulazione nel messaggio. L’unico indizio è che il secondo file sottrae da `line_item.line_price` prima di assegnare. Se lo legge nel verso sbagliato su un articolo da $79.00, sbaglia di $59.02 su una singola unità, in qualunque direzione faccia male. E le due ricostruzioni non differiscono solo nel numero: una conta per variante e si ripete, l’altra conta per prodotto e si attiva una sola volta, quindi divergono anche non appena il cliente ne acquista due.
Questo è il tipo di errore che i consigli abituali non riescono a individuare. Un’offerta ricostruita che legge il file al contrario si attiva comunque su un carrello che dovrebbe attivarla e resta comunque silenziosa su un carrello che non dovrebbe, quindi testare entrambe le direzioni la lascia passare. Scripts Rescue risolve il problema ponendo una domanda diversa: prima di lasciarLa pubblicare, vuole l’importo che il Suo vecchio Script addebitava per un carrello che può ancora riprodurre, e lo confronta con quanto calcola l’offerta ricostruita. Un centesimo di differenza e la pubblicazione resta bloccata. Tra le cinque app che oggi vendono la migrazione degli Script, la nostra ricerca non ne ha trovata nessuna che chieda a un commerciante di dimostrare la cifra.
Cosa diventa ogni frammento di Ruby in una campagna
Una ricostruzione sbaglia sempre negli stessi pochi punti, e quasi mai sono quelli ovvi. Il premio di solito è facile. Il conteggio e la ricorrenza sono dove il denaro si sposta silenziosamente, perché uno Script li esprime in aritmetica e una campagna li esprime in un’impostazione.
| Nel Suo Script | In una campagna | Dove si sbaglia |
|---|---|---|
change_line_price(PRICE * qty) | Un’offerta a volume con premio prezzo fisso. | Assegnazione, non sottrazione. È la trappola descritta sopra. Il prezzo unitario diventa la costante, così un articolo da $79 viene venduto a $9.99. |
line_price - (AMOUNT * qty) | Un’offerta a volume con premio importo di sconto su ogni unità. | La sottrazione è tutto il segnale. Stessa costante della riga sopra, un conto completamente diverso. |
line_price * 0.9 | Un premio percentuale del 10. | Il moltiplicatore è ciò che il cliente trattiene, non ciò che risparmia. Digitato direttamente come 90 regala nove decimi del catalogo. |
next unless line_item.quantity >= 3 | Un livello con quantità minima di 3. | I livelli sono inclusivi al limite e si attiva solo il livello più alto soddisfatto. Gli Script che aggiungevano una regola sopra un’altra non hanno un equivalente a offerta singola, e ne serve una per ciascuna. |
line_items.size > 1 | Una quantità minima di 2. | Non è la stessa regola. Qui gli Script contavano righe di carrello separate, le campagne contano le unità, quindi una riga che contiene due dello stesso articolo ora si qualifica dove lo Script lo ignorava. |
sets = quantity / (BUY + GET) | Buy X Get Y con le unità gratuite conteggiate come aggiuntive. | Dividere solo per BUY rende invece le unità gratuite inclusive. Su nove unità di un buy 3 get 1, sono due gratis oppure tre gratis. Un carattere di differenza, metà in più regalata. |
customer.tags.include?("vip") | Idoneità cliente delimitata da tag. | Shopify confronta i tag in modo esatto, maiuscole incluse, mentre molti dialetti di Script mettevano prima tutto in minuscolo su entrambi i lati. Controlli l’ortografia prima di pubblicare, non dopo. |
product.tags / product_type / vendor | Ambito di destinazione impostato su tag, tipi di prodotto o fornitori. | Una riga di ambito mancata è l’errore più costoso di questa tabella, perché trasforma “20% di sconto sul tag sale” in 20% di sconto su tutto ciò che vende. |
Una cosa che non troverà in questa tabella sono le collezioni. Uno Script poteva leggere i tag, il tipo e il fornitore di un prodotto ma mai le sue collezioni, quindi qualsiasi Ruby che dichiarava di controllare una collezione non stava facendo ciò che sembrava fare. Le campagne possono avere come target le collezioni; il Suo vecchio Script non poteva.
Cerchi il Suo Script invece di ragionarci sopra
Ogni tipologia di Script che abbiamo catalogato ha una propria pagina: il Ruby originale, cosa viene riconosciuto come, la configurazione esatta in cui si trasforma, un carrello del nostro demo store pubblico con lo sconto calcolato dal motore reale, e il carrello che deve restare silenzioso. I rifiuti sono descritti allo stesso modo, ciascuno etichettato come limite di Shopify, nostro limite, o compito per un tipo di app diverso. È il riferimento che avremmo voluto avere all’inizio, quindi è pubblico.
- Forme di Script
- 42
- Ricostruiti oggi
- 38
- Rifiutati, con motivo
- 21
Una risposta onesta sull'ambito
Stackable ricostruisce la logica di sconto basata su regole con Shopify Functions native. Non esegue codice personalizzato arbitrario.
Stackable ricostruisce questo
- Sconti a livelli / per volume (es. "acquista 3+, risparmia il 15%")
- Logica Buy X Get Y e BOGO, inclusi livelli ripetuti
- Regole esplicite di cumulo sconti tra le offerte
- Avvio e fine programmati, e pausa istantanea per qualsiasi campagna
Le servirà comunque uno sviluppatore per questo
- Codice personalizzato arbitrario eseguito dal Suo vecchio Script (formule di prezzo su misura, condizioni una tantum che nessun builder copre)
- Personalizzazioni di spedizione / consegna (un tipo di Function separato)
- Personalizzazioni di pagamento (un tipo di Function separato)
- Qualsiasi cosa non riconducibile a una configurazione di sconto basata su regole
Se il Suo vecchio Script faceva qualcosa presente in questo elenco, un builder senza codice, Stackable incluso, non può raggiungerlo. Si tratta di una Function scritta da uno sviluppatore, non di una schermata di configurazione.
Domande frequenti
I miei vecchi Script sono andati persi?
Scripts ha smesso di essere eseguito il 30 giugno 2026, ma questo non coincide necessariamente con il momento in cui il codice sorgente memorizzato nello Script Editor viene eliminato. In ogni caso, esporti o copi subito il codice del Suo vecchio Script: una volta che Shopify dismetterà completamente l'editor, diventerà irrecuperabile.
Riceverò un errore se una Function è configurata male?
No. Una Function le cui condizioni non corrispondono a un carrello semplicemente non si attiva mai, in silenzio, senza errori e senza avvisi. Testi sempre con un carrello che deve attivarla e uno che non deve farlo prima di considerarla affidabile in produzione.
Stackable sostituisce tutto ciò che faceva il mio vecchio Script?
Solo la parte basata su regole: sconti a livelli e per volume, BOGO, cumulo sconti e pianificazione, tutti ricostruiti su Shopify Functions native. Stackable non esegue codice personalizzato arbitrario. Se il Suo Script faceva qualcosa di davvero su misura, come una formula di prezzo personalizzata o una condizione che nessun builder copre, serve comunque uno sviluppatore che scriva direttamente la Function.
E la logica di spedizione o pagamento gestita dal mio Script?
Si tratta di tipi di Function separati (consegna e pagamento) che Stackable non gestisce. Uno sviluppatore deve migrarli in modo indipendente dalla tua logica di sconto.
Su quale piano si trova Scripts Rescue?
Scripts Rescue, lo strumento che legge il Suo vecchio Ruby e lo ricostruisce, si trova sul piano Pro. Stackable stessa è gratuita da installare e il motore di sconto principale, inclusi i livelli per volume, Buy X Get Y, gli obiettivi di spesa, la spedizione gratuita, la programmazione e il simulatore, è gratuito su ogni piano. Il recupero del Ruby in particolare non lo è: si trova insieme al multi-negozio e a Shopify Flow sul piano Pro.
Come faccio a sapere che lo sconto ricostruito addebita lo stesso importo di quello vecchio?
Perché è tenuto a dimostrarlo prima di poter pubblicare. Testare un carrello che deve attivarsi e uno che non deve è il consiglio standard, e non individua l’errore peggiore, cioè un’offerta che si attiva correttamente ma per l’importo sbagliato. Scripts Rescue Le chiede l’importo che il Suo vecchio Script addebitava su un carrello che può ancora riprodurre, lo confronta con quanto calcola l’offerta ricostruita, e mantiene bloccata la pubblicazione finché i due valori non coincidono fino al centesimo. La nostra ricerca sulle cinque app che vendono la migrazione degli Script non ne ha trovata nessuna che lo richieda.
Perché il mio Script sembrava così complicato?
Perché poteva essere pubblicato un solo Script per ciascun tipo alla volta. Un negozio che gestiva quattro promozioni non poteva scrivere quattro Script, quindi scriveva un unico file con tutti e quattro uniti insieme e una regola in fondo che decideva quale vincesse. La maggior parte del Ruby che sembra illeggibile in realtà è composta da diverse regole semplici che condividono uno slot, e ciascuna di solito si ricostruisce in modo pulito da sola.
Dove posso leggere l’approfondimento completo sulla migrazione?
Il nostro primo articolo del blog illustra in modo più dettagliato la dismissione degli Script e il percorso di migrazione, e la libreria di esempi di Script ha una pagina per ogni tipologia di Script con il Ruby originale e la ricostruzione esatta.
Funzionalità correlate
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.
Installi Stackable e ricostruisca i Suoi sconti basati su regole
Scaglioni di volume, BOGO, cumulo e programmazione, in esecuzione su Shopify Functions native fin dal primo giorno.
Scripts Rescue è sul piano Pro. Stackable stessa è gratuita da installare, senza carta richiesta.