O Shopify Scripts parou de funcionar em 30 de junho de 2026. Veja o que fazer agora.
Se a sua loja tinha um Script personalizado de desconto, BOGO ou combo, ele parou de ser executado em 30 de junho de 2026, silenciosamente. Sem erro, sem alerta, nada nos seus logs. Aqui está exatamente o que aconteceu, o que a migração para o Shopify Functions realmente envolve e uma resposta honesta sobre o que a Stackable pode reconstruir para você.
- O Shopify Scripts parou de ser executado em 30 de junho de 2026 para toda loja que ainda o utilizava.
- Qualquer lógica personalizada de desconto, BOGO ou combo que existia dentro de um Script parou de ser aplicada nessa data.
- A falha é silenciosa por design: um Shopify Function cujas condições não correspondem a um determinado carrinho simplesmente nunca é acionado. Ele não gera um erro, e a Shopify não te notifica.
Lojistas passando por essa migração descrevem o mesmo risco nos fóruns da comunidade Shopify:
“Meu antigo Script parou silenciosamente de aplicar um desconto, e só descobri porque um cliente reclamou de ter pago o preço cheio. Não houve erro, nem alerta, nada nos logs do pedido. Fiquei semanas operando com uma configuração quebrada antes de perceber.”
Esse é o risco central de migrar de Scripts para Functions: uma Function ou está bem formada e em execução, ou está mal configurada e silenciosa. Não existe um estado intermediário visível, então uma condição incompatível, um erro de digitação em um limite ou uma regra vinculada à coleção errada produz exatamente o mesmo silêncio de uma Function funcionando corretamente. A única forma de identificar isso é testar deliberadamente os dois cenários antes de confiar nela em produção.
Quatro coisas que vale a pena saber antes de começar
Um Script muitas vezes vira três migrações
Um único arquivo de Script podia mexer em lógica de desconto, taxas de frete e personalização de pagamento, tudo ao mesmo tempo. O Functions divide isso em tipos de Function separados, desconto, entrega e pagamento, cada um configurado e implantado de forma independente. Migrar "o meu Script" geralmente significa migrar até três coisas diferentes, e essa é a reclamação que os lojistas mais fazem sobre essa mudança.
Construtores no-code geralmente cobrem apenas descontos e BOGO
Se o seu Script também lidava com taxas de frete ou métodos de pagamento, um construtor no-code de Function de desconto, incluindo a Stackable, não alcança essas áreas. Personalizações de entrega e pagamento exigem um desenvolvedor para escrever essa Function diretamente.
Guarde o código-fonte do seu Script antigo agora
Assim que o Script Editor for totalmente desativado, o código armazenado nele se torna irrecuperável. Exporte ou copie o código-fonte do seu Script antigo hoje mesmo, mesmo que ainda não esteja pronto para migrar, para ter uma referência do que vier a substituí-lo.
Teste um carrinho que deveria disparar e um que não deveria
Antes de confiar em uma nova Function, monte dois carrinhos de teste: um que deveria acioná-la e outro que deliberadamente não deveria. Uma Function que dispara quando não deveria é tão custosa quanto uma que silenciosamente nunca dispara.
As três coisas que explicam toda decisão de migração
Quase todo debate sobre o que pode ou não ser reconstruído se resume a três fatos: os Scripts vinham em três tipos, cada um com uma única vaga; o Functions divide esses três tipos em quatro APIs diferentes; e uma Function precisa declarar antecipadamente cada dado que vai ler antes de rodar. Com esses três fatos em mãos, o resto desta página é só aritmética.
O Shopify Scripts vinha em três tipos
O Script Editor pedia que você escolhesse um tipo antes de escrever uma linha sequer de Ruby, e esse tipo determinava o que o seu código tinha permissão para alterar.
Scripts de item de linha
Os que alteravam quanto os produtos custavam. Eles percorriam o carrinho linha por linha e recalculavam o preço, e era ali que viviam todo desconto escalonado, BOGO, preço de combo e markdown.
Scripts de frete
Os que atuavam sobre as taxas de entrega. Podiam dar desconto em uma taxa, escondê-la, renomeá-la ou reordenar a lista que o comprador via. Só a primeira dessas quatro ações é um desconto.
Scripts de pagamento
Os que atuavam sobre métodos de pagamento, com os mesmos quatro verbos: esconder um método, renomeá-lo, reordenar a lista ou, na prática, principalmente escondê-lo de determinados carrinhos.
Agora a restrição que moldou todo Script real que você vai encontrar: só era possível publicar um Script de cada tipo por vez. Uma única vaga de item de linha para a loja inteira. Então um lojista rodando um desconto VIP, um preço de liquidação, um limite de gasto e uma promoção sazonal não escrevia quatro Scripts. Ele escrevia um único arquivo com os quatro combinados, geralmente com uma regra caseira do tipo "fique com o que der o melhor preço" no final. É por isso que Scripts reais parecem emaranhados. Eles não são uma regra mal escrita, são várias regras que nunca puderam ser separadas.
Veja um Script real com quatro campanhas combinadas em um único arquivoQuatro APIs de Function os substituíram
O Shopify não substituiu os Scripts por uma única coisa. Substituiu por quatro, divididas pelo que o código tem permissão para alterar, e não por onde no carrinho ele roda.
Discount Function API
Desconto em dinheiro. Descontos de produto, descontos de pedido e descontos de frete moram todos aqui agora, em uma API unificada. Se o seu Script alterava um preço, é aqui que ele se encaixa.
Documentação da ShopifyDelivery Customization API
Esconder, renomear e reordenar opções de entrega. O Shopify deixa explícito que essa é a única API capaz de personalizar opções de entrega no checkout, então um app de desconto não consegue alcançá-la, não importa como foi construído.
Documentação da ShopifyPayment Customization API
Esconder, renomear e reordenar métodos de pagamento, além de prazos de pagamento e se um pedido precisa de revisão. A metade de pagamento do antigo Script Editor, reunida em um só lugar.
Documentação da ShopifyCart and Checkout Validation API
Bloquear o checkout com uma mensagem. Limites de compra, verificações de idade e regras de pedido mínimo caem aqui. Ela retorna erros, então consegue impedir um pedido, mas não consegue alterá-lo silenciosamente.
Documentação da ShopifyO Stackable é um app de Discount Function, e só isso. Construímos discount functions, então conseguimos reconstruir qualquer coisa que o seu Script fazia com um preço, incluindo descontos de frete. Não entregamos uma personalização de entrega, uma personalização de pagamento nem uma validation function, então esconder uma taxa de frete, renomear um método de pagamento ou limitar uma quantidade de compra não é algo que recusamos por falta de vontade de construir. É um tipo diferente de app.
Junte as duas metades e você chega na frase que os lojistas descobrem do jeito difícil: um Script muitas vezes vira três migrações. Um Script de item de linha que também escondia uma taxa de frete e bloqueava um método de pagamento agora é uma discount function, uma personalização de entrega e uma personalização de pagamento, escritas e implantadas separadamente. Preferimos que você leia isso aqui do que descubra depois de reconstruir tudo.
Veja um Script de frete que, no fim das contas, não é um descontoAs Functions são puras, e todo campo é declarado com antecedência
Um Script rodava como Ruby comum, contra o que quer que o carrinho tivesse naquele momento. Uma Function roda em sandbox, e o Shopify garante que ela não tem nenhum dos itens a seguir:
- Sem rede. Uma Function não consegue chamar o seu ERP, o seu provedor de fidelidade ou qualquer outro serviço enquanto um comprador está finalizando a compra.
- Sem relógio. Uma Function não consegue perguntar que horas são, então "metade do preço às terças-feiras" precisa virar um desconto agendado, em vez de uma condição dentro do código.
- Sem aleatoriedade. Nada consegue jogar um dado para sortear um em cada dez compradores.
- Sem sistema de arquivos, e sem buscar um campo que não foi pedido antes. Todo dado que uma Function lê precisa ser nomeado com antecedência, em uma consulta de entrada, e essa consulta tem um teto rígido de custo definido pelo Shopify.
Essa última regra é a que mais custa aos lojistas, e vale a pena ser preciso sobre de quem é a culpa. Não é que o Shopify esconda os dados. A nossa própria consulta de checkout já está no custo máximo que o Shopify permite, então pedir mais um campo significa abrir mão de outro. Nove dos formatos de Script que recusamos hoje são recusados exatamente por esse motivo e nenhum outro, incluindo ignorar itens que já estão com desconto, ler a província ou o CEP, e verificar quantos pedidos um cliente já fez. O Shopify oferece cada um desses dados. Nós é que ainda não abrimos espaço para eles. Essa é uma limitação nossa, e chamar isso de limite da plataforma seria mentira.
Apenas duas recusas em toda a biblioteca são limitações genuínas do Shopify, e as duas vêm do mesmo fato: toda discount function de uma loja roda no mesmo instante, e nenhuma delas consegue ver o que as outras fizeram. Então um Script que perguntava "esse item já recebeu desconto?" ou media um limite contra um subtotal já reduzido não pode ser reconstruído por nós nem por ninguém, hoje, por preço nenhum. Tudo o mais na nossa lista de recusas é uma responsabilidade nossa de corrigir, e é assim que rotulamos isso no app e em cada página da biblioteca.
Leia as duas recusas que realmente são limitações do ShopifyDefinir um preço não é o mesmo que tirar dinheiro do preço
Se você só for ler uma coisa antes de reconstruir um Script manualmente, leia esta. Dois arquivos podem chamar o mesmo método, com a mesma constante e a mesma mensagem, e significar coisas opostas. Os dois exemplos a seguir são reais, os dois são comuns, e a diferença entre eles é um sinal de subtração.
Este DEFINE o preço em $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.cartEm um item de $79.00, o desconto é de $69.01 e o comprador paga $9.99. Reconstruído como uma oferta de volume cuja recompensa é um preço fixo, contada por variante e recorrente, de modo que cada unidade tem o preço redefinido.
O exemplo resolvido, com o carrinho e as configuraçõesEste TIRA $9.99 de desconto
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.cartNo mesmo item de $79.00, o desconto é de $9.99 e o comprador paga $69.01. Reconstruído como uma oferta de volume cuja recompensa é um valor de desconto por unidade, contada por produto e disparada uma única vez.
O exemplo resolvido, com o carrinho e as configuraçõesMesmo método, mesmo $9.99, mesma frase na mensagem. O único sinal é que o segundo arquivo subtrai de `line_item.line_price` antes de atribuir o valor. Leia ao contrário em um item de $79.00 e você erra por $59.02 em uma única unidade, na direção que for mais prejudicial. E as duas reconstruções não diferem só no número: uma conta por variante e se repete, a outra conta por produto e dispara uma única vez, então elas também divergem assim que o comprador compra duas unidades.
Essa é a falha que o conselho de sempre não consegue pegar. Uma oferta reconstruída que leu o arquivo ao contrário ainda dispara em um carrinho que deveria acioná-la e ainda fica quieta em um carrinho que não deveria, então testar as duas direções deixa passar. O Scripts Rescue fecha essa brecha fazendo uma pergunta diferente: antes de deixar você publicar, ele pede o valor que o seu antigo Script cobrava em um carrinho que você ainda consegue reproduzir, e compara isso com o que a oferta reconstruída calcula. Um centavo de diferença e a publicação continua bloqueada. Entre os cinco apps que vendem migração de Scripts hoje, nossa pesquisa não encontrou nenhum que peça ao lojista para provar o valor.
O que cada trecho de Ruby vira em uma campanha
Uma reconstrução dá errado sempre nos mesmos poucos pontos, e quase nunca são os óbvios. A recompensa costuma ser fácil. Contagem e recorrência são onde o dinheiro se move silenciosamente, porque um Script expressa isso em aritmética e uma campanha expressa isso em uma configuração.
| No seu Script | Em uma campanha | Onde dá errado |
|---|---|---|
change_line_price(PRICE * qty) | Uma oferta de volume com recompensa de preço fixo. | Atribuição, não subtração. Essa é a armadilha descrita acima. O preço da unidade vira a constante, então um item de $79 é vendido por $9.99. |
line_price - (AMOUNT * qty) | Uma oferta de volume com recompensa de valor de desconto por unidade. | A subtração é todo o sinal. Mesma constante da linha acima, uma conta completamente diferente. |
line_price * 0.9 | Uma recompensa percentual de 10. | O multiplicador é o que o comprador mantém, não o que ele economiza. Digitado direto como 90, isso dá de graça nove décimos do catálogo. |
next unless line_item.quantity >= 3 | Um nível com quantidade mínima de 3. | Os níveis são inclusivos no limite, e só o nível mais alto satisfeito dispara. Scripts que empilhavam uma regra em cima da outra não têm equivalente em uma única oferta, e precisam de uma oferta para cada regra. |
line_items.size > 1 | Uma quantidade mínima de 2. | Não é a mesma regra. Aqui os Scripts contavam linhas de carrinho separadas, as campanhas contam unidades, então uma linha com duas unidades do mesmo item agora se qualifica, onde o Script a ignorava. |
sets = quantity / (BUY + GET) | Buy X Get Y com as unidades grátis contadas como adicionais. | Dividir só pelo valor de BUY torna as unidades grátis inclusivas. Em nove unidades de um buy 3 get 1, isso é duas grátis ou três grátis. Um caractere de diferença, metade a mais dado de graça. |
customer.tags.include?("vip") | Elegibilidade de cliente restrita a tags. | O Shopify compara tags de forma exata, incluindo letras maiúsculas, enquanto muitos dialetos de Script colocavam os dois lados em minúsculas antes. Confira a grafia antes de publicar, não depois. |
product.tags / product_type / vendor | Escopo de alvo definido por tags, tipos de produto ou fornecedores. | Uma linha de escopo esquecida é o erro mais caro desta tabela, porque transforma "20% de desconto na tag de promoção" em 20% de desconto em tudo que você vende. |
Uma coisa que você não vai encontrar nesta tabela são coleções. Um Script conseguia ler as tags, o tipo e o fornecedor de um produto, mas nunca suas coleções, então qualquer Ruby que alegava verificar uma coleção não estava fazendo o que parecia fazer. Campanhas conseguem mirar coleções; o seu antigo Script não conseguia.
Consulte o seu Script em vez de tentar deduzi-lo
Todo formato de Script que catalogamos tem sua própria página: o Ruby original, o que ele é reconhecido como, a configuração exata em que se transforma, um carrinho da nossa loja de demonstração pública com o desconto que o mecanismo real calcula para ele, e o carrinho que precisa ficar quieto. As recusas são documentadas da mesma forma, cada uma rotulada como limitação do Shopify, lacuna nossa ou tarefa para um tipo diferente de app. É a referência que gostaríamos de ter tido quando começamos, por isso ela é pública.
- Formatos de Script
- 42
- Reconstruídos hoje
- 38
- Recusados, com motivo
- 21
Uma resposta honesta sobre escopo
O Stackable reconstrói a lógica de desconto baseada em regras usando Shopify Functions nativas. Ele não executa código personalizado arbitrário.
O Stackable reconstrói isso
- Descontos escalonados / por volume (ex.: "compre 3+, economize 15%")
- Lógica de Compre X Ganhe Y e BOGO, incluindo faixas repetidas
- Regras explícitas de empilhamento de descontos entre ofertas
- Início e término agendados, além de pausa instantânea em qualquer campanha
Você ainda vai precisar de um desenvolvedor para isso
- Código personalizado arbitrário que o seu antigo Script executava (fórmulas de preço sob medida, condições pontuais que nenhum construtor cobre)
- Personalizações de frete / entrega (um tipo separado de Function)
- Personalizações de pagamento (um tipo separado de Function)
- Qualquer coisa que não se reduza a uma configuração de desconto baseada em regras
Se o seu antigo Script fazia algo desta lista, um construtor sem código, incluindo o Stackable, não consegue alcançar isso. Isso é uma Function escrita por desenvolvedor, não uma tela de configuração.
Perguntas comuns
Meus Scripts antigos desapareceram?
O Scripts parou de ser executado em 30 de junho de 2026, mas isso não é necessariamente o mesmo momento em que o código armazenado no Script Editor é excluído. De qualquer forma, exporte ou copie o código do seu Script antigo agora: assim que a Shopify desativar totalmente o editor, ele se torna irrecuperável.
Vou receber um erro se uma Function estiver mal configurada?
Não. Uma Function cujas condições não correspondem a um carrinho simplesmente nunca dispara, silenciosamente, sem erro e sem alerta. Sempre teste com um carrinho que deveria acioná-la e outro que não deveria antes de confiar nela em produção.
A Stackable substitui tudo o que o meu antigo Script fazia?
Somente a parte baseada em regras: descontos escalonados e por volume, BOGO, empilhamento de descontos e agendamento, tudo reconstruído sobre Shopify Functions nativas. A Stackable não executa código personalizado arbitrário. Se o seu Script fazia algo genuinamente sob medida, uma fórmula de preço personalizada ou uma condição que nenhum construtor cobre, isso ainda exige um desenvolvedor para escrever a Function diretamente.
E a lógica de frete ou pagamento que o meu Script gerenciava?
Esses são tipos separados de Function (entrega e pagamento) que a Stackable não gerencia. Um desenvolvedor precisa migrá-los de forma independente da sua lógica de desconto.
Em qual plano está o Scripts Rescue?
O Scripts Rescue, a ferramenta que lê o seu Ruby antigo e o reconstrói, está no plano Pro. O Stackable em si é gratuito para instalar, e o mecanismo central de descontos, incluindo níveis por volume, Buy X Get Y, metas de gasto, frete grátis, agendamento e o simulador, é gratuito em todos os planos. O resgate de Ruby especificamente não é: ele fica junto com múltiplas lojas e o Shopify Flow no plano Pro.
Como sei que o desconto reconstruído cobra o mesmo que o antigo cobrava?
Porque você é obrigado a provar isso antes de poder publicar. Testar um carrinho que deveria disparar e outro que não deveria é o conselho padrão, e ele não pega a pior falha, que é uma oferta disparando corretamente com o valor errado. O Scripts Rescue pede o valor que o seu antigo Script cobrava em um carrinho que você ainda consegue reproduzir, compara isso com o que a oferta reconstruída calcula, e mantém a publicação bloqueada até os dois baterem até o centavo. Nossa pesquisa entre os cinco apps que vendem migração de Scripts não encontrou nenhum que peça isso.
Por que o meu Script parecia tão complicado?
Porque só era possível publicar um Script de cada tipo por vez. Uma loja rodando quatro promoções não podia escrever quatro Scripts, então escrevia um único arquivo com os quatro combinados e uma regra no final decidindo qual valia. A maior parte do Ruby que parece ilegível é, na verdade, várias regras simples dividindo uma vaga, e cada uma delas costuma ser reconstruída de forma limpa isoladamente.
Onde posso ler o artigo completo sobre a migração?
Nosso primeiro post no blog detalha a descontinuação do Scripts e o caminho de migração, e a biblioteca de exemplos de Scripts tem uma página para cada formato de Script, com o Ruby original e a reconstrução exata.
Recursos relacionados
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.
Instale o Stackable e reconstrua seus descontos baseados em regras
Faixas de volume, BOGO, empilhamento e agendamento, rodando em Shopify Functions nativas desde o primeiro dia.
O Scripts Rescue está no plano Pro. O Stackable em si é gratuito para instalar, sem necessidade de cartão.