Wenn man den Lieferschein erzeugt, fällt manchmal auf dass das eine Datum sich im Format stark unterscheidet. Es wäre so als würde es eine andere Locale als die anderen benutzen.. oder gar keine.
Der Fehler liegt direkt in der delivery_note.html.twig:
% block document_side_info_contents %}
{{ parent() }}
<tr><td>{% trans with {'%deliveryDate%': config.custom.deliveryDate|format_date('medium', locale=order.language.locale.code)} %}document.deliveryDate{% endtrans %}</td></tr>
{% endblock %}
[code]
Wenn man sich die anderen Datum-Formate in der base oder letter_header Datei anguckt fällt auf, dass hier das Locale nicht aus der Order stammt bzw nicht daraus gelesen wird. Korrekt wäre hier also:
[code]
% block document_side_info_contents %}
{{ parent() }}
<tr><td>{% trans with {'%deliveryDate%': config.custom.deliveryDate|format_date('medium', locale=locale)} %}document.deliveryDate{% endtrans %}</td></tr>
{% endblock %}
Sollte man einfach mal in Cura prüfen, ob die Größe des Beds richtig eingestellt ist. Marlin schien damit keine Probleme auf einem Ender 3 zu haben. Bei Klipper kommt es zu einem Fehler.
Manchmal möchte man Artikel für 0.00 Euro anbieten. Zum Beispiel irgendwelche Muster-Artikel.
Wenn man nun einfach einen Preis von 0.00 Euro eingibt, gibt es einige seltsame Nebeneffekte. Der Warenkorb funktioniert auch nicht mehr und man findet im Log den Fehler (sBasket::getPriceForAddProduct):
Ich habe gerade die Early Access Version von Shopware 6 installiert und erst einmal einen Hersteller und einen eigenen Artikel angelegt.
Das Problem war, dass ich keine Scale-Unit mit angeben konnte, da ich einfach noch keine angelegt hatte und nicht alle Artikeldaten nochmal neu eingeben wollte habe ich das Feld einfach leer gelassen. Speichern klappte ohne Probleme.
Die Kategorie funktionierte dann aber nicht mehr.
Zum Glück war mir das ja direkt aufgefallen, dass ich da was nicht eingeben konnte und habe erst einmal versucht eine Unit anzulegen und zu ergänzen.
Danach funktionierte es dann auch alles.
Da muss man also aufpassen, weil fehlende Eingaben noch viel kaputt machen können. Hab da auch gleich ein Issue dafür aufgemacht.
Wenn der Fehler auftritt, dass ein Windows-PC die Domain in Netzwerk nicht finden kann und keine Verbindung zum Active Directory-Domaänencontroller hergestellt werden kann, kann es helfen das IPv6-Protokoll zu deaktivieren.
Sollte der PC dann in der Domain registriert sein, sollte man das IPv6 wieder aktivieren können und es sollte alles ohne Probleme funktionieren.
Das wären so für mich die Highlights, warum man schnell auf Shopware 5.3.5 updaten sollte. Gerade die eigene Email Adresse für Fehlermails ist echt praktisch, besonders wenn man wieder Bots Formulare ausfüllen und X-CSRF Fehler auslösen.
SW-18075 - Es ist nun möglich, Fehlermails an eine separate Email Adresse zu verschicken.
SW-18510 - Fügt den API Endpunkt /users hinzu, welcher es ermöglicht Backend Benutzer über die API zu verwalten (larsbo).
SW-19404 - Ändern der Erstellung der Cronjobs, um aktive Cronjobs über die 'cronjob.xml' erstellen zu können (t2oh4e).
Falls es beim ersten Deployment zu einer Fehlermeldung vom JBoss/WildFly kommt, das eine Resource nicht gefunden werden könnte. Sollte man "STRG" + "SHIFT" + "ALT" + "S" drücken und dort unter Artifacts das vorhandene Artifact auf einen "Archive"-Typ ändern.
Diese Artifacts sind ganz praktisch, da man sie gut in einander verschachteln kann. Man nutzt ein Artifakt zum Bauen der Haupt-JAR und nutzt dieses Artifakt dann wieder im dem Artifakt, das man zum Bauen
der EAR nutzt.
Maven Elemente kann man einfach mit rein packen in die EAR und die entsprechenden JARs werden in der fertigen EAR abgelegt. Teilweise sehr viel einfacher als eine Standalone Anwendung über Maven zu bauen, wo auch alle Libs als JAR in eine große JAR zusammen kompiliert werden.
Ich mag EAR-Files....
und ich hatte auch etwas den Kampf mit dem JBoss/WildFly vermisst.. so etwas hat man mit PHP einfach nicht.
Ist es falsch das Java einen zwingt eine Exception zu fangen, wenn explizit eine geworfen werden kann.
Also das Fehler dort behandelt werden, wo sie auftreten und man sie nicht immer bis ganz nach oben reichen sollte?
public class ThrowExample {
private void method1() throws Exception {
throw new Exception("test");
}
public void call() throws Exception {
this.method3();
}
}
Bei Java kann es so nie passieren, dass am Ende eine Exception auftaucht, von der man nie wusste, dass sie geworfen wurde. Weil sie entweder schon mit einem Try-Catch-Block gefangen wurde oder aber man über die Existenz dieses Exception mit Hilfe des "throws" an der Methode direkt informiert wird.
PHP hat mit Exception ab PHP 7.0 viel verbessert, aber um die Wahrheit zu sagen, ist das was ich noch gerne hätte ein "throws" damit ich weiß, dass in der Methode, die ich gerade verwende, das Werfen einer Exception implementiert wurde.
Fehler Behandlung ist schwer und Exceptions als brauchbare Fehlermeldungen an den Benutzer hoch zu reichen ist nicht einfach... aber einfach dann die Exceptions bis zum Benutzer durch laufen zu lassen ist doch eher der falsche Weg und ein gutes Exception-Handling Framework wäre die bessere Lösung gewesen.
Deswegen sehen ist den Verzicht auf den Zwang Exceptions fangen zu müssen in Kotlin eher negativ und nicht als Vorteil.Nur als einen Punkt nun dem Entwickler aufgehalst wird (er muss sich nun darum kümmern, dass Exceptions richtig behandelt werden), wo vorher der Compiler einen dabei unterstützt hat auch alle Exceptions richtig zu behandeln.
Wenn man mit JSON arbeitet, hat man auch manchmal das Problem, das eine JSON Nachricht nicht umgewandelt werden kann oder eine Nachricht in einem kaputten Format am Client ankommt.
Dann hilft meistens ein Validator um heraus zu bekommen was an dem Format gerade nicht stimmt. Teilweise ein Komma zu wenig oder eine Klammer zu viel. Wenn man versuchen würde das in einem Texteditor oder in der einzeiligen Darstellung im Webbrowser zu finden, kann man sehr lange suchen. Bei solchen Problemen hilft diese kleine Webapplikation sehr:
Auch wenn man JSON per PHP per Hand zusammen stückelt falls man eine automatische Umwandlung verwenden kann, ist sie sehr hilfreich für schnelle Tests zwischendurch.
Nachdem man in Tine 2.0 einen Account aus einem alten DB-Backup per Hand über SQL wiederherstellt, muss man in GROUP_MEMBERS den Account auch wieder hinzufügen und die Contact-Id überprüfen, sonst kann man den WebDAV-Service für alle Benutzer lahmlegen!
Entity not im WebDAV-Service deutet auf so ein Problem hin.
Blog-entries by search-pattern/Tags:
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?