Blogging mit [tags] und [tags_articles]

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

Moin, moin,

ein erster, zaghafter, Patch für [tags_articles] ModuleTaggedArticleList.php:

Code:

---

--- ModuleTaggedArticleList.php-revBASE.svn000.tmp.php    Di 24. Jan 03:44:17 2012
+++ system/modules/tags_articles/ModuleTaggedArticleList.php    Mo 23. Jan 05:50:54 2012
@@ -71,14 +71,20 @@
 
            // Get published articles
            $pids = join($this->arrPages, ",");
+            $sorting = 'title ASC';
+            if (in_array('edit_date', $this->Config->getActiveModules()))
+            {
+                // Silent support for extension [edit_date]
+                $sorting = 'createdate DESC, tstamp DESC';
+            }
            if ($this->show_in_column)
            {
-                $objArticles = $this->Database->prepare("SELECT id, title, alias, inColumn, cssID FROM tl_article WHERE inColumn = ? AND pid IN (" . $pids . ") " . (!BE_USER_LOGGED_IN ? " AND (start='' OR start<?) AND (stop='' OR stop>?) AND published=1" : "") . " ORDER BY sorting")
+                $objArticles = $this->Database->prepare("SELECT id, title, alias, inColumn, cssID FROM tl_article WHERE inColumn = ? AND pid IN (" . $pids . ") " . (!BE_USER_LOGGED_IN ? " AND (start='' OR start<?) AND (stop='' OR stop>?) AND published=1" : "") . " ORDER BY " . $sorting)
                                              ->execute($this->inColumn, $time, $time);
            }
            else
            {
-                $objArticles = $this->Database->prepare("SELECT id, title, alias, inColumn, cssID FROM tl_article WHERE pid IN (" . $pids . ") " . (!BE_USER_LOGGED_IN ? " AND (start='' OR start<?) AND (stop='' OR stop>?) AND published=1" : "") . " ORDER BY sorting")
+                $objArticles = $this->Database->prepare("SELECT id, title, alias, inColumn, cssID FROM tl_article WHERE pid IN (" . $pids . ") " . (!BE_USER_LOGGED_IN ? " AND (start='' OR start<?) AND (stop='' OR stop>?) AND published=1" : "") . " ORDER BY " . $sorting)
                                              ->execute($time, $time);
            }
            if ($objArticles->numRows < 1)

---

Der Patch tut nicht viel:

1. macht [tags_articles] kompatibel zu [tags] bezüglich der Standard-Sortierung in der Liste (Sortierung nach "title")
2. ist aber [edit_date] installiert und aktiviert, dann wird stattdessen (stillschweigend) nach Datum rückwärts sortiert (createdate DESC, tstamp DESC)

Das funktioniert, für mich, auch wunderbar. Und es sollte auch keine Schaden anrichten für alle bisherigen Benutzer von [tags_articles].

Falls Helmut den Support für [edit_date] in [tags_articles] aufnimmt, müsste natürlich [tags] diesbezüglich ebenfalls nachgeführt werden. Patches dafür kann ich ebenfalls liefern.

Noch eine abschließende Bemerkung zum Einsatz von [edit_date]:

1. installiert man [edit_date] nachträglich, wenn man schon viele Artikel hat, dann wird das "createdate" für all diese Artikel auf 0 aka 01.01.1970 gesetzt. Mein Patch versucht das einigermaßen zu kompensieren, indem auch noch nach "tstamp DESC" sortiert wird. Aber richtig gut funktiniert die Sortierung nur dann, wenn SÄMTLICHE Artikel ihr eigenes "createdate" haben ... "Mehrere bearbeiten" kann da hilfreich sein.
2. ist [edit_date] bereits installiert, wenn man einen neuen Artikel anlegt, dann ist "createdate" mit dem aktuellen Zeitpunkt vorbelegt. Dann gibt es keine Probleme.

LG, Georg

Hallo Georg,

news4ward > sehr interessant, wenn auch noch nicht ganz fertig ( Template html5, Archiv nachträglich bearbeiten nur über *Mehrere bearbeiten* )

https://github.com/psi-4ward/news4ward

Zitat:

---

Zitat von NetMediaWork

news4ward > sehr interessant, wenn auch noch nicht ganz fertig

https://github.com/psi-4ward/news4ward

---

Hmm, der Hinweis im README, dass SÄMTLICHE Inhaltselemente gelöscht werden, falls die eine oder andere Erweiterung des selben Autors nicht installiert ist (oder eventuellt auch einfach nur nicht aktiviert???) macht mir Angst. Macht mir DEUTLICH Angst. Wenn der Autor den Verlust von DB Inhalten nicht verhindern kann, dann rate ich von der Installation ab, bis dies Problem gelöst ist.

LG, Georg

Hallo Georg,

bezog sich darauf und ist bestimmt noch nicht für den produktiven Einsatz geeignet, sonst hätte sie der Autor (Psi) wohl schon veröffentlicht:

Zitat:

---

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.

---

Da wird ja über meine Erweiterungen diskutiert, hübsch ;)
Und jetzt hab ich auch noch ein Forumsmitglied zu demjenigen, der mich da mit Issues bombardiert hat :D

@deerwood: Vielen Dank für deine Rückmeldungen, deine Tickets sind implementiert.

Ein paar Worte zu GlobalContentelements, das ist schon eine etwas "heiße" Sache, da ich hier schon tief in die Trickkiste greife, um die Inhaltselemente auch in nicht Core-Artikeln nutzen zu können. Contao bringt hier einen Aufräum-Mechanismus mit, wenn dieser greift - zum Bsp. wenn gerade jemand einen Artikel bearbeitet - bevor es komplett installiert ist, kann es zu Verlust von Inhaltselementen kommen. Deshalb rate ich generell, macht ein Datenbankbackup vor der Installation.
Läuft dagegen die Erweiterung, kann ich mir im Nachgang kein Szenario vorstellen, bei dem jetzt noch etwas aufgeräumt werden würde.
PS: Dringend Installation über das Repository empfohlen!

News4ward nutzt jetzt diese Technik von GlobalContentelements um die Newsfunktionalität mit etwas mehr Möglichkeiten anzubieten, unter anderem eben alle Inhaltselemente. PS: Ich nutze News4ward schon in 3 Produktivsystemen, allerdings nicht in vollem Funktionsumfang.