kürzlich aufgefallen

Welche Version von Safari? https://caniuse.com/#search=picture

Zu den riesigen blanken Flächen könnte man sicher irgendetwas mit CSS flicken, zB height Angaben für die Images und/oder ihre Container ... oder so. Nur kann ich da nicht helfen; ich habe keinen Zugriff auf so ein Gerät.
(Ein Wechsel auf Firefox ist sowieso ratsamer...!)

Absolut genau gleich? Es sollte ja durch jemanden ausgelöst werden, der ab 0:00 Uhr auf dem Blog einen Request auslöst. Ich habe ja immer noch im Verdacht, dass es vielleicht eine bestimmte Art Seite ist, die den leeren History SQL Query erzeugt. Also zB., der erste Request triggert die Blog Entries Startseite welches OK gibt, bzw irgendwo anders zB archive wo es failed. Deswegen hatte ich damals gesagt, man müsse das quasi mal live beobachten.

Also der Fall mit nl2br muss korrigiert werden, denn das lag sehr wahrscheinlich nur einfach daran, dass du die entryproperties Tabelle noch nicht befüllt hattest. Darin stehen ja die einzelnen Anweisungen per entry welche markup Plugins nicht angelaufen werden sollen. Wir wollen ja hier nicht was Falsches verbreiten! ?

ähem ... what ..??

<!-- s9ymdb:10290 -->
<picture>
    <source srcset="/uploads/Fotoalben/.v/2020_beatsblog.webp" type="image/webp">
    <img alt="beatsblog - Titelbild" class="serendipity_image_center" src="/uploads/Fotoalben/2020_beatsblog.jpg" style="width:1024px">
</picture>

und du willst

<a class="serendipity_image_link" href="/categories/BLOG" title="don't worry - bike happy! -> klicken/tippen für BLOG-Ansicht">
    <!-- s9ymdb:10290 -->
    <picture>
        <source srcset="/uploads/Fotoalben/.v/2020_beatsblog.webp" type="image/webp">
        <img alt="beatsblog - Titelbild" class="serendipity_image_center" src="/uploads/Fotoalben/2020_beatsblog.jpg" style="width:1024px">
    </picture>
</a>

nimm mal das letztere als Quellcode Übernahme.

Und du sagst das ginge nicht als Image auto Eintrag mit href="/categories/BLOG" ... verstehe ich das so richtig?

Was wäre wenn du "/categories/BLOG/index.html" verwendest oder "/categories/BLOG.html" oder "/zumblog" oder https://www.beatsblog.ch/?frontpage verwendest??

Ja. du hast recht - das liegt daran, dass es eine Besonderheit der webp Zusammenstellung ist. Das ist aber relativ einfach zum umgehen, in dem du als /link das default einfach beibehälst (also den link zu "/uploads/Fotoalben/.v/2020_beatsblog.webp" obwohl du ja auf "großes Bild nutzen" gestellt hast), aber dann im Quelltext per Hand das href mit deinem gewünschten link "/categories/BLOG" befüllst.

Wie man das schon von vorneherein besser machen kann ist etwas schwierig bzw kompliziert, denn dazu müsste der Generator wissen dass es ein anderweitiger Link ist. (Ich werde darüber sicherlich einmal knobeln...)

Wie oft kommt denn so was vor im laufenden Betrieb..?

Vielleicht ist es doch nicht ganz so einfach nur...

Ich übersah, dass es ja eigentlich auch eine Alternative geben sollte. Wenn man plugin_syndication korrekt auf feedburner (das Ding läuft noch, ist aber eigentlich offiziell seit 2012 als beendet erklärt..) eingestellt hat, sollte eine zusätzliche globale Konfiguration unter Konfiguration - Feed Einstellungen

Individuelle Feed-URL
Wenn gesetzt, wird die eingetragene URL verwendet um Feedreader dorthin weiterzuleiten. Dies ist hilfreich für Statistikdienste wie z.B. Feedburner, so dass hier die Feedburner-URL des eigenen Feeds hinterlegt werden kann.

Erzwingen der individuellen Feed-URL? Ja / Nein
Wenn aktiviert, werden alle Feedreader automatisch zu der eingetragenen individuellen Feed-URL weitergeleitet.

aber einen 302 header redirect auf die individuelle Feed-URL auslösen. Hast du das so eingestellt? Und es funktioniert nicht? Dann ist möglicherweise deine Verwendung von /categories/BLOG daran Schuld.

Trotzdem stehen im head-Bereich rss- und atom-feed. Ob's an categories/BLOG liegt, weiss ich nicht. Die Zeilen 14 (rss) und 15 (atom) bleiben immer gleich. Egal, welche Kategorie gerade aktiv ist und auch in der Single-Entry-Ansicht sind sie da.

Soweit ich das verstehe (aber ohne praktische Erfahrung damit) sollen und können sich die Links (im Quelltext) auch nicht verändern, denn sie sind in der index.tpl hartkodiert (und das überall schon seit Ewigkeiten). Diese globale Einstellung soll Feedreader (on the fly) bei Aufruf der /rss.php umleiten, siehe https://github.com/ophian/styx/blob/master/rss.php#L240 .

Irgendwann wurde mal feedly als Alternative ins Spiel gebracht. Keine Ahnung ob die Statistiken führen, oder ob das nur eine Art Sammelaggregator ist. Am besten wirklich mal selber suchen.

Die Einstellung Individuelle Feed-URL aktivieren?
Falls der Link zu der individuellen Feed-URL der globalen Konfiguration führen soll, muss diese Option aktiviert werden.

aus dem syndication Plugin hattest du ebenfalls aktiviert, oder?

Ansonsten wäre ja mal ein Debug der genannten if Abfrage in der rss.php unter deinen (category) Kondititionen interessant gewesen...

Nur noch ein paar Old-Fashion-Blogger und naive, nichtkommerzielle Seiten bieten vollständige Feeds an...

Na das ist ja mal ein Spruch... da fühl ich mich direkt angesprochen ...? ob vom ersten oder zweiten bleibt ungewiss.

Hmm, Muss ich das jetzt alles verstehen... Nein! ?

Immerhin scheinst du ja irgendwie Erfolg zu vermelden, so dass ich nicht tätig werden muss. Sehr schön!

Wenn Viele das so handhaben, können sie ihre eigene Webstatistik gleich in die Tonne treten. Unter Umständen haben sie nur sehr wenige Web-Leser, dafür viele rss-Abonennten, die sie höchst selten sehen und bei "nur lesen" auch nicht erfassen.

Ich hatte in der letzten Dekade eher den umgekehrten Eindruck, dass RSS Feeds der "Jugend"  genauso abhanden gekommen ist wie Ping- und Trackbacks untereinander.  ?

Da gibt es noch mehr...

Und dann noch Unterschiede zwischen hier und dort, zB im August 2019. Es sind ingesamt 15 Einträge, aber die Summe ist bei beiden blogs unterschiedlich. Worin unterscheiden die sich diesbezüglich?

-

Hier ist übrigens immer noch die Biene zu sehen (ich kann mich auch da dunkel erinnern, dass ich das schon mal hatte und weiß nur nicht mehr ob du das dann wieder richtig eingestellt hast oder ich im Firefox etwas geändert hatte...)

Fortführung von https://www.blog.dokumenzi.ch/index.php?url=2635-kuerzlich-aufgefallen.html#c6870

So. Ich habe mich gerade mal kurz um das 2 Stunden Problem gekümmert. Ich glaube es ist u.U. ein sehr alter Bug. Mit Serendipity 1.1 (2006) wurde der genannte SQL cache eingeführt, der ja dieses 5 Minuten Zeitfenster erlaubt. Das hohe Alter dieses "Bugs" stimmt mich gerade deshalb etwas unsicher, da es nahezu unwahrscheinlich scheint, dass bisher keiner darüber gestolpert ist. Etwas an das dabei wohl nie gedacht wurde, ist die ServerOffset Zeitverschiebung, so wie bei dir.

Allerdings handelt es sich hier ja um die Startzeit der Abfrage und nicht um falsche Berechnungen zum nächtlichen Übergang alter Einträge. Also eigentlich etwas, was nur bestimmte counter ab dem augenblicklichen timestamp und die eventuelle Einbeziehung von zukünftigen Einträgen bestimmen sollte. Insofern würde ich das gerne mal sehen bevor ich das allgemein commite. Vielleicht handelt es sich hier um das fixen eines Problems was uns mit dem November Problem (und bitte so lassen) gar nicht explizit betrifft.

Bitte ändere (auf beatsblog) mal in der include/functions.inc.php in Zeile 1448 das
$now = time();
in
$now = serendipity_serverOffsetHour();

Ah,  siehe da ?

Ja das kann dann wohl passieren, wenn der alte Server und der neue Server sich im OffsetHour unterscheiden. Woran man so alles denken muss...!

Was ich nicht verstehe ist, sollte es nur ein Server offsetHour Verschiebungsproblem sein, warum das Zählen dann fehlschlägt❓❔❓ Denn wenn sich alle um eine Stunde verschieben, ist das eben so und bildet die dann (neue) Grundlage für das Abzählen, oder ⁉

Ja genau!

Immerhin verwenden wir Logik um die einzelnen Schritte, die schlußendlich zur beobachteten Fehlkalkulation führen, voneinander abzugrenzen und die hoffentlich richtigen Schlüsse zu ziehen!

Von drei haben wir also 2 schon genau eruiert! [Hoffentlich!]

Nee, ich glaube das passt schon (irgendwie), denn du hattest bei den Hörnli Geschichten herumgefummelt, als es um die Zählweise des search Requests ging. Erinnerst du dich?

...in die neue DB ein Server-Zeitversatz von +1 Std. angewendet wurde...

Das wäre auch eine interessante Erklärung, und war da nicht gerade erst was mit 1 Stunde und hostech (?, siehe c6858 ?), würde allerdings bedeuten, dass alle Einträge um 1 Stunde verschoben wurden, auch wenn man es problematisch nur bei der Mitternachtgeschichte befinden könnte.

Ich hatte jedenfalls auch noch in Verdacht, dass bei bestimmten nachträglichen Eintragsänderungen mit neuerem Zeitstempel time() statt serverOffsetHour() verwendet wird. Es gibt solche Stellen, auch wenn ich noch nicht genau nachsehen und verstehen konnte, ob sie dort absichtlich oder nur vergessenerweise als time() initiisiert werden.

Ich hatte jedenfalls auch noch in Verdacht, dass bei bestimmten nachträglichen Eintragsänderungen mit neuerem Zeitstempel time() statt serverOffsetHour() verwendet wird. Es gibt solche Stellen, auch wenn ich noch nicht genau nachsehen und verstehen konnte, ob sie dort absichtlich oder nur vergessenerweise als time() initiisiert werden.

Also ich werde mich jetzt gleich der Besinnung zuwenden, sonst zaubere ich da noch irgendwelche Terroirs hinein... in vino veritas ?, glaube aber inzwischen, dass ich damit falsch liege. Es geht ja gerade darum, dass der create timestamp GMT ist und erst in der diversen Folge mit serverOffsetHour() abgeglichen wird.

Ob es im Original richtig ist, nehmen wir nur an. Das ist nicht völlig sicher. Aber es ist der Ausgangspunkt unserer Betrachtungen. Und du hast völlig recht, egal wie sie sind, die timestamps, sie sind diejenigen auf denen alles beruht. Kommt es also zu Fehldarstellungen, ist es ein Problem der korrekten Umrechnung, auch wenn der eine Server im Offset weiter als der Vorherige sein sollte, da ja "früher" beim Schreiben eines entries, der timestamp auf Grundlage des dortigen Offsets zurück errechnet wurde, in dem Fall -1, nicht wahr ⁉ Ich meine im Übrigen auch, dass das mit Sy9 genauso sein müsste, da ich diesbezüglich nicht wirklich etwas bewußt geändert habe, ... aber wer weiß es genau...! Die Frage ist ja zB., ob man mit den jetzigen 2 Stunden Einstellung den Zähl-Fehler noch einmal produzieren kann bei einem neuen Eintrag oder einem nachbearbeiten kann, der auf diesem Server zuerst angelegt wurde. Könnstest du das mal testen?

Auf alle Fälle sagt uns die Archiv Debug Ausgabe, das der erste Eintrag 2005-12-16 22:55:00 von PHPs default strftime() Funktion um 1 Std in die Vergangenheit Zukunft errechnet wird. Ich bessere sogleich nochmal nach, um auch eine strftime mit Offset Ausgabe zu erhalten.  Ebenso sagt uns die Debug Ausgabe, dass die Änderung in der serendipity_db_time einerseits eine gute und vielleicht sogar richtige Idee war, denn sie zeigt ja auf den richtigen aktuellen lokalen Zeitstempel mit Offset als Start - wobei der Start timestamp sich aber wohl doch nach der DB Serverzeit richten sollte, also muss man die serendipity_db_time wieder zurück auf time() setzen.

Das Debugging hat mir also noch keine Lampe gebracht die alles in Wohlgefallen auflösen könnte.

Ich habe heute Morgen (mit frischem Kopf) ein wenig herumgespielt.

Eine Test timestamp Änderung eines hiesig (+2) zuerst erstellten Blog Eintrags (ja es ist dieser) von
2020-03-21T19:53 auf 2020-03-31T23:53 erbrachte keine Auswirkung im Archiv-Listen-Zähler.
Aber mit 2020-03-01T00:53 ist der Zähler um 1 verrutscht. Es verzählt sich dann im Jahr 2020
also 5 4 2 13 (echt 5 4 2 13) zu 5 3 3 13 (echt 5 4 2 13) (April März Februar Januar).

Außerdem bemerkbar, vertut sich der Zähler ganz unabhängig vom timeframe cache.

Ergo schließe ich daraus, dass nur Monatsanfänge wie 2020-03-01T00:53 mit Zeitstempel
zwischen 00:00 und 00:59 bzw 01:59 diesen Fehler aufweisen und dann für den (und nur den)
nächsten Monat weitergeben. Noch nicht klar habe ich, ob analog ein "1999-08-01T01:53"
erstellter Eintrag (also zurzeiten des +1 Offsets) dasselbe macht. Haben wir eine Beispiel,
das so bereits besteht, also auf 1. Tag des Monats und die Zeit zwischen 01:00 und 01:59 steht?

Bitte vorläufig nicht weiter herumändern an älteren Beiträgen, die ein solches Muster aufweisen.

Wenn alles gut geht und wir diesen Zählfehler in der weiteren Folge wegbekommen, dann erst kann man daran gehen, diese alten Eintrags-Muster an das neue Offset anzupassen, also dass sie nicht mehr weiterrutschen, so das Problem dann noch besteht. Denn klar ist ja, die Offsets sind durch den Serverwechsel anders. Also verrückt sich die Stunde so oder so. Nur macht es ja bei den aller-allermeisten Einträge überhaupt gar nichts aus, wenn sie um 1 Stunde verrückt werden, außer, es entspricht dem Muster oder ist so explizit (!) von dir gewünscht.

Nachdem du das gemacht hast und wir uns beide mal die Archiv Liste daraufhin haben ansehen
und überprüfen können, lies bitte mal unseren Eintrag mit einer weiteren erst dann folgenden Anweisung nach.

Spricht irgendetwas meinem Schluss entgegen?

Ja schon - aber nicht unter Auschluss der übrigen! ?
Und du darfst nicht vergessen dass ich das auch noch verstehen musste! ?

Ich habe übrigens entry 2642 gerade mal als draft verstaut, damit man das ordentlich auch für das Jahr 13 mitbekommt. Da geht es ja nicht um November ➡ Oktober, sondern um Dezember ➡ November..

Eine Kleinigkeit..

Ab und an gibt es einen Kommentar der ohne grundsätzlichen Fehler angenommen, aber trotzdem "aus (..) Gründen" auf moderate gesetzt wird, dem User aber als "Kommentar wurde hinzugefügt", statt "Dieser Kommentar wird ohne Bewilligung nicht dargestellt" als Beendigungsmeldung zur Ansicht kommt. Wahrscheinlich geschieht dies durch nicht abgefangene timeout Bedingungen des Bee Captchas, oder so. Das ist für einen Kommentator verwirrend.

Kannst du deshalb mal bitte folgendes hier ausprobieren. In functions_comments in Zeile 1056 steht $serendipity['csuccess'] = 'true'; Bitte ändere das mal auf $serendipity['csuccess'] = $serendipity['csuccess'] ?? 'true';

Ich werde dann versuchen mt den nächsten Antworten bzw Kommentaren so einen Fall zu reproduzieren.

Oh - heute von der schnellen Truppe. Guten Morgen.

Super. Jetzt ist nur die Frage wie ich das hinbekomme, denn die Vermutung mit dem timeout ist nur eine vage...
Test1

Und es ist eher selten...

Antwort zu https://www.blog.dokumenzi.ch/2635-kuerzlich-aufgefallen.html#c7261

Im plugin history file line 263 (hier mit included) setze mal Folgendes ein. Und dann werden wir das mal wieder beobachten müssen

        if ((int)$xyears > 1 && $specialage == 'year') {
            // get, read and echo possible cache file in case of freetag tag requests
            if (file_exists($cachefile) && preg_match('@/plugin/tag/@', $_SERVER['REQUEST_URI'], $match)) {
                $history = unserialize(file_get_contents($cachefile));
                echo "<!-- freetag case cached f $timeout $cache -->";
                echo $history;
                return;
            }

Zur Fehlervermeindung: Das heißt, ersetze Zeile 263 komplett durch... ☺

bin gespannt ?

https://www.beatsblog.ch/762-Gigathlontag-3-Davos-Lenzerheide.html
Das fehlende Bild ist ein hotlink, das aber auf eine Seite verweist die ihren Dienst eingestellt hat.

..komisch, warum zeigt er nur wieder das versteckte bee Captcha...? Hast du irgendetwas zwischen gestern und heute gemacht?
Nachtrag: Mit der Kommentar Suche bin ich meinem letzten Schluß zu diesem Thema wieder auf die Spur gekommen, in dem ich es dem NGINX Proxy zugeschrieben habe. Es ist [damit] sowieso nur eine vorübergehende Erscheinung.

Ganz Pfiffige würden jetzt einen Rückfall bauen und einen automatisch generierten Platzhalter ala "hier war mal ein Bild dessen Seite verschwunden ist" generieren.

Aber ich zweifle ob sich der Aufwand dafür lohnt..

Hmmm, Jehova! Jehova! ?

Nein, ich glaube nicht, ..wenn ich nicht gerade mit Blindheit geschlagen bin...

Das Script wird ja bei jedem Request durchlaufen und es wird vor dem eigentlichen Geraffel einfach nur kurz nachgefragt, ob das cachefile (noch) existiert und ob der REQUEST URI false oder true auf "/plugin/tag/" zurückliefert. Wenn true, soll also nur der Inhalt des cachefiles ausgeliefert werden, auch wenn es bereits der nächste Tag ist/wäre.

Ich glaube eher das die angenommene Failure auf freetags nicht stimmt. Es könnte in diesem Zusammenhang ja auch nur soetwas wie ein "spocky jetlag" sein, was anderes (also echte Fehler) müssten sonst ja auch auf dokumenzi stattfinden.

Lass es aber noch drin. Ich überlege noch ein wenig und dann müssen wir wohl noch etwas mehr und besseres debugging einbauen...

Eben!  Das Phänomen tritt ja auch nur dort auf, wenn ich recht erinnere.

Weibsleut! ?

Wer hat denn - um mal anders herum zu fragen - das heute (korrekte) cache file ausgelöst?

Am besten lassen wir das noch bis zum Wochende als Full log laufen und reduzieren das dann auf nur noch das Wesentliche, ok?!

Was zu lesen...

☺wie gewünscht v9

Das liegt daran: Seit 2.03 wird eine andere library simple cache benutzt, welche in einen Unterordner nach templates_c/simple_cache stored! Das Fallback, wie in den vorherigen Versionen, ist das PEAR cache LITE das direct in template_c als cache_langeNummer Datei stored. Falls beides nicht geht wird die config Datenbanktabelle benutzt.
Dein Problem muss gelöst werden! Und sei es mit Hilfe von Manitu. Ich sags mal so: die Möglichkeit besteht sogar, dass dein Delay Problem auch damit zusammenhängt. Template_c muss auch in diversen Unterordnern funktional sein.

Nee! Es muss in Unterordnern funktionieren. Da gibt es ja auch noch weit mehr dass das in Anspruch nimmt bzw nehmen möchte. Selbst Smarty schreibt auf Level -4 ‼ ?

Sonst gerne. ?
(Heute Abend gehts weiter für mich.)

Irgendetwas ist seit Gestern dann noch geschehen, nachdem es mit der 40 gut aussah.
Dein Template CSS wird nicht mehr gefunden...
Die im Vergleich andere History Ausgabe ist darauf zurückzuführen, dass dort noch kein offset Fix (du erinnerst dich?) drübergelaufen ist, die Zählung aller 23 Uhr entries fehl läuft.

Rev 43. Wir wollen ja nicht aus der Übung kommen. ?

Rev 45 ?

Differenz Frage ?