phpBB.de

IMC hat geschrieben: 31.03.2026 23:06 da schein eine sehr Interessante Lösung zu sein, die man sicherlich an einigen anderen Stellen nutzen kann.

Beide Twig Features bieten mehr Flexibilität und erlauben elegantere Lösungen. Speziell die echten globalen Variablen können bei Makros sehr hilfreich sein, da man Makros ja primär einsetzt um redundanten Code zu vermeiden und um variable Lösungen zu ermöglichen, die man im Gegensatz zu statischem HTML nicht nur für eine spezielle Aufgabe nutzen kann. So kann man mit switch() ja gleich 3 verschiedene Input Elemente für einen Schalter generieren, 2 echte und der dritte hat nur andere Klamotten an.

Die globalen Variablen haben mir schon so lange gefehlt, wie ich Twig Makros nutze. Bei der grossen Flexibilität die Makros bieten, mutet es schon seltsam an, wenn man ausgerechnet da eine umständliche und redundante Datenübergabe machen muss. Funktions/Prozess-Kapselung in allen Ehren, aber bei Makros nicht immer sinnvoll, sondern teilweise kontraproduktiv. Makros sollen Abläufe einfacher machen, nicht aufwendiger oder gar umständlicher. Globale Variablen haben natürlich auch gewisse Risiken, aber die sind auch nicht grösser als bei den anderen globalen Scopes die bei der Ext Entwicklung berücksichtigt werden müssen.

Das Problems mit der Extension "Separate Announcements and Stickies" ist jetzt auch gelöst.

Habs mitbekommen, Stoker hat ja super schnell reagiert.

Das heist ich habe ein Event hinzugefügt und ein Event um 2 Variablen erweitert. In dem Zusammenhang habe ich die Templatevariablen parent_forums als Array in das $tpl_ary gepackt. So hat man über das Event Zugriff auf alle Templatevariablen.

Klingt gut. Das heisst Ext Entwickler haben mehr Möglichkeiten bei RTNG einzugreifen und/oder nur die generierten RTNG Daten zu nutzen und anderweitig darzustellen. Das macht im gewissen Rahmen von uns unabhängig realisierte RTNG Features möglich.

Kann ich den Branch dev löschen? Ich kann das vorgeschlagene Branch Muster erst anlegen, wenn der besagte Branch nicht mehr vorhanden ist.

Kann gelöscht werden. Bei mir ist alles gesichert.

Okay, dann solltest du den Branch bei dir lokal löschen, weil Git scheint parallel ein dev und ein dev/1.2.3 nicht zu akzeptieren.

LukeWCS hat geschrieben: 04.04.2026 14:52 Okay, dann solltest du den Branch bei dir lokal löschen

Alles gelöscht.

Okay, dev/1.1.1 online.

Wegen Versionsnummer, du wirst auch schon bemerkt haben, dass Composer Validator das Versionsmuster 1.2.3-dev4 bemängelt. Im Prinzip für uns nicht relevant, aber es ist lästig/unnötig wenn CVAL bei EC einen "Fehler" meldet, der bei phpBB Exts eigentlich keiner ist, denn das wird dann nicht nur von CVAL sondern logischerweise auch noch von EPV gemeldet, da dieses Tool ebenfalls CVAL einsetzt. Wir sollten also keine Versionen mehr mit x.y.z-dev{n} benutzen, sondern ein Alpha Suffix oder der Einfachheit halber ein Beta Suffix, denn bei beiden sind Zahlen danach erlaubt und werden von CVAL nicht bemängelt.

Wenn wir feststellen sollten, dass uns 1.1.1 im weiteren Verlauf nicht mehr ins Konzept passt, dann legen wir einfach einen neuen Branch auf Basis von 1.1.1 mit der endgültigen Version an.

Gut, dann belassen wir es ersteinmal bei 1.1.1. Es wird aber mit Sicherheit auf eine 1.2.0 hinaus laufen.

Ich werde die Tage zwei Versionen hochladen, beta2 & beta3. Einmal die Änderungen die ich bereits mitgeteilt habe. Die beta3 beinhaltet eine geänderte DB-Query für die Data der ersten ungelesene Beiträge. Ich habe eine einfache Möglichkeit gefunden diese mit nur einer Abfrage zu ermitteln. In der Vergangenheit hatte ich zu kompliziert gedacht. Als Abfallprodukt konnte ich auch die Anzahl der ungelesene Beiträge eines Themas ermitteln. Vielleicht nutzt man das irgendwann mal.

Wenn ich die Änderungen getrennt hochlade ist die Änderungshistorie etwas übersichtlicher.

IMC hat geschrieben: 04.04.2026 17:17 Gut, dann belassen wir es ersteinmal bei 1.1.1. Es wird aber mit Sicherheit auf eine 1.2.0 hinaus laufen.

Ah okay, wenn du bereits jetzt schon weisst, dass es eher 1.2.0 wird, dann benenne ich den Branch nach Abendessen einfach um und dein nächster Commit kann dann schon 1.2.0-b2 werden.

IMC hat geschrieben: 04.04.2026 17:17 Wenn ich die Änderungen getrennt hochlade ist die Änderungshistorie etwas übersichtlicher.

Klar, wenns thematisch getrennt sein soll, nur zu.

Branch umbenannt, besser gesagt komplett neu angelegt, da Umbenennen nicht so funktionierte wie es sollte. Damit hatte ich schon in der Vergangenheit Probleme.

Bei der Gelegenheit auch gleich den Commit neu gemacht, dieser hat jetzt den Titel für 1.2.0 und auch composer.json hat die richtige Version.

Meine Commits sind jetzt auch in den Branch.