phpBB.de - Die deutsche phpBB-Community
https://www.phpbb.de/community/
Nee, alles gut und kein Stress. Ich muss mich im Sommer auch mehr um mein Alteisen kümmern.LukeWCS hat geschrieben: 19.06.2024 22:41 Oder hab ich was nicht richtig verstanden oder irgendwas versemmelt? Es war ziemlich viel los in den letzten Monaten was Exts und Entwicklung anging.
paybas.recenttopics.topictitle_remove_repaybas.recenttopics.modify_topictitletopictitle_remove_reFIRST_UNREAD_POST_SUBJECTU_FIRST_UNREAD_POSTpaybas.recenttopics.modify_tpl_ary durchgeführt werden.Re: im Titel habe ich bewusst nicht entfernt. Es soll erkennbar sein das der Link zu einer Antwort führt. Das gleiche gilt auch für die Variable LAST_POST_SUBJECT.pl19 hochladen.listener.php herauslösen und in eine acp_listener.php packen.Machen wir dann aber mit unserem Präfix
RTNG, um Kollisionsgefahr zu eliminieren. Speziell U_FIRST_UNREAD_POST ist schon sehr allgemein. Damit das dann nicht zu lang wird, könnte man kürzen: RTNG_FIRST_UNREAD_SUBJECT und U_RTNG_FIRST_UNREAD. Aber primär wäre wichtig, dass das einheitliche Präfix vorhanden ist.Okay, insgesamt hast du bei RT den besseren Überblick. Wenn du meinst das kann raus, dann wech damit. Vor allem alte Events die für Erweiterungen eingebaut wurden, die inzwischen kaum jemand mehr nutzt und/oder veraltet sind und nicht mehr aus dem Stand laufen, brauchen wir auch nicht weiterhin in RTNG zu unterstützen. Lieber bauen wir neue Events aufgrund realem aktuellen Bedarf ein, dann hat man auch einen besseren Überblick was von welcher Ext aktuell wirklich benutzt wird.Die Events sind aus meiner Sicht unnötiger Ballast.
So ist es ja aktuell.Ich habe oft den Wunsch gelesen, dass der letzte Beitrag in RT verlinkt werden soll. Der Sprung zum letzten Beitrag macht für mich nicht in jedem Fall Sinn.
Gute Idee und sehe ich auch so, das wäre viel sinnvoller als stumpf den letzten Beitrag anzusteuern.Der Sprung zum ersten ungelesen Beitrag schon eher.
Solange wir noch die alte Struktur haben, haben wir da nur die Möglichkeit per Template Eingriff. Alternativ wäre ein Eingriff in eine PHP Datei, aber das finde ich nicht prickelnd. Dann lieber Template. Sobald wir RTNG mit eigener Struktur haben, müssen wir uns mit solchen Hindernissen wie fehlende Konfigurierbarkeit nicht mehr befassen. Dann können wir simpel eine neue ACP Option einbauen und gut ist.Ob und wie wir diese Kombinationsmöglichkeiten mit Einstellmöglichkeiten den Nutzern zugänglich machen, können wir später diskutieren.
Bin in den letzten Monaten viel mit anderen Exts und Tools beschäftigt gewesen, von daher habe ich aktuell nichts neues. Ich habe also den Stand von pl18. Im Moment bin ich mit der neuen EMP Version beschäftigt.Damit ich mit meinen recht kleinen Änderungen nicht deine, vielleicht schon begonnen Änderungen "zerschieße".
Passt. Wir behalten die Patchlevel Versionierung bei, bis RTNG wirklich isoliert läuft. Also Änderungen wie gehabt.Ich mir nicht im klaren bin mit welcher Versionsnummer wir weiter machen. Ich vermute dass du diesbezüglich schon eine klare Vorstellungen hast. Ansonsten würde ich es alspl19hochladen.
Du meinst eine Separierung nach ACP- und Foren-Events? Jupp, finde ich gut, dann hat man das sauber getrennt.Wenn es aus deiner Sicht auch Sinn macht, würde ich noch die ACP-Events aus derlistener.phpherauslösen und in eineacp_listener.phppacken.
Ja, das ist erst dann möglich, wenn RTNG isoliert läuft.Für weitere Ergänzungen in RTNG müsste die Migration geändert werden. Das sollten wir aber erst machen wenn die Variablen überarbeitet worden sind.
Da können wir ja dann nochmal plauschen.Für größere Änderungen in RTNG hätte ich ab November wieder Zeit.
Hatte ich noch nicht gemacht weil ich warten wollte bis wir alle Variablen umstellen.LukeWCS hat geschrieben: 18.09.2024 23:53 Machen wir dann aber mit unserem PräfixRTNG, um Kollisionsgefahr zu eliminieren.
Das war auch mein Plan. Du hast schon sehr oft gezeigt dass man mit TWIG sehr viel bewegen kann.
Habe ich mir schon angeschaut und wieder etwas dazu gelernt.
Nullable types, kannte ich noch nicht.Ja, meinte ich.LukeWCS hat geschrieben: 18.09.2024 23:53Du meinst eine Separierung nach ACP- und Foren-Events? Jupp, finde ich gut, dann hat man das sauber getrennt.
Twig ist das perfekte Bindeglied zwischen PHP und Template. Vieles was man früher nur in PHP lösen konnte, geht mit Twig auch direkt im Template. Was mir auch sehr gut gefällt; das man Datenstrukturen 1:1 von PHP an Twig übergeben kann, z.B. assoziative Arrays. Dass das geht wundert aber nicht wirklich, wenn man weiss was mit dem Twig Code schlussendlich passiert.IMC hat geschrieben: 20.09.2024 00:08 Das war auch mein Plan. Du hast schon sehr oft gezeigt dass man mit TWIG sehr viel bewegen kann.
Kenne und nutze ich auch erst seit kurzem. Bei EMP nutze ich es seit 2.0.1, bei FileCheck seit 1.4.1. Ist eine Möglichkeit auch unter PHP 7 mit strikter Typisierung arbeiten zu können, ohne dabei auf Flexibilität komplett verzichten zu müssen. Union Types gibts ja erst ab 8 und das fällt für FileCheck "noch" weg.Nullable types, kannte ich noch nicht.
Viel Spass dir.Heute fahre ich paar Tage mit meinem Zweirad weg.
FIRST_UNREAD_POST_SUBJECT und U_FIRST_UNREAD_POST hinzufügen\phpbb\collapsiblecategoriesdisplay_recent_topics()paybas.recenttopics.topictitle_remove_repaybas.recenttopics.modify_topictitletopictitle_remove_re() entferntis_listening() entferntFIRST_UNREAD_POST_SUBJECT und U_FIRST_UNREAD_POST habe ich die SQL-Funktion COALESCE() verwendet. Meine Recherchiere hat ergeben das diese von allen Datenbanken, die für phpBB verwendet werden können, unterstützt wird.CONFIG_TABLE und dem USERS_TABLE in der Gäste Zeile gespeichert.Code: Alles auswählen
$this->config['rt_index']
$this->config['rt_sort_start_time']
$this->config['rt_unread_only']
$this->config['rt_location']
$this->config['rt_number']
CONFIG_TABLE entfernen und nur noch im Gästekonto führen.Code: Alles auswählen
//rt block location
$this->location = $this->config['rt_location'];
// if user can set location and it is set then use the preference
if ($this->auth->acl_get('u_rt_location'))
{
$this->location = $this->user->data['user_rt_location'];
}
Code: Alles auswählen
$this->location = $this->user->data['user_rt_location'];Benutzer-Verwaltung -> Einstellungen -> Anzeigeoptionen ändernUSERS_TABLE nutzen, unabhängig von den Berechtigungen. Ausgenommen die Berechtigung $this->auth->acl_get('u_rt_view').Gute Idee, das heisst für neue Benutzer liest du dann den Guest Account aus.IMC hat geschrieben: 17.10.2024 23:43 Dies würde ich aus demCONFIG_TABLEentfernen und nur noch im Gästekonto führen.
Hmm weiter unten im Code wird diese Klassen-Eigenschaft als Basis für 3 Template Variable eingesetzt. Sicher dass das weg kann? Habs jetzt aber auch nicht genau verfolgt.Auch glaube ich dass, das folgende Konstrukte für die Werte obsolet ist.
Ich auch nicht. Maximal beim ersten Einrichten und Testen nutzt man zig Optionen, aber dann ist man als Admin eigentlich froh, wenn das Ding macht was es soll und man fasst es nicht/nie mehr an. ^^Ich kann mir jedoch nicht vorstellen das ein Admin die Rechte ständig ändert.
Hier kann ich dir grad nicht folgen.Zusätzlich könnten wir die Einstellungen noch in der Benutzerverwaltung zugänglich machen.
Benutzer-Verwaltung -> Einstellungen -> Anzeigeoptionen ändern
rt_location kann der User doch schon im UCP einstellen?Ja.LukeWCS hat geschrieben: 19.10.2024 21:14das heisst für neue Benutzer liest du dann den Guest Account aus.
Das kommt nicht komplett weg sondern wird aufLukeWCS hat geschrieben: 19.10.2024 21:14weiter unten im Code wird diese Klassen-Eigenschaft als Basis für 3 Template Variable eingesetzt. Sicher dass das weg kann?
$this->location = $this->user->data['user_rt_location']; reduziert.Hier geht es darum das alle Einstellungen des UCP auch in der Benutzerverwaltung des ACP für den Admin zugänglich sind.LukeWCS hat geschrieben: 19.10.2024 21:14Hier kann ich dir grad nicht folgen.rt_locationkann der User doch schon im UCP einstellen?
