Posts by s.rudolph

Alles klar, habe dafür mal einen Eintrag in der Bugbase angelegt.

Falls sonst jemand das Problem kennt, gern trotzdem antworten, vllt lässt sich ja eine grobe Richtung finden. Die Ursachen können ja vielseitig sein (Server, Verbindung, php usw usw)

Hallo in die Runde

wir haben bei zwei größeren Projekten für Kunden-Formulare das we:userinput type="image" im Einsatz und haben hier über das Tag eine Parent-ID für die Dateien hinterlegt. Die beiden Systeme laufen auf der 9.3.1 und unter php 8.3.22.

Nun kommt es aber sporadisch vor, dass zwar die Dateien hochgeladen werden, aber nicht im Ziel-Verzeichnis landen oder weiter verarbeitet werden (z.B. nicht verkleinert). Die Verknüpfung zum Objekt und Kunden funktioniert jedoch.

Wir selbst konnten das verhalten leider bisher nicht reproduzieren und im Fehlerlog gibt es dahingehend keinerlei Fälle. Es tritt in sehr vereinzelten Fällen auf, aber ist doch ein Problem.

Daher einmal in die Runde:
Hat schonmal jemand anders das Problem mit dem Tag und dem Upload gehabt?
Hat jemand kreative Ideen wie man hier debuggen könnte, um die Fehlerursache irgwie einzugrenzen?

Viele Grüße aus Köln!

Hallo Zusammen,

ich sitze gerade an einem kleinen Problemchen. Undzwar möchte ich ein Feld aus einem geparkten Objekt auslesen bzw. dieses bearbeiten/verändern.

Über we:listview type="object" und <we:object> kriege ich keine Werte aus den Feldern zurück.
Gibt es hier eine Möglichkeit oder ein bestpractice wie ich an die Daten komme?

In älteren webEdition versionsn haben wir das teilweise über $DB_WE abgefragt, aber da wurden kürzlich in webEdition methoden privatisiert.

Grüße aus Köln,
Sebastian

Hallo zusammen,

ich bin gerade dabei ein etwas komplexeres, "mehrstufiges" Anmelde-Formular zu entwickeln, mit dem verschiedene Objekte erzeugt werden können müssen.

Jetzt stehe ich gerade vor dem Problem, dass ich bereits ein objekt über <we:write name classid="1" name="xyz"/> erfolgreich schreibe und mit Daten befüllen kann. Ein zweiter <we:write classid="2" name="abc"/> verursacht aber folgenden Fehler:
"Object [ID-Platzhalter] is no element of class 2!"

Wenn ich wie write befehle von der reihenfolge drehe, schreibt er das objekt mit der classid="2" und nicht mehr das mit der classid="1" - einzeln funktionieren die write-befehle also, nur nicht in kombination.

Meine Frage ist daher, ob das in Kombination miteinander vereinbar ist oder webEdition hier aus guten (mir unbekannten?) gründen blockiert?
Hatte vllt jemand eine ähnlichen Problematik und weiß wie da gelöst oder umgangen werden kann?
Oder hat jemand kreative Ideen?

Viele Grüße aus Köln,
Sebastian

Okay, ich glaub ich bin ein Schritt weiter gekommen. In den Einstellungen habe ich die Loginversuche auf jeweils 100 / 0 h gestellt. (Offtopic Frage: Funktioniert hier 0 stunden als wäre kein limit gesetzt?)

Auf der Seite des Benutzers in der KV wurde mir allerdings "TOPT: nicht gesetzt" - wie lässt es sich denn resetten? Sollte es hier ein button oder so geben? Ich sehe da bei mir leider nichts – Screenshot anbei
Ich habe in der Datenbank nun das Feld für das TOPT gesehen und geleert, nun kommt der QR-Code wieder raus.

Lässt sich der QR-Code irgendwie resetten oder das anzeigen neu triggern? Aktuell wird mir dieser ja nicht mehr im Frontend angezeigt & in der App ist er auch nicht mehr hinterlegt.

Über die Kundenverwaltung habe ich die fehlgeschlagenen Logins zurückgesetzt und erhalte direkt wieder die Fehlermeldung, auch wenn hier 0/4 steht.

Hallo Zusammen,

Anbei zwei Screenshots von den erstellten Templates – diese sind nahezu identisch zu dem Code-Beispiel auf der Tag-Referenz des Tags Sessionstart "Beispiel #1 - Login mittels TOTP".

Beim erneuten Testen erhalte ich nun wieder die Fehlermeldung:
"Dear customer, our service is currently not available. Please try again later. Thank you.<br>Sehr geehrter Kunde, aus Sicherheitsgründen ist ein Login derzeit nicht möglich! Bitte probieren Sie es später noch ein mal. Vielen Dank"

In der KV ist beim User das Feld für TOTP "nicht gesetzt" und in der Authenticator app habe ich den code mal komplett entfernt.

Wie verhält es sich denn mit dem QR-Code? Kann man den irgendwie "resetten" oder so?
Mir fehlt leider gerade leider der Ansatz - kann das vllt jemand einmal erklären oder schauen wo das Problem liegt?

Vielen Dank und viele Grüße!

Hallo zusammen,

bin gerade über das Thema gestoßen, da wir auch eine Anforderung bei einem Kundenprojekt haben.
Der Placeholder ist ja jetzt drin und kann beliebig gesetzt werden, jedoch find ich aus usability-sicht die aktuelle Implementierung noch ausbaufähig. Das Problem bei den selectfeldern ist bei einigen usern ja scheinbar, dass diese einfach überflogen werden.

Sinnvoll wäre es aus meiner Sicht daher, den Placeholder wie z.B. "Bitte auswählen" mit dem attribut disabled zu versehen, damit diese browser-nativ nicht auswählbar sind.

Konnte in der bugbase hierzu gerade nichts finden – gibt es dazu schon einen Beitrag den ich übersehen habe?

Persönlich denke ich, dass es den meisten Sinn macht, wenn das CSS standardmäßig komprimiert ausgegeben wird und es in den Einstellungen eine Möglichkeit geben wird, dies aktiv abzuschalten.

So kann z.B. zum Debuggen der unkomprimierte CSS-Code verwendet werden, auf produktiv Seiten wird jedoch das komprimierte genutzt. Darüber hinaus hätte jeder projektabhängig die Flexibilität es individuell einzustellen oder ggf. andere Tools serverseitig hierfür laufen zu lassen.

Ich würde dann hierzu mal einen Feature Request in der QA anlegen. Ideen und Lösungsvorschläge können ja hier weiterhin erarbeitet werden.

Dass das CSS unleserlich ist, sollte eigentlich nicht wirklich ne Rolle spielen. Chrome z.B. kommt prima damit klar und zeigt im source-panel sogar den unkomprimierten Code an, man hat daher sowieso das beste aus beiden Welten (mit der etwas geringeren Speichergröße & Ladezeit).

Wenn ich die unkomprimierte Datei mit der komprimierten Datei vergleiche, sehe ich eine Einsparung von ca. 21% bei unserer eigenen Website. Ich denke, dass sich das daher schon lohnt - allgemein, weil das SCSS ja sowieso geparsed wird und später nur komprimert übergeben wird.

Für den Pagespeed und somit SEO relevant ist das Thema zudem auch - nicht mehr so stark wie früher vielleicht, aber dennoch stark genug.

Für mich stellt sich nun eigentlich nur die Frage, welcher der beste Lösungsansatz wäre. Würde es für die meisten User den größten Benefit liefern, wenn man das CSS standardmäßig komprimiert ausgibt, baut man eine Checkbox/Auswahl in die Einstellungen ein, mit der man das verhalten steuert?

Grundsätzlich geht es mir dabei ja nur um die Update-Sicherheit, damit wir bestenfalls nicht immer in der Core suchen und diese bearbeiten müssen.

Sobald man aber mit frameworks/libs arbeitet ist SCSS aktuell noch gängiger Standard. Das arbeiten mit partials ermöglicht zudem häufig einen übersichtlicheren und leichteren workflow und die Portabilität zwischen Projekten.

Lädt man bootstrap z.B. als source files runter kann man so bequem unbenutzte Partials/Module einfach auskommentieren und einkommentieren falls man diese später doch braucht.

In dem Feature Request ging es auch nicht um die grundsätzliche Frage, ob SCSS oder CSS, sondern ob das bereits integrierte Tool um eine Option zur Komprimierung ergänzt werden könnte.

Darüberhinaus muss man bei solchen "Trends" ja bekanntlich aufpassen, ein nicht zu kleiner Teil der im Beitrag erwähnten Themen ist so meines Wissen nach nicht browserübergreifend integriert - von der backwards compatibility mal ganz abgesehen.

Hallo zusammen,

ich hätte ein Anliegen bezüglich des SCSS-Compilers in webEdition. Bisher sind wir bei Projekten über den save_hook hingegangen, haben alle Verzeichnisse und Dateien "eingesammelt" und dem Compiler den Befehl gegeben, mithilfe der (lokalen) cssmin php-library das erstellte CSS automatisch zu komprimieren.

Problem: die cssmin ist so veraltet, dass sie mit den häufig verwendeten CSS-Variablen var(--hintergrundfarbe) nicht klarkommt und diese schlicht einfach killt.

Ich habe etwas recherchiert und einen Ausflug in die webEdition Core gemacht und dort gesehen, dass webEdition intern die scssphp zum kompilieren der SCSS Dateien nutzt. Die Library bietet 2 verschiedene OutputStyles an: EXPANDED und COMPRESSED.

Testweise habe ich in einer Testumgebung in der we_document_text.class.php einmal das entsprechende Flag in dem Bereich SCSS gesetzt (screenshot anbei) und siehe da: webEdition kompiliert das SCSS, CSS Variablen werden korrekt geparsed und darüber hinaus wird das ganze sogar noch automatisch komprimiert. Klasse, so sparen wir uns sogar die veraltete php library!

Mit der Änderung an der Core-Datei ist das ganze natürlich nicht mehr update sicher, daher hier meine Frage:
Wäre es nicht einfach möglich, in den Einstellungen eine Möglichkeit zu ergänzen, welche dem Compiler die entsprechende Anweisung mitgibt?

Vielleicht fällt der Community eine alternative oder noch schönere Lösung ein, aber ich denke eine Checkbox oder ein Selectfeld in den Einstellungen gäbe hier die nötige Flexibilität, falls andere Tools zum Komprimieren/Parsen genutzt werden.

Viele Grüße aus Köln,
Sebastian

E: das Kommentar in der Core-Datei habe ich nur gesetzt, um die Datei und Stelle, schneller wiederfinden zu können

Hallo zusammen,

während der Testphase eines Projekts ist uns aufgefallen, dass das integrierte <we:form type="object"> nicht verschickt wird, sobald Schadcode wie z. B. "<?php … ?>" enthalten ist.
Jedoch ist im gleichen Zug aufgefallen, dass Inputs mit <script></script> Inhalten scheinbar ungefiltert bzw. nicht escaped in der Datenbank landen. So könnte auf den Trigger/Detailseiten bzw. auch auf listing-seiten, welche die Felder auslesen, vermeintlich fremde JavaScripte ausgeführt werden.

Versuche die Variablen vor dem Schreiben des Objekts über <we:setVar from="post" namefrom="xyz" to="post" nameto="xyz" prepareSQL="true"… /> oder php zu bereinigen waren bisher erfolglos.

Workaround kurzfristig wäre nun, dass Objekt ggf. über we:write zu erzeugen und anschließend über ein mysql update in der Tabelle die jeweilige Zeile mit den bereinigten Werten zu aktualisieren - aber das geht doch sicher schlanker und mit boardmitteln?

Da der we:write Befehl keinerlei Attribute zur Aufbereitung in der Tag-Referenz bereitstellt und direkt das Formular referenziert, einmal die Frage in die Runde: Gibt es hier ein best-practice wie die $_POST variablen vorm schreiben des Objektes bereinigt werden können?

Oder haben wir schlichtweg etwas übersehen?

Viele Grüße aus Köln,

Sebastian