Scadenza Shopify Scripts: passa a Functions entro il 30 giugno 2026

È il 16 aprile 2026. Ieri, 15 aprile, Shopify ha bloccato definitivamente Script Editor. Non puoi più creare o pubblicare nuovi Script. Questa scadenza pesa soprattutto sulla logica legata alle modifiche dopo l’acquisto: cambiare l’indirizzo di spedizione è la modifica più frequente dopo l’acquisto e riguarda il 30,2% di tutti gli ordini modificati (Revize, 2026). Qualsiasi Script che gestisce ancora queste modifiche è ora bloccato nella sua versione attuale. Tra 75 giorni, il 30 giugno 2026, gli Script smetteranno di essere eseguiti.

Se sviluppi per un negozio Shopify Plus, o lavori nell’agenzia che lo gestisce, e negli ultimi dodici mesi hai rimandato questa migrazione al «prossimo sprint», ora hai un problema. Non è una miglioria da fare quando trovi tempo: il checkout potrebbe smettere di funzionare correttamente allo scoccare del 1° luglio. Molti negozi Plus hanno accumulato da 5 a 20 Script nel corso degli anni. Ognuno gestisce in silenzio una regola di sconto, nasconde una tariffa di spedizione o limita un metodo di pagamento, spesso senza che nessuno ricordi chi l’abbia scritto.

Questa è la guida tecnica alla migrazione che avremmo voluto avere a gennaio. Troverai il codice, non solo la strategia. Alla fine saprai come creare la struttura di una Function con Shopify CLI, scrivere la logica in Rust o JavaScript per sconti e personalizzazioni della spedizione e dei pagamenti, testarla in sicurezza su un gruppo di clienti contrassegnati da tag e pubblicarla senza compromettere il checkout esistente.

Rimuoviamo gli Script dal tuo negozio e attiviamo le Functions.

Risposta rapida: da Scripts a Functions in 60 secondi#

La migrazione in un paragrafo: Shopify Scripts (codice Ruby in Script Editor, disponibile solo su Plus) viene sostituito da Shopify Functions (moduli WebAssembly scritti in Rust o JavaScript, disponibili su tutti i piani). Crei la struttura di una Function con shopify app generate extension, scrivi una query run.graphql per ottenere i dati necessari dal carrello e un file run.rs o run.js che restituisce le operazioni da eseguire, come applicare sconti o nascondere metodi di spedizione. Poi distribuisci la Function con shopify app deploy e la attivi dall’interfaccia di amministrazione o tramite una mutazione GraphQL. Le Functions vengono eseguite come moduli WASM compilati, con una latenza inferiore a 5 ms. Funzionano su tutti i piani e sono l’unica modalità di personalizzazione che Shopify supporterà in futuro.

Cosa cambia davvero il 30 giugno#

Prima di passare al codice, chiariamo le date. Sono due ed entrambe contano.

L’esito della migrazione è netto. Se distribuisci la Function entro il 30 giugno, il checkout continua a funzionare. Se non lo fai, ogni carrello interessato torna senza avvisi ai prezzi standard, alle tariffe di spedizione standard e a tutti i metodi di pagamento abilitati. Non esiste una soluzione parziale. Uno Script viene eseguito oppure no; dopo il 30 giugno, non verrà più eseguito.

Suggerimento: Apri Settings → Checkout → Customizations Report nel pannello di controllo Shopify. Il report elenca tutti gli Script attivi nel negozio, cosa fanno e il tipo di Function consigliato per sostituirli. Parti da lì.

Functions e Scripts: cosa è cambiato davvero#

Il cambiamento di architettura conta. Con gli Script modificavi Ruby in un campo di testo. Con le Functions sviluppi una vera app, ne gestisci le versioni, la testi in locale e la distribuisci tramite una pipeline CI. La curva di apprendimento è più ripida. Ma, per quanto oggi si possa prevedere, questa sarà anche l’ultima migrazione della logica di checkout: Functions è la soluzione su cui Shopify punta a lungo termine.

Associare ogni Script al tipo di Function giusto#

Ogni Script che usi oggi corrisponde a una specifica API di Functions. Tieni questa tabella a portata di mano.

Se hai dieci Script, probabilmente creerai da tre a cinque Functions: spesso puoi riunire più Script in una sola Function con una logica condizionale più chiara.

Prerequisito: prepara l’ambiente di sviluppo locale#

Prima di creare una Function, devi installare tre strumenti in locale. Esegui questi controlli nel terminale.

1. Node.js 18+

node --version
# Must be >= 18.0.0

Se la versione è precedente, installa Node.js tramite nvm oppure scaricalo da nodejs.org.

2. Shopify CLI 3+

npm install -g @shopify/cli@latest
shopify version
# Should output 3.x or higher

3. Toolchain Rust (solo se scriverai le Functions in Rust)

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
rustup target add wasm32-wasip1
cargo --version

Le Functions in JavaScript non richiedono Rust. Scegli un linguaggio per il team e mantienilo: usarli entrambi aumenta il lavoro di manutenzione.

4. Un negozio di sviluppo

Accedi alla dashboard Partner e crea un nuovo negozio di sviluppo, oppure usane uno esistente. Distribuirai le Functions in questo negozio prima di portarle in produzione.

Creare la struttura della tua prima Function#

La CLI genera gran parte della struttura iniziale. Da una directory qualsiasi:

# Create a new Shopify app (skip if you already have one)
shopify app init my-checkout-functions
cd my-checkout-functions

# Generate a Function extension
shopify app generate extension

La CLI ti guida con una serie di domande. Per una Function di sconto, scegli:

• Tipo: Function
• Modello: discount (oppure cart_checkout_validation, delivery_customization, payment_customization e così via)
• Linguaggio: Rust o JavaScript
• Nome: per esempio volume-discount-fn

Viene creata la directory extensions/volume-discount-fn/ con questa struttura:

extensions/volume-discount-fn/
├── shopify.extension.toml      # Function config — targets, build, version
├── src/
│   ├── cart_lines_discounts_generate_run.graphql   # Input query
│   └── cart_lines_discounts_generate_run.rs        # Function logic
├── Cargo.toml                  # Rust dependencies (Rust only)
└── README.md

I tre file che modificherai più spesso sono .toml (configurazione), .graphql (input) e .rs / .js (logica). Tutto qui.

Tutorial 1: sostituire un Line Item Script (sconto per quantità)#

Supponiamo che il vecchio Script applicasse uno sconto del 10% al subtotale dell’ordine quando il carrello conteneva almeno 5 unità di una determinata collezione. Ecco l’equivalente con una Function.

Passaggio 1.1: la configurazione (shopify.extension.toml)#

api_version = "2026-01"

[[extensions]]
name = "volume-discount-fn"
handle = "volume-discount-fn"
type = "function"

[[extensions.targeting]]
target = "cart.lines.discounts.generate.run"
input_query = "src/cart_lines_discounts_generate_run.graphql"
export = "cart_lines_discounts_generate_run"

[extensions.build]
command = "cargo build --target=wasm32-wasip1 --release"
path = "target/wasm32-wasip1/release/volume-discount-fn.wasm"
watch = ["src/**/*.rs"]

Passaggio 1.2: la query di input (src/cart_lines_discounts_generate_run.graphql)#

query Input {
  cart {
    lines {
      id
      quantity
      cost {
        subtotalAmount {
          amount
        }
      }
      merchandise {
        ... on ProductVariant {
          product {
            inAnyCollection(ids: ["gid://shopify/Collection/123456789"])
          }
        }
      }
    }
  }
  discount {
    discountClasses
  }
}

Suggerimento: Le Functions vedono solo i dati richiesti dalla query. Mantieni essenziale il GraphQL: ogni campo superfluo che elimini rende l’esecuzione più rapida ed economica.

Passaggio 1.3: la logica (src/cart_lines_discounts_generate_run.rs)#

use super::schema;
use shopify_function::prelude::*;
use shopify_function::Result;

#[shopify_function]
fn cart_lines_discounts_generate_run(
    input: schema::cart_lines_discounts_generate_run::Input,
) -> Result<schema::CartLinesDiscountsGenerateRunResult> {
    // Bail if discount class doesn't match
    let has_order_discount = input
        .discount()
        .discount_classes()
        .contains(&schema::DiscountClass::Order);

    if !has_order_discount {
        return Ok(schema::CartLinesDiscountsGenerateRunResult { operations: vec![] });
    }

    // Sum quantities of items in the target collection
    let qualifying_qty: i64 = input
        .cart()
        .lines()
        .iter()
        .filter(|line| {
            if let schema::Merchandise::ProductVariant(v) = line.merchandise() {
                *v.product().in_any_collection()
            } else {
                false
            }
        })
        .map(|line| *line.quantity())
        .sum();

    if qualifying_qty < 5 {
        return Ok(schema::CartLinesDiscountsGenerateRunResult { operations: vec![] });
    }

    // Apply 10% off the order subtotal
    Ok(schema::CartLinesDiscountsGenerateRunResult {
        operations: vec![schema::CartOperation::OrderDiscountsAdd(
            schema::OrderDiscountsAddOperation {
                selection_strategy: schema::OrderDiscountSelectionStrategy::First,
                candidates: vec![schema::OrderDiscountCandidate {
                    targets: vec![schema::OrderDiscountCandidateTarget::OrderSubtotal(
                        schema::OrderSubtotalTarget {
                            excluded_cart_line_ids: vec![],
                        },
                    )],
                    message: Some("Volume discount: 10% off".to_string()),
                    value: schema::OrderDiscountCandidateValue::Percentage(
                        schema::Percentage { value: Decimal(10.0) }
                    ),
                    conditions: None,
                    associated_discount_code: None,
                }],
            },
        )],
    })
}

Passaggio 1.4: testa, distribuisci e attiva#

# Local development with hot reload
shopify app dev

# When ready, deploy
shopify app deploy

# In the GraphiQL panel that opens (press `g` in the dev terminal),
# create the automatic discount that uses your Function:

mutation {
  discountAutomaticAppCreate(
    automaticAppDiscount: {
      title: "Volume Discount (5+ collection items)"
      functionHandle: "volume-discount-fn"
      discountClasses: [ORDER]
      startsAt: "2026-04-16T00:00:00Z"
    }
  ) {
    automaticAppDiscount { discountId }
    userErrors { field message }
  }
}

Ecco fatto. La Function è attiva, ha una cronologia delle versioni e sostituisce completamente il vecchio Script.

Tutorial 2: sostituire uno Shipping Script (nascondere un metodo oltre una soglia del carrello)#

Uno Script comune dice: «Nascondi la spedizione Express quando il subtotale del carrello supera $500, per evitare costose consegne il giorno successivo sugli ordini più grandi». Ecco la versione con una Delivery Customization Function.

Passaggio 2.1: crea la struttura#

shopify app generate extension --template delivery_customization --name hide-express-fn

Passaggio 2.2: query di input (src/run.graphql)#

query Input {
  cart {
    cost {
      subtotalAmount {
        amount
      }
    }
    deliveryGroups {
      deliveryOptions {
        handle
        title
      }
    }
  }
}

Passaggio 2.3: logica (src/run.js — variante JavaScript)#

// @ts-check
/**
 * @typedef {import("../generated/api").RunInput} RunInput
 * @typedef {import("../generated/api").FunctionRunResult} FunctionRunResult
 */

const NO_CHANGES = { operations: [] };
const THRESHOLD = 500.0;
const HIDE_TITLES = ["Express", "Overnight"];

/**
 * @param {RunInput} input
 * @returns {FunctionRunResult}
 */
export function run(input) {
  const subtotal = parseFloat(input.cart.cost.subtotalAmount.amount);
  if (subtotal < THRESHOLD) return NO_CHANGES;

  const operations = input.cart.deliveryGroups.flatMap((group) =>
    group.deliveryOptions
      .filter((opt) => HIDE_TITLES.some((t) => opt.title.includes(t)))
      .map((opt) => ({
        hide: { deliveryOptionHandle: opt.handle },
      }))
  );

  return { operations };
}

Passaggio 2.4: attiva dal pannello di controllo (senza GraphQL)#

Le Delivery Customizations hanno un’interfaccia nel pannello di controllo. Dopo shopify app deploy:

1. Vai a Settings → Shipping and delivery
2. Scorri fino alla sezione Customizations in fondo alla pagina
3. Clicca su Add customization → seleziona la tua Function
4. Salva

La regola che nasconde il metodo di spedizione è attiva in produzione. Non serve una mutazione.

Tutorial 3: sostituire un Payment Script (nascondere il pagamento alla consegna per i clienti B2B)#

Il vecchio Script dice: «Nascondi il pagamento alla consegna per tutti i clienti con il tag “B2B”». Ecco la versione con Payment Customization.

Passaggio 3.1: crea la struttura#

shopify app generate extension --template payment_customization --name hide-cod-b2b-fn

Passaggio 3.2: query di input#

query Input {
  cart {
    buyerIdentity {
      customer {
        hasTags(tags: [{ tag: "B2B" }]) {
          tag
          hasTag
        }
      }
    }
  }
  paymentMethods {
    id
    name
  }
}

Passaggio 3.3: logica (src/run.js)#

const NO_CHANGES = { operations: [] };

export function run(input) {
  const tagCheck = input.cart?.buyerIdentity?.customer?.hasTags?.[0];
  const isB2B = tagCheck?.hasTag === true;
  if (!isB2B) return NO_CHANGES;

  const codMethod = input.paymentMethods.find((pm) =>
    pm.name.toLowerCase().includes("cash on delivery")
  );
  if (!codMethod) return NO_CHANGES;

  return {
    operations: [{ hide: { paymentMethodId: codMethod.id } }],
  };
}

Passaggio 3.4: attiva#

Anche le Payment Customizations hanno un’interfaccia nel pannello di controllo, in Settings → Payments → Customizations. La procedura è la stessa della spedizione: scegli la Function, salva e hai finito.

Già che ci sei: una nota sulle modifiche dopo l’acquisto#

Una precisazione, dato che stai leggendo il blog di Revize. Revize gestisce ciò che le Functions non possono modificare: dopo aver effettuato un ordine, i clienti possono voler aggiungere un articolo, cambiare taglia, correggere l’indirizzo di spedizione o applicare uno sconto dimenticato. Le Functions operano al checkout. Revize interviene dopo. Le Functions stabiliscono cosa è consentito nel carrello; Revize permette ai clienti e al team di assistenza di modificare l’ordine dopo l’acquisto, senza dover emettere un rimborso e ricrearlo. Questo conta per due tipi di negozi: quelli con un volume di ordini tale da rendere ingestibili le modifiche manuali (negozi Plus, certo, ma anche negozi Advanced che elaborano molti ordini) e quelli che fanno dell’esperienza cliente un elemento centrale del marchio, per cui un’email con scritto «ci dispiace, non possiamo cambiarlo» può compromettere un acquisto futuro.

Se il tuo piano prevede la migrazione da Scripts a Functions ma non hai ancora risolto il problema delle modifiche degli ordini dopo l’acquisto, tra circa tre settimane ti troverai davanti alla prossima difficoltà. La guida alla gestione degli ordini che abbiamo appena pubblicato illustra tutte le possibilità dopo il checkout.

Torniamo alla migrazione.

Strategia di test: usare un tag per i clienti#

Le Functions non hanno una «modalità bozza» da attivare nel pannello di controllo. L’approccio consigliato è limitare la nuova Function ai clienti con un determinato tag, eseguire in parallelo il vecchio Script e la nuova Function, verificare che producano lo stesso risultato per quei clienti e poi estendere la Function a tutti.

Passaggio 1: aggiungi un tag agli utenti di test#

Nella sezione Customers, aggiungi il tag FN-TESTER a due o tre account interni.

Passaggio 2: fai dipendere l’esecuzione della Function dalla presenza del tag#

// At the top of your run function
let is_tester = input
    .cart()
    .buyer_identity()
    .and_then(|bi| bi.customer())
    .map(|c| c.has_any_tag())
    .unwrap_or(&false);

if !*is_tester {
    return Ok(default_result);  // Fall through to existing Script
}

// New Function logic only runs for tagged users

Passaggio 3: aggiungi hasAnyTag alla query di input#

cart {
  buyerIdentity {
    customer {
      hasAnyTag(tags: ["FN-TESTER"])
    }
  }
}

Passaggio 4: verifica nel checkout#

Accedi come utente con il tag, completa il percorso di checkout e conferma che la Function venga eseguita. Accedi poi come utente senza il tag e conferma che il vecchio Script sia ancora in esecuzione. Quando i risultati coincidono per alcuni giorni, rimuovi il controllo del tag e lascia eseguire la Function per tutti.

Passaggio 5: annulla la pubblicazione del vecchio Script#

Vai a Apps → Script Editor → [Your Script] → Unpublish. Da quel momento, la Function è l’unica a gestire quella logica.

Un flusso di distribuzione che regge nel tempo#

Non continuare a distribuire le Functions dal portatile di uno sviluppatore. Dopo aver migrato uno o due Script, configura una pipeline CI.

Il flusso di lavoro minimo#

# .github/workflows/deploy-functions.yml
name: Deploy Shopify Functions
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - uses: dtolnay/rust-toolchain@stable
        with: { targets: wasm32-wasip1 }
      - run: npm install -g @shopify/cli@latest
      - run: shopify app deploy --force
        env:
          SHOPIFY_CLI_PARTNERS_TOKEN: ${{ secrets.SHOPIFY_CLI_PARTNERS_TOKEN }}

Genera il token Partner nella dashboard Partner, in Settings → Tokens. Da quel momento, ogni merge in main distribuisce le tue Functions. Niente più discussioni su Slack per capire se Mike abbia pubblicato l’ultima versione.

Versionamento e ripristino#

shopify app deploy crea una versione salvata. Per tornare a una versione precedente:

shopify app versions list
shopify app release --version <previous-version-id>

Con gli Script, per tornare indietro dovevi ricordare il vecchio codice e incollarlo di nuovo. La differenza è notevole.

Gli errori più comuni dei team#

Dopo aver aiutato i merchant Plus in questa migrazione nell’ultimo anno, abbiamo visto ripetersi gli stessi cinque errori.

1. Convertire ogni Script in una Function separata. Non è necessario. Una sola Function può sostituire tre Script con una logica condizionale più chiara. Esamina tutti gli Script come un unico sistema prima di riscriverli.

2. Dimenticare gli ambiti di accesso. Molte Functions richiedono read_customers, read_orders o write_discounts. Aggiungili in shopify.app.toml sotto scopes e autorizza nuovamente l’app, altrimenti la query di input restituirà null.

3. Eseguire le Functions per i clienti senza tag prima di verificare che i risultati coincidano. Anche se il codice sembra corretto, casi particolari come carrelli vuoti, buoni regalo, credito del negozio e bozze B2B possono creare problemi. Un rilascio limitato tramite tag richiede due giorni e può evitarti un’interruzione critica.

4. Saltare il Customizations Report. È il modo migliore per sapere cosa è realmente in esecuzione. Basa la migrazione sul report, non sulla memoria.

5. Inserire nel codice gli ID delle collezioni e i tag dei clienti. Se il merchant deve poter modificare questi valori, usa una configurazione della Function basata sui metafield. La CLI può generare la struttura per questa configurazione: consulta la documentazione Shopify sulla configurazione delle Functions.

Lista di controllo per la migrazione nei prossimi 75 giorni#

Un piano realistico, settimana per settimana, per arrivare preparati al 30 giugno.

Se inizi questa settimana, hai un margine. Se inizi a giugno, no.

Cosa fare questa settimana#

Non limitarti a leggere questo articolo e chiudere la scheda. Fai queste quattro cose nei prossimi sette giorni.

1. Scarica il Customizations Report. Vai a Settings → Checkout → Customizations Report ed esportalo. Sarà l’elenco delle attività per la migrazione.

2. Prepara l’ambiente di sviluppo. Installa Node 18+, Shopify CLI e Rust, se necessario. Verifica che shopify version funzioni. Tempo totale: 30 minuti.

3. Crea e distribuisci una piccola Function in un negozio di sviluppo. Scegli lo Script più semplice che hai, di solito una regola che nasconde un metodo di pagamento. Completa la migrazione dall’inizio alla fine. Anche se la Function non arriverà mai in produzione, avrai verificato che tutti gli strumenti funzionino.

4. Riserva del tempo in calendario per le prossime otto settimane. Le migrazioni non si completano nei ritagli di tempo tra uno sprint e l’altro. Fissa appuntamenti ricorrenti, per esempio ogni martedì e giovedì pomeriggio, e trattali come una pubblicazione.

Tra i team che abbiamo visto migrare, lo schema si ripete: due settimane di rinvii, tre settimane di lavoro effettivo e una settimana di rifiniture. In tutto, sei settimane. Tu ne hai dieci. Usa il margine per la revisione del codice e il controllo qualità, non per rimandare l’inizio.

E quando avrai sistemato la logica del checkout, il passo successivo per molti team sarà gestire le modifiche dopo l’acquisto: cambi di indirizzo, sostituzioni e aggiunta di sconti dopo che l’ordine è stato effettuato. Se è nella tua roadmap (e dovrebbe esserlo, sia che tu gestisca molti ordini su Plus sia che tu abbia un negozio Advanced incentrato sull’esperienza cliente), Revize è disponibile sullo Shopify App Store e funziona insieme a tutte le Functions che creerai seguendo questa guida.

Risorse#

• Panoramica di Shopify Functions — documentazione Shopify per sviluppatori
• Migrazione da Shopify Scripts a Functions
• Tutorial: creare una Discount Function
• Riferimento API per Delivery Customization Function
• Riferimento API per Payment Customization Function
• Documentazione di Shopify CLI

Aggiornato ad agosto 2026. Revize è un’app Shopify che permette ai clienti di modificare autonomamente gli ordini dopo l’acquisto: possono cambiare l’indirizzo di spedizione, sostituire una variante o un prodotto, annullare l’ordine e ottenere un rimborso o un credito del negozio prima dell’evasione degli ordini (fulfillment), senza aprire una richiesta all’assistenza. Scopri di più su come permettere ai clienti di modificare i propri ordini Shopify oppure trova Revize sullo Shopify App Store.