[3.3] [CDB]Recent Topics NG

[IMC]

Die haben zur Folge, das geänderte Einstellungen erst 1 Stunde später angezeigt werden.

Ist gefixed. (dev19)
Ebenfalls die Schriftgröße im Edge. (dev18)

Und meine Idee war es, hier mit {% block %} zu arbeiten, aber das funktioniert nicht, da gibts Fehlermeldungen.

Ging das nur in deinem speziellen Anwendungsfall nicht? Ich hatte das mal innerhalb einer Datei ausprobiert. Da war es kein Problem einen Block zu definieren und an anderer Stelle wieder zu verwenden.

Im schlimmsten Fall muss die seitliche Anzeige gehen.

Langsam habe ich auch diesen Gedanken.

Ich bin der Meinung, dass wir spätestens mit dem neuen phpBB-Style nur noch die dann standardisierten Anzeigetypen integrieren sollten.


Edit:
Mein GitDesktop hat eben eine komische Sache gemacht.
Merge branch 'dev' of https://github.com/IMC-GER/RecentTopicsNG into dev

[LukeWCS]

Ist gefixed. (dev19)

Ich hab gestern den Commit direkt gesichtet, als du die erste Variante von dev19 gepusht hast. Erst heute Morgen sah ich die zweite Variante. Wenn wir Code ändern, der effektiv das Verhalten ändert, dann müssen wir auch die Version erhöhen, damit man immer präzise die Version referenzieren kann. Sonst müssten wir anfangen mit der Commit ID zu hantieren und dann wirds umständlich und nicht-intuitiv.

Gestern war bei der Sichtung der Variante dev19a mein erster Impuls: "Äh nein, das können wir so nicht machen Thorsten, das haut uns der Validator sehr sicher um die Ohren!". ^^ Wegen eigener Daten-Aktualisierung den kompletten Cache mittels cache->purge löschen zu müssen, ist ein NoGo.

Die zweite Variante (dev19b) ist schon erheblich besser, aber ist sichergestellt, dass wir damit nicht andere Exts beeinträchtigen? Ansonsten wäre es doch besser, wenn wir für die besagten Daten gezielt einen spezifischen (klar benannten) RTNG Cache definieren, denn dann besteht auch keine Kollisionsgefahr mit anderen Exts oder phpBB selber.

Bei WWH wird auch der Cache benutzt, aber das wurde von meinem Vorgänger Anvar eingebaut und ich selber habe mich noch nicht direkt mit Cache Handling in Exts beschäftigt. Ich habe da lediglich später ebenfalls cache->destroy eingebaut, weil ich nach dem Löschen eines Users auch den Cache von WWH löschen wollte, damit die Anzeige auch bei aktiviertem Cache sofort aktualisiert wird und der gelöschte User nicht weiter in der Anzeige herumgeistert, bis der eingestellte Zeitraum überschritten wurde. Mit der Funktion kann man präzise (Skalpell) das löschen, was gelöscht werden muss, ohne "Kollateralschäden" (Holzhammer) zu verursachen.

Ich hatte das mal innerhalb einer Datei ausprobiert. Da war es kein Problem einen Block zu definieren und an anderer Stelle wieder zu verwenden.

Das war tatsächlich in meinem speziellen Fall. Ich wollte das Template-übergreifend versuchen, was bei Twig definitiv so vorgesehen ist, aber wohl bei phpBB nicht funktioniert. Aber das war sowieso ein Irrweg, weil ich die Natur der seitlichen Ansicht vergessen habe. Oder sagen wir besser: erfolgreich verdrängt. Mit block kann man das nicht lösen, da bin ich mental völlig falsch abgebogen.

Mein GitDesktop hat eben eine komische Sache gemacht.
Merge branch 'dev' of https://github.com/IMC-GER/RecentTopicsNG into dev

Hab ich so auch noch nicht gesehen. Okay, ich würde in dem Fall hergehen und ein Reset auf dev18 durchführen. Dann kannst du nochmal in sauber dein finales dev19 pushen und dann ist auch das Repo wieder okay. Aber bevor ich das mache, würde ich jetzt erstmal Crizzo fragen, ob er das kennt. Also erstmal nichts mehr am Repo ändern, damit er das sichten kann.

@Crizzo

https://github.com/IMC-GER/RecentTopicsNG/commits/dev/

[Crizzo]

Ich kann mich auch irren. Aber das sieht mir doch nach einem Merge aus, der den localen Branch/Workspace via Online-Repo (Upstream) aktualisiert hat. Da der commit aber quasi leer ist, ist vielleicht durch ein unsauberes Arbeiten, force-push oder andere Änderung in der Historie zu einem Konflikt gekommen, der so gelöst wurde?

Aber so wirklich sagt mir das jetzt erstmal nichts.

[LukeWCS]

Okay, dann haken wir das mal als X-Akte ab. Keine Ahnung was GHD da gemacht hat, war dann wohl eine automatische Korrektur.

Merci Chris

@Thorsten

Repo ist jetzt auf dev18 zurückgesetzt.

[IMC]

Die zweite Variante (dev19b) ist schon erheblich besser, aber ist sichergestellt, dass wir damit nicht andere Exts beeinträchtigen?

Das sollte keine Probleme geben. Wird im ACP öfter gemacht.

Ansonsten wäre es doch besser, wenn wir für die besagten Daten gezielt einen spezifischen (klar benannten) RTNG Cache definieren, denn dann besteht auch keine Kollisionsgefahr mit anderen Exts oder phpBB selber.

Schau ich mir mal an. Die Klasse ist für mich Neuland.

Mein GitDesktop hat eben eine komische Sache gemacht.

Schon wieder. Statt den Branche im GitDesktop zurückzusetzen hatt er die alten Sachen wieder hochgeladen.

ist vielleicht durch ein unsauberes Arbeiten,

Das wäre eine plausible Erklärung. Ich bin wir nicht sicher ob sich der Zeitstempel von einer Datei geändert hat.

[LukeWCS]

Das sollte keine Probleme geben. Wird im ACP öfter gemacht.

Alles klar.

Schau ich mir mal an. Die Klasse ist für mich Neuland.

Für mich, wie erwähnt, auch. Die kann mal für uns beide relevant werden, weil ich mir seit dem Beitrag von halil16 Gedanken gemacht habe, wie wir gezielt Cache nutzen könnten, um nicht nur die Daten vom Gast zu cachen, sondern vor allem das, was wirklich Leistung zieht: die SQL Abfragen. Habe ich aber noch nicht vollständig durchdacht, daher habe ich es auch hier noch nicht erwähnt.

Statt den Branche im GitDesktop zurückzusetzen hatt er die alten Sachen wieder hochgeladen.

Kein Problem, das hatten wir schon mal. Du wirst vergessen haben, nach meinem Reset deinen lokalen dev Branch zu "bereinigen".

Habe eben erneut Reset im online Repo gemacht und deine Situation bei mir in GHD simuliert und die Lösung selber durchgespielt:

1. GHD starten und auf das RTNG Repo wechseln.
2. Linksklick auf das Pulldown "Current Branch".
3. Rechtsklick auf "dev" und "Delete" klicken, dann kommt Rückfrage. Wenn erledigt, schaltet GHD automatisch auf "master" um.
4. Unten im Pulldown siehst jetzt "origin/dev", da Linksklick drauf.
5. Jetzt schaltet er direkt auf "origin/dev" um, ändert das aber sofort auf "dev" und nimmt dabei den Stand vom Online Repo.

[nx650]

Mir ist in meinem Forum aufgefallen, dass in der Übersicht der Aktuellen Themen fälschlicherweise der Namen des Thread-Erstellers gegen den ersetzt wird, der den letzten Beitrag geschrieben hat.

Das ist kein Fehler, sondern eine Eigenschaft die bei RTNG bewusst eingebaut wurde. Das was du beschreibst, wird direkt von folgendem Schalter im ACP beeinflusst:

"Link des Thementitels:"

Davon wird auch der Autor unterhalb des Titels beeinfusst. Und deine Benutzer können das ebenfalls im UCP frei einstellen, sofern du ihnen das Recht dazu gegeben hast:

"Kann den letzten Post als Anzeige im Thementitel wählen."

Wenn du das für Gäste nicht willst, musst du den Schalter im ACP entsprechend ändern.

Danke für die Info.
Ich habe tatsächlich unterschiedliche globale und persönliche Einstellungen was diesen Punkt betrifft. Deshalb hat es wohl nur die Gasteinstellung betroffen. Und ja, die User dürfen sich das selber einstellen.
Trotzdem finde ich die Formulierung dieser Einstellung etwas unglücklich:
"Mit dieser Option kannst du festlegen, ob ein Klick auf den Thementitel zum ersten oder letzten Beitrag des Themas führen soll. Außerdem wird der entsprechende Beitragstitel als Thementitel verwendet."

Dass damit nämlich auch der Verfasser des Threads (also derjenige, der den allerersten Beitrags verfasst hat bzw. das Thema gestartet hat) anders angezeigt wird, wird nicht erwähnt. Und ich empfinde das immer noch als nicht korrekt.
Rein logisch gefällt mir die Einstellung "zum letzten Beitrag" besser. Denn dadurch lande ich direkt beim letzten von mir noch nicht gelesenen Beitrags eines Threads. Aber dann habe ich das oben beschriebene "Problem".

Edit:
Ok, jetzt habe ich es begriffen.
Wenn ich die Einstellung auf "zum ersten Beitrag" einstelle, muss ich, um auf den tatsächlich letzten ungelesenen Beitrag zu kommen, auf das Themensymbol links vom Thementitel klicken. Dann lande ich tatsächlich beim letzten ungelesenen Beitrag. Ein Klick auf den Titel führt mich zum ersten Beitrag des Themas.
Uff! Jetzt betreibe ich mein Forum schon so lange, und habe an dieser Stelle nie einen besonderen Unterschied festgestellt.
Wieder was gelernt.

[IMC]

nicht nur die Daten vom Gast zu cachen, sondern vor allem das, was wirklich Leistung zieht: die SQL Abfragen.

Da hatte ich mir schon gedanken gemacht. Die meisten Anfragen sind sehr spezifisch. Sie berücksichtigen die Einstellungen für die unterschiedlichen User und deren Berechtigungen. phpBB selbst cached auch nur die sql-querys die voraussichtlich immer die selben Ergebnisse liefern.
Solche eine habe ich in der Methode getforumlist() gefunden. Es geht um die Abfrage von forum_rtng_disp = 1. Da musste ich etwas in der Reihenfolge ändern. Zuerst die Anfrage die, die Foren zur Anzeige in RTNG ermittelt (im cache). Dann die Foren ermittelt die der User sehen darf. Die beiden Arrays miteinander abgleichen und ein Array mit den anzuzeigenden Foren zurückgeben. Es war kein Geschwindigkeitsvorteil festzustellen.

Wenn wir die Methode so belassen wie sie ist wird für jede Konstellation von auth->acl_getf('f_read') ein Eintrag im Cache gemacht.
Cache Variable ist "sql_(md5 des bereinigten Query-Strings)". Wieviele Konstellationen könnte es geben?
Der Cache-Speicher könnte ziemlich groß werden. Die Abfrage ist bei mir eine mit einer kürzeren Zeitspanne.

Die anderen querys lesen den Topics und Posts Table aus. Diese ändern sich fortlaufend.

Kein Problem, das hatten wir schon mal. Du wirst vergessen haben, nach meinem Reset deinen lokalen dev Branch zu "bereinigen".

Mit deiner Anleitung hat es mal wieder bestens geklappt.

Ich habe die Klasse Cache mal überflogen. Bei dem Aufruf von cache->destroy('sql', USERS_TABLE) werden alle sql-ids im cache durchsucht. Diejenigen die den USERS_TABLE in ihrer Abfrage haben werden gelöscht. Was auch Sinn macht da wir den USERS_TABLE geändert haben. Somit ist sichergestellt das alle, aktuelle Daten einlesen.

Edit:
dev19 ist online.

[LukeWCS]

Dass damit nämlich auch der Verfasser des Threads (also derjenige, der den allerersten Beitrags verfasst hat bzw. das Thema gestartet hat) anders angezeigt wird, wird nicht erwähnt.

Da gebe ich dir Recht, das ist eine Info die fehlt. Denn das ist wirklich nicht intuitiv zu verstehen, dass das auch auf den Autor-Namen wirkt. Werden wir noch hinzufügen.

Wenn ich die Einstellung auf "zum ersten Beitrag" einstelle, muss ich, um auf den tatsächlich letzten ungelesenen Beitrag zu kommen, auf das Themensymbol links vom Thementitel klicken. Dann lande ich tatsächlich beim letzten ungelesenen Beitrag. Ein Klick auf den Titel führt mich zum ersten Beitrag des Themas.

Ach das war das Problem: Themensymbol links vom Thementitel

So ist es. Wenn du das so einstellst, dann verhält sich RTNG wie RT und auch wie phpBB. Das mit "Letzter Beitrag" ist eine zusätzliche Funktion, die wir bei RTNG eingebaut haben. Siehe auch:

viewtopic.php?p=1429232#p1429232

Uff! Jetzt betreibe ich mein Forum schon so lange, und habe an dieser Stelle nie einen besonderen Unterschied festgestellt.
Wieder was gelernt.

Mach dir keinen Kopf, auch Veteranen entdecken immer wieder mal Features die sie noch gar nicht kannten. Zum Beispiel der Pfeil bei den Zitaten, der jetzt endlich deutlich grösser ist, weil den früher viele übersehen haben. Oder der Pfeil bei der Rechtverfolgung. Oder eben das Symbol vor dem Thementitel. phpBB hat so einige versteckte Ostereier: "Ach, das neckische kleine Symbol da, macht noch mehr, als nur hübsch auszusehen?". ^^

@Thorsten

Okay, da du dich auch schon damit befasst hast, dann auch mal meine "unfertigen" Gedanken dazu:

Die meisten Anfragen sind sehr spezifisch.

Jupp, das war das erste Problem was mir in die Quere kam, deswegen kann man Caching solcher spezifischer Abfragen vergessen, weil das je nach Forum ruckzuck den Cache massiv anwachsen lässt und das im Prinzip unkontrollierbar. Das habe ich schnell wieder verworfen. Auch andere Modelle hatten Macken.

Mein letzter Stand ist der, das wir nicht die Abfragen an sich cachen, sondern die effektiven Daten. Also das wir quasi ein Fester der jeweiligen Tabellen im Cache speichern. Dann könnte man die bisherigen Abfragen auch quasi 1:1 auf den Cache "umbiegen". Denn ich gehe davon aus, dass vor allem die SQL Abfragen auf die Daten soviel Leistung frisst, was beim Zugriff auf den Cache erheblich schneller sein dürfte. Dann vergleicht man z.B. bei den Posts einfach die letzte Post ID mit der letzten ID im Cache. Ist die ID in der DB höher als im Cache, muss der Cache aktualisiert werden. Gleiches bei den anderen Tabellen. Das Fenster kann man auch präzise begrenzen, anhand der maximalen Seiten der Pagination und den Themen pro Seite.

Aber auch diese Idee ist nicht wirklich ausgereift, denn man müsste auch berücksichtigen, das aufgrund Gruppenrechte und anderer Bedingungen bestimmte Beiträge gar nicht verwendet werden dürfen. Wenn unser Fenster als Beispiel 50 Themen berücksichtigt, also 5 Seiten mit je 10 Themen, dann kann es sein, das ein User gar nicht auf die 5 Seiten kommt, sondern vielleicht nur auf 4 oder sogar nur 1.

Mehr habe ich da aktuell nicht, alles noch sehr unausgereift.