checkoutwoocommerce
WooCommerce-Checkout-Shortcode: Nutzung, Probleme und Block-Migration
23. Oktober 20269 min Lesezeit·ShopMonitor Team
Loading…
Der WooCommerce-Checkout-Shortcode heißt [woocommerce_checkout]. Er gehört auf genau eine Seite: die WordPress-Seite, die WooCommerce als Checkout zugewiesen ist. Dort erscheinen Formular, Adressfelder, Bestellübersicht und Zahlungsarten. Auf einer anderen Seite ist er nur Inhalt am falschen Ort. Dann wirkt der Checkout schnell leer oder kaputt, obwohl nur eine Einstellung fehlt.
WooCommerce-Einstellung für die Checkout-Seite
Öffne WooCommerce > Einstellungen > Erweitert > Seiteneinrichtung. Dort ordnest du WordPress-Seiten für Warenkorb, Checkout und Konto zu. Damit der Checkout funktioniert, müssen zwei Dinge passen: Die gewählte Seite enthält den Shortcode oder den Checkout-Block. WooCommerce muss genau diese Seite verwenden.
WooCommerce speichert die Auswahl als Seiten-ID und nutzt sie im gesamten Kaufprozess. Weiterleitungen aus dem Warenkorb, wc_get_checkout_url() in eigenem Code, Rückkehr-URLs von Zahlungsanbietern, Zahlungslinks für bestehende Bestellungen und die Bestellbestätigung richten sich nach dieser ID.
Zeigt die Einstellung auf die falsche Seite, kann der Shortcode trotzdem dort erscheinen, wo du ihn eingefügt hast. Die von WooCommerce erzeugten URLs führen dann aber an einen anderen Ort.
Fehlt die Zuweisung oder ist sie veraltet, sehen die Symptome oft nicht nach einem Einstellungsproblem aus:
Findest du die Option nicht oder bleibt eine Änderung wirkungslos, erklärt unsere Anleitung zu Anpassen der WooCommerce-Checkout-Seite das aktuelle Layout und mögliche Überschreibungen, die Einstellungen verdecken.
WooCommerce bietet zwei Wege zum Checkout. Der klassische Shortcode [woocommerce_checkout] läuft über PHP-Templates und die etablierten Action- und Filter-Hooks darum herum. Der Checkout-Block nutzt die Block-Oberfläche und speichert seine Konfiguration in Block-Attributen.
Neue Shops können mit blockbasierten Warenkorb- und Checkout-Seiten starten. Bestehende Shops behalten ihren Shortcode, bis ihn jemand bewusst ersetzt. WooCommerce migriert keinen Live-Checkout im Hintergrund. Beide Wege werden weiter unterstützt und über die Block-Werkzeugleiste lässt sich in beide Richtungen umwandeln. Das macht einen kontrollierten Test deutlich sicherer.
WooCommerce-Checkout-Shortcode im Vergleich zum Checkout-Block
Beide Wege arbeiten mit denselben Bestelldaten. Entscheidend ist, wo eigene Logik und Erweiterungen ansetzen. Das entscheidet darüber, ob eine kurze Anpassung reicht oder eine echte Migration ansteht.
| Bereich | Klassischer Shortcode | Checkout-Block |
|---|---|---|
| Darstellung | PHP-Templates, serverseitig gerendert | Blockbasiert, im Browser gerendert |
| Felder anpassen | Klassische Hooks und Filter, Template-Überschreibungen | Block-Einstellungen plus Additional Checkout Fields API |
| Zahlungsgateways | Funktioniert mit jedem Gateway, das den klassischen Checkout unterstützt | Braucht ein Gateway mit Block-Unterstützung oder einen Kompatibilitäts-Fallback |
| Kompatibilität mit Erweiterungen | Breit, weil die meisten Plugins für klassische Hooks geschrieben wurden | Je nach Erweiterung unterschiedlich. Der Editor markiert bekannte Inkompatibilitäten |
| Styling | Theme-CSS und Template-Überschreibungen | Block-Stile, theme.json und Block-Einstellungen |
| Neuere Checkout-Funktionen | Nicht verfügbar | Abholung vor Ort, Express-Zahlungsbereich und weitere Funktionen nur für Blöcke |
| Bearbeitung | Seiteninhalt und Code | Visuelle Bearbeitung mit Einstellungen im Editor |
Funktionsvergleich: Shortcode und Checkout-Block
Nimm den Kompatibilitätshinweis im Editor ernst. Beim Einfügen oder Umwandeln des Checkout-Blocks nennt WooCommerce bekannte inkompatible Erweiterungen. Das ist ein schneller Start für die Bestandsaufnahme, bevor du dich durch Changelogs arbeitest.
Einen pauschalen Sieger gibt es nicht. Entscheidend ist dein Shop.
Bleib beim Shortcode, wenn dein Checkout stark über klassische Hooks angepasst ist, ein wichtiges Gateway keine Block-Unterstützung hat oder eine kritische Erweiterung als inkompatibel markiert wird. Ein nachweislich funktionierender Checkout ist mehr wert als ein neuer Darstellungsweg.
Wechsle zum Block, wenn die Anpassungen überschaubar oder überwiegend visuell sind, die benötigten Gateways und Erweiterungen ihn unterstützen und seine Funktionen zu deinem Shop passen. Baust du die Seite ohnehin neu, bündele die Arbeit und teste alles als eine kontrollierte Änderung.
Zeigt eine Checkout-Seite nur Header und Footer, erkennt WooCommerce sie fast immer nicht als Checkout-Seite. Geh zu WooCommerce > Einstellungen > Erweitert > Seiteneinrichtung und prüfe, ob „Checkout-Seite“ wirklich auf die Seite zeigt, die du aufrufst. Gehe dann diese drei Punkte der Reihe nach durch:
Stimmt die Zuweisung und die Seite bleibt leer, prüfe den Quelltext. Leeres Markup zwischen Header und Footer kann auf einen unterdrückten PHP-Fehler hinweisen. Aktiviere WP_DEBUG_LOG auf Staging und lies das Protokoll, bevor du weitere Änderungen vornimmst.
Siehst du im Frontend den Text [woocommerce_checkout], hat WordPress ihn nicht verarbeitet. Dafür gibt es zwei häufige Ursachen.
Entweder steht der Shortcode in einem Bereich, der ihn als Rohtext ausgibt. Das kann ein Code-Block, ein vorformatierter Block oder ein Page-Builder-Textfeld sein. Oder der Shortcode ist beim Laden der Seite nicht registriert. Dann gibt WordPress ihn als Text aus, etwa wenn WooCommerce deaktiviert ist.
Prüfe auch auf Kopierfehler. Ein Leerzeichen am Ende von [woocommerce_checkout ] wird toleriert. Geschwungene Klammern oder geschützte Leerzeichen hingegen nicht. Tippe den Shortcode direkt in WordPress neu ein.
Zwei Checkout-Formulare bedeuten, dass zwei Ausgaben aktiv sind. Vielleicht steht der Shortcode zweimal im Inhalt. Oder ein Theme- oder Builder-Template liefert den Checkout bereits und der Shortcode setzt eine zweite Kopie darunter.
Das ist mehr als ein optischer Fehler. Beide Formulare senden an denselben Handler und nutzen gleiche Feldnamen sowie Nonces. Die Folge können Validierungsfehler, falsche Summen oder ein scheinbar wirkungsloser Absenden-Button sein.
Behebe die doppelte Ausgabe an der Quelle statt ein Formular mit CSS zu verstecken. Entferne den Shortcode, wenn das Template den Checkout liefert. Verwende ein schlichtes Seitentemplate, wenn der Shortcode die Seite allein füllen soll.
Elementor, Divi und WPBakery legen eigenes Markup und JavaScript um den Seiteninhalt. Das führt oft zu drei Fehlerbildern. Manche Builder brauchen ein eigenes Shortcode-Widget oder ein eigenes Modul statt eines Textfelds. Andernfalls erscheint der Shortcode nur als Text. Verschachtelte Container können außerdem die AJAX-Aktualisierung von Versandkosten und Summen stören.
Die dritte Falle ist leicht zu übersehen: Viele Builder liefern ein eigenes Checkout-Widget. Nutzt du es zusammen mit dem Shortcode auf derselben Seite, erscheint der Checkout doppelt.
Um den Builder als Ursache einzugrenzen, erstelle auf Staging eine schlichte WordPress-Seite nur mit dem Shortcode. Weise sie als Checkout-Seite zu und rufe sie auf. Funktioniert der Checkout dort, liegt das Problem im Builder-Layout.
„Dein Warenkorb ist im Moment leer“ trotz gefülltem Warenkorb ist ein Session- oder Cache-Problem, kein Shortcode-Problem. WooCommerce erkennt Sitzungen über Cookies. Alles, was sie entfernt, verändert oder zwischenspeichert, kann den Warenkorb leer wirken lassen.
Typische Ursachen sind ein Cache oder CDN mit einer zwischengespeicherten Checkout-Seite, unterschiedliche Shop-Adressen oder ein zu aggressiver Objekt-Cache. Warenkorb und Checkout müssen vom Cache ausgeschlossen sein.
Checkout niemals zwischenspeichern
Eine Migration scheitert selten auf einen Schlag. Sie kann für ein Gateway, einen Produkttyp oder ein Land ausfallen, während der Rest des Checkouts weiterläuft. Deshalb braucht sie einen klaren Ablauf.
Diese Probleme treten besonders häufig auf:
Kompatibilität eigener Felder
Eigene Felder machen oft den größten Unterschied. Felder aus dem klassischen Checkout-Felder-Array oder aus Ausgabe-Hooks erscheinen nicht automatisch im Checkout-Block. Der Block nutzt dafür die Additional Checkout Fields API. Ein Feld umzuziehen heißt, es dort neu zu registrieren statt das alte Snippet zu kopieren.
Erfasse vor der Migration jedes eigene Feld samt Quelle: eigenes Snippet, Plugin oder Builder. Alles, was du nicht zuordnen kannst, ist ein Risiko. Kannst du die Felder nicht aus dem Kopf aufzählen, ist das Anpassen der Checkout-Seite mit Blick auf den Block der bessere Startpunkt.
Unterstützung für Zahlungsgateways
Viele große Gateways unterstützen den Checkout-Block. Einige ohne native Unterstützung können über eine Kompatibilitätsschicht trotzdem erscheinen. Entscheidend ist: Sie können es, müssen es aber nicht.
Prüfe die Dokumentation jeder aktivierten Zahlungsart. Teste dann im Editor: Platziere den Checkout-Block auf einer Staging-Seite und lies den Kompatibilitätshinweis. Behandle jedes unbestätigte Gateway als nicht unterstützt, bis eine Testbestellung das Gegenteil beweist. Das gilt auch für selten genutzte Zahlungsarten.
Beginne auf Staging und gehe in dieser Reihenfolge vor:
Klassische Seite behalten
Eine Änderung an der Checkout-Seite betrifft die Seite selbst, ihre Zuweisung und jede Route, die eine Checkout-URL aufruft. Teste den gesamten Kaufpfad statt nur den ersten Seitenaufruf:
Schritt 4 deckt viele Builder- und Block-Probleme auf, weil er von der AJAX-Bestellübersicht abhängt und nicht nur vom ersten Laden der Seite. Unser Guide zum Testen deines Checkouts erklärt den manuellen Test ausführlicher. Begann der Fehler nach einem Plugin- oder Core-Update, Checkout kaputt nach Update hilft beim schnelleren Eingrenzen.
Genau dieses Muster macht Checkout-Änderungen riskant: Die Seite wirkt in Ordnung, während ein Teil der Bestellungen nicht mehr durchgeht. ShopMonitor führt täglich browserbasierte Checkout- und Formulartests aus und meldet Fehler im Formular oder auf dem Bestellbestätigungsweg. Künftig wird ShopMonitor außerdem die Zustellung transaktionaler E-Mails testen können.
ShopMonitor testet Checkout- und Formularabläufe täglich im Browser und meldet dir, wenn ein Pfad bricht. Künftig wird ShopMonitor außerdem die Zustellung transaktionaler E-Mails testen können. Keine Code-Änderungen. Kein Plugin für die Browser-Tests erforderlich. Schnell eingerichtet.
Keine Kreditkarte nötig.
Über das Autorenteam
Verfasst vom Team bei Winning Solutions, der Agentur hinter ShopMonitor. Wir helfen WooCommerce-Teams, ihr Checkout-Verhalten nach Shortcode-Änderungen, Korrekturen der Seitenzuweisung und Migrationen vom Shortcode zum Block zu prüfen.