Es ist der 16. April 2026. Gestern, am 15. April, hat Shopify den Script Editor endgültig gesperrt. Sie können keine neuen Scripts mehr erstellen oder veröffentlichen. Diese Deadline trifft Post-Purchase-Logik am härtesten: Änderungen der Lieferadresse sind die Bearbeitung Nr. 1 nach dem Kauf und machen 30,2 % aller bearbeiteten Bestellungen aus (Revize, 2026). Jedes Script, das diese Änderungen noch verarbeitet, ist ab jetzt eingefroren. Die endgültige Abschaltung der Ausführung erfolgt in 75 Tagen, am 30. Juni 2026.

Wenn Sie ein Shopify Plus-Entwickler oder die Agentur eines Plus-Stores sind und diese Migration in den letzten zwölf Monaten auf den „nächsten Sprint“ verschoben haben, haben Sie ein Problem. Kein „Nice to have“-Problem. Ein „Ihr Checkout bricht am 1. Juli um Mitternacht zusammen“-Problem. Die meisten Plus-Stores haben im Laufe der Jahre 5 bis 20 Scripts angesammelt, von denen jedes im Stillen eine Rabattregel, das Ausblenden von Versandoptionen oder ein Zahlungsgateway steuert, an dessen Code sich niemand mehr erinnert.

Dieser Leitfaden ist das technische Migrationshandbuch, das wir uns im Januar gewünscht hätten. Er behandelt den tatsächlichen Code – nicht nur die Strategie. Wenn Sie diesen Artikel zu Ende gelesen haben, wissen Sie, wie Sie eine Function mit der Shopify CLI erstellen, die Rust- oder JavaScript-Logik für Rabatte, Delivery Customizations und Payment Customizations schreiben, diese sicher an einer getaggten Gruppe Ihrer Kunden testen und sie in die Live-Umgebung übertragen, ohne Ihren bestehenden Checkout zu beeinträchtigen.

Bringen wir die Scripts von Ihrem Store und die Functions darauf.

Schnellantwort: Scripts → Functions in 60 Sekunden

Die Migration in einem Absatz: Shopify Scripts (Ruby-Code im Script Editor, nur für Plus) werden durch Shopify Functions ersetzt (WebAssembly-Module, geschrieben in Rust oder JavaScript, verfügbar für alle Tarife). Sie erstellen eine Function mit shopify app generate extension, schreiben eine run.graphql-Abfrage, die die benötigten Warenkorbdaten abruft, schreiben eine run.rs- oder run.js-Datei, die Aktionen (Rabatte, ausgeblendete Versandarten etc.) zurückgibt, deployen mit shopify app deploy und aktivieren sie über den Admin-Bereich oder eine GraphQL-Mutation. Functions werden als kompiliertes WASM mit einer Latenz von unter 5 ms ausgeführt, laufen in jedem Tarif und sind der einzige Anpassungspfad, den Shopify künftig unterstützt.

Was sich am 30. Juni tatsächlich ändert

Bevor wir Code anfassen, müssen die Daten klar sein. Es gibt zwei Fristen, und beide sind wichtig.

Die Migration ist binär. Entweder ist Ihre Function bis zum 30. Juni deployed und Ihr Checkout funktioniert weiterhin, oder nicht – und jeder betroffene Warenkorb fällt geräuschlos auf Standardpreise, Standardversandtarife und alle aktivierten Zahlungsmethoden zurück. Es gibt keine Teilpunkte. Das Script läuft oder es läuft nicht, und nach dem 30. Juni läuft es nicht mehr.

Tipp: Öffnen Sie Settings → Checkout → Customizations Report in Ihrem Shopify-Admin-Bereich. Dort finden Sie jedes aktive Script in Ihrem Store, was es tut und den empfohlenen Typ für den Function-Ersatz. Beginnen Sie dort.

Functions vs. Scripts: Was sich wirklich geändert hat

Der architektonische Wechsel ist entscheidend. Scripts waren „Ruby in einer Textarea anpassen“. Functions sind „eine echte App schreiben, versionieren, lokal testen und über eine echte CI-Pipeline deployen“. Das erfordert mehr Einarbeitung. Es ist aber auch die letzte Migration, die Sie für die Checkout-Logik auf absehbare Zeit durchführen werden – Functions sind die langfristige Ausrichtung von Shopify, keine Zwischenlösung wie es Scripts letztendlich waren.

Ihre Scripts dem richtigen Function-Typ zuordnen

Jedes Script, das Sie heute im Einsatz haben, lässt sich genau einer Function API zuordnen. Hier ist die Übersichtstabelle für Ihren Monitor.

Wenn Sie zehn Scripts haben, werden Sie wahrscheinlich drei bis fünf Functions erstellen – mehrere Scripts lassen sich oft in einer einzigen Function mit sauberer Verzweigungslogik zusammenfassen.

Voraussetzung: Lokale Entwicklungsumgebung einrichten

Bevor Sie eine Function erstellen, müssen drei Dinge lokal installiert sein. Führen Sie diese Prüfungen in Ihrem Terminal durch.

1. Node.js 18+

node --version
# Must be >= 18.0.0

node --version
# Must be >= 18.0.0

Falls älter, über nvm installieren oder von nodejs.org herunterladen.

2. Shopify CLI 3+

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

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

3. Rust-Toolchain (nur wenn Sie Functions in Rust schreiben)

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

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

JavaScript-Functions benötigen kein Rust. Wählen Sie eine Sprache für Ihr Team – das Mischen von beiden erhöht den Wartungsaufwand.

4. Ein Development Store

Melden Sie sich in Ihrem Partner-Dashboard an und erstellen Sie einen neuen Development Store oder nutzen Sie einen bestehenden. Sie werden Functions auf diesem Store testen, bevor Sie sie in die Live-Umgebung übertragen.

Ihre erste Function erstellen

Die CLI übernimmt den Großteil des Boilerplates. In einem beliebigen Verzeichnis:

# 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

# 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

Die CLI führt Sie durch die Eingabeaufforderungen. Für eine Discount-Function wählen Sie:

• Type: Function

• Template: discount (oder cart_checkout_validation, delivery_customization, payment_customization, etc.)

• Language: Rust oder JavaScript

• Name: etwa volume-discount-fn

Dies erstellt extensions/volume-discount-fn/ mit:

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

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

Die drei Dateien, die Sie ständig bearbeiten werden, sind die .toml (Konfiguration), die .graphql (Input) und die .rs / .js (Logik). Das ist alles.

Tutorial 1: Ersetzen eines Line Item Scripts (Mengenrabatt)

Angenommen, Ihr altes Script gewähre 10 % Rabatt auf die Zwischensumme, sobald der Warenkorb 5 oder mehr Artikel aus einer bestimmten Collection enthielt. Hier ist das Function-Äquivalent.

Schritt 1.1: Die Konfiguration (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"]

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"]

Schritt 1.2: Die Input-Abfrage (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
  }
}

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

Tipp: Functions sehen nur die Daten, die Sie abfragen. Halten Sie die GraphQL-Abfrage minimal – jedes übersprungene Feld bedeutet eine schnellere, ressourcenschonendere Ausführung.

Schritt 1.3: Die Logik (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,
                }],
            },
        )],
    })
}

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,
                }],
            },
        )],
    })
}

Schritt 1.4: Testen, deployen, aktivieren

# 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:

# 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 }
  }
}

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 }
  }
}

Das ist alles. Die Function ist live, versioniert und ersetzt das alte Script vollständig.

Tutorial 2: Ersetzen eines Shipping Scripts (Versandart ab Warenkorb-Schwellenwert ausblenden)

Ein gängiges Script: „Expressversand ausblenden, wenn die Warenkorb-Zwischensumme über 500 $ liegt, um teuren Expressversand bei großen Bestellungen zu verhindern.“ Hier ist die Version als Delivery Customization Function.

Schritt 2.1: Erstellen

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

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

Schritt 2.2: Input-Abfrage (src/run.graphql)

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

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

Schritt 2.3: Logik (src/run.js — JavaScript-Variante)

// @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 };
}

// @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 };
}

Schritt 2.4: Aktivieren über den Admin-Bereich (keine GraphQL-Abfrage erforderlich)

Delivery Customizations verfügen über eine integrierte Admin-Benutzeroberfläche. Nach shopify app deploy:

1. Gehen Sie zu Einstellungen → Versand und Zustellung

2. Scrollen Sie ganz nach unten zum Bereich Anpassungen

3. Klicken Sie auf Anpassung hinzufügen → wählen Sie Ihre Function aus

4. Speichern

Die Regel zum Ausblenden ist in der Live-Umgebung aktiv. Keine Mutation erforderlich.

Tutorial 3: Ersetzen eines Payment Scripts (Nachnahme für B2B ausblenden)

Altes Script: „Nachnahme für alle Kunden mit dem Tag 'B2B' ausblenden.“ Hier ist die Version als Payment Customization.

Schritt 3.1: Erstellen

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

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

Schritt 3.2: Input-Abfrage

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

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

Schritt 3.3: Logik (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 } }],
  };
}

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 } }],
  };
}

Schritt 3.4: Aktivieren

Payment Customizations haben ebenfalls eine Admin-Benutzeroberfläche unter Einstellungen → Zahlungen → Anpassungen. Gleicher Ablauf wie beim Versand: Wählen Sie Ihre Function, speichern Sie, fertig.

Da Sie dies gerade lesen – ein Wort zu Post-Purchase

Ein kurzer Hinweis, da dies der Blog von Revize ist. Revize kümmert sich um die Dinge, die Functions nicht berühren können – sobald eine Bestellung aufgegeben wurde, möchten Kunden Artikel hinzufügen, eine Größe ändern, die Lieferadresse korrigieren oder einen vergessenen Rabatt anwenden. Functions greifen beim Checkout. Revize greift danach. Functions entscheiden, was im Warenkorb erlaubt ist; Revize gibt Ihren Kunden und Ihrem Support-Team die Möglichkeit, die Bestellung nachträglich zu bearbeiten, ohne einen Erstattungs- und Neubestellungsprozess anstoßen zu müssen. Das ist für zwei Arten von Stores wichtig: solche mit so hohem Bestellvolumen, dass die manuelle Bearbeitung kollabiert (Plus-Betreiber natürlich, aber auch volumenstarke Advanced-Stores), und solche, deren gesamte Marke auf dem Kundenerlebnis basiert – wo eine E-Mail mit dem Inhalt „Es tut uns leid, das können wir nicht mehr ändern“ ein Killer für Wiederkäufe ist.

Wenn Ihr Migrationsplan Scripts → Functions abdeckt, Sie aber die Bearbeitung von Bestellungen nach dem Kauf noch nie gelöst haben, werden Sie in etwa drei Wochen auf das nächste Problem stoßen. Der gerade von uns veröffentlichte Leitfaden zum Bestellmanagement zeigt die vollständige Strategie für die Phase nach dem Checkout.

Zurück zur Migration.

Teststrategie: Das Pattern mit getaggten Kunden

Functions haben keinen „Entwurfsmodus“, den Sie im Admin-Bereich umschalten können. Der professionelle Weg besteht darin, die neue Function an ein Kunden-Tag zu binden, das alte Script und die neue Function parallel laufen zu lassen, zu überprüfen, ob sie für getaggte Benutzer identische Ergebnisse liefern, und dann den Schalter umzulegen.

Schritt 1: Testbenutzer taggen

Fügen Sie unter Kunden das Tag FN-TESTER zu zwei oder drei internen Konten hinzu.

Schritt 2: Function basierend auf dem Tag verzweigen

// 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

// 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

Schritt 3: Fügen Sie hasAnyTag zu Ihrer Input-Abfrage hinzu

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

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

Schritt 4: Im Checkout überprüfen

Melden Sie sich als getaggter Benutzer an, durchlaufen Sie den Checkout und bestätigen Sie, dass die Function ausgeführt wird. Melden Sie sich als nicht getaggter Benutzer an und bestätigen Sie, dass das alte Script weiterhin läuft. Wenn die Gleichwertigkeit einige Tage lang gegeben ist, entfernen Sie die Tag-Prüfung und lassen Sie die Function für alle laufen.

Schritt 5: Altes Script deaktivieren

Gehen Sie zu Apps → Script Editor → [Ihr Script] → Unpublish. Nach der Deaktivierung ist die Function die einzige Source of Truth.

Ein Deployment-Workflow, der tatsächlich skaliert

Deployen Sie nicht für immer vom Laptop eines Entwicklers aus. Sobald Sie ein oder zwei Scripts migriert haben, richten Sie eine echte CI-Pipeline ein.

Der minimale funktionsfähige Workflow

# .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 }}

# .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 }}

Erzeugen Sie das Partner-Token in Ihrem Partner-Dashboard unter Settings → Tokens. Jetzt überträgt jeder Merge in den Branch main Ihre Functions. Keine Slack-Nachrichten mehr mit der Frage „Hat Mike das deployed?“.

Versionierung und Rollback

shopify app deploy erstellt einen versionierten Snapshot. Für ein Rollback:

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

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

Im Vergleich zu Scripts – wo ein Rollback bedeutete, den alten Code manuell herauszusuchen und wieder einzufügen – ist das ein Unterschied wie Tag und Nacht.

Was die meisten Teams falsch machen

Nachdem wir im vergangenen Jahr Plus-Händlern bei dieser Migration geholfen haben, treten immer wieder die gleichen fünf Fehler auf.

1. Functions wie eine 1:1-Kopie des Scripts behandeln. Das sind sie nicht. Eine einzige Function kann drei Scripts durch sauberere Verzweigungen ersetzen. Analysieren Sie Ihre Scripts als Gesamtsystem, bevor Sie sie neu schreiben.

2. Die Read Scopes vergessen. Viele Functions benötigen read_customers, read_orders oder write_discounts. Fügen Sie diese in shopify.app.toml unter scopes hinzu und autorisieren Sie die App erneut, da Ihre Input-Abfrage andernfalls null zurückgibt.

3. Functions für nicht getaggte Kunden ohne Paralleltests ausführen. Selbst wenn Ihr Code korrekt aussieht, werden Edge Cases (leerer Warenkorb, Geschenkkarten, Store Credit, B2B-Entwürfe) Probleme aufwerfen. Ein über Tags gesteuerter Rollout kostet Sie zwei Tage und bewahrt Sie vor einem kritischen Ausfall.

4. Den Customizations Report ignorieren. Er ist die beste Bestandsaufnahme dessen, was tatsächlich aktiv ist. Migrieren Sie nicht aus dem Gedächtnis – migrieren Sie auf Basis des Berichts.

5. Collection-IDs und Kunden-Tags fest im Code hinterlegen. Nutzen Sie die Konfiguration von Functions über Metafields, wenn Sie Werte benötigen, die vom Händler angepasst werden können. Die CLI kann eine auf Metafields basierende Konfiguration erstellen – siehe dazu die Shopify-Dokumentation zur Konfiguration von Functions.

Migrations-Checkliste für die nächsten 75 Tage

Ein realistischer Wochenplan, um den 30. Juni entspannt zu erreichen.

Wenn Sie diese Woche beginnen, haben Sie einen Puffer. Wenn Sie erst im Juni anfangen, nicht.

Häufig gestellte Fragen (FAQ)

Benötige ich Shopify Plus, um Functions zu nutzen?

Custom Functions erfordern Shopify Plus, aber Functions über Public Apps funktionieren in jedem Tarif. Wenn Sie nicht den Plus-Tarif nutzen, haben Sie zwei Möglichkeiten: Installieren Sie eine Public App aus dem Shopify App Store, die die Function für Sie bereitstellt, oder wechseln Sie zu Plus, um Ihre eigenen Custom Functions zu schreiben. Die meisten großen Händler, die Scripts nutzten, hatten ohnehin bereits Plus, sodass sich in der Praxis selten etwas ändert.

Kann ich Functions in TypeScript schreiben?

Ja – TypeScript wird vollständig unterstützt und die CLI stellt das entsprechende Template bereit. Wenn Sie shopify app generate extension ausführen und „JavaScript“ wählen, enthält das generierte Projekt Typdeklarationen aus import("../generated/api"). Sie können Dateien in .ts konvertieren und eine tsconfig.json hinzufügen, falls gewünscht. Der kompilierte Output (WASM) ist unabhängig von der Ausgangssprache identisch.

Wie schnell sind Functions im Vergleich zu Scripts?

Functions werden in der Regel unter 5 ms ausgeführt – deutlich schneller als Ruby-Scripts. Da sie in WebAssembly kompiliert werden und in einer minimalistischen Laufzeitumgebung laufen, setzt Shopify ein Limit von 5 ms für die Ausführung. Wenn Ihre Function dieses Limit überschreitet, wird die Aktion abgebrochen und Ihre Function gibt keine Operationen zurück. In der Praxis benötigt eine gut geschriebene Function 1–2 ms. Das Performance-Limit ist viel höher als bei Scripts.

Kann eine Function eine externe API aufrufen?

Nein – Functions können keine Netzwerkanfragen stellen. Sie sind reine Rechenoperationen: Input Warenkorbdaten → Output Aktionen. Wenn Sie externe Daten benötigen (einen CRM-Abgleich, eine Echtzeit-Bestandsprüfung), müssen Sie die Daten entweder vorab in Metafields speichern oder eine andere Methode nutzen (App Proxy, Webhooks, Cart Transform mit Backend-Abruf). Dies ist der häufigste Grund, warum Teams Logiken neu konzipieren müssen, anstatt sie einfach nur zu übertragen.

Was ist der Unterschied zwischen Cart Transform und Discounts?

Discounts wenden Preisänderungen an; Cart Transform ändert den Inhalt des Warenkorbs. Nutzen Sie die Discounts API, um 10 % Rabatt, kostenlosen Versand oder BOGO-Aktionen anzuwenden. Nutzen Sie Cart Transform, um zwei Produkte zu einem Line Item zu bündeln oder eine Variante in mehrere aufzuteilen. Viele alte Scripts haben beide Bereiche vermischt – trennen Sie diese bei der Migration in zwei Functions auf.

Wie teste ich eine Function lokal ohne einen Development Store?

Sie können Unit-Tests mit cargo test (Rust) oder npm test (JS) ausführen, aber für vollständige Integrationstests ist ein Development Store erforderlich. Die CLI bietet shopify app function run, wodurch Ihre Function mit einer Beispiel-Input-Datei ausgeführt wird – nützlich für schnelle Iterationen. Um das Checkout-Verhalten jedoch End-to-End zu überprüfen, benötigen Sie einen echten Store mit einem echten Warenkorb.

Kann ich mehrere Functions desselben Typs nutzen?

Ja – Shopify unterstützt mehrere Functions pro Target, und sie werden in einer festgelegten Reihenfolge ausgeführt. Bei Rabatten wird die Reihenfolge durch die Shopify-Regeln für das Kombinieren von Rabatten bestimmt. Bei Delivery und Payment Customizations können Sie Functions verketten, wobei jeder Output in den nächsten einfließt. Die meisten Teams nutzen der Einfachheit halber eine Function pro Typ.

Was passiert mit meinem Script, nachdem ich die Function deploye?

Beide laufen parallel, bis Sie das Script unter Apps → Script Editor deaktivieren. Dies ist so gewollt – es gibt Ihnen die Möglichkeit für parallele Tests. Deaktivieren Sie das Script manuell, nachdem Sie die Funktion der Function überprüft haben. Nach dem 30. Juni 2026 werden alle Scripts gestoppt, unabhängig davon, ob Sie sie deaktiviert haben oder nicht.

Beeinträchtigt die Migration mein SEO oder mein Theme?

Nein – Functions werden serverseitig beim Checkout ausgeführt und berühren weder Ihr Theme noch Ihre Produktseiten. Sie ändern lediglich Rabatte, Versandoptionen und Zahlungsmethoden im Checkout. Ihr Storefront, Ihre Produkttemplates und Ihr SEO bleiben völlig unberührt.

Wie migriere ich ein Script, das Input.line_items mit benutzerdefinierten Eigenschaften nutzt?

Benutzerdefinierte Eigenschaften sind über das Feld attribute der Warenkorbzeilen im GraphQL-Input zugänglich. Fügen Sie attribute(key: "your-key") { value } innerhalb der lines-Auswahl hinzu. Die Function liest dies genauso aus wie Scripts die Line Item Properties gelesen haben – nur über GraphQL statt über Ruby-Methodenaufrufe.

Wie sieht es mit Analytics und Order Tags aus? Können Functions Daten schreiben?

Functions können selbst keine Order Tags schreiben oder Webhooks auslösen – sie geben nur Operationen für den aktuellen Warenkorb zurück. Verwenden Sie für das Tagging oder nachgelagerte Workflows Shopify Flow, das durch das Ereignis der Bestellerstellung ausgelöst wird. Viele Händler kombinieren eine Function (für den Rabatt) mit einem Flow (um „VOLUME-DISCOUNT-APPLIED“ an der Bestellung zu taggen).

Gibt es eine Public App, die ich anstelle einer Custom Function installieren kann?

Ja – der Shopify App Store bietet Dutzende von Apps, die Functions für gängige Anwendungsfälle bereitstellen. Suchen Sie nach „Discount Function“, „Delivery Customization“ oder „Payment Customization“. Für einfache Anwendungsfälle (Mengenrabatte, Ausblenden von Zahlungsarten nach Tag, kostenloser Versand ab X) kann eine bestehende App Ihnen tagelange Entwicklungsarbeit ersparen. Nutzen Sie Custom Functions nur für Logiken, die für Ihr Unternehmen absolut einzigartig sind.

Was passiert, wenn ich die Deadline am 30. Juni verpasse?

Die Ausführung der Scripts stoppt – es gibt kein Fallback, keine Übergangsfrist und keine Verlängerung. Was auch immer das Script gesteuert hat (der Rabatt, der ausgeblendete Versandtarif, die blockierte Zahlungsmethode), fällt am 1. Juli um Mitternacht UTC auf das Standardverhalten zurück. Wenn Ihr Geschäft von dieser Logik abhängt, planen Sie ein, lange vor diesem Datum live zu gehen. Die Migration dauert meist länger, als Teams anfangs schätzen, insbesondere wegen der Tests auf Gleichwertigkeit.

Kann ich die Script Editor App vollständig löschen?

Sie können sie nach dem 30. Juni 2026 deinstallieren, Shopify wird sie jedoch voraussichtlich automatisch entfernen. Sobald Scripts nicht mehr ausgeführt werden, hat der Editor keinen Nutzen mehr. Sie können auch jetzt schon alle Scripts deaktivieren und die App sofort deinstallieren, wenn Sie die Migration abgeschlossen haben – Ihre Functions laufen unabhängig davon.

Was diese Woche zu tun ist

Lesen Sie diesen Artikel nicht nur, um dann den Tab zu schließen. Erledigen Sie diese vier Dinge in den nächsten sieben Tagen.

1. Rufen Sie den Customizations Report ab. Gehen Sie zu Settings → Checkout → Customizations Report. Exportieren Sie ihn. Das ist Ihr Migrations-Backlog.

2. Richten Sie Ihre Entwicklungsumgebung ein. Installieren Sie Node 18+, Shopify CLI und Rust (falls zutreffend). Überprüfen Sie, ob shopify version funktioniert. Zeitaufwand: 30 Minuten.

3. Erstellen und deployen Sie eine kleine Function in einem Development Store. Wählen Sie das einfachste Script, das Sie haben – meist eine Regel zum Ausblenden einer Zahlungsart. Migrieren Sie es End-to-End. Selbst wenn es nie in die Live-Umgebung geht, haben Sie die Toolchain validiert.

4. Blockieren Sie Zeit im Kalender für die nächsten acht Wochen. Migrationen laufen nicht nebenher zwischen Sprints. Planen Sie ein festes Zeitfenster ein – beispielsweise jeden Dienstag- und Donnerstagnachmittag – und behandeln Sie es wie ein offizielles Release.

Bei den Teams, deren Migration wir begleitet haben, zeigt sich ein klares Muster: zwei Wochen Zögern, drei Wochen tatsächliche Arbeit, eine Woche Bereinigung. Das sind sechs Wochen. Sie haben zehn. Nutzen Sie den Puffer für Code Reviews und QA, nicht für das Aufschieben des Starts.

Sobald Ihre Checkout-Logik steht, ist das nächste Thema für die meisten Teams die Phase nach dem Kauf – Adressänderungen durch Kunden, Artikeltausch oder das Hinzufügen von Rabatten nach der Bestellung. Wenn das auf Ihrer Roadmap steht (und das sollte es, egal ob Sie ein volumenstarker Plus-Betreiber oder ein serviceorientierter Advanced-Store sind), finden Sie Revize im Shopify App Store – bereit für den Einsatz neben jeder Function, die Sie hier aufbauen.

Ressourcen

• Shopify Functions Übersicht — Shopify Developer Docs

• Migration von Shopify Scripts zu Functions

• Tutorial: Eine Discount Function erstellen

• Delivery Customization Function API-Referenz

• Payment Customization Function API-Referenz

• Shopify CLI Dokumentation

Verwandte Artikel

• Shopify Bestellmanagement: Der vollständige Leitfaden für 2026

• Shopify Checkout Extensibility 2026: Sie haben die Deadline verpasst. Was nun?

• Das Universal Commerce Protocol (UCP): Was jeder Shopify-Entwickler wissen muss

• Klassische Shopify-Kundenkonten sind veraltet

• Beste Shopify Kundenservice-Apps für 2025 (getestet & bewertet)

Aktualisiert im August 2026. Revize ist eine Shopify-App für die selbstständige Bearbeitung von Bestellungen nach dem Kauf durch den Kunden. Käufer können damit noch vor der Ausführung und ohne Support-Ticket die Lieferadresse ändern, Varianten oder Produkte tauschen, stornieren und eine Erstattung oder Store Credit erhalten. Erfahren Sie mehr darüber, wie Sie Kunden ihre eigenen Shopify-Bestellungen bearbeiten lassen, oder finden Sie Revize im Shopify App Store.