Wenn Shopware ein Feld schreibschützt
In 6.7 nimmt description_teaser keine Schreibzugriffe von außen mehr an — und bekam gleichzeitig einen eigenen Indexer. Ein Übersetzungslauf meldete Erfolg, verbrauchte Kontingent und schrieb nichts.
Es gibt einen Fehler, der teurer ist als ein Absturz: der, der wie Erfolg aussieht. Ein Werkzeug überträgt Daten, meldet „fertig", und am Ziel ist nichts angekommen. In Shopware 6.7 gibt es dafür eine neue Ursache.
Was wir gemessen haben
In der laufenden 6.7.13.1 trägt das Feld description_teaser die Markierung
WriteProtected. Ein Schreibzugriff von außen — über die Admin-API, über
ein Importprofil, über eine Erweiterung — wird abgewiesen. Gleichzeitig führt
dieselbe Version einen neuen Indexer: product.description_teaser.indexer.
Beides gehört zusammen. Der Kern hat die Zuständigkeit für dieses Feld übernommen: Er berechnet den Teaser selbst aus der Beschreibung. Wer ihn von außen setzen will, arbeitet gegen diese Zuständigkeit — und verliert.
Wie sich das im Betrieb anfühlt
Der Fall, an dem wir darauf gestoßen sind, war ein Übersetzungslauf. Das Werkzeug las die Produkte, schickte die Texte an den Übersetzungsdienst, bekam die Übersetzungen zurück und schrieb sie über die Admin-API in den Shop. Der Lauf meldete Erfolg.
Im Shop stand nichts. Das Kontingent beim Übersetzungsdienst war trotzdem verbraucht — die Texte waren übersetzt, nur nicht gespeichert.
Der Grund liegt in einer Annahme, die in vielen Werkzeugen steckt: Eine Antwort ohne Fehlermeldung gilt als Erfolg. Bei einem schreibgeschützten Feld ist die Anfrage aber formal korrekt. Sie wird angenommen und für dieses eine Feld verworfen. Wer nicht nachliest, merkt es nicht.
Wie man Produktübersetzungen aufsetzt, ohne solche Lücken zu erzeugen, haben wir in Produktdaten übersetzen ohne Datenverlust beschrieben.
Warum der Kern das tut
Schreibschutz ist kein Schikane-Mechanismus. Er markiert Felder, deren Wert sich aus anderen Daten ergibt. Wer sie von außen setzt, erzeugt einen Zustand, den der Kern beim nächsten Indexlauf ohnehin überschreibt — nur dass dann niemand weiß, warum der Wert wieder anders ist.
Andere Felder mit demselben Muster sind berechnete Verfügbarkeiten,
Zählwerte und interne Zustände. Der Unterschied bei description_teaser:
Dieses Feld war vorher frei beschreibbar. Die Änderung trifft deshalb
bestehende Prozesse, nicht nur neue.
Welche weiteren Bereiche 6.7 neu berechnet, steht in unserer Zählung der Indexer im Kern.
Der Prüfweg vor dem Update
- Liste der schreibenden Werkzeuge erstellen. Welche Systeme schreiben in Produktdaten? Übersetzung, PIM, ERP, Importprofile, eigene Skripte.
- Je Werkzeug die Felder prüfen. Schreibt eines davon in
description_teaser? In vielen Übersetzungsprofilen ist das Feld standardmäßig enthalten, weil es in 6.6 beschreibbar war. - Nach dem Update gegenlesen. Ein Produkt exemplarisch übersetzen oder importieren und den Wert danach erneut abrufen. Nicht die Erfolgsmeldung des Werkzeugs prüfen, sondern den Inhalt im Shop.
- Das Feld aus den Profilen nehmen. Wenn der Kern es berechnet, ist die Pflege von außen ohnehin verloren — jeder Indexlauf setzt sie zurück.
Die allgemeine Lehre
Der eigentliche Befund ist nicht das eine Feld, sondern die Klasse von Fehlern: Ein Schreibzugriff, der nicht ankommt, meldet sich nicht von selbst. Wer Daten über Schnittstellen pflegt, sollte den Rückweg einbauen — schreiben, lesen, vergleichen. Das kostet einen zusätzlichen Aufruf je Datensatz und spart den Fall, in dem drei Wochen später auffällt, dass eine Sprache leer ist.
Wir haben denselben Mechanismus schon einmal an anderer Stelle gesehen: Eine API-Antwort mit Statuscode 204 bedeutet „angenommen", nicht „gespeichert". Bei falsch benannten Feldern verschwinden die Werte still. Der Unterschied zwischen Admin-API und Store-API und was beide zusichern, steht in Store-API oder Admin-API.
Grenzen
Gemessen haben wir das Verhalten an einer 6.7.13.1 für ein Feld. Wir haben nicht systematisch erhoben, welche weiteren Felder in 6.7 neu als WriteProtected geführt werden — das wäre für eine Update-Checkliste nützlich und ist hier nicht beantwortet. Ebenfalls offen: ob und wie Erweiterungen den Schutz gezielt umgehen können.
Häufige Fragen
- Was bedeutet WriteProtected in Shopware?
- Das Feld ist für Schreibzugriffe von außen gesperrt. Der Kern darf es befüllen, eine API-Anfrage, ein Import oder ein Plugin nicht. Der Versuch wird abgewiesen.
- Welches Feld ist in 6.7 betroffen?
- description_teaser. In derselben Version kommt ein Indexer hinzu, der dieses Feld selbst berechnet — der Kern übernimmt also die Pflege, die vorher von außen kommen konnte.
- Warum meldet mein Übersetzungswerkzeug trotzdem Erfolg?
- Weil die Anfrage formal in Ordnung war. Wenn das Werkzeug nur den Aufruf prüft und nicht das Ergebnis, sieht ein abgewiesenes Feld aus wie eine erfolgreiche Übertragung.
- Wie prüfe ich, ob ein Wert wirklich angekommen ist?
- Den Datensatz nach dem Schreiben erneut lesen und den Wert vergleichen. Das kostet einen zusätzlichen Aufruf und ist der einzige verlässliche Nachweis.