Das ist ein beliebter Stolperstein: Eigentlich würde man davon ausgehen, dass das zeitgesteuerte Veröffentlichen von Datensätzen aus Extensions, z.B. News-Artikeln aus tx_news, so funktioniert wie von normalen Inhaltselementen (tt_content) gewohnt. Im Backend sind schliesslich die Felder für Veröffentlichungsdatum (Start-Date) und Enddatum (End-Date) vorhanden und wenn man das ohne Cache benutzt, dann funktioniert auch alles wunderbar.
Sobald die Seite jedoch gecached wird, also bei allen Produktivseiten, geht das nicht mehr, da die Cache-Lifetime (Default ist hier 24h) verhindert, dass der Artikel zum richtigen Zeitpunkt ein- oder ausgeblendet wird. Es kann im ungünstigsten Fall also bis zu einem Tag länger dauern als im Backend unter Veröffentlichungsdatum angegeben, bis ein Contentelement sichtbar wird. Eine nicht sehr schöne Lösung wäre hier das Herabsetzen der Cache-Lifetime - vielleicht auf eine Stunde. Aus Gründen der Performance will man das aber möglichst auch nicht, vor allem in Situationen, wo eine Extension auf fast allen Seiten vorkommt, z.B. eine "Latest News" Liste.
Ich muss leider zugeben, dass ich mich damit jetzt ein paar Stunden rumgeschlagen habe und kurz davor war einen Scheduler-Task zu bauen, um Newsartikel besser zeitgesteuert einblenden zu können. Ich konnte aber nicht so recht glauben, dass TYPO3 hier so kaputt ist und habe so erst mal weiter gesucht und Doku gelesen. Heureka! config.cache!
config.cache to the rescue!
Mit config.cache lassen sich weitere Tabellen angeben, die bei der Berechnung der Cache-Lifetime von Seiten miteinbezogen werden und Seiten, deren Cache dann gelöscht werden soll.
Veröffentlichungsdatum am Beispiel von tx_news
News sind hier ein gutes Beispiel für Dinge, die man zeitgesteuert veröffentlichen möchte. Nehmen wir an, es gib eine News-Liste auf einer Seite (id=99), diese hat eine Cache-Lifetime von 24h. Der Storage Folder der News hat die ID 33. Damit das zeitgesteuerte Veröffentlichen auf der Seite mit aktiviertem Cache funktioniert muss folgender Eintrag in das Typoscript-Setup geschrieben werden:
config.cache.99 = tx_news_domain_model_news:33
setup.tsconfig.cache ist ein Array, die Keys entsprechen dabei der Seiten-ID, deren Cache-Lifetime berechnet werden soll.
Da unsere Seite mit der Liste der News die ID 99 hat verwenden wir hier den Key 99. Anschliessend geben wir als Wert zunächst die Tabelle an, die wir berücksichtigen wollen und nach einem Doppelpunkt noch die Storage ID, also die ID der Seite im Seitenbaum, wo die News.Artikel gespeichert sind. Mehrere Einträge lassen sich mit einem Komma voneinander getrennt angeben.
Es kann ja nun auch sein, dass man auf allen Seiten einen Latest-News Block einbindet. In diesem Fall wäre es mühsam alle Seiten-IDs anzugeben. Auch hierfür gibt es aber eine Lösung:
config.cache.all = tx_news_domain_model_news:33
Der key all kann - oh Überraschung - verwendet werden um den Cache aller Seiten zu beeinflussen, z.B. wenn man eine Liste mit den neuesten News-Artikeln hat, die auf allen Seiten eingebunden ist.
Fazit
Wenn man Datensätze aus Extensions wie tx_news zeitgesteuert veröffentlichen will, dann muss das über config.cache entsprechend individuell konfiguriert werden. Das ist wegen der einzutragenden IDs nicht besonders flexibel, aber dafür bekommt man fast minutengenaues Veröffentlichen von Artikeln ohne eine verrückt niedrige Cache-Lifetime zu verwenden.
Kommentare (2)