Grundsatzdiskussion: Gruppen

webbird · 30.06.2026 18:27:01

Gruppen haben immer eine 1:n Beziehung zu Beiträgen. Das heißt, ein Beitrag kann immer nur in einer Gruppe sein.

Historie: (ohne Anspruch auf Vollständigkeit und Korrektheit, einiges lag sogar vor MEINER Zeit...)

Früher waren Gruppen der einzige Weg, einem Beitrag in der Listen- oder Beitragsansicht ein Bild zu verpassen. Das News-Modul selber machte (soweit ich weiß) standardmäßig gar nichts weiter mit Gruppen. Es ging nur um das Bild.

Per Droplet konnte man dann Beiträge nach Gruppen gefiltert anzeigen lassen. Nach meiner Kenntnis kam das aber erst später, weil irgendwer die Idee hatte, dass man diese Gruppen doch auch noch für was anderes benutzen könnte als nur für das Bild. Mittlerweile gibt es mit "News...anywhere" ein dediziertes Modul, was aber ein eigenes Addon ist und nicht Bestandteil des News-Moduls als solches. Daher lassen wir das an dieser Stelle außen vor.

Noch viel später kamen die Tags (Schlagworte) dazu. Tags sind eine weitere Möglichkeit, Beiträge als (thematisch) zusammengehörig zu markieren. Im Gegensatz zu Gruppen kann ein Beitrag beliebig vielen Tags zugeordnet sein.

Das erlaubt im wesentlichen folgende Filteroptionen:
* Liste Beiträge, die aktiv
>>> und keiner Gruppe zugeordnet sind
oder
>>> und einer Gruppe A oder B oder C zugeordnet sind
oder
>>> und keiner Gruppe oder einer Gruppe B [oder...] zugeordnet sind

Das Ergebnis läßt sich über Tags weiter einschränken, also z.B. "Zeige (aktive) Beiträge, die der Gruppe A zugeordnet sind und mindestens eines der Tags X, Y oder Z zugeordnet haben".

Natürlich läßt sich auch nur nach Tags filtern. wink

---

Aus dem vorangegangenen erklärt sich unter anderem, warum ein Beitrag immer nur in einer Gruppe sein kann - es geht (ging) ja nur um das Bild.

---

Irgendwann kam dann die Option hinzu, dass man Gruppen deaktivieren kann. Wann das war, weiß ich nicht, ist auch nicht wichtig. Die beabsichtigte Semantik war ziemlich klar: Eine inaktive Gruppe blendet alle ihre Beiträge im Frontend aus - analog zum Beitrags-active, nur eine Ebene höher (Beitrag-active = „diesen Beitrag zeigen", Gruppen-active = „die Beiträge dieser Gruppe zeigen"). Detailansicht und Suche setzen das so um. Allerdings: Die Listen-/Teaser-Ansicht (der wichtigste Pfad!) filtert die Gruppe nicht. Folge: Beiträge einer deaktivierten Gruppe erscheinen weiter in der Liste, aber beim Klick liefert die Detailansicht „nichts" (faktisch 404/leer). Vermutlich aus Zeitmangel wurde daher die Möglichkeit, Gruppen zu deaktivieren, irgendwann auskommentiert - bis das Feature vollständig implementiert sein würde.

Für die in Arbeit befindliche Version 6.x heißt das also: Das Feature zum Deaktivieren von Gruppen kann vervollständigt und damit freigeschaltet werden, sofern sich alle einig sind, das die oben beschriebene Semantik die Folge ist. Ein Beitrag, der selbst zwar aktiv ist, sich aber in einer Gruppe befindet, die nicht aktiv ist, wird im Frontend nicht angezeigt.

Last edited by webbird (30.06.2026 18:57:51)

webbird · 30.06.2026 18:55:47

Konflikte durch Gruppen

Sortierung von Beiträgen

Ursprünglich konnte man Beiträge nur nach wenigen Kriterien sortieren. Durch die Gruppen entsteht eine zusätzliche Komplexitätsebene. Läßt man Gruppen außen vor, entstehen im Kern folgende logische Sortier-Optionen:

* Nach Erstelldatum
* Nach Änderungsdatum
* Nach manueller Sortierung
* Alphabetisch nach Titel (vermutlich eher selten)

Bezieht man nun die Gruppen mit ein, wird es komplizierter. Denkbare Optionen:

* Nur nach Beitrag, Gruppe ignorieren
* Erst nach Gruppe, dann nach Beitrag
-> Beitragsoptionen wie oben

Hier muss man nun zusätzlich eine Sortieroption für die Gruppen einbinden. Am wahrscheinlichsten:

* Alphabetisch
* Nach manueller Sortierung
* ggfs. auch noch nach Erstelldatum (eher selten/unwahrscheinlich)

Damit wird so ein Sortier-Dropdown schon ganz schön voll, da man ja alle denkbaren Optionen einzeln anbieten muss. Und wo listet man nun hier die Beiträge auf, die gar keiner Gruppe zugeordnet sind?

Beitrag mehreren Gruppen zuordnen

Das ist, wie ja schon sehr deutlich geschrieben, aktuell *kein* Feature und auch nicht als solches geplant. Nicht nur in Kombination mit den Sortieroptionen wird es jetzt wirklich haarig, auch was das Deaktivieren von Gruppen angeht.

Der Konfliktfall: Beitrag aktiv, in A (aktiv) und B (inaktiv)

Hier gibt es zwei mögliche Auflösungsregeln:

* ODER-Semantik („sichtbar, wenn in mindestens einer aktiven Gruppe"): Der Beitrag ist sichtbar, weil A ihn „trägt". Dass B inaktiv ist, versteckt ihn nicht.
* UND-Semantik („versteckt, sobald irgendeine Gruppe inaktiv ist"): B inaktiv → Beitrag weg, obwohl A aktiv ist.

Die UND-Variante ist kontraintuitiv und gefährlich: Man deaktiviert Gruppe B („Archiv") und reißt damit Beiträge mit, die auch in der aktiven Gruppe A („Aktuelles") hängen. „Eine Gruppe abschalten" darf nicht Beiträge anderer, aktiver Gruppen mit ausblenden.
ODER ist die saubere Verallgemeinerung des heutigen Einzelgruppen-Verhaltens: bei genau einer Gruppe ist „≥1 aktive Gruppe" identisch mit „die Gruppe ist aktiv". Nichts ändert sich für bestehende Inhalte.

Die Gesamtregel wäre dann:

Ein Beitrag ist sichtbar, wenn post.active=1 und (er hat keine Gruppe oder mindestens eine seiner Gruppen ist aktiv).

Wichtig ist der Kontext: In einer gruppengefilterten Ansicht (&g=B) taucht der Beitrag trotzdem nicht auf - nicht weil der Beitrag versteckt ist, sondern weil die Ansicht von B leer ist (B inaktiv). In der ungefilterten Liste und in der Detailansicht greift die ODER-Regel oben.

Die Folgeherausforderungen

Multi-Gruppe sprengt mehrere Stellen, die heute „die eine Gruppe" annehmen:

1. Datenmodell. posts.group_id (ein Int) → Junction-Tabelle mod_news_img_groups_posts(post_id, group_id). Das Muster existiert im Modul schon — exakt so funktionieren die Tags (mod_news_img_tags_posts). Das ist die naheliegende Blaupause inkl. Backend-UI (Checkboxen statt Single-Select).
2. Die [GROUP_TITLE]/[GROUP_IMAGE]-Platzhalter und group_id. Detail- und Teaser-Templates zeigen eine Gruppe (Bild/Titel). Bei N Gruppen braucht es eine Regel: eine Primärgruppe, oder die Kontextgruppe (die aus dem aktuellen &g=-Filter), oder eine Liste.
3. Prev/Next-Navigation. Läuft heute „innerhalb der Gruppe" (functions.inc.php:1184). Bei Multi-Gruppe: an die Kontextgruppe binden, sonst global. Ohne Festlegung wird die Reihenfolge mehrdeutig.
4. Sektion-Verflechtung — der eigentliche Stolperstein. Der Gruppen-Wert ist heute group_id|section_id|page_id, und eine Gruppe zuzuweisen kann den Beitrag in eine andere Section/Page verschieben (save_post.php:86-97). Gruppenzugehörigkeit und Section-Platzierung sind also verheiratet. Multi-Gruppe innerhalb derselben Section ist sauber machbar; Multi-Gruppe über Sections hinweg ist konzeptioneller Sprengstoff (ein Beitrag „wohnt" in einer Section, würde aber in mehreren erscheinen). → Multi-Gruppe auf Gruppen der eigenen Section beschränken und die Section-Zuordnung vom Gruppen-Picker entkoppeln.
5. Reihenfolge/Position. position ist heute pro Section (Drag-&-Drop). Soll die Sortierung je Gruppe unterschiedlich sein, muss die Position in die Junction-Tabelle wandern (groups_posts.position) — sonst hat ein Beitrag nur eine globale Position über alle Gruppen.
6. Konsistente Durchsetzung. Die ODER-Regel muss in alle Frontend-Abfragen (Liste, Detail, Suche, RSS, Prev/Next) mitfixen.

Fazit: Bis auf weiteres wird es in NWI keine Multi-Gruppen geben, da der Aufwand zu hoch ist und die Komplexität bzw. die Auswirkungen auf das Frontend nur schwer zu beschreiben und zu durchschauen sind.

Für eine Zuordnung zu mehreren "Kategorien" können eventuell die Tags verwendet werden.

Last edited by webbird (30.06.2026 18:57:12)

florian

webbird · 30.06.2026 18:59:32

Fazit - "Back to the roots"

Das Feature zum Deaktivieren von Gruppen wird vervollständigt und wieder freigeschaltet.

Es wird keine Multi-Gruppen geben.

Das News-Modul selbst wird nur noch Sortieroptionen für Beiträge anbieten, aber keine für Beiträge UND Gruppen. Gruppen ermöglichen die Definition eines einheitlichen Beitragsbilds für alle Beiträge in der Gruppe sowie die Möglichkeit für das Deaktivieren aller Beiträge einer Gruppe. Nicht mehr, nicht weniger.

Im Umkehrschluß bedeutet das: Wer Beitragslisten filtern und "anders" sortieren will, muss ein Addon für das News-Modul (oder einen Fork) erstellen. Ob diese Optionen in "News...Anywhere" eingebaut werden, ist nicht meine Entscheidung. Ich werde alles an Code und SQL-Statements streichen, was über das oben gesagte hinaus geht. NWI wird also keine Funktionen mitliefern, die "gib mir mal alle aktiven Beiträge, die in der Gruppe A oder B sind, die Tags X oder Y oder Z hat, UND sortier mir die dann noch nach Kriterium..." umsetzen.

Last edited by webbird (02.07.2026 11:48:07)

florian, stefanek

webbird · 02.07.2026 12:04:19

https://github.com/WBCE/News-with-Image … /Groups.md

mk70

WBCE CMS Forum

#1 30.06.2026 18:27:01