[3.3] Recent Topics NG

[IMC]

Oder hab ich was nicht richtig verstanden oder irgendwas versemmelt? Es war ziemlich viel los in den letzten Monaten was Exts und Entwicklung anging.

Nee, alles gut und kein Stress. Ich muss mich im Sommer auch mehr um mein Alteisen kümmern.

[IMC]

@LukeWCS
Hallo Patrick,
ich hatte etwas Luft und habe ein paar Kleinigkeiten an RTNG geändert.
Ich habe zwei Events und eine Funktion entfernt:

• event paybas.recenttopics.topictitle_remove_re
• event paybas.recenttopics.modify_topictitle
• function topictitle_remove_re

Weiterhin habe ich zwei neue Templatevariablen eingeführt:

• FIRST_UNREAD_POST_SUBJECT
• U_FIRST_UNREAD_POST

Die Events sind aus meiner Sicht unnötiger Ballast. Wenn es gewünscht ist, können Modifikationen an der Ausgabe auch über das Event paybas.recenttopics.modify_tpl_ary durchgeführt werden.

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. Der Sprung zum ersten ungelesen Beitrag schon eher. Deshalb habe ich diese Variablen eingeführt. Ob, wie und wann diese zur Anzeige kommen kann im Template ausgewertet werden. Das 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.

Ob und wie wir diese Kombinationsmöglichkeiten mit Einstellmöglichkeiten den Nutzern zugänglich machen, können wir später diskutieren.

Bevor ich meine Änderungen in das Repository lade möchte ich mich erst mit dir abstimmen.

1. Damit ich mit meinen recht kleinen Änderungen nicht deine, vielleicht schon begonnen Änderungen "zerschieße".
2. 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 als pl19 hochladen.

Wenn es aus deiner Sicht auch Sinn macht, würde ich noch die ACP-Events aus der listener.php herauslösen und in eine acp_listener.php packen.

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.

Für größere Änderungen in RTNG hätte ich ab November wieder Zeit.

[LukeWCS]

Hi Thorsten

Weiterhin habe ich zwei neue Templatevariablen eingeführt:

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.

Die Events sind aus meiner Sicht unnötiger Ballast.

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.

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.

So ist es ja aktuell.

Der Sprung zum ersten ungelesen Beitrag schon eher.

Gute Idee und sehe ich auch so, das wäre viel sinnvoller als stumpf den letzten Beitrag anzusteuern.

Ob und wie wir diese Kombinationsmöglichkeiten mit Einstellmöglichkeiten den Nutzern zugänglich machen, können wir später diskutieren.

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.

Damit ich mit meinen recht kleinen Änderungen nicht deine, vielleicht schon begonnen Änderungen "zerschieße".

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.

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 als pl19 hochladen.

Passt. Wir behalten die Patchlevel Versionierung bei, bis RTNG wirklich isoliert läuft. Also Änderungen wie gehabt.

Wenn es aus deiner Sicht auch Sinn macht, würde ich noch die ACP-Events aus der listener.php herauslösen und in eine acp_listener.php packen.

Du meinst eine Separierung nach ACP- und Foren-Events? Jupp, finde ich gut, dann hat man das sauber getrennt.

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.

Ja, das ist erst dann möglich, wenn RTNG isoliert läuft.

Für größere Änderungen in RTNG hätte ich ab November wieder Zeit.

Da können wir ja dann nochmal plauschen.

[IMC]

Hi Patrick,

Machen wir dann aber mit unserem Präfix RTNG, um Kollisionsgefahr zu eliminieren.

Hatte ich noch nicht gemacht weil ich warten wollte bis wir alle Variablen umstellen.
Dann werde ich in diesem Patch schon einmal alle Templatevariablen (ausgenommen die im ACP & UCP) entsprechend anpassen. Die Anpassungen im ACP & UCP sollten gemacht werden wenn die Migration erneuert wird, und somit auch die Spaltennamen in den DB-Tabellen neu vergeben werden.

Dann lieber Template.

Das war auch mein Plan. Du hast schon sehr oft gezeigt dass man mit TWIG sehr viel bewegen kann.

Im Moment bin ich mit der neuen EMP Version beschäftigt.

Habe ich mir schon angeschaut und wieder etwas dazu gelernt. Nullable types, kannte ich noch nicht.

Du meinst eine Separierung nach ACP- und Foren-Events? Jupp, finde ich gut, dann hat man das sauber getrennt.

Ja, meinte ich.

Ich werde die Änderungen Ende nächster Woche hochladen. Heute fahre ich paar Tage mit meinem Zweirad weg.

[LukeWCS]

nAbend Thorsten

Das war auch mein Plan. Du hast schon sehr oft gezeigt dass man mit TWIG sehr viel bewegen kann.

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.

Nullable types, kannte ich noch nicht.

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.

Heute fahre ich paar Tage mit meinem Zweirad weg.

Viel Spass dir.

[IMC]

Hallo Patrick,
Folgende Änderungen habe ich durchgeführt und als PL19 in das neue Repositorie hochgeladen.

• Aufteilung der Datei listener.php in main_listen.php und acp_listener.php
• Template-Variablen FIRST_UNREAD_POST_SUBJECT und U_FIRST_UNREAD_POST hinzufügen
• Optimierung des Codes für die Unterstützung der Erweiterung \phpbb\collapsiblecategories
• Umbenennung von Template-Variablen in UCP und Core
• Umbenennung von Sprachvariablen außer Variablen im ACP
• Entfernung des Donate-Abschnitts aus dem ACP
• Entfernung von unbenutzten Template-Variablen in der Funktion display_recent_topics()
• Entfernung des Event paybas.recenttopics.topictitle_remove_re
• Entfernung des Event paybas.recenttopics.modify_topictitle
• Funktion topictitle_remove_re() entfernt
• Funktion is_listening() entfernt

Die Blockvariablen für das Template habe ich nicht umbenannt da diese durch den geänderten Schleifennamen einen eignen, neuen Namen haben.
An der Migration und den Variablen im ACP habe ich noch keine Änderungen vorgenommen. Da dies etwas aufwendiger ist, hätte ich dies zu heute nicht geschafft.

In der Datenbankabfrage für die neuen Template-Variablen FIRST_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.

Falls du nicht schon vorher Zeit finden solltest (ich befürchte eher nicht) kann ich mit der neuen Migration im November beginnen. In dieser müssen dann neue Spalten in den Tabellen für folgende Einstellungen vorgesehen werden.

• Auswahl für den Link des Thementitel. Sprung zum ersten oder letzten Betrag des Themas. ACP&UCP
• Auswahl ob bei ungelesenen Beiträgen in einem Thema über den Thementitel zum ersten ungelesenen Beitrag gesprungen werden soll, oder nicht. ACP&UCP
• Einstellmöglichkeiten für "Seperate Page". Anzahl der gezeigten Themen pro Seite und die Anzahl der Seiten. ACP&UCP
• Einstellmöglichkeiten für "Simple Page". Anzahl der gezeigten Themen pro Seite und die Anzahl der Seiten. ACP

Für die Einstellungen im UCP müssen dann auch die Berechtigungen mit gepflegt werden.

Mehr To-dos fallen mir im Moment nicht ein. Ist auch schon genug um uns über einen längeren Zeitraum zu beschäftigen.

[IMC]

Hi Patrick,

eine Sache ist mir noch aufgefallen die ich gerne ändern würde bevor die Migration angepasst wird. Es geht um die Werte, die für das Benutzerkonto eingestellt werden können. Diese sind redundant in dem CONFIG_TABLE und dem USERS_TABLE in der Gäste Zeile gespeichert.

Betroffen sind diese Einträge.

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'] 

Dies würde ich aus dem CONFIG_TABLE entfernen und nur noch im Gästekonto führen.

Auch glaube ich dass, das folgende Konstrukte für die Werte obsolet ist.

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'];
		}

Da die Benutzerdaten grundsätzlich mit den Defaultwerten belegt sind, wenn der Benutzer diese nicht ändern kann. sollte eine einfache Zuweisung reichen.

Code: Alles auswählen

$this->location = $this->user->data['user_rt_location'];

Es gibt Zehnarien die ein Abweichung der der Werte von den Defaultwerten ermöglichen. z.B. Der User hatte die Berechtigung die Werte zu ändern, und diese wurde im zu einen späteren Zeitpunkt wieder entzogen. Ich kann mir jedoch nicht vorstellen das ein Admin die Rechte ständig ändert. Wenn wir dies umgehen wollen können die Defaultwerte auch aus den Gästekonto ausgelesen werden.
In diesem Zusammenhang würde ich gerne deine Meinung dazu hören, wie wir in diesem Bereich vorgehen sollten. Ich bin da so bei 50/50.

Edit:
Zusätzlich könnten wir die Einstellungen noch in der Benutzerverwaltung zugänglich machen.
Benutzer-Verwaltung -> Einstellungen -> Anzeigeoptionen ändern

Nochmal Edit:
Den letzten Punk habe ich gestern bei einer meiner Extensions umgesetzt. Ist ein sehr geringer Aufwand und die Bedienung von phpBB wird dadurch durchgängiger.

Wenn du keine Gründe hast die dagegen sprechen würde ich demnächst folgende Änderungen durchführen.

• Die genannten Config Einträge entfernen.
• Für die Ansicht von RTNG ausschließlich die Einstellungen aus dem USERS_TABLE nutzen, unabhängig von den Berechtigungen. Ausgenommen die Berechtigung $this->auth->acl_get('u_rt_view').
• Die Einstellungen in dem UCP auch in der Benutzerverwaltung zugänglich machen.

Dann können die Benutzereinstellungen durch den Admin sowohl für einzelne Benutzer verändert werden und komplett für alle Nutzer. Damit sollten keine Wünsche offen bleiben.

[LukeWCS]

nAbend Thorsten

Dies würde ich aus dem CONFIG_TABLE entfernen und nur noch im Gästekonto führen.

Gute Idee, das heisst für neue Benutzer liest du dann den Guest Account aus.

Auch glaube ich dass, das folgende Konstrukte für die Werte obsolet ist.

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.

Ich kann mir jedoch nicht vorstellen das ein Admin die Rechte ständig ändert.

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. ^^

Zusätzlich könnten wir die Einstellungen noch in der Benutzerverwaltung zugänglich machen.
Benutzer-Verwaltung -> Einstellungen -> Anzeigeoptionen ändern

Hier kann ich dir grad nicht folgen. rt_location kann der User doch schon im UCP einstellen?

[IMC]

Hi Patrick,

das heisst für neue Benutzer liest du dann den Guest Account aus.

Ja.

weiter unten im Code wird diese Klassen-Eigenschaft als Basis für 3 Template Variable eingesetzt. Sicher dass das weg kann?

Das kommt nicht komplett weg sondern wird auf $this->location = $this->user->data['user_rt_location']; reduziert.
Ich schau mir das natürlich noch im Detail an, damit es an anderer Stelle nicht zu Problemen kommt. Grundsätzlich sollen die Einstellungen aus dem User-Account für die Anzeige von RTNG genutzt werden.

Hier kann ich dir grad nicht folgen. rt_location kann der User doch schon im UCP einstellen?

Hier geht es darum das alle Einstellungen des UCP auch in der Benutzerverwaltung des ACP für den Admin zugänglich sind.

[LukeWCS]

Ach jetzt, habs übersehen. Wäre prima, dann wäre auch RT rundum im ACP einstellbar. Auch praktisch im TB um zügig mehrere Test Accounts einstellen zu können, ohne umständlich mit jedem User einzuloggen und ins UCP zu wechseln.