Also halten wir fest. Es ging hier noch nie. Stimmt das?
Also kannst du auch wieder 2 Seitenleisten verwenden, wenn du willst.
Jetzt muss nur noch geklärt ob es blog/alles Kategorieverwendung ist oder nicht. Ich würde jetzt, nachden du mit frontpage und selbigem Ergebnis getestest hast, sagen es müsste sogar noch etwas anderes sein.
Im Unterschied zu BB ist hier das normale entrypaging aktiv. Was passiert wenn du es umstellst?
Vielleicht ist es auch eine Frage der Reihenfolge der Seitenleisten Plugins???
Beat Post author am |
Im Unterschied zu BB ist hier das normale entrypaging aktiv. Was passiert wenn du es umstellst?
Ob mit der identischen Konfiguration wie auf bbbeat.ch und auch bei Deaktivierung des entrypaging-Plugins -> keine Veränderung.
Vielleicht ist es auch eine Frage der Reihenfolge der Seitenleisten Plugins???
Die Reihenfolge der Plugins ist bis auf die unterschiedlichen Plugins identisch.
? Es liegt an der Einstellung "Stabile Archive" = Nein. DAS ist der Unterschied zu www.bbbeat.ch. Habe jetzt hier auch auf "Stabile Archive" = Ja umgestellt und siehe da: Die history-Plugin-Anzeigen sind auf allen Seiten gleich. Schade, denn eigentlich wollte ich davon abkommen und mit "Stabile Archive" stimmt nun meine Anzeige in der Fusszeile der Index-Seite auch nicht mehr...
Habe soeben auf www.bbbeat.ch "Stablie Archive" zu Testzwecken auf Nein gesetzt und auch dort verlieren sich die history-Plugin-Einträge von Seite zu Seite und ab Seite 4 sind dann gar keine mehr da. Also das gleiche Phämonen wie hier.
Unschön an "Stabile Archive" = Ja ist einfach, dass die zweite Anzeigeseite immer zwischen 1 und 10 Beiträge anzeigt, da hier der Ausgleich zu den stabilen Restseiten geschieht. Bei nur 1, 2 oder 3 Beiträgen sieht das ziemlich blöd aus.
Habe den BLOG-Menü-Link wieder auf /categories/BLOG gesetzt. Das hat keinen Einfluss.
Es liegt an der Einstellung "Stabile Archive" = Nein. DAS ist der Unterschied zu www.bbbeat.ch.
Ja das meinte ich mit "normales entrypaging".
Ich werde mich mal mit dem history Plugin beschäftigen. Das ist ja so kein Zustand. Denn stable archive war ja nie an und führte über mehr als eine lange Zeit ein (eher experimentelles) Nischendasein.
Hast du, als du diese Tage zum zurückrechnen der Jahre entwickelt hast, das vor dem stable archiv switch gemacht, also im alten Zustand, oder unter Verwendung von stable yes?
Kannst du bitte mal das ">" über dem ersten Bild dieses Eintrags wegmachen. Das hat da nix zu suchen und stört mich! Im Quelltext ist als entity & g t ; ausgezeichnet.
Ich hätte meine Fragen zwar noch gerne beantwortet, aber denke inzwischen, dass das history Plugin nie dafür entwickelt wurde unabhängig vom entries paging, also auf jeder Folgeseite zu funktionieren. Es war als eine 1 Seiten Information konzipiert, als flüchtiges Gimmick. Nach dem Motto: Ich komme als User auf einen Blog und sehe die letzten X Einträge per Liste also "frontpage". Dem Admin sei Dank, bekomme ich noch als ein lustiges Gimmick obendrauf, zu sehen, was dieser vor einem voraus berechneten Zeitraum bereits geschrieben hat.
Das peppt das entriespaging etwas auf. In gewisser Weise durchaus ähnlich dem, was der Kalender oder auch die Suche macht, eine bereitgestellte Zusatzsortierung anhand bestimmter Kriterien. Es macht gar keinen wirklichen Sinn diese Information erneut abzurufen, wenn ich jetzt durch alle "276" Seiten eines Blogs blättere. Immerhin ist das ja auch zusätzliche Arbeit für das System.
Dass das nun mit "stable Archive" plötzlich funktioniert, ist eher eine Art von Regression, da "stable archive" ja meint, der letzte - also aktuellste - Artikel müsse nicht oben in der Liste erscheinen sondern unten und deshalb die Liste einfach umdreht. (Die dafür damals genannten Gründe habe ich schon entkräftet, siehe andere Kommentare zu diesem Thema.)
Mich persönlich hat das schon immer irgendwie gestört, denn es negiert sozusagen das normale menschliche Verhalten, wie ich schon einmal schrieb. Normal ist es, dass ich etwas befülle und deshalb alles Neuere immer obenauf liegt. Das macht die Erfahrung der Geologie nicht anders. Natürlich drückt es das damit älter Werdende im weiter Stück für Stück nach unten. Wenn man es aber als ein Buch betrachtet, so steht das zuletzt Geschriebene natürlich hinten und Seite 1 wäre das historisch Älteste. Deshalb auch klappt dein Vergangenheitsblick mit dem history Plugin auch mit "stable archiv" stabil bis zum Ende des Seitenpagings, nein so gesehen eher "Anfang". ?
Dazu kommt die merkwürdige Anwendung von vorherige und nächste Seite. Ich will nicht links in die Vergangenheit, wenn ich vorherige Seite sehe. Das ist für mich die Seite auf der ich vorher war. Also, wie bereits erklärt, eigentlich die zuletzt/zuvor erstellte/gesehene Seite. Mit der nächsten Seite (rechts) will ich mich also tiefer eingraben, in die Vergangenheit. Das ist für mich die natürliche Ordnung!
Ich glaube diese "Gleichwertigkkeit" und damit auch verqueren Vernudelung im Hirn wurde leider von diesem schrecklichen Wordpress Paging ins Leben und unters Volk gebracht! Ich kann und will mich nicht daran gewöhnen!
Ich habe das history Plugin mal mit einer Option für Zeitraum 1 Jahr über mehrere Jahre aufgebohrt.
Vielleicht kannst du das mal testen.
Beat Post author am |
Adler?
Beat Post author am |
Habe im erweiterten Beitrag ein Bild der Excel-Tabelle eingefügt, wo Du sehen kannst, wie ich die Zeiträume der einzelnen Plugins errechnet habe. Dies habe ich am 08.01. gemacht und damals war "Stabile Archive" = Nein.
Habe erst gestern, als ich die Ursache des Plugin-Fehlers herausgefunden habe die "Stabile Archive" auf Ja gesetzt.
Beat Post author am |
Mache ich gerne. Aber ich brauche wohl noch etwas Hilfe. Wenn ich nun auf Plugins klicke, erhalte ich folgende Fehlermeldung:
Parse error: syntax error, unexpected ')' in /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/plugins/serendipity_plugin_history/serendipity_plugin_history.php on line 159
Ich spiele jetzt wieder das alte Plugin ein, deaktiviere alle 14 "alten" History-Plugins, ersetzte dann die Plugin-Daten und versuche ein History-Plugin neu zu installieren.
Und ich habe es in jetzt so einigermaßen in pure und dude gefixt.
Hast du das dann an Bord, solltest du deins in der user.css wieder herausnehmen.
Beat Post author am |
? wie muss ich das denn konfigurieren?
Setzen Sie die Anzahl der Jahre, die durchlaufen werden sollen, wenn Sie die "Heute vor einem Jahr" als Zeitrahmen ausgewählt haben. Standard ist 1. Setzen Sie dafür die folgenden "Mindestalter" und "Höchstalter" Einträge auf exakt 365 Tage.
Habe "Anzahl der durchlaufenden Jahre " auf 14 eingestellt. Trotzdem zeigt es mir nur den 365. Tag. Das ändert sich auch nicht, wenn ich beim Höchstalter z.B. 10'000 eingebe.
Ja habe gerade noch 2 neue Versuche nachgeschoben.
Allerdings ist das mit dem dreizehnten irgendwie komisch... während das mit 15 stimmt, denn wir sind in 2020.
Beat Post author am |
O.K. Eingespielt.
Ich muss nicht alles verstehen, doch von 2006 bis 2020 errechne ich 14 Jahre. Weshalb braucht es dann 15 Durchläufe? Nein. Egal. Die Lösung ist ja wirklich simpel - also keine Rede wert.
Beat Post author am |
Wie im Kommentar darüber geschrieben, hat sich dieses Problem für mich erledigt. Werde
verwenden.
Ian Styx am |
Also halten wir fest. Es ging hier noch nie. Stimmt das?
Also kannst du auch wieder 2 Seitenleisten verwenden, wenn du willst.
Jetzt muss nur noch geklärt ob es blog/alles Kategorieverwendung ist oder nicht. Ich würde jetzt, nachden du mit frontpage und selbigem Ergebnis getestest hast, sagen es müsste sogar noch etwas anderes sein.
Im Unterschied zu BB ist hier das normale entrypaging aktiv. Was passiert wenn du es umstellst?
Vielleicht ist es auch eine Frage der Reihenfolge der Seitenleisten Plugins???
Beat Post author am |
Ob mit der identischen Konfiguration wie auf bbbeat.ch und auch bei Deaktivierung des entrypaging-Plugins -> keine Veränderung.
Die Reihenfolge der Plugins ist bis auf die unterschiedlichen Plugins identisch.
www.bolg.dokumenzi.ch = 21 Event-Plugins = + ckeditor + changelog + modemaintain
www.bbbeat.ch = 19 Event-Plugins = + serendipity_event_google_sitemap
Beat Post author am |
? Es liegt an der Einstellung "Stabile Archive" = Nein. DAS ist der Unterschied zu www.bbbeat.ch. Habe jetzt hier auch auf "Stabile Archive" = Ja umgestellt und siehe da: Die history-Plugin-Anzeigen sind auf allen Seiten gleich. Schade, denn eigentlich wollte ich davon abkommen und mit "Stabile Archive" stimmt nun meine Anzeige in der Fusszeile der Index-Seite auch nicht mehr...
Habe soeben auf www.bbbeat.ch "Stablie Archive" zu Testzwecken auf Nein gesetzt und auch dort verlieren sich die history-Plugin-Einträge von Seite zu Seite und ab Seite 4 sind dann gar keine mehr da. Also das gleiche Phämonen wie hier.
Unschön an "Stabile Archive" = Ja ist einfach, dass die zweite Anzeigeseite immer zwischen 1 und 10 Beiträge anzeigt, da hier der Ausgleich zu den stabilen Restseiten geschieht. Bei nur 1, 2 oder 3 Beiträgen sieht das ziemlich blöd aus.
Habe den BLOG-Menü-Link wieder auf /categories/BLOG gesetzt. Das hat keinen Einfluss.
Ian Styx am |
Ja das meinte ich mit "normales entrypaging".
Ich werde mich mal mit dem history Plugin beschäftigen. Das ist ja so kein Zustand. Denn stable archive war ja nie an und führte über mehr als eine lange Zeit ein (eher experimentelles) Nischendasein.
Hast du, als du diese Tage zum zurückrechnen der Jahre entwickelt hast, das vor dem stable archiv switch gemacht, also im alten Zustand, oder unter Verwendung von stable yes?
Ian Styx am |
Kannst du bitte mal das ">" über dem ersten Bild dieses Eintrags wegmachen. Das hat da nix zu suchen und stört mich! Im Quelltext ist als entity & g t ; ausgezeichnet.
Ian Styx am |
Ich hätte meine Fragen zwar noch gerne beantwortet, aber denke inzwischen, dass das history Plugin nie dafür entwickelt wurde unabhängig vom entries paging, also auf jeder Folgeseite zu funktionieren. Es war als eine 1 Seiten Information konzipiert, als flüchtiges Gimmick. Nach dem Motto: Ich komme als User auf einen Blog und sehe die letzten X Einträge per Liste also "frontpage". Dem Admin sei Dank, bekomme ich noch als ein lustiges Gimmick obendrauf, zu sehen, was dieser vor einem voraus berechneten Zeitraum bereits geschrieben hat.
Das peppt das entriespaging etwas auf. In gewisser Weise durchaus ähnlich dem, was der Kalender oder auch die Suche macht, eine bereitgestellte Zusatzsortierung anhand bestimmter Kriterien. Es macht gar keinen wirklichen Sinn diese Information erneut abzurufen, wenn ich jetzt durch alle "276" Seiten eines Blogs blättere. Immerhin ist das ja auch zusätzliche Arbeit für das System.
Dass das nun mit "stable Archive" plötzlich funktioniert, ist eher eine Art von Regression, da "stable archive" ja meint, der letzte - also aktuellste - Artikel müsse nicht oben in der Liste erscheinen sondern unten und deshalb die Liste einfach umdreht. (Die dafür damals genannten Gründe habe ich schon entkräftet, siehe andere Kommentare zu diesem Thema.)
Mich persönlich hat das schon immer irgendwie gestört, denn es negiert sozusagen das normale menschliche Verhalten, wie ich schon einmal schrieb. Normal ist es, dass ich etwas befülle und deshalb alles Neuere immer obenauf liegt. Das macht die Erfahrung der Geologie nicht anders. Natürlich drückt es das damit älter Werdende im weiter Stück für Stück nach unten. Wenn man es aber als ein Buch betrachtet, so steht das zuletzt Geschriebene natürlich hinten und Seite 1 wäre das historisch Älteste. Deshalb auch klappt dein Vergangenheitsblick mit dem history Plugin auch mit "stable archiv" stabil bis zum Ende des Seitenpagings, nein so gesehen eher "Anfang". ?
Dazu kommt die merkwürdige Anwendung von vorherige und nächste Seite. Ich will nicht links in die Vergangenheit, wenn ich vorherige Seite sehe. Das ist für mich die Seite auf der ich vorher war. Also, wie bereits erklärt, eigentlich die zuletzt/zuvor erstellte/gesehene Seite. Mit der nächsten Seite (rechts) will ich mich also tiefer eingraben, in die Vergangenheit. Das ist für mich die natürliche Ordnung!
Ich glaube diese "Gleichwertigkkeit" und damit auch verqueren Vernudelung im Hirn wurde leider von diesem schrecklichen Wordpress Paging ins Leben und unters Volk gebracht! Ich kann und will mich nicht daran gewöhnen!
Ian Styx am |
Ich habe das history Plugin mal mit einer Option für Zeitraum 1 Jahr über mehrere Jahre aufgebohrt.
Vielleicht kannst du das mal testen.
Beat Post author am |
Adler?
Beat Post author am |
Habe im erweiterten Beitrag ein Bild der Excel-Tabelle eingefügt, wo Du sehen kannst, wie ich die Zeiträume der einzelnen Plugins errechnet habe. Dies habe ich am 08.01. gemacht und damals war "Stabile Archive" = Nein.
Habe erst gestern, als ich die Ursache des Plugin-Fehlers herausgefunden habe die "Stabile Archive" auf Ja gesetzt.
Beat Post author am |
Mache ich gerne. Aber ich brauche wohl noch etwas Hilfe. Wenn ich nun auf Plugins klicke, erhalte ich folgende Fehlermeldung:
Ich spiele jetzt wieder das alte Plugin ein, deaktiviere alle 14 "alten" History-Plugins, ersetzte dann die Plugin-Daten und versuche ein History-Plugin neu zu installieren.
Ian Styx am |
Und, um es gleich zu sagen, sie sind falsch! Denn du hast die Rechnung ohne den Wirt gemacht.
Schaltjahre werden automatisch berechnet, also sind es immer 365 mal X.
Ian Styx am |
Beat Post author am |
Ja (d.h. ich habe die vier geänderten Files im bestehenden Plugin überschrieben).
Ian Styx am |
Ops... Sorrry! Mein Fehler.
Gerade korrigiert.
Ian Styx am |
Und ich habe es in jetzt so einigermaßen in pure und dude gefixt.
Hast du das dann an Bord, solltest du deins in der user.css wieder herausnehmen.
Beat Post author am |
? wie muss ich das denn konfigurieren?
Habe "Anzahl der durchlaufenden Jahre " auf 14 eingestellt. Trotzdem zeigt es mir nur den 365. Tag. Das ändert sich auch nicht, wenn ich beim Höchstalter z.B. 10'000 eingebe.
Beat Post author am |
Du meinst: width: auto!important; ?
Ian Styx am |
ja
Ian Styx am |
Dachte ich zumindest... aber irgendwie ist da noch der Wurm drinnen. Ich arbeite dran.
Musste erstmal ein wunderbares Bürli verspeisen. Yammmi! ?
Ian Styx am |
Bitte erneuter Versuch. Es muss wahrscheinlich einfach nur das return im year loop weg.
Ansonsten bräuchte ich testdata...
Beat Post author am |
Sieht schon viel besser aus. ? Nur das mit den Schaltjahren scheint doch nicht so automatisch... und heute ist der 14.01. und nicht der 13.
Ich musste zudem 15 Jahre/Durchläufe definieren um den ältesten Beitrag (vor 14 Jahren) zu sehen.
Ian Styx am |
Ja habe gerade noch 2 neue Versuche nachgeschoben.
Allerdings ist das mit dem dreizehnten irgendwie komisch... während das mit 15 stimmt, denn wir sind in 2020.
Beat Post author am |
O.K. Eingespielt.
Ich muss nicht alles verstehen, doch von 2006 bis 2020 errechne ich 14 Jahre. Weshalb braucht es dann 15 Durchläufe? Nein. Egal. Die Lösung ist ja wirklich simpel - also keine Rede wert.