Shopify Scripts termina il 30 giugno 2026: come migrare i tuoi sconti senza uno sviluppatore

Shopify Scripts smettono di funzionare il 30 giugno 2026, e ogni regola personalizzata di sconto, spedizione o pagamento che hai creato nell'Editor di Script smette di applicarsi in quella data. La sostituzione è Shopify Functions, che esegue la tua logica lato server all'interno del checkout. Hai tre modi per arrivarci: assumere uno sviluppatore per scrivere Function, pagare un'agenzia per farlo, o ricostruire la logica degli sconti basata su regole in un'app Functions senza codice. La parte urgente è che il fallimento è silenzioso. Uno Script che smette di funzionare, o una regola migrata che non corrisponde a un carrello, non genera un errore e non ti avvisa. Semplicemente addebita il prezzo intero silenziosamente fino a quando un cliente non si lamenta.

Questa guida spiega cosa facevano gli Script, perché Shopify li sta ritirando, cosa sono veramente le Function, perché "migrare il mio Script" è in realtà fino a tre migrazioni separate, la trappola del fallimento silenzioso e esattamente come testarlo, cosa un'app senza codice può e non può coprire, e un'analisi onesta di quando hai ancora bisogno di uno sviluppatore.

Cosa succede a Shopify Scripts e quando?

Shopify Scripts stanno per essere dismessi. Secondo la documentazione degli sviluppatori di Shopify, "Shopify Scripts saranno dismessi il 30 giugno 2026. Tutti gli Script Shopify esistenti smetteranno di funzionare dopo questa data." Ci sono due date importanti, e la prima è già passata:

• 15 aprile 2026: la modifica e la pubblicazione di nuovi Shopify Scripts non è più possibile. Secondo il changelog degli sviluppatori di Shopify, dopo questa data non puoi creare o modificare uno Script affatto.
• 30 giugno 2026: tutti gli Script Shopify smettono di funzionare completamente. Qualsiasi logica di sconto, spedizione o pagamento contenuta in uno Script semplicemente smette di funzionare.

Se il tuo negozio si affidava ancora a uno Script il 1 luglio 2026, quella logica è già offline mentre leggi questo. Le personalizzazioni non hanno generato errori o eseguito il rollback a un'impostazione predefinita sicura. Sono diventate silenziose. Questa è la cosa più importante da capire su questa scadenza: non è un fallimento rumoroso che noterai da un avviso della dashboard. È un'assenza.

Shopify fornisce anche uno strumento per aiutarti a definire l'ambito del lavoro. Il rapporto di personalizzazione di Shopify Scripts ti aiuta a identificare quali delle tue attuali personalizzazioni possono essere trasferite a Function o app pubbliche. Se non l'hai ancora eseguito, questo è il primo passo.

SEGNAPOSTO IMMAGINE (Immagine 1): La cronologia del tramonto degli Script

Visual suggerita: Una cronologia orizzontale pulita 16:9 su uno sfondo bianco con tre marcatori cardine in viola e oro profondo. Marcatore uno, "15 aprile 2026 - la modifica termina" in oro. Marcatore due, "30 giugno 2026 - gli Script smettono di funzionare" in viola con un piccolo tag rosso "silenzioso". Una freccia finale etichettata "Shopify Functions" continua oltre l'ultimo marcatore. Etichette sans-serif pulite e minimaliste, nessuna fotografia.

Cosa facevano Shopify Scripts e perché Shopify li sta ritirando?

Shopify Scripts erano piccoli programmi Ruby che funzionano nell'app Script Editor e personalizzano tre parti del flusso di acquisto: sconti su carrello e articoli di riga, tariffe di spedizione e metodi di pagamento. Un commerciante su Shopify Plus potrebbe scrivere uno Script che fornisca uno sconto a livelli, nasconda un'opzione di spedizione per indirizzi specifici, o riordinare i metodi di pagamento al checkout. Gli Script erano potenti proprio perché erano codice arbitrario: se potevi esprimerlo in Ruby, potevi farlo.

Shopify li sta sostituendo con Shopify Functions. Secondo la documentazione di migrazione, "Con Shopify Functions, queste personalizzazioni sono ora gestite tramite API Function dedicate che offrono migliori prestazioni e flessibilità." Le Function vengono eseguite sull'infrastruttura di Shopify all'interno della pipeline di checkout, il che le rende più veloci e scalabili rispetto al vecchio modello di Script, e significa che la stessa logica si applica se un acquirente esegue il checkout sulla pagina del carrello, sulla pagina di checkout, o su un portafoglio accelerato come Shop Pay.

Il compromesso è che le Function non sono una casella di testo in cui incollare Ruby. Sono artefatti dello sviluppatore: li scaffoldi con Shopify CLI, scrivi la logica in Rust o JavaScript, definisci una query di input GraphQL, e li distribuisci tramite un'app. Questo cambio, da "il commerciante scrive uno Script" a "lo sviluppatore invia una Function", è l'intero motivo per cui questa migrazione è un progetto e non una casella di controllo.

Cosa sono Shopify Functions e perché di solito hanno bisogno di uno sviluppatore?

Shopify Functions ti consente di estendere o sostituire parti della logica backend di Shopify con codice personalizzato che viene eseguito durante il checkout. Ci sono API Function dedicate per le cose che gli Script solevano fare, inclusa un'API Discount Function, un'API Delivery (spedizione) Customization e un'API Payment Customization.

Due proprietà delle Function sono importanti per il tuo piano di migrazione.

Le Function vengono eseguite lato server, una volta

Una Function viene eseguita all'interno del checkout di Shopify, non nel tuo tema. Questo è un vero aggiornamento rispetto ai metodi di sconto che calcolano un totale nel JavaScript del tema sulla pagina del carrello e poi discordano su ciò che il checkout addebita. Poiché la Function è l'unica fonte di verità, l'anteprima del carrello e l'addebito finale sono lo stesso calcolo. Questo è anche il motivo per cui una Function costruita correttamente si applica identicamente su Shop Pay, Apple Pay e Google Pay, che saltano completamente la pagina del carrello.

Le Function sono costruite, non configurate, per impostazione predefinita

Scrivere una Function da zero è un compito dello sviluppatore. Hai bisogno di Shopify CLI, di una toolchain di linguaggio e di familiarità con la query di input della Function e la forma del risultato. C'è una sfumatura che vale la pena conoscere sulla disponibilità del piano: secondo la documentazione sulla disponibilità di Function, "I negozi su qualsiasi piano possono utilizzare app pubbliche distribuite tramite Shopify App Store e che contengono function. Solo i negozi su un piano Shopify Plus possono utilizzare app personalizzate che contengono API Shopify Function." In parole semplici: un'app pubblica dall'App Store può portare le Function a qualsiasi piano, ma una Function costruita su misura è un percorso solo Shopify Plus. Questa distinzione è ciò che rende attraente un'app Function senza codice per i commercianti non-Plus che erano soliti contare su uno sviluppatore.

La buona notizia è che una volta che una Function viene distribuita all'interno di un'app, il commerciante la configura dall'admin senza toccare il codice. Come ha detto Shopify quando le Function sono state lanciate, "gli utenti finali commercianti non devono mai toccare una riga di codice quando modificano le loro personalizzazioni." Il codice viene scritto una volta; le impostazioni vivono nell'admin.

Perché "migrare il mio Script" è in realtà tre migrazioni separate?

Ecco il dettaglio che sorprende le persone, e viene direttamente da come i commercianti descrivono il lavoro nei forum della comunità di Shopify. Un singolo file di Script potrebbe toccare sconti, spedizione e logica di pagamento contemporaneamente. Le Function dividono deliberatamente questo in tipi di Function separati e indipendenti.

• Logica degli sconti (prezzo a livelli, BOGO, sconti su ordini e prodotti, regole di stacking) mappe all'API Discount Function. L'API unified di Shopify Discount Function API può applicare risparmi su tutte e tre le classi di sconto, prodotto, ordine e spedizione, da una singola function.
• Logica di spedizione e consegna (rinominazione, riordinamento o occultamento delle opzioni di consegna) mappe all'API Delivery Customization Function, una function completamente separata.
• Logica di pagamento (rinominazione, riordinamento o occultamento dei metodi di pagamento) mappe all'API Payment Customization Function, una terza function separata.

Quindi la frase "Ho bisogno di migrare il mio Script" spesso significa migrare fino a tre cose diverse, configurate e distribuite in modo indipendente. Un'app di sconto senza codice può ricostruire il primo bucket. Non raggiunge i bucket di spedizione e pagamento, che è esattamente il motivo per cui devi fare un inventario del tuo vecchio Script prima di assumere che un singolo strumento lo copra. Dividi il lavoro per superficie prima, quindi scegli un percorso per ogni superficie.

SEGNAPOSTO IMMAGINE (Immagine 2): Uno Script diventa tre Function

Visual suggerita: Un diagramma 16:9. A sinistra, una singola casella etichettata "Uno Shopify Script (Ruby)" in ardesia. Tre frecce si diffondono a destra per tre caselle separate: "Discount Function" in viola, "Delivery Function" in oro, "Payment Function" in blu-ardesia, ciascuna con una didascalia "distribuito in modo indipendente" piccola. Vettore piatto pulito, colori del marchio viola e oro, nessuna fotografia.

Il pericolo del fallimento silenzioso e come testarlo

Questa è la parte che costa soldi veri ai commercianti, e merita la sua sezione perché si applica sia alla scadenza stessa che a ogni regola che ricostruisci.

Una Shopify Function è o ben formata e in esecuzione, o non configurata correttamente e silenziosa. Non c'è uno stato in mezzo visibile. Una Function le cui condizioni non corrispondono a un determinato carrello non si attiva, non genera errori e non ti avvisa. Questo è progettato così: lo stesso silenzio che ottieni da una Function che funziona correttamente (ha correttamente fatto nulla per un carrello che non dovrebbe qualificarsi) è il silenzio che ottieni da una Function che è rotta (un errore di battitura in una soglia, una regola scoped nella collezione sbagliata, un livello che non si attiva mai).

I commercianti che lavorano attraverso questa migrazione descrivono la stessa esperienza nei forum della comunità di Shopify: una regola silenziosamente smette di applicare uno sconto, e il commerciante lo scopre solo perché un cliente si lamenta di essere stato addebitato al prezzo pieno. Nessun errore, nessun avviso, nulla nei log dell'ordine. Il negozio era stato in esecuzione su una configurazione rotta per settimane prima che chiunque se ne accorgesse.

L'unica difesa affidabile è testare in entrambe le direzioni prima di fidarti di una regola live:

1. Costruisci un carrello che dovrebbe attivarsi. Assembla un carrello reale che soddisfa ogni condizione della regola, effettua un ordine bozza o test, e leggi il riepilogo del checkout riga per riga. Conferma che lo sconto esatto che ti aspetti è presente, all'importo che ti aspetti.
2. Costruisci un carrello che non dovrebbe attivarsi. Assembla un carrello che deliberatamente non si qualifica, ad esempio un articolo al di sotto della tua soglia di quantità, e conferma che lo sconto rimane correttamente disattivato.

Una Function che si attiva quando non dovrebbe è altrettanto costosa di una che silenziosamente non si attiva mai. Non hai finito il test finché non hai visto la regola sia applicarsi che correttamente rifiutarsi. Esegui il carrello che dovrebbe attivarsi anche tramite Shop Pay, così confermi che il percorso accelerato concorda con il checkout standard.

Un passo di conservazione in più mentre sei qui: mantieni la tua vecchia fonte di Script ora. Una volta che lo Script Editor è completamente ritirato, il suo codice memorizzato diventa irrecuperabile da Shopify. Esporta o copia la fonte del tuo Script oggi, anche se non sei ancora pronto per ricostruirla, in modo da avere un riferimento per qualsiasi cosa lo sostituisca.

Un'app senza codice può migrare i miei Script? Cosa copre e cosa non copre

Per la superficie degli sconti specificamente, un'app Function senza codice può assorbire una grande quota di ciò che i commercianti usavano gli Script per. Se la logica del tuo Script si riduce a regole, cioè "quando il carrello ha l'aspetto di X, applica lo sconto Y", un'app basata su configurazione di solito può ricostruirla senza uno sviluppatore. Questo copre un sacco di terreno comune:

• Sconti a livelli e di volume, come "acquista 3 o più, risparmia il 15 percento."
• Buy X Get Y e logica BOGO, inclusi livelli ripetuti come "acquista 6 ricevi 2, acquista 9 ricevi 3."
• Regole di stacking e combinazione esplicite tra offerte.
• Inizio pianificato, fine e pausa istantanea su una campagna.

Ciò che un'app di sconto senza codice non può fare è ugualmente importante da dire chiaramente, perché assumere il contrario è come le migrazioni falliscono silenziosamente:

• Codice personalizzato arbitrario. Se il tuo Script ha eseguito una formula di prezzo personalizzata o una condizione una tantum che non si riduce a una regola che nessun builder espone, nessun'app di sconto può esprimerla. Quella logica ha ancora bisogno di uno sviluppatore per scrivere una Function personalizzata.
• Personalizzazioni di spedizione e pagamento. Questi sono tipi di Function separati (consegna e pagamento). Un'app solo sconto non li raggiunge. Uno sviluppatore li migra in modo indipendente.
• Qualsiasi cosa al di fuori di una configurazione di sconto basata su regole. Se non era fondamentalmente "condizioni in, sconto fuori", una schermata di configurazione è la forma sbagliata per essa.

Il test onesto è semplice: scrivi, in una sola frase, cosa ha fatto ogni pezzo del tuo vecchio Script. Se la frase è una regola su sconti, un'app senza codice è un candidato forte. Se è una formula, un cambio di spedizione, un cambio di pagamento, o qualcosa che non puoi esprimere come regola, budget per uno sviluppatore su quel pezzo.

Esegui questa migrazione in modo affidabile con Stackable

Se la logica degli sconti del tuo Script era basata su regole, livelli, BOGO, stacking e pianificazione, Stackable ricostruisce esattamente quella superficie su Shopify Functions native senza codice, ed è onesto sui suoi bordi.

• Ricostruisce la logica degli sconti basata su regole, inclusi prezzi a livelli e di volume, BOGO, stacking di sconti esplicito, e inizio programmato, fine e pausa, come configurazione che modifichi nell'admin anziché Ruby che mantenessi.
• La matematica viene eseguita all'interno di una Shopify Function, quindi carrello, checkout e Shop Pay calcolano un totale identico. Non c'è varianza tema-versus-checkout, che è una modalità di fallimento comune di setup di sconti più vecchi.
• Un simulatore di carrello ti consente di eseguire sia un carrello che dovrebbe attivarsi che uno che non dovrebbe prima di andare live, quindi catturi una manconfigurzione silenziosa in un'anteprima anziché in una lamentela di un cliente.
• È onesto sull'ambito. Stackable non esegue codice personalizzato arbitrario e non tocca personalizzazioni di spedizione (consegna) o pagamento. La logica genuinamente personalizzata e quei due tipi di Function separati hanno ancora bisogno di uno sviluppatore.

Installa Stackable gratis e ricostruisci le tue regole di sconto su Shopify Functions prima che ti costino una vendita senza che te ne accorga, su usestackable.com/pricing. 🚀

Esempio lavorato: una lista di controllo di migrazione che puoi seguire oggi

Usa questa sequenza per trasformare "il mio Script si è rotto" in una migrazione controllata. La tabella mappa uno Script multi-funzione tipico alle sue destinazioni.

Quindi elabora i passaggi in ordine:

1. Inventario il vecchio Script prima di costruire qualsiasi cosa

Apri l'Editor di Script mentre puoi ancora farlo e scrivi una frase per comportamento. Esegui il rapporto di personalizzazione degli Script di Shopify per confermare che nulla si nasconde. Esporta la fonte Ruby e conservala da qualche parte al sicuro, perché diventa irrecuperabile una volta che l'editor è ritirato.

2. Dividi l'inventario per superficie

Ordina ogni comportamento in sconto, spedizione o pagamento. Questo ti dice immediatamente quali pezzi un'app di sconto senza codice può prendere e quali pezzi hanno bisogno di uno sviluppatore. Non assumere che uno strumento copra tutti e tre.

3. Ricostruisci i pezzi di sconto basati su regole senza codice

Per ogni comportamento che si riduce a "condizioni in, sconto fuori", ricrealo negli sconti Shopify nativi o in un'app Function basata su discounts. Imposta le regole di combinazione esplicitamente se le offerte sono destinate a stackarsi.

4. Consegna i pezzi non regole a uno sviluppatore

Le formule personalizzate, le personalizzazioni di consegna e le personalizzazioni di pagamento vanno a uno sviluppatore o agenzia per essere costruite come le loro stesse Function. Dai loro la tua fonte di Script esportata come specifica.

5. Testa ogni regola ricostruita in entrambi i modi

Per ogni regola, esegui un carrello che dovrebbe attivarsi e un carrello che non dovrebbe. Leggi il riepilogo del checkout riga per riga. Una regola non è migrata finché non hai visto sia applicarsi che correttamente rifiutarsi.

6. Verifica i checkout accelerati

Esegui il tuo carrello che dovrebbe attivarsi tramite Shop Pay. Poiché le Function calcolano lato server, una regola costruita correttamente si applica identicamente. Questo è il tuo ultimo controllo che nulla dipende dal codice del tema che i portafogli saltano.

SEGNAPOSTO IMMAGINE (Immagine 3): Testa entrambe le direzioni prima di fidarti

Visual suggerita: Un'illustrazione split 16:9. Pannello sinistro etichettato "Carrello che dovrebbe attivarsi" mostra un riepilogo di checkout con una riga di sconto verde correttamente presente. Pannello destro etichettato "Carrello che non dovrebbe attivarsi" mostra un riepilogo di checkout con lo sconto correttamente assente e una spunta verde. Una didascalia centrale legge "Una regola silenziosa non genera mai errori - prova entrambi." Colori del marchio viola e oro, vettore piatto, nessuna fotografia.

Il punto essenziale

• Shopify Scripts smettono di funzionare il 30 giugno 2026, e la modifica è già terminata il 15 aprile 2026. Qualsiasi Script ancora in uso è ora offline.
• Il fallimento è silenzioso. Uno Script che si è interrotto, o una regola migrata che non corrisponde a un carrello, non genera mai errori e non ti avvisa mai. Semplicemente addebita il prezzo pieno.
• Le Function sono la sostituzione, in esecuzione lato server all'interno del checkout, ma scriverne una da zero è un compito dello sviluppatore, e le Function personalizzate sono un percorso solo Shopify Plus.
• Uno Script spesso diventa tre migrazioni: sconti, consegna e funzioni di pagamento, ciascuno distribuito in modo indipendente.
• Un'app Function senza codice può ricostruire la logica degli sconti basata su regole (livelli, BOGO, stacking, pianificazione). Non può fare codice arbitrario, spedizione o personalizzazioni di pagamento.
• Mantieni la tua vecchia fonte di Script ora. Diventa irrecuperabile una volta che lo Script Editor è ritirato.
• Testa ogni regola ricostruita con un carrello che dovrebbe attivarsi e uno che non dovrebbe, e leggi il riepilogo del checkout riga per riga, incluso tramite Shop Pay.

Articoli correlati

• Migrazione da Shopify Scripts: il percorso di soccorso completo, cosa ricostruisce senza codice, e cosa ha ancora bisogno di uno sviluppatore.
• Come funziona lo stacking di sconti in Shopify: perché il nativo applica solo lo sconto più alto, e come combinare le offerte correttamente.
• Sconti di volume e interruzioni di quantità: ricrea il prezzo a livelli che conta lo stesso prodotto, non l'intera collezione.
• Discount stacking, fatto bene: i tre interruttori di combinazione per classe, con un simulatore di carrello live.
• Il limite di 100 prodotti di Shopify su Buy X Get Y: esegui 3 per 2 su un catalogo completo dopo la migrazione.
• Prezzi di Stackable: piani, il livello gratuito, e cosa include ciascuno.