Um erste Erfahrungen mit dem Patchen von webEdition zu sammeln, habe ich mich auf von mir selbst entdeckte/gemeldete Fehler konzentriert. Dabei habe ich mit ehr trivialen Fehlern angefangen, um dann an komplexere heranzugehen. Ein anderes Kriterium war, ob mich dieser Fehler selbst bei der Template Entwicklung besonders störte und ein aufwändiger Workaround notwendig war.

Hier die einzelnen Fehler in (halbwegs) chronologischer Reihenfolge:

• #3547 "sessionField name="Username" type="hidden" autofill="true" erzeugt ungültige Usernamen"
  Lösung: eigentlich (siehe unten) ein Einzeiler in der we:sessionField-Tag Datei  Patch wurde in Version 6.0.0.5 aufgenommen und veröffentlicht
• #3152 "<we:img ohne gewähltes Bild produziert nicht valide Ausgabe"
  Eigentlich eine we-5-Bugmeldung, aber der Fehler ist auch in we-6 noch vorhanden
  Lösung: trivial (ein "/>" statt ">" am Ende der Ausgabe des Tags
• #3537 "weCheckForm findet sich selbst nicht"
  Lösung: trivial (ein "/" löschen)
• #3666 "Shop-Einstellungsdialog speichert bei Klassen-ID nur noch max. 1 Klasse ab"
  Lösung: trivial (abs($_REQUEST['classID'] ersetzt durch trim($_REQUEST['classID'])) 
• #3443 bzw. #3101 "Newsletter-Modul: Bilder können nicht gesendet werden"
  Ursache: Änderungen in der in PHP eingesetzten PCRE-Version (preg_match..), in unterschiedlichen PHP-Versionen, je nach Distribution, unterschiedlich "drin", daher sehr schlecht reproduzierbar
  In der neuen PCRE-Version muss das = Zeichen escaped werden, Lösung mit Hilfe von Daniel Schröder, der einen Ersatz-Pattern geliefert hat.
  Der Pattern taucht nicht nur im Newsletter-Modul auf, sondern auch an verschiedenen anderen Stellen, könnte die Ursache für weitere schlecht reproduzierbare Bugs sein.
  Lösung: Alle entsprechenden identischen Pattern geändert (es könnte mehr geben wo das = noch vorkommt),
  Relativ aufwändig (musste aber gelöst werden, da Kunde in we-5 — auch betroffen— seinen Newsletter versenden wollte), mit Auswirkungen in vier Dateien.
• #3538 "we:a edit="shop" findet nicht die Objekt-ID wenn das Objekt mit we:objekt geladen wird" (Shop realisiert mit Objekt-Modul)
  und (nicht in der bugbase) we:a findet ObjektID auch nicht, wenn in einer listview über Shop-Objekte eine Listview über Varianten drin ist, und dann die einzelnen Varianten per we:a in den Warenkorb sollen
  Lösung: ca. 3 Stunden (hab ursprünglich deutlich länger gebraucht um in zwei Kunden-Projekten einen Workaround herum zu programmieren)

Zu allen obigen Patches fehlt es bisher an jeglicher Rückmeldung durch das Entwickler-Team. Manches hätte sicherlich eleganter gelöst werden können, mache Patches sind eventuell nicht vollständig in dem Sinne, dass nicht alle Seiteneffekte berücksichtigt wurden. Aber wer will das ohne Rückmeldung wissen.

Eins weiß ich aber: Ich muss meine Patches vor Veröffentlichung besser testen.

Neuer Fehler durch meinen Patch

Der einzige meiner Patches, der bisher in den Main-Trunk von we aufgenommen wurde (#3547) war leider fehlerhaft!

Entstanden ist der Fehler

• #3669 "we:sessionfield type="hidden" autofill="true" name= XYZ gibt immer ein input tag für username aus (auch bei passwort)"
  Damit funktionieren jetzt alle Shops nicht mehr richtig, die autofill="true" beim we:sessionField-Tag einsetzen!
  Es ist ein typischer Flüchtigkeitsfehler, der wegen magelnder Tests erst nach ein paar Tagen aufgefallen ist.
  if($name="Username"){$condition = array...
  sollte sein
  if($name=="Username"){$condition = array...
  Habe natürlich sofort einen Patch dafür erzeugt.

Meine Hoffnung ist natürlich, dass das Entwickler-Team die obigen Patches prüft, (gegebenenfalls kritisiert / korrigiert / Hinweise für Verbesserungen gibt) und in den Main-Trunk aufnimmt (und schnellstmöglich eine neue Version veröffentlicht die wenigstens #3669 behebt).

ältere Meldungen »« aktuelle Meldung