Moin alle, Helmut,
nachdem ich nun reichlich nach einer Blog-Erweiterung für Contao herum geschaut habe, kann ich nur sagen: [tags] und Co haben genau das Potential, nach dem ich suche. Es fehlt nur wenig.
Ein Blog-System basierend auf den News scheidet aus, weil der Blogger "full blown" Funktionalität von Contao erwartet, besonders das Konzept von Artikeln als Container und diversen unterschiedlichen Inhaltselementen darin. Mit verschiedenen CSS Klassen/IDs per Backend (unterstützt von [Stylepicker4ward]), damit die Redakteure jeden Artikel (mit verschiedensten Inhaltselementen) sehr individuell gestalten können.
News bietet das ja nicht, bestenfalls kann man noch eine Galerie hinzufügen, das reicht aber für mein Projekt nicht aus.
Ich bin auch auf [GlobalContentelements] gestoßen, dort wird verwiesen auf [News4ward] ... allein diese Erweiterung existiert offenbar nicht (und ich bin zu blöd, die Doku im Wiki zu verstehen). Irgendwie erscheint mir das Konzept suspekt, ich lasse mich aber gern eines Besseren belehren.
Dann habe ich auch noch [auto_news] gefunden und angetestet. Die Idee dahinter ist echt nicht schlecht: im Artikelkopf kann man den Teaser (oder ein Inhalts-Element) in ein oder auch mehrere News-Archiv/e einsortieren. Die Erweiterung sorgt dafür, dass die Auswahl als News-Teaser verwendet wird, die News hat keinen Inhalt, sondern verlinkt auf den Artikel. Und zwar, ohne dass man jemals die News-Archive editieren müsste.
Damit kann man elegant, bei der Bearbeitung des Artikelkopfs, eine grobe Kategorisierung in verschieden Archive vornehmen. Und man hat die vollständige Paginierungs-Funktionalität von News. Falls nötig auch nach Jahr/Monat usw.
Aber die groben Kategorien von News reichen in meinem Projekt nicht aus. Da wird unbedingt [tags] & Co benötigt. Klar, [tags] bzw. [tags_news] bieten das an ... aber [auto_news] "kennt" [tags] nicht. Deshalb müssten Editoren, nach der Zuordnung im Artikelkopf, auch noch die News aufrufen, und die passenden Tags dort nachtragen, statt sie bequem im Artikelkopf eingeben zu können. Damit ginge der Vorteil von [auto_news] in meinem Projekt komplett verloren. Und der Autor von [auto_news] ist zur Zeit anderweitig beschäftigt und kann vermutlich keinen zeitnahen Support leisten. Und selbst bei automatischer Übertragung der Tags wäre das ganze Konzept fragwürdig: eine Duplizierung von Tags aus den Artikeln in ein oder mehrere Nachrichten fände ich zumindest komisch. Damit schließe ich den Umweg über News erst einmal aus.
Nun zu dem, was [tags] und [tags_articles] bereits bieten:
Beide bieten eine Liste an (zum Glück hat auch [tags_articles] eine Option, ALLE Artikel zu zeigen, falls keine Tags übergeben wurden, auch wenn das anders dokumentiert ist).
Sortierung:
Standardmäßig werden nur die Links zu den Artikeln ausgegeben, und das auch noch "merkwürdig" sortiert:
- in [tags] ModuleGlobalArticlelist.php wird sortiert nach dem Feld "tl_article.title". Nicht ganz schlecht, aber für Blooging nicht so gut geeignet.
- in [tags_articles] ModuleTaggedArticleList.php wird dagegen sortiert nach "tl_article.sorting". Das ist a) inkonsistent zu [tags] und b) führt es dazu, dass in der Essenz meist nach ID des Artikels sortiert wird. "sorting" bezieht sich ja immer auf den Container (hier die Seite), hat man also, wie das oft der Fall ist, nur einen Artikel pro Seite, dann ist "sorting" immer 128, bei allen Artikeln. Die DB sortiert dann theoretisch zufällig (das Ergebnis ist eine Menge), in der Praxis nach dem Primärschlüssel (der Id).
Als Blogger wünscht man sich aber in der Regel eine Sortierung nach Datum rückwärts. Das wäre leicht zu erreichen, wenn beide Listen-Module nach "tl_article.tstamp DESC" sortieren würden. Entweder als Standard oder optional mit einem Feld im Backend, in dem man zwischen "title" und "tstamp" wählen kann.
Zur "tstamp" allgemein ist aber noch einiges zu sagen/beachten: Contao (zumindest 2.10.x) mag es ganz und gar nicht, wenn an der tstamp gedreht wird, unter anderem hängt die korrekte Versionierung von Datensätzen davon ab! Contao setzt deshalb die tstamp (in DC_Table.php und an vielen anderen Stellen) explizit in einem eigenen UPDATE Statement NACH Speicherung des Datensatzes. Damit scheitert jeder Versuch, die tstamp im Backend ausdrücklich zu setzen.
Auch ist das "Änderungsdatum", das im Kopf der Artikel-Übersicht gezeigt wird, nicht die "tl_article.tstamp" allein, sonders die neueste tstamp des Artikels und aller seiner Inhaltselemente. Verwirrend? Ja.
Nun gibt es die Erweiterung [edit_date], die ich gerade für 2.10.x angepasst habe. Damit hat man ein zusätzliches Feld "tl_article.createdate", das beliebig gesetzt werden kann.
Mein Vorschlag: ist [edit_date] installiert und aktiviert, dann sortiert [tags] und [tags_articles] nach "createdate DESC, tstamp DESC", sonst sortieren beide nach "title".
Paginierung:
So wie es ist, zeigen beide Listen immer ALLE betroffene Artikel. Ohne Tag Auswahl eben ALLE, mit Tag Auswahl eventuell sehr viele. Auch wenn im Standard Template nur die Links gezeigt werden, die Listen sind oft viel zu lang. Und intern beschaffen beide Erweiterung sämtliche Informationen zu jedem Artikel, auch das "full blown" HTML. Das kostet natürlich reichlich Verarbeitungszeit/Serverlast und das meiste davon wird einfach weggeworfen, weil es im Template ignoriert wird. Ich fände es wundervoll, wenn [tags] und Co eine Paginierung anbieten würde. Wie gewohnt von den News, also "Seite 1 von 12" usw.
Keinesfalls sollte der Umfang der Infos zum Artikel beschränkt werden, im Gegenteil:
Support für Teaser Images:
In den Template Variablen sind sowohl die Teaser, wie auch das komplette HTML des Artikels verfügbar. Und mit einem eigenen Template kann man davon auch Gebrauch machen. Siehe (eine Zeit lang) http://georg-rehfeld.com/liste.html. Der jeweils erste Artikel in der Liste zeigt (zur Zeit) das komplette HTML des Artikel, danach werden nur noch die Teaser-Texte ausgegeben.
Aber eigentlich will ich, für mein Projekt, nur die Teasertexte ausgeben ... allerdings soll der jeweils erste Teaser auch noch ein Teaser-Bild anzeigen. Für Teaser-Bilder gibt es offenbar diverse Erweiterungen. Ich erforsche sie gerade. Zur Zeit erscheint mir [teaserimages] die erste Wahl zu sein.
Jedenfalls wünschte ich mir Support für eine der Teaser Image Erweiterungen.
Liebe Leser, diese Nachricht zu Ende zu schreiben, hat verflixt lange gedauert. Anfangs hatte ich gehofft, auch die Patches gleich mitliefern zu können. Aber das Zusammenwirken verschiedener Erweiterungen, die nicht vom gleichen Autor sind, ist echt schwierig. Und natürlich hat auch jeder Autor nur begrenzte Zeit und Interessen. Für dies Problem habe ich nicht einmal einen Lösungs-Ansatz.
LG, Georg
Lesezeichen