Von OpenCart zu einem eigenen Shop wechseln

Was OpenCart ist, und wer es entwächst

OpenCart ist ein kostenloser, quelloffener Shop, geschrieben in PHP und von dir selbst gehostet. Du lädst ihn herunter, legst ihn auf deinen eigenen Server, verbindest ihn mit einer MySQL oder MariaDB Datenbank, und von da an gehört er dir.¹ Er steht unter Version 3 der GNU General Public License, es gibt also weder eine Lizenzgebühr noch eine Umsatzbeteiligung, und der Quellcode liegt offen, sodass du oder jede Entwicklerin ihn lesen und ändern kann.² Für einen schlanken Shop ist das eine starke Position, und ich sage es direkt: Wenn dein OpenCart Shop klein, stabil und günstig im Betrieb ist, bleibst du wahrscheinlich besser darauf. Für dich ist dieser Artikel nicht gedacht.

Gedacht ist er für den Shop, der OpenCart entwachsen ist. Das Muster wiederholt sich. Der Katalog ist gewachsen, das Gewerbegeschäft ist gewachsen, und aus dem Shop wurde ein Turm aus bezahlten Erweiterungen, die alle miteinander auskommen müssen. Jede einzelne verlangt, dass ihre Lizenz erneuert wird. Eine neue Hauptversion ist erschienen, das Theme wurde für die alte Version gekauft und läuft auf der neuen nicht, und die Hälfte der Erweiterungsautoren hat ihre Arbeit nicht aktualisiert oder möchte erneut bezahlt werden. Irgendwo im Shop hat ein Entwickler, der vor zwei Jahren gegangen ist, eine wichtige Regel in einer Modifikationsdatei versteckt, und niemand weiß genau, was sie bewirkt. Der Shop läuft noch, doch etwas zu ändern fühlt sich an, als entschärfte man eine Bombe.

Stehst du dort, dann lautet die gute Nachricht: OpenCart zählt zu den Plattformen, die sich leichter verlassen lassen, weil dir die Daten bereits gehören. Schwer ist nicht der Export. Schwer ist es, zu entwirren, was die Erweiterungen und Modifikationen wirklich getan haben, und das Ganze als eine einzige, dir gehörende, getestete Anwendung neu zu bauen. Diese Anwendung baue ich auf Solidus, einem quelloffenen Shop Framework auf Ruby on Rails, und ich begleite den Umzug. Das Ergebnis gehört dir. Dieser Artikel beschreibt die ehrliche Form dieses Umzugs, eigens für OpenCart. Für die tiefe, plattformunabhängige Erklärung, wie jede Datenart reist, verweise ich auf die Leitfäden, denen sie gehört, statt sie hier zu wiederholen, angefangen bei der Säule, was sich überträgt und was nicht.

Was dir gehört, und was eingesperrt ist

Weil OpenCart selbst gehostet ist, spricht die wichtigste Tatsache beim Verlassen für dich: Die Datenbank gehört dir. Alles, was der Shop weiß, liegt in Tabellen, die du unmittelbar lesen kannst, mit einem Präfix wie oc_ vor Namen wie oc_product, oc_customer, oc_order und oc_seo_url. Ein schlichter Datenbankauszug mit mysqldump gibt dir alles, und von dort ist die Zuordnung in ein neues Modell gewöhnliche, sorgfältige Arbeit statt eines Kampfes um Zugang. Stell das einer gehosteten Plattform gegenüber, bei der du nur die Exporte erhältst, die der Anbieter herausgeben möchte, und es wird klar, warum quelloffene Shops freundlicher zu verlassen sind.

Eingesperrt sind also nicht die Daten. Eingesperrt ist das Verhalten rund um die Daten: die Zahlungs und Versandlogik, die jede Erweiterung auf eigene Weise hält, die Geschäftsregeln, die in Modifikationen stecken, das Theme, das für eine bestimmte OpenCart Version geschrieben wurde, und die Anbindungen, die genau an diese Installation verdrahtet sind. Davon reist nichts mit. Es muss verstanden und neu gebaut werden. Die folgende Tabelle zeigt die ehrliche Aufteilung.

Export und API, wie es wirklich ist

OpenCart bietet dir drei ehrliche Wege, deine Daten herauszuholen, und es lohnt sich, genau zu benennen, was jeder davon ist, denn das Marketing rund um Migrationswerkzeuge verwischt die Grenzen.

Der erste ist der direkte Datenbankzugriff, und er ist der stärkste. Dir gehören Server und Datenbank, ein vollständiger Auszug steht dir daher jederzeit offen. Bei einem großen Katalog oder einer komplexen Bestelltabelle nehme ich tatsächlich diesen Weg, weil nichts verborgen und nichts zu einer Summe verdichtet ist.

Der zweite ist das Export und Importwerkzeug. Oft wird angenommen, es sei Teil von OpenCart. Ist es nicht. Das verbreitete Export/Import Tool ist eine Community Erweiterung, für das Projekt gepflegt und über den OpenCart Marktplatz verteilt, die du selbst installierst.³ Es leistet echte Arbeit: einen Massenexport von Kategorien, Produkten, Optionen, Attributen, Filtern und Kunden in eine Tabelle, die du offline bearbeiten und erneut einlesen kannst. Der Import kennt zwei Modi, einer ergänzt und aktualisiert gegen den Bestand, der andere löscht zuerst alle alten Daten und ersetzt sie. Zwei Einschränkungen zählen. Der Speicherbedarf ist hoch, und auf einfachem geteiltem Hosting empfiehlt der Autor, nicht mehr als ein paar tausend Produkte auf einmal zu exportieren und in Chargen zu arbeiten.³ Zudem ist die Tabelle eine Bequemlichkeitsschicht, nicht die ganze Wahrheit: Was ein eigenes Feld oder eine Erweiterung außerhalb der Standardtabellen abgelegt hat, fehlt darin. Bei einem Shop jeder Größe nehme ich die Tabelle als Ausgangspunkt und gleiche sie gegen die Datenbank ab.

Der dritte ist die API, und hier gehören die Erwartungen gedämpft. OpenCart hat eine eingebaute API, die du bei den Systembenutzern einrichtest, indem du eine Zugangskennung mit Benutzernamen, erzeugtem Schlüssel und einer Liste erlaubter IP Adressen anlegst und ein oder ausschaltest.⁴ Was die Dokumentation beschreibt, ist eine Schnittstelle, damit vertrauenswürdige Anwendungen mit deinem Shop sprechen, samt einer Aufrufhistorie, keine vollständige Leseschnittstelle über deinen gesamten Katalog. Es gibt keinen dokumentierten Endpunkt, der dir einfach jedes Produkt, jeden Kunden und jede Bestellung auflistet. Die eingebaute API entstand rund um Warenkorb und Bestellvorgänge für den Shop und Begleitapps, und eine echte REST Schnittstelle über die Daten bedeutet in aller Regel eine weitere Erweiterung. OpenCart selbst setzt bei der eingebauten API kein veröffentlichtes Ratenlimit, jede Grenze, an die du stößt, gehört deinem Hoster, nicht der Plattform.⁴ Der praktische Schluss ist einfach: Bei OpenCart migrierst du aus der Datenbank, und die API ist Nebenrolle, nicht Hauptrolle.

Passwörter ziehen nie um, und das ist gut so

Kein Passwort kommt in lesbarer Form herüber, nicht aus OpenCart und aus keiner vernünftigen Plattform, denn OpenCart speichert das Passwort selbst nie. Die aktuelle Version hasht jedes Passwort mit PHPs eigener Funktion password_hash und dem Standardalgorithmus, der heute bcrypt ist, und schreibt nur diesen Hash.⁵ Ältere OpenCart Installationen nutzten stattdessen ein gesalzenes, mehrfach gehashtes SHA1 Verfahren, mit einem kurzen Zufallssalz neben dem Hash.⁶ In beiden Fällen ist der gespeicherte Wert einseitig. Er lässt sich nicht in das Passwort zurückrechnen, es gibt also nichts mitzunehmen, womit sich eine Kundin anmelden könnte.

Das ist ein Vorteil, kein Verlust, und der Plan dahinter entspricht genau dem, was der Leitfaden zu Kundenkonten vollständig ausführt. Jedes Konto, mit Namen, Adressen und Bestellhistorie, wird im neuen Shop angelegt. Beim ersten Besuch setzt die Kundin entweder über einen Einmallink ein neues Passwort oder, wenn du die alten Hashes behältst, wird der alte Hash einmal geprüft und danach still in das Format des neuen Shops überführt, ohne dass sie es bemerkt. Welchen Weg du auch wählst, niemand sieht je ein Passwort im Klartext, und das Konto, das die Kundin wieder aufbaut, hängt an ihrer gesamten Historie.

Der Turm aus Erweiterungen ist der eigentliche Grund zu gehen

Kaum jemand verlässt OpenCart, weil die Daten gefangen wären. Man geht wegen dessen, was obendrauf liegt. Ein funktionierender OpenCart Shop mit Anspruch ist selten reines OpenCart. Er ist reines OpenCart plus zwanzig oder dreißig bezahlte Erweiterungen: eine bessere Suche, abgestufte Filter, ein Modul für Gewerbepreise, Mails für abgebrochene Warenkörbe, ein Bewertungssystem, ein Retourenportal, eine Anbindung an die Buchhaltung, ein Feed für Marktplätze und ein oder zwei Zahlungserweiterungen. Jede ist ein eigener Kauf von einem eigenen Autor, mit eigenem Veröffentlichungsrhythmus und eigener Qualität. Sie müssen zusammenspielen, und sie müssen jedes Mal weiter zusammenspielen, wenn eine von ihnen aktualisiert wird. Sind sie uneins, bricht der Shop auf schwer auffindbare Weise, denn der Fehler liegt im Zwischenraum zweier Erweiterungen, den kein Autor besitzt.

Darüber liegt die Upgradefrage, die bei OpenCart schärfer ausfällt als bei den meisten Plattformen. Der Sprung zwischen Hauptversionen, von der 1.5 Reihe auf 2, von 2 auf 3, von 3 auf 4, ist weniger ein Upgrade als ein Neubau. Themes sind gegen eine bestimmte Version und ihr Vorlagensystem geschrieben, ein Theme für eine Reihe läuft daher nicht einfach auf der nächsten. Erweiterungen müssen von ihren Autoren für die neue Version neu herausgegeben werden, und viele werden das nie, oder nur gegen erneute Bezahlung. Ein Shop, der aktuell bleiben will, steht also alle paar Jahre vor einem Projekt, das nahezu so viel kostet wie ein frischer Aufbau und dafür nichts Neues vorzuzeigen hat. Das ist die Tretmühle. Mein Argument für einen eigenen Solidus Shop lautet nicht, dass Rails gerade in Mode ist. Es lautet, dass du einen Turm aus fremden Erweiterungen, jede eine Abhängigkeit, die du nicht steuerst, durch eine einzige Anwendung ersetzt, die dir gehört, die mit Tests beweist, dass sie sich richtig verhält, und die eine Entwicklerin, die sie kennt, pflegen und erweitern kann, ohne irgendwen um Erlaubnis zu bitten.

Modifikationen verstecken deine Geschäftslogik

OpenCart besitzt ein geschicktes System, um das Verhalten des Shops zu ändern, ohne die Kerndateien anzufassen, genannt OCMOD, mit einem älteren Vorfahren eines Drittanbieters namens vQmod, den viele Shops bis heute mitführen. Eine Modifikation ist eine XML Anweisung, die im Kern sagt: Finde diese Zeile in jener Datei und ändere sie, und das System wendet die Änderung zur Laufzeit auf eine Kopie an, das Original bleibt unberührt.⁷ Die Idee ist sinnvoll, und sie ist zugleich der Ort, an dem sich Geschäftslogik verbirgt.

Die Falle ist, dass über die Jahre die echten Regeln deines Shops in diese Modifikationsdateien wandern. Wie Gewerbekunden bepreist werden, die eigentümliche Rundung, auf der dein Buchhalter besteht, das Zusatzfeld auf der Bestellung, die Art, wie das Etikett eines bestimmten Transporteurs erzeugt wird: Ein Entwickler, oft längst fort, löste jedes davon mit einer kleinen Modifikation, und das Wissen ging mit ihm. Beim Umzug sind diese Dateien das Wertvollste und zugleich Gefährlichste, das es zu verstehen gilt, denn sie sind der Unterschied zwischen dem Shop, den du zu haben glaubst, und dem Shop, den du wirklich hast. Die erste ernste Aufgabe in jeder OpenCart Migration, die ich begleite, besteht darin, jede Modifikation zu lesen und in klaren Worten festzuhalten, was jede wirklich tut. Dieses Dokument, nicht der Datenexport, ist meist der Ort, an dem die Überraschungen lauern.

SEO URLs und die Weiterleitungsliste

OpenCart bildet die Adresse einer Seite auf zwei Arten. Ab Werk nutzt es Abfragezeichenfolgen, ein Produkt liegt daher unter so etwas wie index.php?route=product/product&product_id=42. Mit eingeschalteten SEO URLs erhält stattdessen jedes Produkt, jede Kategorie und jede Informationsseite ein Schlüsselwort, das im gesamten Shop eindeutig sein muss, und der Server wird so eingerichtet, dass er die freundliche Adresse auf die echte Route umschreibt.⁸ Diese Schlüsselwörter sind die URLs, die sich deine Kunden gemerkt haben und die Suchmaschinen indexiert haben, und wenn du den Shop seit Jahren betreibst, tragen sie echtes Ranking.

Der Umzug in einen neuen Shop ist der Moment, in dem dieser Wert am häufigsten verschenkt wird, und das hat nichts mit OpenCart im Besonderen zu tun und alles mit Disziplin. Jede Adresse, die im letzten Jahr einen Besuch oder einen Link erhielt, muss mit einer dauerhaften Weiterleitung ihrem neuen Zuhause zugeordnet werden, und die Weiterleitung muss direkt auf die Zielseite zeigen, nicht über eine Kette. Die ganze Methode, und warum der meiste Rankingverlust bei einer Migration von verpassten Weiterleitungen herrührt und nicht vom Umzug selbst, steht im Leitfaden zu Produkt und Katalogdaten. Bei OpenCart lautet der eine plattformspezifische Hinweis, dass deine Schlüsselwortliste in einer Datenbanktabelle liegt, die du direkt lesen kannst, der erste Entwurf der Weiterleitungsliste ist also eine Abfrage, kein Crawl. In den Shops, die ich baue, leben die Weiterleitungen in der Anwendung selbst als bearbeitbare Tabelle, sie überstehen daher jedes künftige Deploy, und dein eigenes Team kann eine ergänzen, wenn ihm eine Lücke auffällt.

Zahlungen und gespeicherte Karten

Zahlungen sind der Punkt, an dem ein OpenCart Umzug aufhört, aufgeräumt zu sein. In OpenCart ist jedes Gateway eine eigene Zahlungserweiterung, und jede speichert ihre Konfiguration und jeden Verweis auf eine gespeicherte Karte auf eigene Art. Es gibt keinen einzigen, portablen Zahlungstresor zum Übergeben. Entscheidend ist, wer die Kartendaten hält, und die Antwort lautet nie OpenCart: Es ist dein Zahlungsanbieter. Bucht dein Shop Karten bereits über dein eigenes Konto bei Stripe oder einem ähnlichen Anbieter, gehören die gespeicherten Karten diesem Konto, und der neue Solidus Shop kann sich mit demselben Konto verbinden, sodass die Karten schlicht dort bleiben und nichts verloren geht. Liegen die Karten dagegen in einem Anbieter, den du nur über eine OpenCart Erweiterung erreicht hast, bedeutet ein Umzug eine Übertragung von Anbieter zu Anbieter, die der empfangende Abwickler nur von einem anderen Inhaber mit Zertifizierung auf der höchsten Stufe des Kartensicherheitsstandards annimmt, und die niemals die Abonnements oder die Zahlungshistorie mitbringt.

Das ist das Wichtigste, das zuerst zu klären ist, nicht zuletzt, und der Leitfaden zu Zahlungstoken geht jeden Fall durch. Wenn du aus diesem Abschnitt nur eines mitnimmst, dann dies: Entscheide deinen Zahlungsanbieter, bevor du eine Zeile des neuen Shops schreibst, denn diese eine Entscheidung bestimmt, ob wiederkehrende Kunden ihre gespeicherten Karten behalten oder neu eingeben müssen. Macht dich das Thema nervös, ist die warnende Geschichte vom Wechsel des Payment Gateways die passende Lektüre.

Abonnements und wiederkehrende Zahlungen

Verkauft dein OpenCart Shop irgendetwas auf wiederkehrender Basis, behandle es als den härtesten Teil des ganzen Umzugs und bring es am ersten Tag zur Sprache. OpenCart kann wiederkehrende Produkte abbilden, doch das eigentliche Abbuchen hängt davon ab, dass die jeweilige Zahlungserweiterung es unterstützt, und das Mandat, mit dem du eine Kundin erneut belasten darfst, liegt beim Gateway, nicht in OpenCart. Ein laufendes Abonnement lässt sich also nicht einfach als Datenzeile exportieren und im neuen Shop nachspielen. Ob es überhaupt umziehen kann, hängt von deinem Gateway ab und braucht oft dessen Mitwirkung, und manchmal lautet die ehrliche Antwort, dass bestehende Abonnenten neu zustimmen müssen. Der Leitfaden zu Abonnements legt die Möglichkeiten und die Fragen an deinen Anbieter dar. Die Regel ist dieselbe wie bei Karten: zuerst ansprechen, denn die Antwort formt alles Übrige.

Ein Beispiel

Ich mache es an einem erfundenen Shop konkret. Elster Ausrüstung (elsterausruestung.example) ist ein Leipziger Betrieb, der Schuhe, Arbeitskleidung und Schutzausrüstung verkauft, mit einem wachsenden Gewerbegeschäft, das Baufirmen auf Rechnung beliefert. Der Shop setzt online rund 1,4 Millionen € um, führt etwa 6.000 Produkte, sobald Größen und Farben gezählt sind, und läuft seit fünf Jahren auf OpenCart 3. In dieser Zeit hat er 22 bezahlte Erweiterungen gekauft und ein Dutzend Modifikationen angehäuft. Die Gewerbepreise, die Art, wie Rechnungskunden Preise ohne Mehrwertsteuer sehen, und ein eigenes Feld auf Bestellungen für die Baustelle, an die geliefert wird, laufen allesamt über Modifikationen eines Entwicklers, der weitergezogen ist.

Das Problem der Inhaberin ist nicht, dass der Shop kaputt wäre. Es ist, dass es furchteinflößend geworden ist, ihn anzufassen. OpenCart 4 ist erschienen, das Theme wurde für 3 gekauft und der Autor hat es nicht neu herausgegeben, vier der Erweiterungen sind verwaist, und der Kostenvoranschlag, alles auf der neuen Version zum Laufen zu bringen, liegt nahe an den Kosten eines Neuanfangs, für keine neue Fähigkeit. Sie hat entschieden, keine fremden Erweiterungen mehr zu mieten und den Shop stattdessen zu besitzen.

So verläuft der Umzug. Der saubere Teil kommt zuerst und beruhigt alle: ein vollständiger Datenbankauszug, und daraus werden die 6.000 Produkte mit Größen, Farben, Preisen, Lagerstand und Bildern in einigen Wochen sorgfältigen Abgleichs auf den Solidus Katalog abgebildet. Die Kundendatensätze, einschließlich der Gewerbekonten, kommen mit Adressen und Bestellhistorie herüber, Passwörter ausgenommen. Die Bestellhistorie wird als nur lesbare Referenz eingebracht, drei Jahre tief, die älteren Datensätze verbleiben im archivierten Export. Die SEO Schlüsselwörter werden direkt aus der Datenbank in den ersten Entwurf der Weiterleitungsliste gelesen, rund 7.000 Zeilen, die anschließend eine Person prüft.

Dann die harten Teile, die in Woche eins zur Sprache kamen, nicht in Woche zehn. Die Gewerbepreise und die Anzeige ohne Mehrwertsteuer, gefunden beim Lesen der Modifikationen, werden echte, getestete Funktionen des neuen Shops statt Flicken. Das Bestellfeld für die Baustelle wird sauber neu gebaut. Zahlungen sind der Angelpunkt: Der Shop nutzt bereits sein eigenes Stripe Konto, der neue Solidus Shop verbindet sich also mit demselben Konto, und die gespeicherten Karten der Gewerbekunden bleiben gültig, was den beängstigendsten Teil zum einfachsten macht. Es gibt keine Abonnements, diese Frage ist daher rasch geklärt. Vierzehn Wochen nach dem ersten Workshop stellt Elster Ausrüstung an einem ruhigen Dienstagvormittag um, lässt die alte OpenCart Installation dreißig Tage unberührt als Rückfalloption laufen und kündigt sie erst danach. Ein Jahr später ist der Shop eine gepflegte Anwendung mit Tests, ohne Erweiterungsverlängerungen, und die Gewerberegeln stehen dort aufgeschrieben, wo die nächste Person sie lesen kann.

Der ehrliche Umzugsplan

Auf das Wesentliche gebracht, verläuft der Weg von OpenCart zu einem eigenen Solidus Shop so. Erstens die Erhebung: jede Modifikation lesen und aufschreiben, was sie tut, die Erweiterungen auflisten und wofür jede wirklich da ist, den Zahlungsanbieter wählen und die eine Person im Betrieb benennen, der die Daten gehören. Zweitens der Bau: den Solidus Shop aufsetzen, die Importskripte schreiben und sie wieder und wieder gegen eine Kopie der echten Datenbank laufen lassen, bis der Import langweilig ist. Drittens Katalog und Kunden zuordnen und die versteckte Modifikationslogik in getestete Funktionen verwandeln. Viertens die Weiterleitungsliste aus der Schlüsselworttabelle bauen und jede Zeile prüfen. Fünftens ein Parallelbetrieb über einige Wochen mit eingefrorenem Katalog, der finale Import zweimal geprobt. Sechstens an einem ruhigen Werktagvormittag umstellen, eine echte Testbestellung auf jeder Zahlungsart aufgeben, die wichtigsten Weiterleitungen von Hand prüfen und den alten Shop dreißig Tage als Rückfalloption behalten, bevor irgendetwas gekündigt wird.

Durch alles hindurch gilt das Prinzip aus der Säule: Zieh den Shop um, wie er ist, mach ihn stabil, und verbessere erst dann. Aus einer Migration zugleich eine Neugestaltung zu machen, verdoppelt das Risiko und macht es unmöglich zu sagen, welche Änderung einen Einbruch verursacht hat.

Wann du auf OpenCart bleiben solltest

Mir ist lieber, ich verliere die Arbeit, als dir einen Umzug zu verkaufen, den du nicht brauchst, hier also, wann du bleiben solltest. Bleib, wenn dein OpenCart Shop klein ist, die Erweiterungen, auf die du angewiesen bist, wenige und gut gepflegt sind und die Rechnung tragbar ist. Bleib, wenn dich nichts wirklich blockiert und die einzige Klage ein vages Gefühl ist, die Software sei alt. Bleib, wenn du die Person im Betrieb nicht benennen kannst, die die Daten, die Gewerberegeln und den Grund für die Endungen an den alten Produktcodes versteht, denn ohne diese Person bringt jede Migration, auf jede Plattform, einen schönen neuen Shop voller falscher Daten.

Zieh um, wenn der Turm aus Erweiterungen zur Steuer und zum Risiko geworden ist, wenn das nächste Upgrade der Hauptversion so viel kostet wie ein frischer Start für nichts Neues, wenn die Regeln, die dein Geschäft steuern, in Modifikationen gefangen sind, die niemand lesen kann, und wenn du einen Shop willst, der dir gehört und sich ordentlich testen lässt. Für die Geldseite dieser Entscheidung rechnet die Gesamtkosten über fünf Jahre die Zahlen durch, der Plattformvergleich stellt OpenCart neben die Alternativen, und wem deine Geschäftsdaten eigentlich gehören ist das Prinzip darunter. Wägst du im selben Atemzug andere quelloffene Shops ab, habe ich denselben ehrlichen Leitfaden für den Abschied von WooCommerce und für den Abschied von PrestaShop geschrieben. Solidus selbst ist quelloffen unter der BSD Lizenz, der Shop, den ich dir baue, trägt also keine Lizenzgebühr und keine eigene Abhängigkeit.⁹

Der Workshop

Wenn du einen OpenCart Shop betreibst und nicht sicher bist, ob du ihm entwachsen bist, bring ihn in einen kostenlosen Workshop, und die ersten zwei Wochen Arbeit gehen auf mich. Bring deine Erweiterungsliste, deine Verlängerungsrechnungen und alles, was du über die Modifikationen weißt. Gemeinsam lesen wir, was der Shop wirklich tut, klären, was sauber umzieht und was neu gebaut werden muss, bringen die Fragen zu Zahlung und Abonnement zuerst zur Sprache, und ich sage dir ehrlich, ob sich ein Umzug für dich rechnet. Manchmal tut er das nicht, und dann sage ich das auch.