WooCommerce Entwickler in Karlsruhe

Ein Shop mit kleinem Sortiment und wenigen Bestellungen verzeiht vieles. Bei einem großen Katalog und vielen Bestellungen wird jede Entscheidung über Datenbank, Warteschlange und Cache sichtbar: im Checkout, im Backend und im Abgleich mit Ihrem ERP. Ich bin ein einzelner WooCommerce-Entwickler in Gdynia, arbeite remote und schriftlich und baue solche Shops so um, dass jeder Schritt vorher auf einer Kopie erprobt ist.

Foto: Achim Lammerts (Syntaxys), CC BY-SA 4.0, Wikimedia Commons.

#Woran Sie merken, dass Ihr Shop ein Mengenproblem hat

Die Anzeichen sind meist unspektakulär: Die Bestellliste im Backend lädt träge, ein Export für die Buchhaltung bricht ab, Statusmails kommen spät, oder ein Import läuft nachts nicht mehr durch. Meist ist es kein einzelner Fehler, sondern ein Zusammenspiel aus Bestelldaten, Hintergrundjobs und Datenbankabfragen.

Auf karlsruhe.de nennt die Stadt für die Messe Karlsruhe unter anderem die Publikumsmesse offerta und die Fachmessen LEARNTEC, IT-TRANS und NUFAM. Wer als Betrieb aus der Region auf so einer Messe ausstellt und danach Anfragen und Bestellungen im Shop bekommt, erlebt Lastspitzen zu einem Termin, den er vorher kennt. Auf einen bekannten Termin können Sie sich vorbereiten.

Deshalb stelle ich zu Beginn vier Fragen:

1. Wie viele Bestellungen und Produkte hat der Shop, und wie viele kommen an einem starken Tag hinzu?
2. Welche Systeme lesen oder schreiben Bestellungen: ERP, Versand, Buchhaltung, Auswertungen?
3. Welche Plugins greifen auf Bestelldaten zu?
4. Gibt es Termine mit absehbarer Last, etwa Messen, Newsletter oder Aktionen?

#HPOS bei vielen Bestellungen: der Umstieg in Phasen

Mit High-Performance Order Storage (HPOS) speichert WooCommerce Bestellungen in eigenen Tabellen statt in den allgemeinen Tabellen von WordPress. Für neue Installationen ist das seit WooCommerce 8.2 Standard. Bei einem bestehenden Shop mit vielen Bestellungen ist der Umstieg ein Projekt. Die Entwickler von WooCommerce haben dafür eine eigene Anleitung für große Shops geschrieben. Ich halte mich daran:

Phase 1, lokal. Alle Plugins und eigener Code laufen mit den neuesten Versionen. Getestet werden der Checkout mit jeder Zahlart, Erstattungen, bei Abos auch Verlängerungen und alle Abläufe, die für Ihren Shop kritisch sind, jeweils mit und ohne Synchronisation.

Phase 2, Staging. Die Produktionsdatenbank kommt auf eine Kopie. Die Migration läuft nicht über die Hintergrundjobs, sondern über WP-CLI, weil das bei großen Beständen schneller ist. Die Dauer wird gemessen: Im Testshop der WooCommerce-Entwickler mit 9 Millionen Bestellungen dauerte sie laut Anleitung etwa eine Woche. Danach prüfe ich mit wp wc hpos verify_data --verbose, ob die Daten übereinstimmen, und wiederhole alle Tests mit Synchronisation an und aus.

Phase 3, Produktion. Zuerst wird die Synchronisation eingeschaltet, die Posts-Tabellen bleiben führend. Dann wandern die vorhandenen Bestellungen per wp wc hpos sync. Erst danach werden die HPOS-Tabellen führend. Die Anleitung betont, dass der Wechsel in beide Richtungen im laufenden Betrieb möglich ist und keine geplante Ausfallzeit braucht. Wer kann, wählt eine ruhige Zeit und bleibt danach online, um echte Bestellungen zu prüfen.

#Die Befehle, die ich dafür nutze

Die vollständige Liste mit Optionen steht in der Dokumentation zu wc hpos und in den HPOS-CLI-Werkzeugen. Den älteren Namensraum wp wc cot führt die Dokumentation als veraltet.

#Kompatibilitätsmodus: was er sichert und woran er scheitert

Im Kompatibilitätsmodus hält WooCommerce beide Speicherorte gleich. Das ist die Absicherung für den Umstieg: Geht etwas schief, kann der Shop laut Anleitung sofort auf die Posts-Tabellen zurück. Er hat aber Grenzen, an denen ich in Projekten oft hänge:

• Plugins. Ist ein aktives Plugin nicht kompatibel, sperrt WooCommerce die HPOS-Option. Die betroffenen Plugins zeigt die Plugin-Liste im Filter “incompatible with feature” (WooCommerce, Dokumentation für Händler). Auf der Kommandozeile listet wp wc hpos compatibility-info bekannte kompatible, inkompatible und unklare Plugins.
• Direkter Datenbankzugriff. Die Anleitung für große Shops warnt vor Systemen, die ohne PHP direkt an der Datenbank hängen, etwa Data Warehouse, Sendungsverfolgung oder Buchhaltung. Lesen sie die Posts-Tabellen direkt, müssen sie vor dem Abschalten der Synchronisation angepasst werden.
• Eigener Code. Laut Rezeptbuch für Erweiterungen soll man Bestell-Metadaten nicht mit get_post_meta lesen oder schreiben, sondern über das Bestellobjekt (update_meta_data, dann save()). Direkte Lese- und Schreibzugriffe auf wp_posts und wp_postmeta können eine veraltete Bestellung liefern oder eine, die nie gelesen wird. Ich suche Ihren Code deshalb nach wpdb, Post- und Meta-Funktionen ab, wobei es Fehlalarme gibt.

Der Kompatibilitätsmodus ist kein Dauerzustand. Wer ihn nach dem Umstieg aus Vorsicht für immer eingeschaltet lässt, schreibt jede Bestellung zweimal. Die Anleitung für große Shops schaltet deshalb stufenweise ab: zuerst die Synchronisation beim Lesen (Filter woocommerce_hpos_enable_sync_on_read, weil sie mehr Ressourcen braucht), dann beim Schreiben. Im Beispiel der Entwickler lagen dazwischen sechs Stunden und eine Woche. Für Ihren Shop lege ich die Abstände schriftlich fest, abhängig von Bestellvolumen und angebundenen Systemen.

#Action Scheduler: die Warteschlange, die niemand ansieht

WooCommerce nutzt Action Scheduler für Hintergrundaufgaben. Auch der HPOS-Abgleich läuft zunächst darüber: Der Rückabgleich der Bestellungen geschieht laut Händlerdokumentation in Stapeln zu 25. Unter WooCommerce, Status, Geplante Aktionen sehen Sie, was offen ist, was läuft und was fehlgeschlagen ist.

Die Leistungsseite von Action Scheduler nennt die Standardwerte: Ein Durchlauf endet bei 90 Prozent des verfügbaren Speichers oder wenn drei weitere Aktionen das Zeitlimit von 30 Sekunden überschreiten würden. Der Stapel umfasst 25 Aktionen, es läuft ein Läufer gleichzeitig. Zeitlimit, Stapelgröße und Läufer lassen sich über die Filter action_scheduler_queue_runner_time_limit, action_scheduler_queue_runner_batch_size und action_scheduler_queue_runner_concurrent_batches ändern. Die Dokumentation rät ausdrücklich zur Vorsicht: Mehr gleichzeitige Läufer können die Last stark erhöhen und im schlimmsten Fall die Seite lahmlegen. Für mehr Durchsatz empfiehlt sie WP-CLI.

Mein Vorgehen bei einer wachsenden Warteschlange:

1. Ursache klären. Welcher Hook stapelt sich, aus welchem Plugin, seit wann? Ein Läufer, der schneller arbeitet, hilft nicht, wenn ein Plugin ständig neue Aufgaben nachschiebt.
2. Fehlgeschlagene Aktionen lesen. Seit Version 4.0.0 behält Action Scheduler fehlgeschlagene Aktionen standardmäßig drei Monate, mit action_scheduler_retention_period_for_failed lässt sich das ändern. Eine Liste voller Fehler ist ein Befund, kein Müll.
3. Über WP-CLI laufen lassen. wp action-scheduler run verarbeitet standardmäßig 100 Aktionen je Stapel und lässt sich mit --hooks und --group auf bestimmte Aufgaben begrenzen (WP-CLI-Dokumentation). Läuft ein echter Systemdienst statt WP-Cron, hängt die Abarbeitung nicht mehr vom Seitenaufruf ab.
4. Aufräumen mit Maß. wp action-scheduler clean entfernt standardmäßig abgeschlossene und abgebrochene Aktionen, die älter als 31 Tage sind, und lässt sich mit --batch-size und --pause schonend dosieren.

Stand November 2026 steht Action Scheduler im Plugin-Verzeichnis von WordPress.org in Version 4.2.0, die GitHub-Veröffentlichung stammt vom 16. September 2026. Welche Version Ihr Shop mitbringt, hängt von der installierten WooCommerce-Version ab.

#Objekt-Cache: was er tut und was nicht

Laut WordPress-Entwicklerdokumentation ist der Objekt-Cache standardmäßig nicht persistent: Die Daten leben nur für die Dauer einer Anfrage. Ohne persistenten Cache landen Transients in der Options-Tabelle. Persistent wird er erst mit einem passenden Plugin. Die Dokumentation nennt als Back-ends Redis, Memcached, Docket Cache und SQLite Object Cache. Die Konstante WP_CACHE allein bewirkt dafür nichts.

Für einen Shop mit vielen Bestellungen heißt das: Ein persistenter Objekt-Cache nimmt der Datenbank wiederholte Abfragen ab, aber er repariert keine langsame Abfrage, die jedes Mal etwas Neues fragt. Welcher Cache zu Ihrem Hosting passt, hängt davon ab, was Ihr Anbieter bereitstellt. Ich lese das vor dem Angebot aus Ihrer Umgebung ab, nicht aus einer Wunschliste.

Beim Seiten-Cache gilt die Regel aus der WooCommerce-Dokumentation: Warenkorb, Mein Konto und Kasse bleiben ungecacht, weil sie kundenabhängig sind. Bietet das Cache-System Datenbank-Caching, kann es sinnvoll sein, _wc_session_ auszunehmen. Passwort-Rücksetzungen, die in einer Schleife enden, deuten darauf hin, dass die Seite “Mein Konto” doch gecacht wird.

Ob der Shop danach besser läuft, messe ich an den Werten, die Google selbst nennt: LCP bis 2,5 s, INP bis 200 ms, CLS bis 0,1 (siehe web.dev). Das sind die Schwellen, keine Versprechen für Ihren Shop.

#Importe vieler Produkte: WP-CLI statt Browser

Der CSV-Import im Backend hängt an Speicher, Upload-Größe und Laufzeit des Servers und läuft im Browser. Wie ich damit und mit Aktualisierungen über SKU oder ID umgehe, beschreibe ich ausführlich auf der Seite WooCommerce Entwickler Hannover. Hier nur der Teil, der zu großen Beständen mit vielen Bestellungen passt:

• WP-CLI hat keine Browseranfrage. WooCommerce bringt mit wp wc product Befehle zum Anlegen, Ändern und Löschen von Produkten mit (Anleitung zu WC-CLI). Ein Skript über diese Befehle läuft ohne die Zeitgrenze einer Webanfrage.
• Import und Bestellungen nicht gleichzeitig. Ein Vollimport, der um die Mittagszeit die Warteschlange füllt, konkurriert mit Bestellmails und Lagerabgleich. Ich plane Importe in Zeiten mit wenig Bestellungen und frage in der Warteschlange ab, ob sie leer ist.
• Termzählung. Bei Massenänderungen an Kategorien und Attributen lässt sich die Zählung der Begriffe mit wp_defer_term_counting() steuern (Funktionsreferenz). Ob das bei Ihrem Katalog etwas bringt, zeigt ein Testlauf auf Staging.
• Attribut-Lookup-Tabelle. Nach einem großen Import prüfe ich mit wp wc palt info, ob die Lookup-Tabelle für Produktattribute vollständig ist. Die Befehle stehen in der Dokumentation zu wc palt.

#Datenbankindizes: erst messen, dann anlegen

Die HPOS-Tabellen bringen ihre eigenen Indizes mit. Ob an anderer Stelle ein zusätzlicher Index nötig ist, entscheidet kein Bauchgefühl. MySQL zeigt mit EXPLAIN, wie eine Abfrage ausgeführt würde, und die MySQL-Dokumentation nennt das ausdrücklich als Weg, um zu sehen, wo Indizes die Abfrage beschleunigen. Werden vorhandene Indizes nicht genutzt, empfiehlt sie, zuerst ANALYZE TABLE auszuführen.

So gehe ich vor: Query Monitor liefert auf Staging die langsamen Abfragen, EXPLAIN zeigt den Plan, und erst dann entsteht ein Index, der ein konkretes Problem löst. Jeder zusätzliche Index kostet beim Schreiben Zeit und Platz, bei einem Shop mit vielen Bestellungen ist das nicht gratis. Änderungen an Kerntabellen von WooCommerce vermeide ich, wo eine Anpassung der Abfrage im eigenen Code reicht.

#Updates nur über Staging

Eine neue Version von WooCommerce, Action Scheduler oder einem Zahlungs-Plugin ändert Verhalten, auf das Ihre Anbindungen aufbauen. Stand 11. November 2026 listet WordPress.org WooCommerce in Version 11.3.0. Ich prüfe jede Version auf einer Kopie, bevor sie in den Live-Shop kommt:

#Datenschutz: die Aufsicht in Baden-Württemberg

Bestellungen enthalten Namen, Adressen und Zahlungsdaten. Für Unternehmen in Baden-Württemberg ist der Landesbeauftragte für den Datenschutz und die Informationsfreiheit Baden-Württemberg zuständig, mit Sitz in der Heilbronner Straße 35 in Stuttgart. Seine Website bietet ein Beschwerdeformular und ein Formular, um eine Datenpanne zu melden. Wenn ich in Ihrem Shop Bestelldaten bewege, etwa bei der HPOS-Migration oder beim Kopieren auf Staging, halte ich schriftlich fest, wo die Kopie liegt und wann sie gelöscht wird. Rechtsfragen zur Speicherdauer klärt Ihre Kanzlei oder Ihr Datenschutzbeauftragter.

#So läuft ein Projekt mit mir

Ich arbeite allein, von Gdynia aus, nur schriftlich und ohne Termine. Das Layout liefern Sie oder Ihre Agentur als Mockup oder Wireframe, ich baue es im Theme Ihres Shops nach.

1. Schriftliche Anfrage. Sie schicken die Adresse des Shops und beantworten die vier Fragen vom Anfang.
2. Bestandsaufnahme. Ich lese Plugins, Hosting, Warteschlange und die langsamsten Abfragen und halte Befunde schriftlich fest.
3. Schriftlicher Umfang. Reihenfolge, Annahmen, Abnahmekriterien und ein Rückweg stehen vor dem ersten Eingriff im Angebot. Die erste Einschätzung ist kostenlos.
4. Umsetzung auf Staging. Jeder Schritt läuft zuerst auf einer Kopie des Shops, bei HPOS in den drei Phasen von oben.
5. Abnahme und Übergabe. Sie prüfen anhand einer Checkliste. Anschließend betreuen Sie den Shop selbst oder beauftragen die Wartung. Nicht genutzte Wartungsstunden übertrage ich nicht in den nächsten Monat.

#Was ich von Ihnen brauche

#Häufige Fragen

#Muss ich bei vielen Bestellungen auf HPOS umsteigen?

Für neue Shops ist HPOS Standard. Bei einem bestehenden Shop ist der Umstieg eine Entscheidung mit Vorbereitung: Erst müssen alle Plugins und angebundene Systeme damit umgehen können. Ich prüfe das auf Staging und schlage dann schriftlich einen Ablauf vor.

#Wie lange läuft der Kompatibilitätsmodus?

Das hängt von Ihrem Shop ab. Die Entwickler von WooCommerce beschreiben für ihren Großshop, dass sie die Synchronisation beim Lesen nach wenigen Stunden abschalteten und beim Schreiben nach etwa einer Woche. Das ist ein Beispiel, kein Fahrplan für Ihren Shop.

#Was tun, wenn die Warteschlange von Action Scheduler wächst?

Zuerst klären, welche Aktionen sich stauen und warum. Danach entscheide ich, ob ein WP-CLI-Läufer, andere Stapelgrößen oder eine Korrektur am auslösenden Plugin die richtige Antwort ist. Mehr gleichzeitige Läufer allein sind es laut Dokumentation selten.

#Reicht Redis, damit mein Shop schnell wird?

Ein persistenter Objekt-Cache nimmt der Datenbank wiederholte Abfragen ab. Er ersetzt weder aufgeräumte Plugins noch passende Indizes noch eine geprüfte Bestellstrecke. Ich messe vor und nach der Umstellung.

#Können Sie Indizes in meine Datenbank einbauen?

Ja, aber erst nach einer Messung. Ich prüfe langsame Abfragen mit EXPLAIN auf einer Kopie Ihrer Datenbank und lege einen Index nur an, wenn der Plan zeigt, dass er der Abfrage hilft.

#Welche Datenschutzaufsicht ist für meinen Shop in Karlsruhe zuständig?

Für Unternehmen in Baden-Württemberg ist es der Landesbeauftragte für den Datenschutz und die Informationsfreiheit Baden-Württemberg in Stuttgart. Auf seiner Website gibt es ein Beschwerdeformular und ein Formular für Datenpannen.

#Schreiben Sie mir zu Ihrem Shop

Senden Sie mir über die Kontaktseite die Adresse Ihres Shops, die ungefähre Zahl der Bestellungen pro Monat und der Produkte, das Hosting, die angebundenen Systeme und Ihr Wunschdatum. Ich antworte per E-Mail an Werktagen. Die erste Einschätzung ist kostenlos.