nAbend
Mit Verspätung, sorry, der Tag hat zuwenig Stunden. Ich schlage vor, wir ziehen um auf einen Planeten mit einer 30-Stunden-Rotation.
Habe mir - aber nur grob - pl19 bis pl21 angeschaut. Das man die UCP Einstellungen eines Users auch direkt im ACP ändern kann, ist ne prima Sache.
Hast auch Code Pflege betrieben, z.B. pl19:
Code: Alles auswählen
//alt
if ($this->collapsable_categories !== null)
//neu
if (isset($this->collapsable_categories))
Minimal kompakter, aber vor allem robuster.
pl20:
Code: Alles auswählen
{{ rtng.S_DISP_FIRST_UNREAD_POST ? rtng.FIRST_UNREAD_POST_TIME : (rtng.S_DISP_LAST_POST ? rtng.LAST_POST_TIME : rtng.FIRST_POST_TIME) }}
Du hast zwar den verschachtelten Ternary korrekt notiert und ist somit auch PHP 8 tauglich, aber das sollte man trotzdem besser vermeiden, weil a) schwerer zu lesen und b) fehlerträchtig. Aus Rücksicht auf gute Wartbarkeit sollte man hier lieber ein klassisches
if/else/endif Konstrukt nutzen, z.B. (ungetestet):
Code: Alles auswählen
{% if rtng.S_DISP_FIRST_UNREAD_POST %}
{{ rtng.FIRST_UNREAD_POST_TIME }}
{% else %}
{{ rtng.S_DISP_LAST_POST ? rtng.LAST_POST_TIME : rtng.FIRST_POST_TIME }}
{% endif %}
Bei Ternary ist das Highlander-Prinzip besser: "Es kann nur einen geben." Prima bei simplen Sachen wo
if/else/endif viel zu sperrig wäre, aber schlecht bei verschachtelten Bedingungsblöcken.
Bei pl21 fiel mir auf, dass du die extrem aufgeblähten DocBlocks (
/** @var) der Klassen-Eigenschaften kräftig gekürzt notiert hast. So sind mal eben 66 Zeilen in
recenttopics.php entfallen. Ich möchte aber vorschlagen, das global zu entfernen. Ich hab das anfangs auch immer übernommen, als ich noch nicht wusste, wozu das dient. Als ich es dann wusste, hab ich es entfernt, dass war bei WWH 2.0. Und bei späteren Projekten gar nicht erst eingefügt.
Weder du noch ich nutzen eine PHP IDE, darum sind diese Blöcke für uns nur Ballast und blähen unnötig den Code auf. Ausserdem müssten wir das dann bei jeder Änderung manuell aktualisieren und das ist ebenfalls unnötige Arbeit, die ich ehrlich gesagt nicht einsehe. Und ein falscher DocBlock ist prinzipiell schlechter als ein nicht-vorhandener. ^^
Auch der Konstruktor DocBlock ist eigentlich überflüssig, weil du bei pl19 den Parameter
$collapsable_categories explizit als nullable deklariert hast. Somit erklärt sich der Konstruktor komplett von alleine und im DocBlock steht nichts zusätzliches, das ist einfach nur redundant und damit unnötig:
Code: Alles auswählen
/**
* recenttopics constructor.
*
* @param \phpbb\auth\auth $auth
* @param \phpbb\cache\service $cache
* @param \phpbb\config\config $config
* @param \phpbb\language\language $language
* @param \phpbb\content_visibility $content_visibility
* @param \phpbb\db\driver\driver_interface $db
* @param \phpbb\event\dispatcher_interface $dispatcher
* @param \phpbb\pagination $pagination
* @param \phpbb\request\request_interface $request
* @param \phpbb\template\template $template
* @param \phpbb\user $user
* @param $root_path
* @param $phpEx
* @param \phpbb\collapsiblecategories\operator\operator|NULL $collapsable_categories
*/
public function __construct
(
\phpbb\auth\auth $auth,
\phpbb\cache\service $cache,
\phpbb\config\config $config,
\phpbb\language\language $language,
\phpbb\content_visibility $content_visibility,
\phpbb\db\driver\driver_interface $db,
\phpbb\event\dispatcher_interface $dispatcher,
\phpbb\pagination $pagination,
\phpbb\request\request_interface $request,
\phpbb\template\template $template,
\phpbb\user $user,
$root_path,
$phpEx,
?\phpbb\collapsiblecategories\operator\operator $collapsable_categories = null
)
Was meinst du zu den DocBlöcken?
Bei pl21 stimmt noch was nicht, mit keinem User bekomme ich im Index die RT Anzeige, obwohl Einstellungen passen. Wenn ich auf pl20 runterstufe, funktioniert es sofort wieder.
Ein Umbau auf eigene Strukturen hat die Nebenwirkung, dass man dabei gleich so einiges lernt. Allerdings hast du inzwischen schon genug andere Projekte gemacht, der RT Umbau dürfte also eigentlich für dich nur noch Fleissarbeit und keine Lernarbeit mehr sein.
