Posts by AndiPalm

Herzlichen Dank twokay! Ich schaue es mir schnellstmöglich an und gebe Feedback.

Ich habe mich dem Thema einmal angenommen. Ich schätze die Entwicklungskosten auf etwa 500€. Eine rechtzeitige/kurzfristige Umsetzung ist möglich, wenn die Finanzierung zumindest teilweise gesichert wird. Da ich selbst die Schnittstelle nicht nutze, möchte ich die Kosten dafür auch nicht tragen.

twokay Würdest du dich an der Entwicklung beteiligen? Und wenn ja, mit welchem Betrag?

Wer nutzt die Schnittstelle sonst noch und würde sich hier beteiligen?

Das BZSt hat scheinbar die Schnittstelle geändert (schon im November 2025) von XMLRPC auf REST.

Ich kümmere mich drum, ein paar Tage wird es aber dauern.

Ist auch nicht als Vorwurf gemeint.

Ich glaube nur, dass es vom Prozess her sinnvoller wäre erstmal einen kleinen Teil umzubauen, dann ein Feedback einzuholen und danach weiter zu machen. Ich bin beispielsweise mit einigen Änderungen der KI nicht einverstanden. Kann man vermutlich mit kleinen Anpassungen am Prompt beheben, aber dann muss man halt nochmal alles durchrattern lassen und vor allem muss man dann nochmal alles kontrollieren. Das ist eher suboptimal.

Außerdem sollten wir vermutlich erstmal das PHP8.5 Thema fertigstellen bevor wir den nächsten PR mit 20.000 Zeilen Diff haben der dann lange auf einen Merge warten muss.

Ich möchte deinen Enthusiasmus keinesfalls bremsen... nur ein kleines bisschen "lenken"

Okay, die Commits waren scheinbar noch nicht nach Github gepusht. Jetzt sehe ich was.

Und ich sehe, dass du schon fleißig was durch die KI jagst. Aber können wir das vielleicht nochmal besprechen bevor du jetzt alles umbaust? Ich habe da durchaus ein paar Kritikpunkte.

Ich möchte jetzt nicht noch einen dritten selbst (oder von KI) geschriebenen DatabaseService haben. Entweder wir arbeiten vorläufig weiter mit mysql.class.php (würde ich eher von abraten) oder wir nutzen die schon vorhandene "Database"-Klasse oder wenn wir mit beiden unzufrieden sind, dann sollten wir direkt zu Doctrine gehen.

Dann sollten wir meiner Meinung nach "named Parameters" benutzen. Die Queries werden sonst ja teilweise noch schlechter lesbar. Ich möchte in einer 10 Zeilen langen Query mit 4 JOINS nicht die "?" zählen müssen.

Ich habe jetzt mal in dein ( Lexan) Repository reingeschaut. Sehe aber bisher nur zahlreiche .md Files... ist das so gedacht oder mache ich was falsch?

Was mir dabei aber aufgefallen ist: Du möchtest die prepared Statements mit der mysql.class.php umsetzen, richtig? Davon würde ich wirklich abraten. Es gibt bereits eine wesentlich modernere "Database" Klasse die man über den Container bekommen kann. Wird bisher nur wenig genutzt, kann aber viel mehr.

Allerdings frage ich mich dann auch ob man nicht direkt auf Doctrine geht. Es muss ja nicht direkt der Schritt zum ORM sein, aber der Doctrine DBAL scheint mir eigentlich nur Vorteile zu haben. Bei solch zentralen Dingen bin ich immer eher ein Fan von Standards als von Eigenbräu.

Was denkst du?

Ich habe mal in meine Repository einen Branch "symfony" gepusht. Dort habe ich verschiedene Aspekte ausprobiert und mal unterschiedliche "Ausbaustufen" gebastelt.

Das "Passwort vergessen"-Formular ist quasi komplett auf Symfony umgestellt, mit Controller, Form, Twig-Templates, Doctrine-Entities, usw.

Ich habe einen LegacyController implementiert der das gesamte "alte" System durchleiten kann. Es sollte also im Wesentlichen alles bestehende weiter laufen.

Ich habe sehr viele "alte" Klassen in composer integriert um einen einzigen Autoloader zu bekommen der funktioniert und damit hoffentlich die meisten include_once überflüssig macht. Einige zentrale Klassen habe ich auch bereits so umgebaut, dass sie mit der Symfony-DependencyInjection funktionieren und als Services zur Verfügung stehen.

Das "welcome"-Module habe ich auf Doctrine umgestellt mit named Parameters in den SQL-Abfragen. Einige Templates habe ich auf Twig umgestellt und somit den Anteil an HTML-Code in PHP reduziert. Bei Funktionen die vermutlich ganz wegfallen werden habe ich mich versucht etwas zu bremsen.

Den Umbau auf Doctrine mit named Parameters bekommt die KI sehr gut hin, wenn man die Aufgabe in kleine Häppchen herunterbricht und auf Tokenlimits achtet. Wann immer die erpapi ins Spiel kommt, winken die meisten Modelle mit der weißen Fahne oder der Output ist unbrauchbar

Ihr könnt ja auch gerne mal in meinen Branch reinschauen... es ist aber eher eine Spielwiese als ein "Konzept". Mir ging es erstmal darum herauszufinden was gut funktioniert, was mit gefällt und was eher nicht.

okay, ich checke das nochmal. Mein letzter Versuch ist jetzt fast ein halbes Jahr her...

Ich versuche seit inzwischen sehr langer Zeit bei DHL und DHL Express entsprechende Accounts zu bekommen mit denen ich eine solche Schnittstelle testen könnte. Das war aber alles dermaßen frustrierend und ich hatte das Gefühl auf der Suche nach dem berühmten Passierschein A38 zu sein. Niemand war zuständig, versprochene Rückmeldung erfolgten nicht. Der Koordinationsaufwand dafür war fast so groß wie der von mir geschätzte Aufwand zu Implementierung der Schnittstelle.

Da es mit Sendcloud eine gut funktionierende Alternative gibt war es mir dann irgendwann zu blöd.

Ich gehe das gerne wieder an, wenn sich ein kompetenter Mitarbeiter von DHL bei mir meldet, aber ich werde bis dahin keinen weiteren Aufwand investieren. Ich hoffe auf Verständnis.

Ja klar, das hilft auf jeden Fall! Ich wollte das auch lediglich ergänzen/klarstellen/kommentieren wie ich das sehe.

Ich finde es wirklich gut, dass wir uns da Gedanken zu machen. Früher oder später werden uns sonst auch gewisse Dinge einholen und dann wird es Stress... Ich sage nur "die Zukunft von jQuery"

Danke für die ausführliche Analyse, auch wenn da jetzt für mich erstmal nicht viel neues drin steht.

Hinsichtlich deines Vorschlags würde ich ungeachtet aller subjektiven Empfindungen und Beliebtheiten etc. einfach mal vermuten, dass wenn man den gleichen Aufwand der für einen kompletten Rewrite nötig wäre in eine Verbesserung des bestehenden Systems (egal ob mit Symfony, mit was anderem oder ohne Framework) investiert, vermutlich am Ende mehr raus kommt... Kann ich nicht beweisen, ist einfach mein Gefühl

Bezüglich deiner drei genannten Optionen würde ich aber gerne noch etwas ergänzen:

Die unter Option A genannten Pro- und Contra-Argumente treffen meiner Meinung nach so nicht alleine für Symfony zu. Die Lernkurve wird bspw. bei einem Wechsel von PHP zu JS/TS vermutlich noch viel steiler ausfallen und die Lernkurve ist bei dem derzeitigen Code-Stand auch alles andere als gering.

Eine zusätzliche Abhängigkeit erhält man mit jeder Art von Lib/Framework. Hier spielt aber gerade Symfony eine Stärke gegenüber bspw. Laravel aus. Die aktuelle LTS Version von Symfony (7.4) wird bis 11/2029 mit Sicherheitsupdates versorgt. Das dürfte erstmal für genügend Ruhe sorgen.

Dass das Ganze langwierig sein wird haben wir vermutlich auch immer - egal für welchen Weg wir uns entscheiden. Symfony ist aber sehr modular aufgebaut und ich kann Teile davon nutzen und andere wiederum nicht. Ich wähle erstmal nur die Komponenten aus, die mir wirklich weiterhelfen und lasse den Rest so wie es ist. Wenn diese Baustelle dann abgeschlossen ist kann ich die nächste angehen. Damit kann ich dann auch den Parallelbetrieb von verschiedenen Architekturen deutlich reduzieren.

Dein Post erweckt für mich den Eindruck, dass die Optionen A, B und C (und D wenn wir deinen Ansatz noch dazu nehmen) verschiedene Wege darstellen und wir uns dazwischen entscheiden müssen. Das sehe ich aber in vielen Aspekten nicht so. Bei einem vollständigen Wechsel zu Symfony, wäre bspw. die Option C quasi "enthalten". Bei Option B kann man für jeden Punkt durchaus die von Symfony "angedachte" Lösung benutzen und eben modular ohne den Rest des Symfony-Frameworks verwenden. Und bei Option A kann man die Umstellung natürlich mit der unter Option B genannten Priorisierung starten. Für mich spielt das also alles ineinander.

Was mir noch einfällt:

- Eine Menge von Code der darauf abzielt optionale Module (separat zu erwerbern) zu integrieren und wenn das Modul fehlt oder da ist aber deaktiviert ist oder da ist und aktiviert ist jeweils etwas anders macht

- Unmengen von JS-Code der inline in PHP-Dateien erzeugt wird, oft noch mit PHP-Variablen ergänzt wird und dann mittels $app->Tpl->Set in eine Template-Variable geschrieben wird. Wann welche JS-Code nun im Output vorhanden ist und ob der auch was bewirkt oder oder Target fehlt ist sehr häufig nur mit aufwendiger Suche nachvollziehbar

- Zahlreiche DB-Querys mit potentiell gefährlichen sprintf oder sowas... ob die dort injizierte Variable zuvor korrekt escaped oder geprüft wurde... erstmal suchen, also potentiell weiterhin gefährlich

- Daten werden oft in wirren Arrays umhergereicht... was da drin steckt oder stecken muss und was nun der Unterschied zwischen $data['ustfrei'], $data['umsatzsteuer'] und $data['steuersatz'] ist erfordert ebenfalls sehr viel Recherchearbeit

- Das Ganze Cronjob/Prozessstarter-System ist "historisch gewachsen"... das ist die einzige Ausrede die mir dafür einfällt

Und wenn ich noch länger nachdenke fällt mir sicher auch noch mehr ein...

Für mich ist es relativ eindeutig, dass egal was wir unternehmen, der Umbau "nebenher" laufen muss. Wir können uns da natürlich organsieren und die Themen nacheinander angehen oder verschiedene Personen arbeiten an unterschiedlichen Themen gleichzeitig. Aber das System muss während des Umbaus lauffähig bleiben, anders sehe ich nicht wie das funktionieren soll.

Warum habe ich symfony vorgeschlagen? Natürlich weil ich damit schon gearbeitet habe und es kenne. Aber auch weil ich oft bei den von mir und Alex erwähnten Punkte ja bereits überlegt habe wie man es besser machen könnte und dachte: hätte ich jetzt symfony wüsste ich einen guten Weg. Das ist sicherlich nicht immer das non-plus-ultra, aber symfony hat ein breites Spektrum mit gut durchdachten Ansätzen und es hat für mich ein schlüssiges Gesamtkonzept. Am Ende wirkt zumindest der Großteil des Codes wie aus einem Guss.

Ich mache gerade mit symfony auch ein paar Trockenübungen an OpenXE um mal zu sehen wie das gehen könnte. Ich kann da momentan nicht super viel Zeit reinstecken, daher werde ich wohl noch ein paar Tage brauchen bis ich mehr dazu sagen kann. Aber der erste Test, symfony einfach vor das ganze OpenXE zu schalten war schonmal erfolgreich und ich kann alle Anfragen durch symfony routen (inkl. ErrorHandler und WebProfiler) und zudem Symfony-Services in OpenXE nutzen (bspw. Twig-Templates oder Doctrine). Dazu gerne in ein paar Tagen mehr.

Ich habe ja schon auf Github etwas dazu geschrieben, will das aber der Vollständigkeit halber hier auch nochmal kurz schreiben:

Ich finde deine Bemühungen auch echt klasse. Zumal man mit einem kleinen Proof-of-Concept auch mehr erreicht als mit vielen langen Diskussionen... wobei "klein" jetzt für deine Arbeiten auch nicht mehr ganz passend ist

Bei deinem Ansatz gibt es einen kompletten Technologie-Wechsel. Kein PHP mehr, überwiegend JavaScript/TypeScript. Mal davon abgesehen, dass ich kein großer Fan davon bin, bedeutet das natürlich einen vollständigen Code-Rewrite inkl. den ganzen neuen Erweiterungen. Also auch der ganze "neue" Code seit dem Fork von Xentral muss ein weiteres mal "geschrieben" werden. Das zudem in einer Sprache, die zumindest für einige der aktuellen Kernentwickler nicht in der Komfort-Zone liegt. Es braucht also nicht nur den Willen sondern auch eine gewisse Lernphase.

Aktuell geplante und laufende Entwicklungen müssen entweder pausieren oder doppelt erfolgen (in PHP und in TS). Da bestehender Code nicht weitergenutzt werden kann, würde die neue Fassung sehr viel Zeit verschlingen bis sie auch nur ansatzweise an die aktuelle Version heran reicht.

Ich sehe gerade nicht, dass die Vorteile deines Ansatzes die Nachteile überwiegen. Zudem frage ich mal ganz vorsichtig: Wer bezahlt das alles? Ich investiere auch viele Stunden in ein OpenSource-Projekt ohne finanzielle Gegenleistung, aber das geht natürlich nur bis zu einem gewissen Grad. Der Kühlschrank muss ja auch irgendwie gefüllt werden. Ohne, dass hier Investoren bereit sind Geld hinzulegen würde sich so ein vollständiger Umbau vermutlich über viele Monate/Jahre hinziehen - eben ohne einen Zwischenstand der für die Mehrheit nutzbar wäre.

Da ich aber auch sehe, dass hier Handlungsbedarf besteht, möchte ich zumindest einen Gegenvorschlag machen:
Mit dem Einsatz des PHP-Frameworks Symfony könnten wir den bestehenden Code schrittweise modernisieren. Das "Backend" könnte nach und nach auf die Verwendung von Symfony umgestellt werden, Modul für Modul modernisiert werden ohne dass es längere Zeiträume gibt in der die Codebasis nicht produktiv genutzt werden kann. Das UI kann ebenfalls durch die Verwendung eines modernen Template-Systems wie Twig überarbeitet werden, womit auch dein ursprüngliches Problem adressiert werden kann. Statt einem vollständigen Umbau auf React oder Vue, werden einzelne Komponenten je nach Komplexität und Dringlichkeit mittels Symfony UX "aufgewertet", durch ein Vue oder React Component ersetzt oder auch erstmal unverändert weitergenutzt. Mit diesem Ansatz erhalten wir ebenfalls viele Vorteile eines modernen Frameworks, bleiben aber in der PHP-Welt und können die Umstellung ohne harten Bruch vornehmen.

Vielen Dank für Deine Mühe und den PR.

Dies freut mich gleich in zweifacher Hinsicht. Ich hatte die docker-compose vernachlässigt, da nach meinem Gefühl das ohnehin niemand bzw. kaum jemand benutzt. Eine Integration in Richtung github-Actions hatte ich daher gar nicht erst in Betracht gezogen, halte das aber grundsätzlich für sehr sinnvoll - auch da ich ja Stück für Stück den Javascript-Code modernisiere und dafür vite einsetze.

Auf den ersten Blick habe ich jetzt gesehen, dass der vite-container bei dir rausgeflogen ist. Das würde in der Entwicklung so für mich nicht funktionieren.

Ich begrüße einige deiner Ideen für Entwicklungs- und Test-Umgebungen, würde aber das Auto-Update so wie hier ungern in einem Produktiv-Image haben wollen.

Mein Vorschlag wäre daher, dass wir deinen PR als wirklich guten Start ansehen, aber noch ein paar weitere Schritte gehen, bevor wir den PR mergen.

Um da konkreter werden zu können, muss ich mir aber auch etwas mehr als 15min Zeit nehmen, was ich nicht sofort schaffe. Ich würde mich dazu bald nochmal detaillierter (direkt im PR) zu Wort melden.

Habe den Fix schon gepusht, Alex muss ihn nur noch übernehmen, dann sollte das wieder gehen.

Ich weiß, dass es von Xentral damals mal ein Tool gab, aber auch das gab es nur für Mac und Linux soweit ich weiß. Und ob das mit OpenXE kompatibel ist und ob das OpenSource ist, weiß ich leider nicht.

Soweit ich weiß ist Hetzner Webspace auch Linux...

Webspace unter Windows kann ich eigentlich nur abraten

Ja, das geht. Du brauchst eigentlich nur das passende cups print command für deinen Drucker.

Dann wählst du im Drucker als Anbindung "Kommandozeilenbefehl" und trägst das dort ein. Du kannst es natürlich auch noch wie ich mit einem Cups-Printserver kombinieren auf dem dann alle Drucker zentral mit ihren Treibern eingerichtet sind:

Es gibt aber echt gute Etikettendrucker für wenig Geld... das wäre meine Empfehlung

Ich denke ich konnte das Problem beheben. Alex muss es noch reviewen und veröffentlichen, er wird dann hier sicher Bescheid geben.