Zum Thema "Strukturierte Fehleranalysen vs. Stochern" hat Sebastian bereits eine mögliche Herangehensweise erläutert. Dabei erklärt er die Methode abstrakt. Im heutigen Beitrag wird sie auf ein konkretes Problem angewandt:
Ein simpler File-Upload funktioniert nicht und terminiert mit einer ebenso knappen Fehlermeldung.
Weiterer Hintergrund:
uploadSignedPDFAction() konnte nicht gecalled werden. Diese Methode erwartet zwei Parameter: ein Formular und die hochgeladene Resource. Wird der Resourcen-Parameter weggelassen, funktioniert der Aufruf. Daraus resultiert die Annahme, dass die im Backend ankommende Resource nicht der Erwartungshaltung des Backends entspricht und bereits im Client etwas schief gegangen ist.
Wir beobachten in den DevTools im Netzwerk-Tab, wie das übermittelte Request aussieht und versuchen herauszufinden, ob die Parameter korrekt formatiert sind.
Daraus resultierende Annahme: Die HTML-Struktur unseres Formulars passt nicht.
Fragestellung: Gibt es Besonderheiten, welche in einem HTML-Formular mit Datei-Upload beachtet werden müssen?
Damit Datei-Uploads funktionieren, muss zwingend der enctype="multipart/form-data" am <form>-Tag gesetzt sein.
Dieser fehlt aktuell in unseren DOM.
Der fehlende enctype ist die Ursache dafür, dass keine Binärdaten übertragen werden.
Wir schreiben den enctype manuell in den Browser-DevTools an das Formular-Tag und starten einen Upload. Dabei beobachten wir wieder das Request im Netzwerk-Tab und prüfen, ob der Payload nun korrekt übertragen wird.
In Neos.Fusion.Form im Upload gibt es eine Möglichkeit, um den enctype explizit zu setzen.
Da sich in der Dokumentation von Neos.Fusion.Form kein passendes Beispiel findet, prüfen wir auf Github den Quelltext (Achtung: hier hätten wir bereits im lokalen Code der Library schauen sollen, da die Versionen abweichen können).
Es gibt drei Wege, wie das Encoding gesetzt werden kann:
1. standardmäßig ist die `method` von Form bereits `post` -> in diesem Fall sollte das encoding automatisch `multipart/form-data` sein
2. die `method` kann auch manuell mit `form.method` auf post gesetzt werden
3. der enctype kann manuell mit `form.encoding` gesetzt werden
Unser eigener Fusion code könnte das Form-Element der Library falsch benutzen, weshalb der enctype nicht gesetzt wird.
Überprüfen der verschiedenen Varianten in unserem eigenen Fusion-Code, um herauszufinden, ob es eine Möglichkeit gibt, dass der enctype korrekt gerendert wird und die Binärdaten entsprechend korrekt versendet werden.
Keine der Möglichkeiten führt zum Erfolg.
Das Problem liegt im Neos.Fusion.Form Code, da wir die API (vermutlich - versteckte Annahme ;D) korrekt benutzen.
Wir überprüfen den lokal ausgecheckten Library-Code im laufenden Docker-Container und schauen, ob es dort Auffälligkeiten beim Setzen des enctypes gibt. Dabei suchen wir nach der Stelle im Code, in welchem das Form-Model mit der für das Rendering verantwortlichen Fusion-Component verdrahtet wird.
Wir haben den aktuellen Stand der Library ausgecheckt und in diesem ist das Problem noch vorhanden.
Wir prüfen unsere lokale Library-Version mit der des letzten offiziellen Library-Releases.
Dabei stellen wir fest, dass die lokale Version 1.0.0--beta3 der letzte Release aber bereits 1.0.3 ist.
Jetzt überprüfen wir noch, ob der Fehler im Github-Repository noch vorhanden ist, oder ob er bereits behoben wurde.
Er ist behoben, wir können also einfach ein composer update machen. Andernfalls könnten wir selbst einen Fix mit entsprechendem Pull Request erstellen.
Nach dem Update der Library funktioniert der Code - unsere Detektivarbeit hat sich ausgezahlt =)
Debugging kann manchmal tricky sein. Daher ist es umso wichtiger, strukturiert und systematisch vorzugehen. Ich empfehle daher, Annahmen immer so explizit wie möglich zu formulieren und sie im Anschluss entsprechend mit einem klar designten Experiment zu verifizieren.
Falls ihr Feedback oder Fragen habt, schreibt mir einfach via Twitter an @on3iro
Dein Besuch auf unserer Website produziert laut der Messung auf websitecarbon.com nur 0,28 g CO₂.
