Interessanterweise gab es vor 02:00 Uhr aber bereits Dutzende von Zugriffen. Ist das Plugin denn so konfiguriert, dass es erst ab 02:00 Uhr neu geschrieben wird? (hier wurde es um 02:49:54 Uhr neu generiert).
Ich stehe geade auf dem Schlauch... woher genau hast du diesen Logauszug?
Wenn das als Auslöser stimmt, war dies also so eine Art "Suche" nach entries über https://www.beatsblog.ch/plugin/tag/corona-virusnach dem tag xx über freetag. Der vorherige von dir genannte, eine entries list pagination Seite. Lass uns also weiter sammeln, bis wir darin eine relative Häufung bestimmter Art (oder des Ausschlusses) erkennen können (unter der Annahme natürlich, dass du jeweils die richtigen Auslöser gefunden hast).
Und warum zeigt er mit 02:03:17 +0200 eine andere Uhrzeit als 02:49:54 Uhr (und woher kommt dieser Zeitstempel?) ?
Ist das Plugin denn so konfiguriert, dass es erst ab 02:00 Uhr neu geschrieben wird?
Nicht das ich wüßte. Warum auch...!? Die Frage ist ja eher, ob diese merkwürdige Übereinstimmung eventuell etwas mit dem anderen Phänomen zu tun hat.
Beat Post author am |
Das history-daylist.dat von www.beatsblog.ch wurde um 02:03:17 geschrieben (leer). Danach suchte ich im Serverlogfile den zeitlich passenden Zugriff und habe diesen im Kommentar erwähnt.
Die im letzten Satz genannte Uhrzeit ist die des history-daylist.dat von hier (blog.dokumenzi.ch), welches richtig/voll geschrieben wurde.
Beide Files wurden nach 02:00 Uhr geschrieben, obwohl es auf beiden Servern auch schon Zugriffe zwischen 00:00 und 02:00 Uhr gab.
Ob diese 2 Std. irgendetwas mit den Archiv-2-Std. zu tun haben entzieht sich meiner Kenntnis. Kann purer Zufall sein. Könnte aber auch sein, dass "Serendipity-intern" generell mit GMT operiert und nicht mit Server+OffsetTime. Aber obacht: Das ist eine plumpe Spekulation. Ich weiss noch nichtmal, ob es überhaupt so etwas wie eine "interne Serendipity-Zeitrechnung" gibt...
1. Über die serendipity_db_time mit beigefügtem offset für die Startzeit bin ich mir gar nicht mehr so sicher. Wir sollten das bei dir auf alle Fälle nochmal gegenchecken!
2. Abgesehen davon, dass du den November mit dem test entry irgendwie korrigiert hast, sind es jetzt im direkten Vergleich nur noch 3 Unterschiede zu meiner Testinstallation (ich habe alle ausgegebenen Summen seit Feburar 20 miteinander verglichen).
2013/10 mit sum 13 Anzeige 12
2011/06 mit sum 30 Anzeige 31 (genau gegenteilig!)
2011/05 mit sum 18 Anzeige 17.
Gibt es dazu also noch andere Anzeigenunterschiede?
Haben diese 3 irgendetwas Spezielles, was ansonsten überhaupt nicht mehr vorkommt?
Sollte es sich also eventuell nicht um einen generellen bug handeln, so müssten diese, und dabei ist der zweite, bei dem es ja genau umgekehrt ist, vielleicht bedeutsam(?), etwas Besonderes haben.
Im Grunde bräuchten wir eine generelle SELECT Liste aller in den 3 Monaten genannten IDs (inklusive der dazwischenliegenden IDs, die einem anderen Monat zugeordnet sind) mit allen eventuell relevanten Feldern.
Hier mal als Beispiel für den Oktober+November'13
SELECT id, title,timestamp, DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%Y-%m-%d %H:%m' ) AS date, authorid, isdraft, last_modified, DATE_FORMAT( FROM_UNIXTIME( last_modified ) , '%Y-%m-%d %H:%m' ) AS lmdate FROM styx_entries WHERE id BETWEEN 2041 AND 2055 OR id BETWEEN 2056 AND 2063
Beat Post author am |
Ich wage (ohne irgendwelche Test's) folgende Behauptung:
Es gibt einen Blogeintrag mit Timestamp 01.06.2011, zwischen 00:00 und 01:59 Uhr. Dieser fehlt im Monat 5 (deshalb werden 17 angezeigt und 18 gezählt). Dieser wird im Monat 6 angezeigt, aber nicht gezählt. Dies, weil jeweils vom 01. des Monats ab 02:00 Uhr bis zum 01. des Folgemonats, ebenfalls um 02:00 Uhr, gezählt wird.
Ich werde das jetzt aber verifizieren. ?
Nachtrag: Es handelt sich um folgenden Beitrag: /2276-Italien-Radreise-2011.html (TimeStamp: 01.06.2011 00:01). Dieser wird im Mai mitgezählt aber nicht dargestellt und im Juni ist es umgekehrt.
Nur kurz: Ich habe den SELECT gerade erweitert, so dass man chainen kann, als Beispiel 2013 10+11 entries. Man müsste das jetzt nur noch für die 2011er Monate ergänzen. Falls es nicht ganz passt, durch dazwischenliegende entries eines anderen Monats, muss man die Ids jeweils +2 oder -2 oder so ergänzen.
Beat Post author am |
? Guck mal in den gemeinsamen Artikel.
Wenn Du mehr Info/Abfragen willst, musst Du dies idiotensicher ausdrücken. ?
Und um dies klarzustellen: Die Abfragen machte ich auf der DB von www.beatsblog.ch (und nicht hier).
Ist die Betreffungs von hier und auf Beat genau gleich, bezüglich sums und Ausgaben? Also bezüglich der auftretenden Fehler?
Beat Post author am |
Neue SQL-Abfrage-Ergebnisse im gemeinsamen Beitrag.
Ist die Betreffungs von hier und auf Beat genau gleich, bezüglich sums und Ausgaben? Also bezüglich der auftretenden Fehler?
Davon gehe ich aus. Wegen der Archiv-Zählfehler habe ich immer (nur) auf www.beatsblog.ch nachgesehen.
Nachtrag: Sehe gerade, dass hier noch der Kategorie-Zählfehler drin ist. Die Archivzählung ist hier (blog.dokumenzi.ch) also noch falscher als auf www.beatsblog.ch
Ich meine die timestamps der DB sind UTC, was in unserem Fall gleich GMT ist. Das ist ja auch wichtig, damit es da etwas Universelles gibt. Die Umrechnung erfolgt dann durch die die lokalen und persönlichen Gegebenheiten.
wie was...? ?
Und auch noch eine Frage im Artikel.
Beat Post author am |
wie was...? ?
Das Archiv hier zählt für den Dezember 2019 51 Beiträge. Es sind aber nur deren 27. Das liegt an der Mehrfachzählung pro Kategorie. Diesen Fehler haben wir auf www.beatsblog.ch behoben. Jedoch nicht hier. Alles gut. Hier wurden im Dezember 2019 viel mehr Beiträge geschrieben. Die Zahl 51 stimmt schon. Entschuldige die Verwirrung. Soweit alles gut und soweit (möglich) vergleichbar mit www.beatsblog.ch.
Und auch noch eine Frage im Artikel. Und wenn du diese nun durchsiehst, fällt dir da irgendetwas Besonderes / Bemerkenswertes auf?
Du überforderst mich. Für mich ist das einfach eine Liste, mit den Beiträgen von zwei Monaten. Und? Was sollte mir denn auffallen?❓ Du müsstest da schon spezifischer werden.
Beat Post author am |
Bemerkenswert wäre vielleicht, dass ich sehr viele Beiträge im Dezember 2017 und im November 2019 editiert habe. Das war die Zeit, in der ich (alle) Erweiterten Beiträge abgeschafft habe und den Text nach oben in den Startbeitrag verschoben habe.
Den Artikel /2276-Italien-Radreise-2011.html habe ich wirklich erst viel später geschrieben und zurückdatiert. Er ist eine Art Einleitungsbeitrag der Kategorie "Tour 2011" und gehört deshalb zeitlich vor den ersten Beitrag dieser Kategorie.
Sonst fällt mir wirklich nichts auf.
(Bei mir ist es durchaus üblich, dass ich Beiträge zu einem späteren Zeitpunkt noch einmal editiere. Meist korrigiere ich Rechtschreibfehler. Das kann auch Jahre später sein).
Das nachträgliche editieren oder auch zurückstufen von Einträgen soll ja auch ohne weiteres möglich sein.
Ich suche immer noch... nach dem Offset Kasus...
Für die UTC/GMT Aussage muss ich natürlich ergänzen, dass dies natürlich nur gilt, wenn keine Server Zeitzone definiert ist (die natürlich ebenso gesetzt sein kann). Also ist immer die Server Zeitzone als timestamp genommen, ansonsten eben UTC/GMT.
Dabei fand ich .. dass das entryproperties Plugin schon wieder ziemlich weit nach oben verschoben war. Das muss immer zuunterst (oder zumindest immer unter allen Plugins stehen, die in das backend entryform hineinhooken) stehen. Ich habe das korrigiert.
Ein weiteres war, dass du "Automatische Speicherung aktivieren" in den Persönlichen Einstellungen auf AN gestellt hast. Ich finde das furchtbar irritierend. Gerade zum Beispiel auch, wenn du auf "Neuen Eintrag" gehst und irgend einen anderen zuletzt bearbeiteten Eintrag, den du da im Cache hast, angezeigt vorgesetzt bekommst, inklusive aller Einstellungen der hooks. Ich empfehle das DING abzuschalten! Es ist zwar gegenüber ganz früher verbessert, aber taugt nicht um die Dinge klar zu halten. Sicher kann es unter Umständen mal helfen einen langen Text nicht im Nirwana verschwinden zu lassen, aber das kommt so selten vor, das die Verwirrung die das Ding anstiftet weit schwerer wiegt. So kann man wirklich lange Texte, an denen man online lange sitzt, ja als Draft bearbeiten und immer wieder mal abspeichern etc., oder für den Grobrahmen sowieso ganz anderswo konzipieren. Mir persönlich ist das vor gefühlten 10 Jahren++ zuletzt passiert. Aber da war Serendipity eben auch noch etwas anderes. Es hat ja zB auch mit dem Login zu tun. Solche "Abbrüche" können ja eventuell geschehen, wenn die Login Session abläuft. Hat man aber sowieso "Login Merken" an, so ist auch an dieser Front relative Ruhe.
Jetzt machst du natürlich mit dem Gesagten was du beliebst und was sich nach deinen eigenen Erfahrungen richtet. ?
Wenn du bereit und online für ein wenig weiteres debugging bist, sag LOS.
Beat Post author am |
Bin jetzt online, muss jedoch um 14:30 Uhr wieder weg.
Beat Post author am |
Betreffend der Serverzeit: Aktuell ist ja hier, wie auch auf www.beatsblog.ch, die Serverzeit = GMT. In der Konfiguration habe ich jedoch:
Basiert die Zeitdifferenz auf der Server-Zeitzone? = Ja
Zeitunterschied des Servers = 2
Würde es irgendetwas ändern, wenn ersteres auf "Nein" stelle? Ein kurzer Test auf www.beatsblog.ch zeigte, dass sich kein erkennbarer Unterschied daraus ergibt (was ja zu erwarten war). Ich frage mich halt, weshal ich "Ja" wählen soll, wenn die Server eh auf GMT eingestellt sind.
Sind sie ja nicht (alle). Es macht ja keinen Sinn seinen eigenen Server, ob nun lokal oder remote, zB auf eine andere Zeitzone zu setzen als jene, in der man selber darinnen ist. Ich kenne (auch) Manitu Server, die sind auf JA und 0 und sind trotzdem meine aktuelle lokale Uhrzeit (in der info der Differenzoption).
Zum weiteren Testen würde ich jetzt auch nichts ändern, also bitte auf 2 lassen.
Schnapp dir mal die pure/entries_archives .tpl und ändere {$month.date|formatTime:"%B"} in Zeile 12 auf {$month.date|formatTime:"%B":false} und lade sie dann mal in dein eigenes Beat theme hoch (dann brauchen wird sie nachträglich nur einfach löschen). Ich habe zwar nicht viel Hoffnung, aber einen Versuch ist es vielleicht wert. Die Kaltender Plugin Anzeigen der Tage und des Monats stehen auch auf ":false".
Hui was für einen (total unerwarteten) Effekt! ? Hau wech das Teil!
Weitere debugging Anweisung (gleich) im Text.
Beat Post author am |
Oh, die Archive sind nun um einen Monat verschoben. März 2020 zeigt nun die Aprli-Beiträge, usw. Deshalb gibt es auch keine April 2020 Anzeige - weil der Mai noch nicht zu Ende ist.
Beat Post author am |
Ist weg.
Beat Post author am |
Debug-Anweisung eingefügt. Muss jetzt weg. Bin ca. um 17:00 Uhr wieder online.
Hatte das noch um eine (erste und eine weitere) Zeile erweitert. Bei mir (lokal ohne Offset) steht das letzte Datum deines ersten entries auf 2005-12-16 23:55:00 also eine Stunde weiter. Korreliert das mit unseren bisherigen Beobachtungen?
Beat Post author am |
Again. Die Leeranzeigen des History-Plugins auf www.beatsblog.ch häufen sich...
Laut timestamp des history_daylist.dat Files hat dieser Zugriff das Neuschreiben des Files ausgelöst:
[10/May/2020:02:03:17 +0200] "GET /plugin/tag/corona-virus HTTP/1.1" 200 23146 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" 611 27704
Interessanterweise gab es vor 02:00 Uhr aber bereits Dutzende von Zugriffen. Ist das Plugin denn so konfiguriert, dass es erst ab 02:00 Uhr neu geschrieben wird? (hier wurde es um 02:49:54 Uhr neu generiert).
Ian Styx am |
Ich stehe geade auf dem Schlauch... woher genau hast du diesen Logauszug?
Wenn das als Auslöser stimmt, war dies also so eine Art "Suche" nach entries über https://www.beatsblog.ch/plugin/tag/corona-virus nach dem tag xx über freetag. Der vorherige von dir genannte, eine entries list pagination Seite. Lass uns also weiter sammeln, bis wir darin eine relative Häufung bestimmter Art (oder des Ausschlusses) erkennen können (unter der Annahme natürlich, dass du jeweils die richtigen Auslöser gefunden hast).
Und warum zeigt er mit 02:03:17 +0200 eine andere Uhrzeit als 02:49:54 Uhr (und woher kommt dieser Zeitstempel?) ?
Nicht das ich wüßte. Warum auch...!? Die Frage ist ja eher, ob diese merkwürdige Übereinstimmung eventuell etwas mit dem anderen Phänomen zu tun hat.
Beat Post author am |
Das history-daylist.dat von www.beatsblog.ch wurde um 02:03:17 geschrieben (leer). Danach suchte ich im Serverlogfile den zeitlich passenden Zugriff und habe diesen im Kommentar erwähnt.
Die im letzten Satz genannte Uhrzeit ist die des history-daylist.dat von hier (blog.dokumenzi.ch), welches richtig/voll geschrieben wurde.
Beide Files wurden nach 02:00 Uhr geschrieben, obwohl es auf beiden Servern auch schon Zugriffe zwischen 00:00 und 02:00 Uhr gab.
Ob diese 2 Std. irgendetwas mit den Archiv-2-Std. zu tun haben entzieht sich meiner Kenntnis. Kann purer Zufall sein. Könnte aber auch sein, dass "Serendipity-intern" generell mit GMT operiert und nicht mit Server+OffsetTime. Aber obacht: Das ist eine plumpe Spekulation. Ich weiss noch nichtmal, ob es überhaupt so etwas wie eine "interne Serendipity-Zeitrechnung" gibt...
Ian Styx am |
Ich gebe mal einen kleinen Zwischenstand:
1. Über die serendipity_db_time mit beigefügtem offset für die Startzeit bin ich mir gar nicht mehr so sicher. Wir sollten das bei dir auf alle Fälle nochmal gegenchecken!
2. Abgesehen davon, dass du den November mit dem test entry irgendwie korrigiert hast, sind es jetzt im direkten Vergleich nur noch 3 Unterschiede zu meiner Testinstallation (ich habe alle ausgegebenen Summen seit Feburar 20 miteinander verglichen).
Gibt es dazu also noch andere Anzeigenunterschiede?
Haben diese 3 irgendetwas Spezielles, was ansonsten überhaupt nicht mehr vorkommt?
Sollte es sich also eventuell nicht um einen generellen bug handeln, so müssten diese, und dabei ist der zweite, bei dem es ja genau umgekehrt ist, vielleicht bedeutsam(?), etwas Besonderes haben.
Im Grunde bräuchten wir eine generelle SELECT Liste aller in den 3 Monaten genannten IDs (inklusive der dazwischenliegenden IDs, die einem anderen Monat zugeordnet sind) mit allen eventuell relevanten Feldern.
Hier mal als Beispiel für den Oktober+November'13
Beat Post author am |
Ich wage (ohne irgendwelche Test's) folgende Behauptung:
Es gibt einen Blogeintrag mit Timestamp 01.06.2011, zwischen 00:00 und 01:59 Uhr. Dieser fehlt im Monat 5 (deshalb werden 17 angezeigt und 18 gezählt). Dieser wird im Monat 6 angezeigt, aber nicht gezählt. Dies, weil jeweils vom 01. des Monats ab 02:00 Uhr bis zum 01. des Folgemonats, ebenfalls um 02:00 Uhr, gezählt wird.
Ich werde das jetzt aber verifizieren. ?
Nachtrag: Es handelt sich um folgenden Beitrag: /2276-Italien-Radreise-2011.html (TimeStamp: 01.06.2011 00:01). Dieser wird im Mai mitgezählt aber nicht dargestellt und im Juni ist es umgekehrt.
Ian Styx am |
Nur kurz: Ich habe den SELECT gerade erweitert, so dass man chainen kann, als Beispiel 2013 10+11 entries. Man müsste das jetzt nur noch für die 2011er Monate ergänzen. Falls es nicht ganz passt, durch dazwischenliegende entries eines anderen Monats, muss man die Ids jeweils +2 oder -2 oder so ergänzen.
Beat Post author am |
? Guck mal in den gemeinsamen Artikel.
Wenn Du mehr Info/Abfragen willst, musst Du dies idiotensicher ausdrücken. ?
Und um dies klarzustellen: Die Abfragen machte ich auf der DB von www.beatsblog.ch (und nicht hier).
Ian Styx am |
Ditto!
Ist die Betreffungs von hier und auf Beat genau gleich, bezüglich sums und Ausgaben? Also bezüglich der auftretenden Fehler?
Beat Post author am |
Neue SQL-Abfrage-Ergebnisse im gemeinsamen Beitrag.
Davon gehe ich aus. Wegen der Archiv-Zählfehler habe ich immer (nur) auf www.beatsblog.ch nachgesehen.
Nachtrag: Sehe gerade, dass hier noch der Kategorie-Zählfehler drin ist. Die Archivzählung ist hier (blog.dokumenzi.ch) also noch falscher als auf www.beatsblog.ch
Ian Styx am |
Aha. Jetzt verstehe ich das viel besser..
Ich meine die timestamps der DB sind UTC, was in unserem Fall gleich GMT ist. Das ist ja auch wichtig, damit es da etwas Universelles gibt. Die Umrechnung erfolgt dann durch die die lokalen und persönlichen Gegebenheiten.
Ian Styx am |
wie was...? ?
Und auch noch eine Frage im Artikel.
Beat Post author am |
Das Archiv hier zählt für den Dezember 2019 51 Beiträge. Es sind aber nur deren 27. Das liegt an der Mehrfachzählung pro Kategorie. Diesen Fehler haben wir auf www.beatsblog.ch behoben. Jedoch nicht hier.Alles gut. Hier wurden im Dezember 2019 viel mehr Beiträge geschrieben. Die Zahl 51 stimmt schon. Entschuldige die Verwirrung. Soweit alles gut und soweit (möglich) vergleichbar mit www.beatsblog.ch.Du überforderst mich. Für mich ist das einfach eine Liste, mit den Beiträgen von zwei Monaten. Und? Was sollte mir denn auffallen?❓ Du müsstest da schon spezifischer werden.
Beat Post author am |
Bemerkenswert wäre vielleicht, dass ich sehr viele Beiträge im Dezember 2017 und im November 2019 editiert habe. Das war die Zeit, in der ich (alle) Erweiterten Beiträge abgeschafft habe und den Text nach oben in den Startbeitrag verschoben habe.
Den Artikel /2276-Italien-Radreise-2011.html habe ich wirklich erst viel später geschrieben und zurückdatiert. Er ist eine Art Einleitungsbeitrag der Kategorie "Tour 2011" und gehört deshalb zeitlich vor den ersten Beitrag dieser Kategorie.
Sonst fällt mir wirklich nichts auf.
(Bei mir ist es durchaus üblich, dass ich Beiträge zu einem späteren Zeitpunkt noch einmal editiere. Meist korrigiere ich Rechtschreibfehler. Das kann auch Jahre später sein).
Ian Styx am |
Das nachträgliche editieren oder auch zurückstufen von Einträgen soll ja auch ohne weiteres möglich sein.
Ich suche immer noch... nach dem Offset Kasus...
Für die UTC/GMT Aussage muss ich natürlich ergänzen, dass dies natürlich nur gilt, wenn keine Server Zeitzone definiert ist (die natürlich ebenso gesetzt sein kann). Also ist immer die Server Zeitzone als timestamp genommen, ansonsten eben UTC/GMT.
Dabei fand ich .. dass das entryproperties Plugin schon wieder ziemlich weit nach oben verschoben war. Das muss immer zuunterst (oder zumindest immer unter allen Plugins stehen, die in das backend entryform hineinhooken) stehen. Ich habe das korrigiert.
Ein weiteres war, dass du "Automatische Speicherung aktivieren" in den Persönlichen Einstellungen auf AN gestellt hast. Ich finde das furchtbar irritierend. Gerade zum Beispiel auch, wenn du auf "Neuen Eintrag" gehst und irgend einen anderen zuletzt bearbeiteten Eintrag, den du da im Cache hast, angezeigt vorgesetzt bekommst, inklusive aller Einstellungen der hooks. Ich empfehle das DING abzuschalten! Es ist zwar gegenüber ganz früher verbessert, aber taugt nicht um die Dinge klar zu halten. Sicher kann es unter Umständen mal helfen einen langen Text nicht im Nirwana verschwinden zu lassen, aber das kommt so selten vor, das die Verwirrung die das Ding anstiftet weit schwerer wiegt. So kann man wirklich lange Texte, an denen man online lange sitzt, ja als Draft bearbeiten und immer wieder mal abspeichern etc., oder für den Grobrahmen sowieso ganz anderswo konzipieren. Mir persönlich ist das vor gefühlten 10 Jahren++ zuletzt passiert. Aber da war Serendipity eben auch noch etwas anderes. Es hat ja zB auch mit dem Login zu tun. Solche "Abbrüche" können ja eventuell geschehen, wenn die Login Session abläuft. Hat man aber sowieso "Login Merken" an, so ist auch an dieser Front relative Ruhe.
Jetzt machst du natürlich mit dem Gesagten was du beliebst und was sich nach deinen eigenen Erfahrungen richtet. ?
Wenn du bereit und online für ein wenig weiteres debugging bist, sag LOS.
Beat Post author am |
Bin jetzt online, muss jedoch um 14:30 Uhr wieder weg.
Beat Post author am |
Betreffend der Serverzeit: Aktuell ist ja hier, wie auch auf www.beatsblog.ch, die Serverzeit = GMT. In der Konfiguration habe ich jedoch:
Würde es irgendetwas ändern, wenn ersteres auf "Nein" stelle? Ein kurzer Test auf www.beatsblog.ch zeigte, dass sich kein erkennbarer Unterschied daraus ergibt (was ja zu erwarten war). Ich frage mich halt, weshal ich "Ja" wählen soll, wenn die Server eh auf GMT eingestellt sind.
Ian Styx am |
Sind sie ja nicht (alle). Es macht ja keinen Sinn seinen eigenen Server, ob nun lokal oder remote, zB auf eine andere Zeitzone zu setzen als jene, in der man selber darinnen ist. Ich kenne (auch) Manitu Server, die sind auf JA und 0 und sind trotzdem meine aktuelle lokale Uhrzeit (in der info der Differenzoption).
Zum weiteren Testen würde ich jetzt auch nichts ändern, also bitte auf 2 lassen.
Ian Styx am |
Schnapp dir mal die pure/entries_archives .tpl und ändere {$month.date|formatTime:"%B"} in Zeile 12 auf {$month.date|formatTime:"%B":false} und lade sie dann mal in dein eigenes Beat theme hoch (dann brauchen wird sie nachträglich nur einfach löschen). Ich habe zwar nicht viel Hoffnung, aber einen Versuch ist es vielleicht wert. Die Kaltender Plugin Anzeigen der Tage und des Monats stehen auch auf ":false".
Beat Post author am |
Hier (auf blog.dokumenzi.ch) gemacht.
Ian Styx am |
Hui was für einen (total unerwarteten) Effekt! ?
Hau wech das Teil!
Weitere debugging Anweisung (gleich) im Text.
Beat Post author am |
Oh, die Archive sind nun um einen Monat verschoben. März 2020 zeigt nun die Aprli-Beiträge, usw. Deshalb gibt es auch keine April 2020 Anzeige - weil der Mai noch nicht zu Ende ist.
Beat Post author am |
Ist weg.
Beat Post author am |
Debug-Anweisung eingefügt. Muss jetzt weg. Bin ca. um 17:00 Uhr wieder online.
Ian Styx am |
Salut!
Hatte das noch um eine (erste und eine weitere) Zeile erweitert. Bei mir (lokal ohne Offset) steht das letzte Datum deines ersten entries auf 2005-12-16 23:55:00 also eine Stunde weiter. Korreliert das mit unseren bisherigen Beobachtungen?