[3.3] Recent Topics NG

[IMC]

Meine Tendenz wäre Cast (oder Type Juggling wie das bei PHP heisst), denn das wäre dann einheitlich auf alle Typen anwendbar.

Dann lass uns das so machen. Ist auch konform zur php Sprachreferenz und habe ich auch schon mehrfach eingesetzt.

https://github.com/IMC-GER/phpBB-Extern ... #L561-L585

Das ändert dann derjenige von uns, der den nächsten Commit ausführt.

[LukeWCS]

Das ändert dann derjenige von uns, der den nächsten Commit ausführt.

Roger

[LukeWCS]

Thorsten, wenn 1.0.1 validiert wurde und die angepasste Ext von MattF auch verfügbar ist, könnten wir evtl. im Startbeitrag eine Liste der Exts mit RTNG Schnittstellen/Anpassungen einfügen. Sowas habe ich als Beispiel bei WWH auch.

[IMC]

Gute Idee. Werde ich dann umsetzen.

[IMC]

Das ändert dann derjenige von uns, der den nächsten Commit ausführt.

Werde ich wohl heute Abend machen.

Getriggert durch einen anderen Post habe ich eine meiner Entscheidungen geändert. Diese hatte ich ursprünglich getroffen um die Anzahl der Datenbankabfragen niedrig zu halten.

Zu Zeit fülle ich die Template Variable mit den first unread Post Daten nur wenn diese Option zur Anzeige ausgewählt ist. Für einige Optionen/Veränderungen im Template ist es sinnvoll diese im Event jederzeit auswerten zu können. Deshalb werde ich diese Daten auch zur Verfügung stellen wenn "Link des Thementitels zu ungelesenen Beiträgen" nicht ausgewählt ist. Außerdem habe ich noch einige mittlerweile überflüssige ternäre Operatoren entdeckt.

[LukeWCS]

Wenn die zusätzlichen Daten ohnehin schon zur Verfügung stehen sollten, ohne das extra Querys nötig sind, dann kann man das auch jederzeit so machen und Event Daten Pakete oder Template Variablen umfangreicher bestücken. Denn z.B. RAM zu schonen ist zwar immer gut, aber phpBB benötigt so wenig, dass man sich da jetzt keinen Kopf machen muss, wenn man da paar KB mehr reinpackt.

Anders sieht es aus, wenn zusätzliche und evtl. belastende Querys nötig werden. Dann kann es sinnvoll sein, solche Dinge schaltbar zu machen. Sowas habe ich bei WWH unter der Rubrik "Serverlast". Da kann ein Admin notfalls quasi die Handbremse ziehen, wenn sein Forum eh schon am Limit läuft. Dadurch wird der Komfort zwar eingeschränkt, gleichzeitig aber auch die Last verringert. Aber das betrifft die meisten üblichen Foren eher weniger, sondern gilt vor allem für richtig grossen Foren, wo konstant hunderte bis tausende User gleichzeitig unterwegs sind. Und selbst da hängt es ja auch wieder davon ab, wie potent der Webserver ist und mit wievielen anderen Betreibern man sich den Server teilen muss.

[IMC]

Moin Patrick,
die Änderung ist Online.

Anders sieht es aus, wenn zusätzliche und evtl. belastende Querys nötig werden. Dann kann es sinnvoll sein, solche Dinge schaltbar zu machen.

Die Belastung durch zusätzliche Querys ist übersichtlich. Mein Testforum benötigt für die zusäzliche DB-Abfrage, pro ungelesen Post in der RTNG Anzeige 1/100 Sek.

Mein Ziel ist schon seit längerer Zeit diese Abfrage in get_topics_sql() zu integrieren. Dafür benötige ich etwas Zeit, um mich detailliert in das Thema hineinzudenken. Die ich im Moment nicht über habe. Ich gehe aber davon aus dass, das Release nicht vor Januar 2026 erscheint. Bist dahin weiß ich ob es für mich machbar ist.

[LukeWCS]

Moin Thorsten

die Änderung ist Online.

Bei deiner Änderung auf NCO bin ich kurz ins Grübeln gekommen, weil sich ein !empty() nicht zwangsläufig in einen NCO wandeln lässt. Hat einen Moment gedauert, bis ich das verarbeitet hatte. Als Beispiel eine der geänderten Zeilen:

Code: Alles auswählen

'FIRST_UNREAD_POST_AUTHOR'			=> !empty($first_unread_post_author) ? $first_unread_post_author : '',

Code: Alles auswählen

'FIRST_UNREAD_POST_AUTHOR'			=> $first_unread_post_author ?? '',

Denn abseits der Gemeinsamkeit (Var muss vorhanden sein) ist die Abfrage auf leerer String und null ja nicht das gleiche. Ist hier die Variable $first_unread_post_author leer, wird bei der !empty() Variante der false-part ausgeführt und ein leerer String an die Template Variable zugewiesen. Beim NCO wird in diesem Fall jedoch der true-part ausgeführt und die abgefragte Variable (die einen leeren String enthält) selbst an die Template Variable zugewiesen, wodurch unterm Strich das gleiche erzielt wird.

Verflixte Details. ^^ Und guter Fund.

[IMC]

... diese Abfrage in get_topics_sql() zu integrieren.

Eigentlich wollte ich es nicht. Aber der neu getriggerte Ehrgeiz und das gestrige Wetter, Sturm und Dauerregen, haben mich veranlasst das Thema neu anzugehen.

Ich musste leider feststellen das es nicht geht. Mit meiner geänderten Datenbankabfrage wurden alle ungelesenen Beträge gefunden, nicht nur der erste. Hat ein Topic 5 Beiträge und 3 davon waren ungelesen wurden diese ausgegeben. Leider ist es in phpBB nicht möglich in einer LEFT JOIN Abfrage nur den ersten Fund auszugeben.

Das Gute war, dass ich meine vorhandene Abfrage noch weiter optimieren konnte. Dadurch kann ich vermutlich andere Codestellen kürzen. Dafür sind aber noch ein paar Tests erforderlich. Im speziellen muss ich noch testen wie sich alles verhält wenn unter Serverlast "Serverseitige Gelesen-Markierung aktivieren" deaktivert wird. Davon ist abhänig wieviel Code entfernt werden kann. Im Idealfall alles was mit $topic_tracking_info[] zu tun hat. Dann bräuchten wir nur noch das Tracking mit dem Cookie berücksichtigen.

Mit dem Testen werde ich mir etwas Zeit lassen und dies über ein paar Tage verteilen.