Meinung Meinung

WooCommerce 10.9.2: Ein Patch, zwei Warnsignale

WooCommerce 10.9.2: Ein Patch, zwei Warnsignale

Ein Dot-Release mit viel Politik

WooCommerce 10.9.2 ist ein Dot-Release, das man in drei Sätzen erklären kann. Push-Benachrichtigungen sind jetzt für alle aktiviert, selbst die Stores, die das Feature während der Beta absichtlich ausgeschaltet hatten. Und das mit 10.9.0 eingeführte neue Settings-SDK wird nachträglich mit einem Kompatibilitätsstub abgedichtet, damit bestehende Plugins beim Update nicht abstürzen. Brian Coords hat das am 3. Juli 2026 auf developer.woocommerce.com veröffentlicht – unter der harmlosen Überschrift eines Stabilitäts-Patches.

Das ist technisch korrekt. Politisch ist es etwas anderes.

„Fix – Prevent update-time fatal errors by guarding new settings SDK classes and preserving the removed legacy settings API controller as a no-op compatibility stub. Update – Enable push notifications by default and deprecate feature flag.“

These: WooCommerce agiert zunehmend wie ein verwalteter SaaS-Dienst – mit Default-Opt-ins, internen SDK-Brüchen und einem Rückwärtskompatibilitäts-Aufwand, den der einzelne Händler nicht mehr nachvollziehen kann. Für DACH-Händler bedeutet das: Die vermeintliche Hoheit über den eigenen Shop schrumpft mit jedem kleinen Release ein Stück weiter.

Push-Benachrichtigungen als Standard sind kein Detail

Die Entscheidung, Push-Benachrichtigungen standardmäßig zu aktivieren, klingt nach einem Schieberegler. Wer sie nicht will, setzt eben den Filter woocommerce_enhanced_push_notifications_disabled. So jedenfalls liest sich die Mitteilung. In der Praxis aber hat Woo damit einen direkten Kommunikationskanal zum Admin-Backend etabliert – und zwar als Default.

Für deutsche und DACH-weite Händler ist das nicht nur ein Komfortthema. Jeder Kanal, der Daten über das Backend verarbeitet, ist unter DSGVO-Gesichtspunkten lesbar. Woo nennt zwar den Filter, aber nicht, welche Daten fließen, wie lange sie gespeichert werden und ob die Benachrichtigungen personenbezogene Informationen enthalten. Die rechtliche Verantwortung bleibt beim Händler. Der aber muss erst einmal herausfinden, dass überhaupt etwas aktiviert wurde.

Das Muster ist bekannt: Ein Feature, das im Beta-Stadium noch optional war, wird nach der Testphase zum Standard. Wer widersprechen will, muss aktiv werden. Das ist keine Open-Source-Logik, bei der der Nutzer souverän entscheidet, welche Module laufen. Das ist die Rollout-Logik eines SaaS-Anbieters, der die Akzeptanzschwelle senkt, indem er das Opt-out versteckt.

Der no-op-Stub ist kein Erfolg, sondern ein Symptom

Noch aufschlussreicher ist der zweite Punkt. WooCommerce 10.9.2 verhindert „fatal errors“ beim Update, indem es die neuen Settings-SDK-Klassen besser absichert und den entfernten Legacy-Settings-API-Controller als „no-op compatibility stub“ erhält. Übersetzt: Ein interner Architekturwechsel, der mit 10.9.0 eingeführt wurde, hätte bestehende Erweiterungen beim Update kaputtgemacht. Statt die neue Architektur sauber zu veröffentlichen, wurde nachträglich ein Platzhalter eingebaut, der nichts tut, aber auch nichts zerstört.

Das funktioniert. Es ist aber kein Beleg für Stabilität, sondern für wachsende technische Brüche im Kern. Ein Händler, der seinen Shop seit Jahren mit individuellen Plugins und Schnittstellen betreibt, merkt vielleicht gar nicht, dass sein Setup nur noch deshalb läuft, weil Woo einen leeren Stub mitliefert. Er merkt erst etwas, wenn der Stub irgendwann doch entfällt oder ein Drittanbieter darauf aufbaut, ohne zu wissen, dass er auf einem Konstrukt aus Pappe sitzt.

Für den deutschen Markt ist das besonders brisant, weil hier viele mittelständische Shops auf maßgeschneiderte Woo-Setups setzen. Sie kaufen nicht bei Shopify ein, weil sie Eigenständigkeit wollen. Genau diese Eigenständigkeit wird aber durch die wachsende interne Komplexität von WooCommerce unterhöhlt. Je mehr Patches eigene Vorgänger-Patches korrigieren müssen, desto größer wird die Abhängigkeit von Automattics Entwicklungszyklus.

Der einzige Ausweg ist ein bewussteres Nein

Die Konsequenz ist unbequem, aber klar: Wer WooCommerce weiterhin als kontrollierbare Open-Source-Plattform betreibt, muss jeden Patch wie einen Vertragsänderungsvorschlag lesen. Nicht, weil 10.9.2 das System zerstört – das tut es nicht. Sondern weil es zwei Entwicklungen beschleunigt: die Aneignung von Kommunikationskanälen durch den Hersteller und die Normalisierung von nachträglichen Kompatibilitätsflicken.

Fragen Sie sich vor dem nächsten Update nicht, ob etwas kaputtgeht. Fragen Sie sich, welche neue Standard-Einstellung Sie wieder einmal aktiv abwählen müssen – und warum das eigentlich Ihre Aufgabe ist.