20 bis 19 = 1, 19 bis 18 = 2, 18 bis 17 = 3, ...., 06 bis 05 = 15, oder nicht? ?
Aber das 2020 iger Schaltjahr macht uns einen Strich durch die Rechnung, also müsste es ganz ohne Schaltjahrberechnung gehen. Erneuten Versuch, bitte sehr.
Beat Post author am |
Upgedated
Ich will mich ja hier nicht streiten, doch a) gab es im Januar 2005 noch gar keine Blogeinträge, sondern erst im Januar 2006. Und b) wenn ich auf 14 Durchläufe stelle (2020-2006), wird mir 2006 nicht angezeigt. Egal, denn ich habe jetzt sowieso auf 20 gestellt. ? Dann muss ich mich in den nächsten Jahren nicht mehr drum kümmern. ?
Aber um es rauszufinden muss eben der extra loop gemacht werden.. Rufe /archive/ auf und zähle die blöcke vom ersten ab abwärts.
Irgendwie habe ich heute einen Knoten in der Birne - warum nur sind die Älteren immer ein mehr... Vielleicht muss ich die Schaltjahr darin irgendwie herausrechnen. Also ist das noch nicht die finale Version.
Du könntest aber das stable archive wieder wegmachen!
Beat Post author am |
? Natürlich! Es ist immer die Frage, ob man das aktuelle Jahr mitzählt oder nicht. In meiner Excel-Tabelle und in Deinem letzten Kommentar haben wir beide 2020 nicht gezählt, denn mit der aktuellen Aussage ist ja "20 bis 19 = 2" und nicht 1. ?
O.K. Stabile Archive = Nein.
Beat Post author am |
Da bin ich anderer Meinung. Jetzt fehlen die Schaltjahre! Wenn in jedem Schaltjahr 1 Tag mehr zurückgerechnet wird, dann stimmt es. Von aktuell heute, bis 2006 gab es 3 Schaltjahre. Drei Schalttage weiter zurück = 14.01.2006. Ab 29.02.2020 kommt dann erneut ein Schalttag dazu.
In der Theorie müsstest Du pro Jahr 365,25 Tage rechnen und immer abrunden. Dann gibt es nur noch in Schaltjahren einen Fehler, jeweils zwischen dem 01.01. und dem 29.02 (bis der Schalttag effektiv vollzogen wird).
Eröffne eine neue Verschachtelung, damit man wieder mehr Platz hat.
Meine Ansicht, wie man generisch richtig zurückrechnet, habe ich in diesem Kommentar geschrieben: https://www.blog.dokumenzi.ch/2612-Seitenleisten-links-rechts.html#c6206
Damit man nicht scrollen muss, hier als Zitat:
Jetzt fehlen die Schaltjahre! Wenn in jedem Schaltjahr 1 Tag mehr zurückgerechnet wird, dann stimmt es. Von aktuell heute (14.01.2020), bis 2006 gab es 3 Schaltjahre. Drei Schalttage weiter zurück = 14.01.2006. Ab 29.02.2020 kommt dann erneut ein Schalttag dazu.
In der Theorie müsstest Du pro Jahr 365,25 Tage rechnen und immer abrunden. Dann gibt es nur noch in Schaltjahren einen Fehler, jeweils zwischen dem 01.01. und dem 29.02 (bis der Schalttag effektiv vollzogen wird).
Wenn Du es mit einem Loop (also immer gleich) machen willst, musst Du halt immer auf ganze Tage abrunden.
Ich weiss, Dich stört der "eingebaute Fehler", in jedem Schaltjahr, während 59 Tagen. Aber ganz ehrlich: Who cares? Kannst das ja im Infotext der Plugin-Konfiguration erwähnen. Oder das Plugin erst nach dem 29.02.2020 veröffentlichen. ?
Wenn es jemand absolut stört, kann er ja das Plugin z.B. 14x installieren und jeweils die richtige Anzahl an Tagen berechnen (und dann nach dem 29. des Schaltjahres alles nachjustieren). ? Da weiss ich, wovon ich spreche, denn das habe ich im Live-Blog schon 3x gemacht. ?
Hat sich erledigt. Habe den Beitrag im Detail angesehen. Er enthielt die Uhrzeit 00:01. Habe die Zeit nun auf 11:11 Uhr umgespeichert und nun wird der Beitrag angezeigt.
Kannst Dich also (vorerst) entspannen ? Geniesse den Abend!
Beat Post author am |
Bei Deinem nächsten online-Besuch: Guck Dir mal die doofen Intro/Outro-Text-Positionen an. Bei mehrjähriger Anzeige macht das Null Sinn.
Wenn man so etwas machen will, dann Intro vor dem ersten Beitrag und Outro nach dem letzten Beitrag. Dazwischen die Liste (so wie im neu installierten Zufallsbild-Plugin, direkt darunter). So könnte ich mir z.B. folgenden Intro- oder Outro-Text vorstellen. "Bei fehlender Anzeige wurde an diesem Tag kein Blog-Eintrag veröffentlicht."
(oder, man schmeisst die Intro/Outro-Geschichte gleich ganz raus).
Beat Post author am |
? Leider funktioniert das history-Plugin auch in der aktuellen Version nur mit "Stabile Archive" = Ja richtig. Habe aktuell aber wieder Nein eingestellt. Interessant ist, dass ab Seite 2 jeweils nur noch das Intro angezeigt wird... kein Beitrag und kein Outro...
Ja, ich hatte das auch schon gesehen. Es fehlte eine ordentliche Rundung, denn das errechnete Suchmuster muss immer | d-m-y:00:00 - d-m-y:23:59 | sein, Ich musste nur noch eine Mütze voll Schlaf nehmen und einen klaren Kopf bekommen.
Leider funktioniert das history-Plugin auch in der aktuellen Version nur mit "Stabile Archive"
Das stimmt so nicht.... Es ist überall korrekt sichtbar (weenn wir es dann endlich haben), wo sich nicht das aktuelle Datum ändert. Und das ist nur beim entriespaging in der Liste de Fall ‼
Beat Post author am |
Verständnisfrage: Ändert sich das aktuelle Datum (wo, welches), wenn ich von der Index-Seite 1 auf die Seite 2 wechsle? Wie muss ich mir das vorstellen? Und inwiefern ändert sich das, wenn ich mit "Stabile Archive" von Seite 256 auf 255 wechsle?
Natürlich nicht das aktuelle Datum. Ich kann das gerade nicht per Code belegen, aber ich meinte damit, dass sich der start timestamp range und der end timestamp range der entries fetch SQL ändert und in der Zeit herunter schreitet.
Mit der Umdrehung der Liste bei "stable archives" schreitet das jetzt irgendwie anders herum und hat deshalb auch keinen Einfluss auf die history, die ihren content ja aus der gleichen Quelle holt. Und das ist ja offensichtlich.
Wenn du es gerne auch ohne stable archives hättest, müsste man den ersten Aufruf "einfach nur" irgendwie zwischenspeichern und an der Stelle der Berechnung dann "einfach nur" den gespeicherten Content anzeigen, bis irgend jemand einen neuen Cache - weil anderes Datum - erstellt.
Beat Post author am |
Du führst mich jetzt auf's Glatteis... ? "Stabile Archive" JA oder NEIN ist meiner Meinung nach eine Ansichtssache, wo es kein "richtig" oder "falsch" gibt.
Du vertrittst die Sicht des Schreibers (NEIN), der jede neu geschriebene Seite oben auf den Stapel legt und somit ist die neuste Seite immer die Erste/Oberste. Und mit jeder neuen Seite ändert sich die Nummerierung der vorhergehenden Seiten um +1.
Andere vertreten die Sicht des Lesers (JA), der entlang des Zeitstrahls liest. Er beginnt mit dem ältesten Eintrag auf Seite 1 und ist aktuell in diesem Blog mittlerweile auf Seite 256.
Man könnte jetzt sagen: "Der Wurm muss dem Fisch schmecken und nicht dem Angler". -> also hat das Zielpublikum (der Leser) "recht" und deshalb sind stabile Archive vorzuziehen.
Das Einzige, was ich an stabilen Archiven auszusetzen habe, ist die ominöse, zweitletzte Seite. Weil in den Designeinstellungen vorgegeben wird, dass eine "Standardseite" hier z.B. 10 Einträge anzeigt, wird auf der zweitletzten Seite jeweils die Restmenge aller Einträgen : 10 untergebracht. Das hat zur Folge, dass jeder Besucher, der nur schon eine Seite in die Vergangenheit blickt, diese Restmengenseite zu sehen kriegt und sich darauf im schlechtesten Fall nur gerade ein Eintrag befindet. Das finde ich sehr unschön. Würde dieser Ausgleich z.B. auf Seite 10 oder 20 gemacht, so würde ich trotz guter Gegenargumente "Stabile Archive" auf JA setzen.
Aber, so wie es jetzt ist, gefällt mir NEIN besser, denn hier ist die Restmenge immer auf der letzten Seite.
Was mich auf die gestellte Frage zurückkommen lässt: Ja, nach meiner Meinung werden (alle) Seitenleistenplugins auf JEDER Index-Seite angezeigt. Und während dem jemand blättert, ändert sich das Lese-Datum nicht. Also soll das History-Plugin auf jeder Index-Seite immer das Gleiche anzeigen. Es ist auch irgendwie unlogisch, wenn jemand z.B. 5 Index-Seiten (zeitlich) zurückblättert und sich dann einen Beitrag in der Einzelansicht anzeigen lässt, dass er dann wieder ein gefülltes History-Plugin angezeigt kriegt, welches vom aktuellen Lesedatum ausgeht (und nicht vom Datum des Beitrags in der Einzelansicht). Deshalb: JA, es soll immer das Gleiche anzeigen.
Ian Styx am |
20 bis 19 = 1, 19 bis 18 = 2, 18 bis 17 = 3, ...., 06 bis 05 = 15, oder nicht? ?
Aber das 2020 iger Schaltjahr macht uns einen Strich durch die Rechnung, also müsste es ganz ohne Schaltjahrberechnung gehen. Erneuten Versuch, bitte sehr.
Beat Post author am |
Upgedated
Ich will mich ja hier nicht streiten, doch a) gab es im Januar 2005 noch gar keine Blogeinträge, sondern erst im Januar 2006. Und b) wenn ich auf 14 Durchläufe stelle (2020-2006), wird mir 2006 nicht angezeigt. Egal, denn ich habe jetzt sowieso auf 20 gestellt. ? Dann muss ich mich in den nächsten Jahren nicht mehr drum kümmern. ?
Ian Styx am |
Aber um es rauszufinden muss eben der extra loop gemacht werden.. Rufe /archive/ auf und zähle die blöcke vom ersten ab abwärts.
Irgendwie habe ich heute einen Knoten in der Birne - warum nur sind die Älteren immer ein mehr... Vielleicht muss ich die Schaltjahr darin irgendwie herausrechnen. Also ist das noch nicht die finale Version.
Du könntest aber das stable archive wieder wegmachen!
Beat Post author am |
? Natürlich! Es ist immer die Frage, ob man das aktuelle Jahr mitzählt oder nicht. In meiner Excel-Tabelle und in Deinem letzten Kommentar haben wir beide 2020 nicht gezählt, denn mit der aktuellen Aussage ist ja "20 bis 19 = 2" und nicht 1. ?
O.K. Stabile Archive = Nein.
Beat Post author am |
Da bin ich anderer Meinung. Jetzt fehlen die Schaltjahre! Wenn in jedem Schaltjahr 1 Tag mehr zurückgerechnet wird, dann stimmt es. Von aktuell heute, bis 2006 gab es 3 Schaltjahre. Drei Schalttage weiter zurück = 14.01.2006. Ab 29.02.2020 kommt dann erneut ein Schalttag dazu.
In der Theorie müsstest Du pro Jahr 365,25 Tage rechnen und immer abrunden. Dann gibt es nur noch in Schaltjahren einen Fehler, jeweils zwischen dem 01.01. und dem 29.02 (bis der Schalttag effektiv vollzogen wird).
Ian Styx am |
Du verwirrst mich! Das habe ich doch gerade gesagt, oder?!
Neuer Versuch online...
Beat Post author am |
Ich sag jetzt nichts...
(Du verfolgst den falschen Ansatz)
Ian Styx am |
Ich sags ja ich habe heute nen Knotem im Hirn..!
Mache es doch selbst, du vorlauter Schweizer! ?
Wie gehts richtig?
Beat Post author am |
Eröffne eine neue Verschachtelung, damit man wieder mehr Platz hat.
Meine Ansicht, wie man generisch richtig zurückrechnet, habe ich in diesem Kommentar geschrieben: https://www.blog.dokumenzi.ch/2612-Seitenleisten-links-rechts.html#c6206
Damit man nicht scrollen muss, hier als Zitat:
Wenn Du es mit einem Loop (also immer gleich) machen willst, musst Du halt immer auf ganze Tage abrunden.
Ich weiss, Dich stört der "eingebaute Fehler", in jedem Schaltjahr, während 59 Tagen. Aber ganz ehrlich: Who cares? Kannst das ja im Infotext der Plugin-Konfiguration erwähnen. Oder das Plugin erst nach dem 29.02.2020 veröffentlichen. ?
Wenn es jemand absolut stört, kann er ja das Plugin z.B. 14x installieren und jeweils die richtige Anzahl an Tagen berechnen (und dann nach dem 29. des Schaltjahres alles nachjustieren). ? Da weiss ich, wovon ich spreche, denn das habe ich im Live-Blog schon 3x gemacht. ?
Ian Styx am |
Tüftel tüftel, .... jetzt bin ich gespannt.
Hurtig Hurtig!
Beat Post author am |
? ?
War noch am essen, deshalb hat es etwas länger gedauert. Das sieht jetzt aber richtig gut aus! Gratuliere!
Beat Post author am |
...und schon geht das Gemecker wieder los: Was ist mit 2017, /2275-Packliste.html ?
Ian Styx am |
HELP!! I need a break! ?
Beat Post author am |
Hat sich erledigt. Habe den Beitrag im Detail angesehen. Er enthielt die Uhrzeit 00:01. Habe die Zeit nun auf 11:11 Uhr umgespeichert und nun wird der Beitrag angezeigt.
Kannst Dich also (vorerst) entspannen ? Geniesse den Abend!
Beat Post author am |
Bei Deinem nächsten online-Besuch: Guck Dir mal die doofen Intro/Outro-Text-Positionen an. Bei mehrjähriger Anzeige macht das Null Sinn.
Wenn man so etwas machen will, dann Intro vor dem ersten Beitrag und Outro nach dem letzten Beitrag. Dazwischen die Liste (so wie im neu installierten Zufallsbild-Plugin, direkt darunter). So könnte ich mir z.B. folgenden Intro- oder Outro-Text vorstellen. "Bei fehlender Anzeige wurde an diesem Tag kein Blog-Eintrag veröffentlicht."
(oder, man schmeisst die Intro/Outro-Geschichte gleich ganz raus).
Beat Post author am |
? Leider funktioniert das history-Plugin auch in der aktuellen Version nur mit "Stabile Archive" = Ja richtig. Habe aktuell aber wieder Nein eingestellt. Interessant ist, dass ab Seite 2 jeweils nur noch das Intro angezeigt wird... kein Beitrag und kein Outro...
Bin am Mittwoch erst ab ca. 13:30 Uhr online.
Ian Styx am |
Ja, ich hatte das auch schon gesehen. Es fehlte eine ordentliche Rundung, denn das errechnete Suchmuster muss immer | d-m-y:00:00 - d-m-y:23:59 | sein, Ich musste nur noch eine Mütze voll Schlaf nehmen und einen klaren Kopf bekommen.
Letzten Stand soeben commitet.
Ian Styx am |
Gerade gefixt.
Einziger Nachteil soweit: Sie werden aber auch angezeigt wenn keinerlei entries vorliegen.
Beat Post author am |
? PERFEKT! ?
Ian Styx am |
Das stimmt so nicht.... Es ist überall korrekt sichtbar (weenn wir es dann endlich haben), wo sich nicht das aktuelle Datum ändert. Und das ist nur beim entriespaging in der Liste de Fall ‼
Beat Post author am |
Verständnisfrage: Ändert sich das aktuelle Datum (wo, welches), wenn ich von der Index-Seite 1 auf die Seite 2 wechsle? Wie muss ich mir das vorstellen? Und inwiefern ändert sich das, wenn ich mit "Stabile Archive" von Seite 256 auf 255 wechsle?
Ian Styx am |
Natürlich nicht das aktuelle Datum. Ich kann das gerade nicht per Code belegen, aber ich meinte damit, dass sich der start timestamp range und der end timestamp range der entries fetch SQL ändert und in der Zeit herunter schreitet.
Mit der Umdrehung der Liste bei "stable archives" schreitet das jetzt irgendwie anders herum und hat deshalb auch keinen Einfluss auf die history, die ihren content ja aus der gleichen Quelle holt. Und das ist ja offensichtlich.
Wenn du es gerne auch ohne stable archives hättest, müsste man den ersten Aufruf "einfach nur" irgendwie zwischenspeichern und an der Stelle der Berechnung dann "einfach nur" den gespeicherten Content anzeigen, bis irgend jemand einen neuen Cache - weil anderes Datum - erstellt.
Beat Post author am |
Du führst mich jetzt auf's Glatteis... ? "Stabile Archive" JA oder NEIN ist meiner Meinung nach eine Ansichtssache, wo es kein "richtig" oder "falsch" gibt.
Du vertrittst die Sicht des Schreibers (NEIN), der jede neu geschriebene Seite oben auf den Stapel legt und somit ist die neuste Seite immer die Erste/Oberste. Und mit jeder neuen Seite ändert sich die Nummerierung der vorhergehenden Seiten um +1.
Andere vertreten die Sicht des Lesers (JA), der entlang des Zeitstrahls liest. Er beginnt mit dem ältesten Eintrag auf Seite 1 und ist aktuell in diesem Blog mittlerweile auf Seite 256.
Man könnte jetzt sagen: "Der Wurm muss dem Fisch schmecken und nicht dem Angler". -> also hat das Zielpublikum (der Leser) "recht" und deshalb sind stabile Archive vorzuziehen.
Das Einzige, was ich an stabilen Archiven auszusetzen habe, ist die ominöse, zweitletzte Seite. Weil in den Designeinstellungen vorgegeben wird, dass eine "Standardseite" hier z.B. 10 Einträge anzeigt, wird auf der zweitletzten Seite jeweils die Restmenge aller Einträgen : 10 untergebracht. Das hat zur Folge, dass jeder Besucher, der nur schon eine Seite in die Vergangenheit blickt, diese Restmengenseite zu sehen kriegt und sich darauf im schlechtesten Fall nur gerade ein Eintrag befindet. Das finde ich sehr unschön. Würde dieser Ausgleich z.B. auf Seite 10 oder 20 gemacht, so würde ich trotz guter Gegenargumente "Stabile Archive" auf JA setzen.
Aber, so wie es jetzt ist, gefällt mir NEIN besser, denn hier ist die Restmenge immer auf der letzten Seite.
Was mich auf die gestellte Frage zurückkommen lässt: Ja, nach meiner Meinung werden (alle) Seitenleistenplugins auf JEDER Index-Seite angezeigt. Und während dem jemand blättert, ändert sich das Lese-Datum nicht. Also soll das History-Plugin auf jeder Index-Seite immer das Gleiche anzeigen. Es ist auch irgendwie unlogisch, wenn jemand z.B. 5 Index-Seiten (zeitlich) zurückblättert und sich dann einen Beitrag in der Einzelansicht anzeigen lässt, dass er dann wieder ein gefülltes History-Plugin angezeigt kriegt, welches vom aktuellen Lesedatum ausgeht (und nicht vom Datum des Beitrags in der Einzelansicht). Deshalb: JA, es soll immer das Gleiche anzeigen.
Ian Styx am |
Na dann darfst du es jetzt nochmal ausprobieren... ☺