[3.3] Recent Topics NG

[IMC]

PHP Max auf 8.4 setzen. Bereits getestet, wie erwartet keine Probleme mit RTNG.

Hi Patrick,
dass hatte ich auch nicht anders erwartet.

Deine Texte und die Umsetzung mit dem Link für die einfache Ansicht von RTNG gefallen mir sehr gut.

Der nächste der ein Update macht, ...

Im Moment habe ich nichts neues und werde mich erst mal auf das Testen beschränken. Nachdem du meine Tipp- und den Copy/Paste Fehler gefunden und beseitigt hast erwarte ich eine einwandfreie Funktion.

[LukeWCS]

Deine Texte und die Umsetzung mit dem Link für die einfache Ansicht von RTNG gefallen mir sehr gut.

Okay.

Im Moment habe ich nichts neues und werde mich erst mal auf das Testen beschränken. Nachdem du meine Tipp- und den Copy/Paste Fehler gefunden und beseitigt hast erwarte ich eine einwandfreie Funktion.

Alles klar, lassen wir a3 bisserl reifen, vielleicht findest auch noch was. Wenn ich EMP fertig habe, guck ich dann auch gezielt in den RTNG Code. Da war ich zwar auch schon, aber im Prinzip alles nur im Rahmen von Sprachdateien und Template.

[IMC]

... vielleicht findest auch noch was.

Hi Patrick,

eine Sache habe ich schon. Ich habe für dem Input der "Ausgeschlossene Themen" ein Pattern definiert. Die Überprüfung im PHP-Code wird auch mit einem regulären Ausdruck durchgeführt. Im Template lasse ich noch Leerzeichen zu, In der Config Tabelle wird der String ohne Leerzeichen gespeichert. Wird ein Leerer String vom Formular gesendet wird der Wert auf "0" gesetzt. Dies war vorher anders und hat mich gestört.

In den Systemanforderungen wird die PHP Mindestanforderung für phpBB 3.3.x mit v7.2.0 angegeben. Soll ich dies auch bei RTNG übernehmen.

[LukeWCS]

eine Sache habe ich schon. Ich habe für dem Input der "Ausgeschlossene Themen" ein Pattern definiert. Die Überprüfung im PHP-Code wird auch mit einem regulären Ausdruck durchgeführt. Im Template lasse ich noch Leerzeichen zu, In der Config Tabelle wird der String ohne Leerzeichen gespeichert.

Pattern, gute Idee!

Auf eine Daten-Validierung per PHP sollte man nicht verzichten, aber wenn schon von vorneherein verhindert wird, dass falsche Daten gesendet werden können, ist das auch für den Admin besser, weil er dann schon direkt beim Absenden auf Fehler hingewiesen wird. Wozu falsche Daten an den Server senden, wenn man das schon vorher prüfen und abfangen kann. Die Formularprüfung ist eine prima Ergänzung zur serverseitigen Daten-Validierung.

Okay, das heisst du lässt per Formularprüfung 0-9, Komma und Leerzeichen zu?

Wird ein Leerer String vom Formular gesendet wird der Wert auf "0" gesetzt. Dies war vorher anders und hat mich gestört.

Aber dass der String auf 0 gesetzt wird bei einem leeren String, das ist doch bei a3 schon so? Gleiches Spiel wenn man z.B. "test" eingibt.

In den Systemanforderungen wird die PHP Mindestanforderung für phpBB 3.3.x mit v7.2.0 angegeben. Soll ich dies auch bei RTNG übernehmen.

Nein, aus 2 Gründen:

1. Zum einen weil ich nichts von "künstlicher" Anhebung halte. Meine Exts z.B., weissen in der composer.json immer die korrekte Code-Basis aus, also die Mindest PHP Version. Somit weiss man sofort, das die Ext mit den Eigenschaften/Features von PHP x.y arbeitet. Wenn da also 7.4 als Minimum steht, muss man es nicht mit 7.3 oder weniger versuchen, weil das auf jeden Fall fehlschlagen wird. Was drauf steht, ist auch drin.
2. Die Mindest phpBB Version bei RTNG ist 3.3.5 und somit gilt auch die Mindest PHP Version 7.1. Mindestens PHP 7.2 gibt es erst seit phpBB 3.3.11. Etwas anderes wäre es, wenn wir 7.2 zwingend bräuchten, was aber nicht der Fall ist.

1 hat auch für Entwickler den Vorteil, das sie bei Exts die sie viel später mal wieder in die Finger nehmen, sofort wissen, welchen Stand/Generation die Code-Basis hat.

[IMC]

Okay, das heisst du lässt per Formularprüfung 0-9, Komma und Leerzeichen zu?

pattern="^\d+(\s?,\s?\d+)*$"

Aber dass der String auf 0 gesetzt wird bei einem leeren String, das ist doch bei a3 schon so? Gleiches Spiel wenn man z.B. "test" eingibt.

Tatsächlich hat RTNG dann gar nichts gemacht. Der alte Wert im Config Table wurde nicht überschrieben.

Mindestens PHP 7.2 gibt es erst seit phpBB 3.3.11.

Das ist so in der "Knowledge Base" nicht erkennbar. Dann werde ich den Wert nicht ändern.

[LukeWCS]

pattern="^\d+(\s?,\s?\d+)*$"

Das ist präzise. Ich würde aber explizit nur das Leerzeichen zulassen: ^\d+( ?, ?\d+)*$

Weil \s darf jedes Whitespace sein, also alle horizontalen und vertikalen Whitespaces. Bei den horizontalen z.B. auch TAB und bei den vertikalen auch LF und CR.

Tatsächlich hat RTNG dann gar nichts gemacht. Der alte Wert im Config Table wurde nicht überschrieben.

Ach daher sahs für mich so aus, als ob er 0 in die DB schreiben würde, weil das einfach schon in der DB ist und dann einfach nicht geändert wird.

Das ist so in der "Knowledge Base" nicht erkennbar. Dann werde ich den Wert nicht ändern.

Hmja, der KB Artikel ist da mehr Admin-relevant, aber die PHP Version hier ist mehr Ext-relevant. Wir haben den KB bewusst "einfacher" gestaltet und 7.2 als Minimum genommen, weil das dann für den ganzen 3.3 Branch passt.

[IMC]

Das ist präzise. Ich würde aber explizit nur das Leerzeichen zulassen: ^\d+( ?, ?\d+)*$

Übernehme ich. Dann reicht auch das str_replace() um die Leerzeichen zu entfernen. Spart Rechenzeit.

[IMC]

Hi Patrick,

in der Erklärung im ACP haben wir diesen Text stehen.

Benutzern erlauben, einige der Parameter für sich selbst zu verändern. Diese haben dann Vorrang vor den Einstellungen des Admin-Panels.

Dies war mal so, ist es zur Zeit nicht mehr. Im Moment werden immer die Einstellungen aus dem User-Table des Benutzers genommen. Unabhängig von den Rechten. Sollten wir wieder wollen das die Benutzer bei nicht vorhandenen Rechten die Standard Vorgaben bekommen müsste dies in der "Benutzer Verwaltung" kenntlich machen da diese Vorgaben dann dort ohne Wirkung sind.

Da der Admin jederzeit die Einstellungen im User-Table überschreiben kann, sollten wir es so belassen das die Einstellungen unabhängig von den Rechten vom User-Table genommen werden und nicht die Standardvorgaben bei nicht vorhandenen Rechten. Wobei diese in der Regel gleich sind. Wenn wir es so lassen wollen wie es jetzt ich müsste nur der letzte Satz gestrichen werden.



Wie wäre es, wenn wir in den ACP Einstellungen unter der Überschrift "Einstellungen, die im Benutzerkontrollzentrum geändert werden können" folgenden Text hinzufügen würden.

In diesem Bereich werden die Einstellungen für Gäste und neue Benutzer vorgenommen. Für bestehende Benutzer bleiben die Einstellungen unverändert. Um die Einstellungen für alle Benutzer zu übernehmen, aktiviere den Schalter "Benutzereinstellungen überschreiben".

Dies wäre zwar eine Dopplung von Informationen die man auch an anderer Stellen herauslesen kann. Aber eine eindeutige Erklärung für Admins die nicht an jeder Stelle lesen.

[IMC]

Dies war mal so, ist es zur Zeit nicht mehr. Im Moment werden immer die Einstellungen aus dem User-Table des Benutzers genommen. Unabhängig von den Rechten. Sollten wir wieder wollen das die Benutzer bei nicht vorhandenen Rechten die Standard Vorgaben bekommen müsste dies in der "Benutzer-Verwaltung" kenntlich machen da diese Vorgaben dann dort ohne Wirkung sind.

Ich habe vorsichtshalber nochmal nachgeschaut ob ich die Thema bereits angesprochen hatte. War mir da nicht mehr so sicher.
viewtopic.php?p=1428997#p1428997

[LukeWCS]

nAbend Thorsten

Hmm folgendes theoretisches Szenario: Admin gibt allen Usern alle Rechte, so das diese sich sämtliche Einstellungen anpassen können. Im Laufe mehrere Monate ändern sich x User ihre Einstellungen individuell ab. Nun entzieht der Admin - Grund egal - einige der Rechte und somit den Zugriff zu den entsprechenden Einstellungen.

Welche Einstellungen gelten nun für die User bei denjenigen Einstellungen, die sie selber nicht mehr ändern können? Haben dann alle den individuellen Stand den sie vor Entziehung der Rechte hatten, oder werden die nicht-erreichbaren Einstellungen alle auf einen einheitlichen Stand gebracht?