Gibt es eine Möglichkeit, die Blog-Satistik am 01.01.2021 auf Null zu stellen? Also alle bisher gesammelten Daten zu löschen, damit man eine aktuelle Jahresstatistik erhält.
Falls ich keine bessere Idee habe, würde ich das Statistik-Plugin deinstallieren, per FTP von Server löschen und danach wieder neu installieren.
Hallo Beat - wünsche schöne Weihnachten gehabt zu haben!
Ich frage mich was das für einen Sinn macht....,
denn die Statistiken sind eigentlich zwei Arten von Daten: Das visitors Log und die Aggregation. Da das Log sich aufbläht über die Zeit, habe ich eine Begrenzung von genau einem Jahr eingeführt und jeder Aufruf des Statistik Plugins löscht alles überstehende, nachdem es die Daten aggregiert, also zusammengefasst und überführt, hat. Deshalb steht da für Heute:
Die erweiterte Besucherstatistik hat seit folgendem Zeitpunkt Daten gesammelt: 2019-12-27
Dies Zusammenfassung landet in der visitors_count (und refs) Tabelle.
Zurück zur "Warum" Frage.
Vielleicht willst du ja einfach nur die "meist überflüssigen" Blog Statistiken loswerden...?!
Dafür gibt es einen Knopf: Alles zeigen?
Es sind also 3 Tabellen: visitors, visitors_count und refs. Diese werden automatisch gelöscht wenn du das Plugin deinstallierst.
Per FTP löschen ist unnötig! Dies wäre ja nur in den Fällen vonnöten, wo es sich um eigene und ev, vermurkste Developer Plugins oder andere sehr spezielle Fälle handelt. Das verbesserte allgemeine Plugin Management sollte, nachdem Migrations Upgrader einmal den Altlastenmanger bedient haben, soetwas nur noch sehr selten zulassen bzw vonnöten machen.
Beat Post author am |
Ja, Weihnachten war stimmig und schön. Danke! Ich hoffe, Du konntest auch ein paar friedliche Tage verbringen und dem Corona-Virus erfolgreich ausweichen. ?
Ah.. ich habe gar nicht gemerkt, dass die Statisk ein "rollendes Jahr" aufzeichnet. Irgendwie hatte ich im Kopf, dass ab Start des Statistik-Plugins einfach immer weiter addiert wird (über all die Jahre). Auf www.beatsblog.ch installierte ich das Plugin am 24.01.2020 und deshalb kam ich auf die Idee, dass mich eher die Daten pro Kalenderjahr, also ab 01.01.2021, interessieren.
Was den "Alles zeigen?"-Button anbelangt: Asche auf mein Haupt. Ich habe die Plugineinstellungen nie im Detail angesehen. Habe nun kurz damit rumgespielt. Im Live-Blog werde ich mir dennoch alles anzeigen lassen. Das passt schon so.
Somit hat sich das Thema dann auch erledigt. Danke! ?
Früher war das auch tatsächlich so, das dass aufquellende visitors log die Datenbank ziemlich ausbremsen konnte. Ich habe da Blogs mit gigantischen Logs erlebt .... die mich später veranlassten das rolling year einzuführen.
Guten Rutsch! ?
Beat Post author am |
? Wünsche Dir auch einen guten Rutsch ins neue Jahr! ?
Vielen Dank für die vielen Stunden "Support", die Du mir in diesem Jahr geboten hast. Ohne Deine Unterstützung wäre mein Live-Blog nie so schön herausgekommen. Ich weiss das ausserordentlich zu schätzen!
Ich auch für meinen furchtlosen Tester mit seinem wertvollen Blog-Daten-Schatz fürs Debugging! ?
And a Happy New Year! ✨
Beat Post author am |
Und kaum klopft man sich mal gegenseitig etwas auf die Schultern und denkt: Alles ist gut... sieht man wieder etwas Neues/Altes.
Das Historiy-Plugin zeigt zum neuen Jahr ganz unverschämt Beiträge vom 01.01 und vom 02.01. an. Hmmm... Ein Schaltjahr/Nicht-Schaltjahr-Problem? Das history_daylist.dat löschen und neu erzeugen hat auch keine Korrektur gebracht. Mal schauen, wie es morgen aussieht. Ob sich das einrenkt oder ob nun dauernd zwei Tage angezeigt werden.
Ja ich sitze da schon dran.
Mein Verdacht ist auch dass es sich dabei um ein "Schaltjahr" Problem handelt. Und zwar eines normalen Jahres das auf ein Schaltjahr folgt, in diesem Fallauf 2020. Ich muss das nur noch richtig denken können.
Nachsehen ja; aber das ist ja nur der fehlende bzw addierte Tag, also 365 oder 366. Ich denke dass das jetzt grundsätzlich klappt! Nur eine gehäufte Ansammlung von aufgesetzten Schaltsekunden oder ein PHP bug könnte dem jetzt noch in ferner Zukunft gefährlich werden. Oder halt Blogs mit falsch gelisteten Einträgen... ?
Oder halt Blogs mit falsch gelisteten Einträgen...
Willst Du mir damit irgendetwas sagen? ??
Beat Post author am |
Grummel... ?
Nachdem ich hier zwei Plugins aktualisiert habe, wollte ich das Selbe im Live-Blog durchführen. Wenn ich dort auf "Plugins updaten" klicke, erhalte ich als Antwort eine leere Seite. Da nützte auch erneutes ab- und anmelden nichts und auch den Browsercache (mitsamt Coockies) löschen blieb ohne Wirkung.
Hmmm... ? Irgendetwas läuft da momentan schief. Muss noch weiter nachforschen. Interessanterweise funktionierte das Plugins updaten auf styx.beatsblog.ch ohne Probleme.
Haben eben jene denn nun vielleicht schon die neue Versionsnummer (in Pluginliste im i Info Aufklappkasten) ?
Im Vergleich zu hier?
Beat Post author am |
Strange ?! Beim heutigen Versuch die Plugins upzudaten, habe ich wieder eine blanke Seite erhalten.
So zum Spass klickte ich dann auf den Button "Seitenleistenplugin installieren" und da wurde mir dann rot angezeigt, dass es bei mir eine serendipity_plugin_history_original.php gibt. Klar. Die habe ich am letzten Samstag erzeugt, bevor ich die neue, korrigierte Version aufgespielt habe. Da nun das History-Plugin mit der neuen Fileversion gut funktioniert, habe ich also per FTP die angemäkelte _original.php-Datei gelöscht und siehe da... nun konnte ich auch die noch ausstehenden Plugin-Updates durchführen.
Anscheinend mag das Styx Plugin Update keine Dateien, die da nicht hingehören (auch nicht bei Plugins, für die gar kein Update ansteht). Das Resultat ist dann eine weisse Seite. Gut zu wissen...
Ah ja, so ist es. Wenn du gerne eine Kopie behalten willst, beginne sie mit einem _(Unterstrich - das geht definitiv), oder schreibe vielleicht das original an den Anfang. Das Pluginsystem mag es nicht wenn es gleichlautende Dateien (wenigstens für den Anfang und den Pluginnamen) gibt.
Beat Post author am |
Danke für die entsprechenden Naming-Hinweise. Man lernt nie aus. ?
Beat Post author am |
Kurze Verständnisfrage:
Letzthin wurde das Lightbox-Plugin upgedatet. Dabei wurde meine abgeänderte lightbox.css überschrieben. Gibt es eine Möglichkeit, diese Änderungen update-sicher zu machen?
Ich nehme an, dass es nichts nützt, wenn ich die geänderten Einträge in meine user.css schreibe. Denn ich vermute, dass erst beim Aufstarten der Lightbox die lightbox.css geladen wird und somit meine gemachten Einträge in der user.css übersteuern würde. Sehe ich das richtig?
Das ist nicht sooo wichtig. Ich habe mir einen Entwurfsbeitrag geschrieben, in dem alle Änderungen am Core und innerhalb der einzelnen Plugins aufgelistet sind. Ich muss bei Updates einfach wach sein und danach die gemachten Änderungen wieder nachtragen.
Da das ja ein stylesheet ist das extra geladen wird, sitzt es im head der index, dort wo der frontend_header hook steht. Das ist unterhalb der normalen stylesheets. Auch sieht das Plugin nicht vor, dass man das lightbox stylesheet vom template als bearbeitete Kopie laden könnte.
So bleibt lediglich die Möglichkeit es von vornherein in der user.css mit !important zu überschreiben und damit spätere Eigenschaften zu unterdrücken,
oder durch Verkettung geeigneter Selektoren, die eine höhere Priorität besitzen, eine Überschreibung ohne das !important zu ermöglichen.
P.S. Ich sehe außerdem gerade, dass es eine minifizierte xx.min.css Version gibt. Das werde ich demnächst mal daraufhin abändern.
Beat Post author am |
PSG-Card-Design
Ich habe mir das neue Pure-Child-Theme PSG mal etwas genauer angesehen. Wenn ich das richtig verstanden habe, so kann man mit den einzelnen Karten genau zwei Dinge tun:
Karte als internen Link benutzen (Array)
In Karte X Beiträge von Kategorien anzeigen (Fetching)
Habe ich das soweit richtig verstanden?
Hmm...? Super wäre doch, wenn man in einer Karte ein Seitenleisten-Plugin darstellen könnte. Also statt mit Array auf .../comments zu verweisen, gleich die letzten X Kommentare anzeigen, so wie es das Seitenleisten-Plugin kann/macht. So könnte man ein cleanes Blogdesign ganz ohne Seitenleisten zusammenschustern. D.h. die gewünschten Seitenleisten-Plugins wären nur in den Karten der "Landing-Page - Home" sichtbar, würden in der Blogansicht dann jedoch nicht angezeigt. Das würde vermutlich auch die Blogansicht-Seitenladezeit für Mobile-User reduzieren.
Anmerkung: Einerseits finde ich PSG spannend, andererseits schreckt mich die Theme-Kette pure->PSG->pure-beat etwas ab und ich finde bisher noch zuwenig Nutzen in diesem Card-Design. Wenn Du keine Zeit für etwas Beratung/Coaching aufwenden willst, habe ich volles Verständnis dafür. Wenn Du jedoch an Praxis-Erfahrungen interessiert bist, kann ich zu PSG-Card-Design einen eigenen Blogeintrag schreiben, damit wir das dort etwas themengerechter diskutieren können. Die Umsetzung würde ich auf styx.beatsblog.ch versuchen.
Apropos. Hattest du obige Antwort zu lightbox styles schon realisiert?
Habe ich das soweit richtig verstanden?
? ja. Du kannst so eine Karte allerdings auch als Kurzinfo verwenden und nicht verlinken. Oder als immer mal wechselnde Highlight Karten auf bestimmte Artikel (zb solche die immer wieder abgerufen werden) etc.
Nun..., dafür gibt es die geniale Plugin API, bzw die zur Verfügung gestellten Smarty-Funktionen.
Wie du selbst sehen kannst, nutzt die eine (größere) Karte einen solche als
Wie der Funktions-Name verrät, holt diese soundsoviele Eintrage aus den Eintragstabellen.
Lies einmal nach unter: https://ophian.github.io/book/#U963 im Kapitel 9 und toc 9.6.3
und eben da im Weiteren zB. in {serendipity_showPlugin}
(Gibt die Inhalte eines installierten Seitenleisten-Plugins aus. Dies kann unabhängig von der gewohnten Darstellung innerhalb der Seitenleiste erfolgen, so dass ein Seitenleisten-Plugin an beliebiger Stelle in einem Template platziert werden kann.)
Das könnte allerdings etwas tricky werden, da du es ja wahrscheinlich eher in einer Grid Karte der 2. Zeile haben möchtest, die wiederum von einem php array gespeist wird.
Was nun folgt ist Eigenes experimentieren.
Außerdem gibt es noch - da du es explizit als Beispiel erwähnt hast - {serendipity_printComments} welches analog zum weitaus mächtigeren fetchPrintEntries eben Kommentare ausgibt.
(Stellt die Liste aller Kommentare für einen Eintrag dar.)
Vor Theme Verkettungen a la pure->PSG->pure-beat sollte man keine Angst haben, sind sie doch eher geeignet sehr simpel im Letzteren zu werden, da die Richtung ja auch eher <- ist, also was als template file nicht in beat ist, suche in psg und wenn auch dort nicht in pure. Eine rein interne Funktion um Redundanzen zu vermeiden.
Ganz allgemein sind solche Landungsseiten ja nur wie das "Cover "eines Magazines. Ich persönlich habe immer gemerkt, dass mich dieser Firlefanz als Besucher nicht mehr interessiert, wenn ich mehrfach auf eine solche Seite gehe. Letzthin will ich dann immer zum Content, schnell und praktisch. Diese ganzen Wordpress-themes mir ihren ineinandergeschachtelten Hochglanz/-kant Karussells sehen meist nur schick aus. Wirklich nachhaltige Informationen vermitteln sie nur sehr selten - vor allem bei häufigeren Besuchen.
Leider ist man als Websurfer heute viel an soetwas gewöhnt und meint nun, dass das halt modern und angesagt ist. Aber es ist Fassade. Ich bin deshalb immer wieder auf die grundsätzlichen strukturellen Designs zurückgekehrt. Und die sind: Kopf, Inhalt, Seitenleiste(n), Fuß.
Beat Post author am |
Kurze Frage vor dem Jahresende:
Gibt es eine Möglichkeit, die Blog-Satistik am 01.01.2021 auf Null zu stellen? Also alle bisher gesammelten Daten zu löschen, damit man eine aktuelle Jahresstatistik erhält.
Falls ich keine bessere Idee habe, würde ich das Statistik-Plugin deinstallieren, per FTP von Server löschen und danach wieder neu installieren.
Ian Styx am |
Hallo Beat - wünsche schöne Weihnachten gehabt zu haben!
Ich frage mich was das für einen Sinn macht....,
denn die Statistiken sind eigentlich zwei Arten von Daten: Das visitors Log und die Aggregation. Da das Log sich aufbläht über die Zeit, habe ich eine Begrenzung von genau einem Jahr eingeführt und jeder Aufruf des Statistik Plugins löscht alles überstehende, nachdem es die Daten aggregiert, also zusammengefasst und überführt, hat. Deshalb steht da für Heute:
Dies Zusammenfassung landet in der visitors_count (und refs) Tabelle.
Zurück zur "Warum" Frage.
Vielleicht willst du ja einfach nur die "meist überflüssigen" Blog Statistiken loswerden...?!
Dafür gibt es einen Knopf: Alles zeigen?
Es sind also 3 Tabellen: visitors, visitors_count und refs. Diese werden automatisch gelöscht wenn du das Plugin deinstallierst.
Ian Styx am |
Per FTP löschen ist unnötig! Dies wäre ja nur in den Fällen vonnöten, wo es sich um eigene und ev, vermurkste Developer Plugins oder andere sehr spezielle Fälle handelt. Das verbesserte allgemeine Plugin Management sollte, nachdem Migrations Upgrader einmal den Altlastenmanger bedient haben, soetwas nur noch sehr selten zulassen bzw vonnöten machen.
Beat Post author am |
Ja, Weihnachten war stimmig und schön. Danke! Ich hoffe, Du konntest auch ein paar friedliche Tage verbringen und dem Corona-Virus erfolgreich ausweichen. ?
Ah.. ich habe gar nicht gemerkt, dass die Statisk ein "rollendes Jahr" aufzeichnet. Irgendwie hatte ich im Kopf, dass ab Start des Statistik-Plugins einfach immer weiter addiert wird (über all die Jahre). Auf www.beatsblog.ch installierte ich das Plugin am 24.01.2020 und deshalb kam ich auf die Idee, dass mich eher die Daten pro Kalenderjahr, also ab 01.01.2021, interessieren.
Was den "Alles zeigen?"-Button anbelangt: Asche auf mein Haupt. Ich habe die Plugineinstellungen nie im Detail angesehen. Habe nun kurz damit rumgespielt. Im Live-Blog werde ich mir dennoch alles anzeigen lassen. Das passt schon so.
Somit hat sich das Thema dann auch erledigt. Danke! ?
Ian Styx am |
Jupp soweit alles gut! ?
Ein Rolling Year Plugin. ? Genau!
Früher war das auch tatsächlich so, das dass aufquellende visitors log die Datenbank ziemlich ausbremsen konnte. Ich habe da Blogs mit gigantischen Logs erlebt .... die mich später veranlassten das rolling year einzuführen.
Guten Rutsch! ?
Beat Post author am |
? Wünsche Dir auch einen guten Rutsch ins neue Jahr! ?
Vielen Dank für die vielen Stunden "Support", die Du mir in diesem Jahr geboten hast. Ohne Deine Unterstützung wäre mein Live-Blog nie so schön herausgekommen. Ich weiss das ausserordentlich zu schätzen!
Ian Styx am |
Ich auch für meinen furchtlosen Tester mit seinem wertvollen Blog-Daten-Schatz fürs Debugging! ?
And a Happy New Year! ✨
Beat Post author am |
Und kaum klopft man sich mal gegenseitig etwas auf die Schultern und denkt: Alles ist gut... sieht man wieder etwas Neues/Altes.
Das Historiy-Plugin zeigt zum neuen Jahr ganz unverschämt Beiträge vom 01.01 und vom 02.01. an. Hmmm... Ein Schaltjahr/Nicht-Schaltjahr-Problem? Das history_daylist.dat löschen und neu erzeugen hat auch keine Korrektur gebracht. Mal schauen, wie es morgen aussieht. Ob sich das einrenkt oder ob nun dauernd zwei Tage angezeigt werden.
Ian Styx am |
Ja ich sitze da schon dran.
Mein Verdacht ist auch dass es sich dabei um ein "Schaltjahr" Problem handelt. Und zwar eines normalen Jahres das auf ein Schaltjahr folgt, in diesem Fallauf 2020. Ich muss das nur noch richtig denken können.
Ian Styx am |
Sorry für das delay ... ich war gestern etwas zermust und konnte nicht denken.
Jetzt meine ich aber es gelöst zu haben. Ich schicke es dir gleich mal rüber zum testen.
Beat Post author am |
? magic hands ?
Habe das neue serendipity_plugin_history.php hier und im Live-Blog eingefügt. Dann das history_daylist.dat gelöscht und... ?
Sieht sehr gut aus! ?
Ian Styx am |
Wunderbar!
Mal sehen, wann wir dieses Stehaufmännchen endlich besiegt haben..! ?
Beat Post author am |
Ich denke, dass am 01.03.2021 der nächste "Checkpoint" ansteht. ?
Ian Styx am |
Nachsehen ja; aber das ist ja nur der fehlende bzw addierte Tag, also 365 oder 366. Ich denke dass das jetzt grundsätzlich klappt! Nur eine gehäufte Ansammlung von aufgesetzten Schaltsekunden oder ein PHP bug könnte dem jetzt noch in ferner Zukunft gefährlich werden. Oder halt Blogs mit falsch gelisteten Einträgen... ?
Beat Post author am |
Willst Du mir damit irgendetwas sagen? ??
Beat Post author am |
Grummel... ?
Nachdem ich hier zwei Plugins aktualisiert habe, wollte ich das Selbe im Live-Blog durchführen. Wenn ich dort auf "Plugins updaten" klicke, erhalte ich als Antwort eine leere Seite. Da nützte auch erneutes ab- und anmelden nichts und auch den Browsercache (mitsamt Coockies) löschen blieb ohne Wirkung.
Hmmm... ? Irgendetwas läuft da momentan schief. Muss noch weiter nachforschen. Interessanterweise funktionierte das Plugins updaten auf styx.beatsblog.ch ohne Probleme.
Ian Styx am |
Irgendwie verschluckt, vielleicht?
Haben eben jene denn nun vielleicht schon die neue Versionsnummer (in Pluginliste im i Info Aufklappkasten) ?
Im Vergleich zu hier?
Beat Post author am |
Strange ?! Beim heutigen Versuch die Plugins upzudaten, habe ich wieder eine blanke Seite erhalten.
So zum Spass klickte ich dann auf den Button "Seitenleistenplugin installieren" und da wurde mir dann rot angezeigt, dass es bei mir eine serendipity_plugin_history_original.php gibt. Klar. Die habe ich am letzten Samstag erzeugt, bevor ich die neue, korrigierte Version aufgespielt habe. Da nun das History-Plugin mit der neuen Fileversion gut funktioniert, habe ich also per FTP die angemäkelte _original.php-Datei gelöscht und siehe da... nun konnte ich auch die noch ausstehenden Plugin-Updates durchführen.
Anscheinend mag das Styx Plugin Update keine Dateien, die da nicht hingehören (auch nicht bei Plugins, für die gar kein Update ansteht). Das Resultat ist dann eine weisse Seite. Gut zu wissen...
Ian Styx am |
Ah ja, so ist es. Wenn du gerne eine Kopie behalten willst, beginne sie mit einem _(Unterstrich - das geht definitiv), oder schreibe vielleicht das original an den Anfang. Das Pluginsystem mag es nicht wenn es gleichlautende Dateien (wenigstens für den Anfang und den Pluginnamen) gibt.
Beat Post author am |
Danke für die entsprechenden Naming-Hinweise. Man lernt nie aus. ?
Beat Post author am |
Kurze Verständnisfrage:
Letzthin wurde das Lightbox-Plugin upgedatet. Dabei wurde meine abgeänderte lightbox.css überschrieben. Gibt es eine Möglichkeit, diese Änderungen update-sicher zu machen?
Ich nehme an, dass es nichts nützt, wenn ich die geänderten Einträge in meine user.css schreibe. Denn ich vermute, dass erst beim Aufstarten der Lightbox die lightbox.css geladen wird und somit meine gemachten Einträge in der user.css übersteuern würde. Sehe ich das richtig?
Das ist nicht sooo wichtig. Ich habe mir einen Entwurfsbeitrag geschrieben, in dem alle Änderungen am Core und innerhalb der einzelnen Plugins aufgelistet sind. Ich muss bei Updates einfach wach sein und danach die gemachten Änderungen wieder nachtragen.
Ian Styx am |
Da das ja ein stylesheet ist das extra geladen wird, sitzt es im head der index, dort wo der frontend_header hook steht. Das ist unterhalb der normalen stylesheets. Auch sieht das Plugin nicht vor, dass man das lightbox stylesheet vom template als bearbeitete Kopie laden könnte.
So bleibt lediglich die Möglichkeit es von vornherein in der user.css mit !important zu überschreiben und damit spätere Eigenschaften zu unterdrücken,
oder durch Verkettung geeigneter Selektoren, die eine höhere Priorität besitzen, eine Überschreibung ohne das !important zu ermöglichen.
P.S. Ich sehe außerdem gerade, dass es eine minifizierte xx.min.css Version gibt. Das werde ich demnächst mal daraufhin abändern.
Beat Post author am |
PSG-Card-Design
Ich habe mir das neue Pure-Child-Theme PSG mal etwas genauer angesehen. Wenn ich das richtig verstanden habe, so kann man mit den einzelnen Karten genau zwei Dinge tun:
Habe ich das soweit richtig verstanden?
Hmm...? Super wäre doch, wenn man in einer Karte ein Seitenleisten-Plugin darstellen könnte. Also statt mit Array auf .../comments zu verweisen, gleich die letzten X Kommentare anzeigen, so wie es das Seitenleisten-Plugin kann/macht. So könnte man ein cleanes Blogdesign ganz ohne Seitenleisten zusammenschustern. D.h. die gewünschten Seitenleisten-Plugins wären nur in den Karten der "Landing-Page - Home" sichtbar, würden in der Blogansicht dann jedoch nicht angezeigt. Das würde vermutlich auch die Blogansicht-Seitenladezeit für Mobile-User reduzieren.
Anmerkung: Einerseits finde ich PSG spannend, andererseits schreckt mich die Theme-Kette pure->PSG->pure-beat etwas ab und ich finde bisher noch zuwenig Nutzen in diesem Card-Design. Wenn Du keine Zeit für etwas Beratung/Coaching aufwenden willst, habe ich volles Verständnis dafür. Wenn Du jedoch an Praxis-Erfahrungen interessiert bist, kann ich zu PSG-Card-Design einen eigenen Blogeintrag schreiben, damit wir das dort etwas themengerechter diskutieren können. Die Umsetzung würde ich auf styx.beatsblog.ch versuchen.
Ian Styx am |
Apropos. Hattest du obige Antwort zu lightbox styles schon realisiert?
? ja. Du kannst so eine Karte allerdings auch als Kurzinfo verwenden und nicht verlinken. Oder als immer mal wechselnde Highlight Karten auf bestimmte Artikel (zb solche die immer wieder abgerufen werden) etc.
Nun..., dafür gibt es die geniale Plugin API, bzw die zur Verfügung gestellten Smarty-Funktionen.
Wie du selbst sehen kannst, nutzt die eine (größere) Karte einen solche als
Wie der Funktions-Name verrät, holt diese soundsoviele Eintrage aus den Eintragstabellen.
Lies einmal nach unter: https://ophian.github.io/book/#U963 im Kapitel 9 und toc 9.6.3
und eben da im Weiteren zB. in
{serendipity_showPlugin}(Gibt die Inhalte eines installierten Seitenleisten-Plugins aus. Dies kann unabhängig von der gewohnten Darstellung innerhalb der Seitenleiste erfolgen, so dass ein Seitenleisten-Plugin an beliebiger Stelle in einem Template platziert werden kann.)
Das könnte allerdings etwas tricky werden, da du es ja wahrscheinlich eher in einer Grid Karte der 2. Zeile haben möchtest, die wiederum von einem php array gespeist wird.
Was nun folgt ist Eigenes experimentieren.
Außerdem gibt es noch - da du es explizit als Beispiel erwähnt hast -
{serendipity_printComments}welches analog zum weitaus mächtigeren fetchPrintEntries eben Kommentare ausgibt.(Stellt die Liste aller Kommentare für einen Eintrag dar.)
Vor Theme Verkettungen a la pure->PSG->pure-beat sollte man keine Angst haben, sind sie doch eher geeignet sehr simpel im Letzteren zu werden, da die Richtung ja auch eher <- ist, also was als template file nicht in beat ist, suche in psg und wenn auch dort nicht in pure. Eine rein interne Funktion um Redundanzen zu vermeiden.
Ganz allgemein sind solche Landungsseiten ja nur wie das "Cover "eines Magazines. Ich persönlich habe immer gemerkt, dass mich dieser Firlefanz als Besucher nicht mehr interessiert, wenn ich mehrfach auf eine solche Seite gehe. Letzthin will ich dann immer zum Content, schnell und praktisch. Diese ganzen Wordpress-themes mir ihren ineinandergeschachtelten Hochglanz/-kant Karussells sehen meist nur schick aus. Wirklich nachhaltige Informationen vermitteln sie nur sehr selten - vor allem bei häufigeren Besuchen.
Leider ist man als Websurfer heute viel an soetwas gewöhnt und meint nun, dass das halt modern und angesagt ist. Aber es ist Fassade. Ich bin deshalb immer wieder auf die grundsätzlichen strukturellen Designs zurückgekehrt. Und die sind: Kopf, Inhalt, Seitenleiste(n), Fuß.