Fahlermeldung bei Dokumenterstellung nach Update auf 5.2.1

Hallo zusammmen,

nach dem Erstellen der Rechnung in der Bestellverwaltung kommt folgende Fehlermeldung, wenn man das Dokument anklickt:

{"success":false,"data":{"id":"0fe9133add0cd542f6ab4962d98336c7","module":"backend","controller":"Order","action":"openPdf"},"message":"File not exist"}

Wenn ich versuche, die Rechnung oder ein anderes Dokument neu zu erstellen, kommt bei Klick auf „Vorschau“ oder „Dokument erstellen“ folgende Fehlermeldung: 

503 Service unavailable

Hoppla, das ist wohl so nicht vorgesehen. Was muss ich machen? Kenne mich mit Computern leider überhaupt nicht aus. Kann nur sagen, dass unser Betreib stillsteht, weil die Auftragsbearbeitung keine Rechnungen aus dem System rauskriegt.

Fehler existiert erst seit Update auf 5.2.2. Im Update-Guide steht nichts zu dem Thema.

Grüße
Pierre

Beim Querlesen des Forums entsteht bei mir der Eindruck, dass der 503-Fehler nach Update auf 5.2  bei verschiedenen Funktionen auftaucht und qualifizierte Antworten halten sich momentan noch in Grenzen, anscheinend weiß man bei SWAG selbst noch nicht so genau wo es hakt. Dass es bei mir an Plugins liegen könnte, vermute ich eher nicht, ich hab da außer den Core-Plugins eigentlich kaum was drin. IonCube ist auch auf der neuesten Version, Systeminfo sagt alles in Ordnung.

Wenn die Verifizierung des Problems noch mehr Zeit in Anspruch nimmt, muss ich ein Downgrade machen bzw. zur Datensicherung von vor dem Update zurückkehren. Muss man in Zukunft wohl abwarten, bis die „finalen“ Versionen etwas abgehangen sind.

@pierre-schmitz schrieb:

Muss man in Zukunft wohl abwarten, bis die „finalen“ Versionen etwas abgehangen sind.

das war noch nie anders :) 

@pierre-schmitz schrieb:

Hallo zusammmen,

nach dem Erstellen der Rechnung in der Bestellverwaltung kommt folgende Fehlermeldung, wenn man das Dokument anklickt:

{„success“:false,„data“:{„id“:„0fe9133add0cd542f6ab4962d98336c7“,„module“:„backend“,„controller“:„Order“,„action“:„openPdf“},„message“:„File not exist“}

Wenn ich versuche, die Rechnung oder ein anderes Dokument neu zu erstellen, kommt bei Klick auf „Vorschau“ oder „Dokument erstellen“ folgende Fehlermeldung: 

503 Service unavailable

Hoppla, das ist wohl so nicht vorgesehen. Was muss ich machen? Kenne mich mit Computern leider überhaupt nicht aus. Kann nur sagen, dass unser Betreib stillsteht, weil die Auftragsbearbeitung keine Rechnungen aus dem System rauskriegt.

Fehler existiert erst seit Update auf 5.2.2. Im Update-Guide steht nichts zu dem Thema.

Grüße
Pierre

Hallo,

da das Generieren von Dokumenten bei allen Demoshops und auch vielen anderen Shops unter Shopware Version 5.2.2 problemlos funktioniert, wird es leider an deinem System liegen, beziehungsweise an einem Plugin von dir, was noch nicht kompatibel mit Shopware ab Version 5.2 ist. Das hat also nichts direkt mit Shopware Version 5.2 zu tun. Ebenso sollte man so und so das Update vorerst in seiner eigenen Testumgebung durchführen, um Fehler vorher auszuschließen.

Die 503 - Fehler wurden bisher ansich immer durch eigene Anpassungen in Template - Dateien oder nicht kompatible Plugins verursacht - also ist dies ansich auch nicht die „Schuld“ von Shopware.

Hast du Anpassungen an den Template - Dateien der Dokumente genommen?

Beste Grüße

Sebastian

1 „Gefällt mir“

Hallo Sebastian,

ja, ich habe Änderungen an den Templatedateien der Dokumente vorgenommen. Wo steht, dass man dadurch die Updatefähigkeit des Gesamtsystems verliert?

Im Rechnungstemplate wurde die Reihenfolge der Tabellenspalten geändert und es wird zusatzlich ein Artikelattributfeld (Lagerort) ausgegeben. Mehr isses nicht

Der 503-Fehler kommt aber auch bei den Dokumentenarten, deren Template nicht verändert wurde…

Grüße
PIerre

@pierre-schmitz schrieb:

Hallo Sebastian,

ja, ich habe Änderungen an den Templatedateien der Dokumente vorgenommen. Wo steht, dass man dadurch die Updatefähigkeit des Gesamtsystems verliert?

Im Rechnungstemplate wurde die Reihenfolge der Tabellenspalten geändert und es wird zusatzlich ein Artikelattributfeld (Lagerort) ausgegeben. Mehr isses nicht.

Grüße
PIerre

Hallo,

das Problem ist bei diesem Punkt nicht, dass man Änderungen vorgenommen hat - sondern wie. Oft wird beispielsweise von einer Template - Datei falsch abgeleitet und somit wichtige Sachen unnötig überschrieben oder Fehler verursacht. Natürlich kann man (mittels Vererbung) jederzeit updatesicher Änderungen vornehmen - man sollte dies eben nur nach den Shopware - Regeln tun, damit keine Fehler entstehen.

Wenn du beispielsweise eine fehlerhafte Anpassung im Rechnungstemplate vorgenommen hast, wird diese ja automatisch auch an alle anderen Dokumente weiterverbt, da alle anderen Dokumente ja auf dem Rechnungstemplate basieren.

Hast du einmal probiert, deine Anpassung zu entfernen, ob es dann wieder funktioniert?

Beste Grüße

Sebastian

Und die Tatsache, dass es im Demoshop funktioniert, heißt noch lange nicht dass alles so miteinander funktioniert wie es funktionieren soll, sondern eben nur dass es in der Demokonfiguration funktioniert.

@pierre-schmitz schrieb:

Und die Tatsache, dass es im Demoshop funktioniert, heißt noch lange nicht dass alles so miteinander funktioniert wie es funktionieren soll, sondern eben nur dass es in der Demokonfiguration funktioniert.

Hallo,

nein - das heisst aber, dass das Update in der Standardkonfiguration des Shopsystems funktioniert/funktioneren muss - und es bei Fehlern nicht am System, sondern an eigenen Anpassungen (Theme, Plugins, etc.) liegen muss.

Beste Grüße

Sebastian

Ich habe im Themeverzeichnis nachgesehen, da war bei den Dokumenten eine angepasste index.tpl drin. Hab die Datei in index.OLD umbenannt und alle Caches gelöscht. Jetzt sollte er sich ja die Dokumententemplates aus Bare holen, oder? Leider ohne Erfolg, es kommt immernoch Fehler 503.

Dokumenten-Templates sind unter Grundeinstellungen > Shops einzustellen.

@pierre-schmitz schrieb:

Ich habe im Themeverzeichnis nachgesehen, da war bei den Dokumenten eine angepasste index.tpl drin. Hab die Datei in index.OLD umbenannt und alle Caches gelöscht. Jetzt sollte er sich ja die Dokumententemplates aus Bare holen, oder? Leider ohne Erfolg, es kommt immernoch Fehler 503.

Hallo,

hast du einfach einmal alle Plugins deaktiviert, die eventuell im Bestellungsbereich aktiv sein könnten? Beziehungsweise mal im Shopware Store nachgesehen, ob all deine installierten Plugins auch kompatibel mit Shopware ab Version 5.2 sind?

Beste Grüße

Sebastian

1 „Gefällt mir“

Okay, ich brech jetzt hier ab. Es scheint doch mit Inkompatibilitäten mit Plugins zu tun zu haben. Anscheinend muss man wirklich sehr genau darauf achten, dass wirklich alle Plugins als kompatibel markiert sind. Ich benutze hier das DHL-Plugin von SWAG und hierzu steht im Update-Guide (ganz unten in der allerletzten FAQ-Zeile), dass noch an einer Lösung gearbeitet wird. Hab ich natürlich übersehen… Der simple Updatemechanismus im Backend verleitet dann doch vielleicht etwas vorschnell dazu, einfach mal auf den Knopf zu  drücken…

Trotzdem schon mal vielen Dank.

Hallo Sebastian,

ich komme nochmal aufs Thema zurück, zwei Fragen haben ich noch:

  1. Du hattest geschrieben, dass man ein Upgrade erst einmal in einer eigenen Testumgebung nachvollziehen soll. Das fände ich ja super, bisher hab ich aber keine Ahnung, wie ich so eine Testumgebung sinnvoll aufsetzen kann. Die Plugin-Lizenzen sind ja auf die endgültige Domain registriert und wenn man das Zusammenspiel mit Plugins testen will, ist man ja quasi gewzungen, am offenen Herzen zu arbeiten. Am liebsten wäre mir die Möglichkeit, eine Zweitinstallation als Testumgebung auf der Live-Hardware, z.B. unter einer nicht für den Live-Betrieb geeigneten kryptischen Subdomain laufen zu lassen (auch über htusers abgesichert) und die Plugins funktionieren trotzdem. Soweit ich das verstanden hab, ist das aber nicht möglich, oder? Gibt es eine Alternative?

  2. Ich hab jetzt meine Datensicherung zurückgespielt und jetzt stimmen die Umlaute im Backend nicht mehr (Popup-Medungen etc.). Die Umlaute der Produkte sind richtig. Hab die Datenbank mit der Option --default-character-set=utf8 zurückgespielt aber das reicht anscheinend nicht aus. Irgend ein Tipp?

Danke und Grüße
Pierre

@pierre-schmitz schrieb:

Hallo Sebastian,

ich komme nochmal aufs Thema zurück, zwei Fragen haben ich noch:

  1. Du hattest geschrieben, dass man ein Upgrade erst einmal in einer eigenen Testumgebung nachvollziehen soll. Das fände ich ja super, bisher hab ich aber keine Ahnung, wie ich so eine Testumgebung sinnvoll aufsetzen kann. Die Plugin-Lizenzen sind ja auf die endgültige Domain registriert und wenn man das Zusammenspiel mit Plugins testen will, ist man ja quasi gewzungen, am offenen Herzen zu arbeiten. Am liebsten wäre mir die Möglichkeit, eine Zweitinstallation als Testumgebung auf der Live-Hardware, z.B. unter einer nicht für den Live-Betrieb geeigneten kryptischen Subdomain laufen zu lassen (auch über htusers abgesichert) und die Plugins funktionieren trotzdem. Soweit ich das verstanden hab, ist das aber nicht möglich, oder? Gibt es eine Alternative?

  2. Ich hab jetzt meine Datensicherung zurückgespielt und jetzt stimmen die Umlaute im Backend nicht mehr (Popup-Medungen etc.). Die Umlaute der Produkte sind richtig. Hab die Datenbank mit der Option --default-character-set=utf8 zurückgespielt aber das reicht anscheinend nicht aus. Irgend ein Tipp?

Danke und Grüße
Pierre

Hallo,

zu 1.: man kann ja jederzeit ein zweites Shopsystem als Testumgebung in einem Unterordner ablegen - die Plugins sind ja auf die Domain registriert, dadurch klappen sie dann auch problemlos im Unterordner (natürlich sollte man auch eine zweite Datenbank verwenden). Da gibt es auch keinen Grund, wieso das nicht erlaubt sein soll Angry-Face.

zu 2.: da hast du sicher den falschen Charset verwendet - hast du es einmal mit iso oder anderen probiert? Ich musste bisher noch nie eine Datensicherung zurückspielen, da immer alles vorab in der Testumgebung ausgiebig getestet wurde. Kann dein Hoster nicht ein Backup einspielen?

Beste Grüße

Sebastian

Hier mal ein Screenshot.

Jo, die Sicherung ist schon okay und wenn global der falsche Zeichensatz verwendet wurde, krieg ich das schon repariert. Aber momentan scheint alles quer durcheiander zu gehen und ich weiß gar nicht, ob die Datenbank das Problem ist…

Hab mal ein neues Thema aufgemacht. Vielen Dank!

@pierre-schmitz schrieb:

Okay, ich brech jetzt hier ab. Es scheint doch mit Inkompatibilitäten mit Plugins zu tun zu haben. Anscheinend muss man wirklich sehr genau darauf achten, dass wirklich alle Plugins als kompatibel markiert sind. Ich benutze hier das DHL-Plugin von SWAG und hierzu steht im Update-Guide (ganz unten in der allerletzten FAQ-Zeile), dass noch an einer Lösung gearbeitet wird. Hab ich natürlich übersehen… Der simple Updatemechanismus im Backend verleitet dann doch vielleicht etwas vorschnell dazu, einfach mal auf den Knopf zu  drücken…

Trotzdem schon mal vielen Dank.

@pierre-schmitz Bist du dir sicher, dass das DHL-Plugin den Fehler verursacht? Ich habe gestern auch auf 5.2.4 aktualisiert und musste heute feststellen, dass die PDF nicht mehr generiert werden. Sollte es an dem Plugin liegen, möchte ich ungern zurück auf 5.1.7.

@shopware Schade, dass der Hinweis nur in den FAQs steht  

Hallo JoernBernd,

sorry für die verspätete Antwort! Jou, wir konnten anhand des Ausschlussprinzips herausfinden, dass es mit dem DHL-Plugin zusammenhängen muss. Bei uns ist es auch zuerst bei der PDF-Belegerstellung aufgefallen. Irgendwo wurde die Vermutung geäußert, dass es mit den Hausnummern bei DHL oder einer generell unterschiedlichen Verarbeitung der Adressdaten zu tun hat. Da hat sich wohl bei Shopware beim Wechsel auf 5.2 etwas verändert.

Ich frage mich aber trotzdem, warum unbedingt das Plugin dafür angepasst werden muss und warum dazu die Mithilfe von DHL notwendig ist. Das hängt jetzt schon über einen Monat in der Schwebe und die Beteiligten (SWAG und DHL) schieben sich gegenseitig die Zuständigkeiten zu. Um so etwas zu vermeiden, wäre es wahrscheinlich sinnvoller  gewesen, in Shopware eine Rückfalloption drinzulassen, damit die Version 5.2 (übergangsweise) weiterhin mit der alten Plugin-Version funktioniert. Dass nicht bei allem auf Abwärtskompatibiltät geachtet werden kann, ist mir schon klar, aber das hier scheint sich zu einer längeren Aktion zu entwickeln. Bei Großkonzernen liegen die Prioritäten  eben anders.

Grüße