? "super einfach selbst einfügen" -> you made my day! ?
Dafür habe ich Matthias 3x um (Nach-)Hilfe gebeten und das hat mich ein Video aus seiner Wishliste gekostet. ? Aber ja, wer's kann, der kann das super einfach einfügen. ?
Irgendwie möchte ich das Hamburger-Thema beenden...
Um es einfach nocheinmal zu erwähnen. Den pure-Hamburger habe ich verworfen, weil man unten auf den Hamburger klickt und dann von oben der Header mit Menü eingeblendet wird. Ich mag meinen go-to-top-Button und komme damit an das genau gleiche Ziel. Ohne, dass ich unten immer diese Menüzeile eingeblendet habe. Die pure-Hamburger Lösung hat den Vorteil, dass die Seite nicht scrollt (wenn man das einen Vorteil nennen will). Meine go-to-top Lösung hat den Vorteil, dass sie nicht nur nach oben scrollt, sondern auch noch das Menü einblendet. (Vielleicht müsste ich das nach oben zeigende Dreieck noch um drei Hamburger-Längsstriche ergänzen). ?
Ja eben, das ist doch auch schick so. Ich habe ja auch nicht rumgemäkelt das Beat keinen Hamburger hat... (obwohl, .. hat er ja doch, er weiß es nur nicht... tztztz!)
Ist dir schon mal aufgefallen, dass dein jAlbum mit einem > beginnt? Ich nehme an es ist ein versehen und wird wahrscheinlich durch das javascript res/all.min.js bzw einem dort aufgerufenen weiteren scriptes nach dem body und nach einem der property og: eingesetzt, siehe:
Vielleicht findest du das ja als >> irgendwo in den dazugehörigen Dateien.
Ansonstem immer wieder tolle Reise, tolle Bilder! ?
Beat Post author am |
Danke für den Hinweis. Hab das auch mal gesehen, doch so auf die Schnelle keine Lösung gefunden.
Heute habe ich nun das Skin/Theme auf den neusten Stand aktualisiert, das Album neu generiert und hochgeladen. Und siehe da: Dieses >Dingens ist weg! ?
Und: Ja... seufz... schön war's! Dieses Jahr wegen Corina Corona und Hausumbau wohl kein Bike-Urlaub. ?
Ich denke, dass am 01.03.2021 der nächste "Checkpoint" ansteht. ?
...und offenbart, dass ich zu voreilig, und ein besonderer Fall eben doch noch nicht bedacht war, denn in Schaltjahren ist nach dieser Rechnung der 1. März eben doch eigentlich nur ein (eingeschobener) 29. Februar.
Der Algorithmus für multiyear Anzeigen zählt einfach den Tag + (365/366) hoch, damit man die Einträge mit wenig Aufwand aus dem timestamp der Datenbank auslesen kann. Morgen müsste also eigentlich alles wieder in Ordnung sein, bis zum nächsten 1. März.
Ich bin schlicht zu wenig Mathematiker um diesen Algorithmus so zu verändern, dass er dieses Schaltjahr mit verhältnismäßigem Aufwand richtig berücksichtigt und ich damit in der Lage wäre diesen Nagel endlich richtig einzuschlagen, so es überhaupt mit Tagen alleine ginge. Jetzt könnte man also sagen der 29. Februar sei ja auch ein schöner 1. März, aber man vergisst dabei, dass es eben auch Fälle gibt, wo es in Schaltjahren statt eines Eintrags am 29. Februar (auch) einen am 1. März gibt. So hatte ich gerade einen workaround bereitgestellt, der die gefundenen Schalttag-Einträge eben dann einfach nicht darstellt, wenn der heutige Tag nicht auch ein solcher Schalttag ist. Aber damit habe ich immer noch nicht die Einträge des 1. März in historischen Schaltjahren...
Ich kann das gerade nicht präzise genug denken wie man einen solchen 1. März in Schaltjahren mit der bisherigen Berechnung richtig ausgeben kann, außer man verwirft den jetzigen (365/366) Tag Zähler und macht die Datenbankanfrage strikt nach Tag/Monat.
Forget it! Ich hab es doch noch hinbekommen ? (fingers crossed!)
Wäre natürlich toll wenn du das heute noch überprüfen könntest. Wie so oft nähert man sich einer Lösung wenn man sie zu beschreiben versucht. Und dann stellt sie sich als relativ einfach heraus...
Beat Post author am |
? Passt!
Olà... V3.3.0... es steht also noch ein Update an. Gab es Änderungen in pure (index.tpl, entries.tpl oder pure.js)?
Für die index, ja! 2 Stück.
Siehe https://github.com/ophian/styx/commits/master/templates/pure/index.tpl
Beat Post author am |
Danke für die Hinweise
Öhm.. Die erste Änderung (on Jan 19, 2021) war einfach.
Bei der zweiten Änderung (Feb 21, 2021) war ich unsicher. In meiner index.tpl fehlte bisher der ganze "highlight.min.js"-Bereich. Habe nun ab Zeile 128 alles aus der original-pure-index.tpl in mein File (in dieser Installation) übernommen. Erste Tests zeigen keine Auffälligeiten. Ich weiss aber auch nicht genau, wie ich das prüfen kann.
Hmmm... ob das so passt?
Ian Styx am |
Passt schon, denke ich.
Jedenfalls wird bei single entry comments und bei /comments/ summary Seiten gehighlighted.
Aber irgendetwas ist falsch, denn es gibt einen javascript error. Du solltest also am besten ab Zeile 119 https://github.com/ophian/styx/blob/master/templates/pure/index.tpl#L119 die Übernahme starten.
Beat Post author am |
Danke! Was "gehighlighted" auch immer sein mag...
Dann kann ich ja morgen den Live-Blog auch auf V3.3.0 updaten. ?
Ich hatte es schon geahnt, dass es nicht auf den ersten März beschränkt sein könnte...
Gerade neu commitet und gefixt! (Ab jetzt sage ich nur noch ..vorerst..) ?
Beat Post author am |
Sieht vorerst ganz gut aus! ?
Beat Post author am |
Habe jetzt die \pure-beat\index.tpl noch einmal überarbeitet und auch www.beatsblog.ch auf V3.3.0 upgedatet.
In der Konsole sehe ich keine Fehler (konnte jedoch vorher auch den von Dir genannten javascript-error nicht sehen). Kannst Du vielleicht kurz nachsehen, ob Du noch einen Fehler findest? Danke!
Das war gestern als ich den letzten Kommentar verschickt hatte, der in die Moderation geschickt wurde, und ich dabei zufällig die Dev-F12-Konsole offen hatte. Es war ein Fehler des ckeditor javascriptes, welches meinte, irgendetwas nicht gefunden zu haben. Als ich heute Morgen meinen Kommentar schrieb habe ich das nachzustellen versucht, aber alles war in Ordnung.
Im Nachhinein konnte ich mir das nur dadurch erklären, dass du ja gestern das Styx Update gemacht hast, welches auch eine neue Version des assets Editors mitgebracht hat, mein Browser aber noch die vorherige Version aus dem Cache verwendet hat. Jedenfalls hoffe ich dass es das war.
Edit: Und da dieser Kommentar mit dem Abschicken auch in der Moderation landete, trat der Fehler eben auch erneut auf. Diesmal habe ich dann richtig hingeschaut und gesehen, dass es ein valider und guter Fehler ist. Aber auch nichts schlimmes, eher eine Art von Status Information.
Wenn ein Kommentar abgeschickt wurde, wird ja die Kommentarform und damit auch die textarea nicht angezeigt; aus gutem Grund übrigens. Nun will aber CKE die textarea input form, die eben nicht da ist, mit seinen Rich Text Eigenschaften ersetzen und scheitert.
Ich werde nachher mal einen JS Gegencheck überall nachtragen wo es derart verwendet wird, was mir vorerst einfacher erscheint, als aufwendig eine PHP/Smarty Variable für diesen 1-minütigen Fall zu setzen, die den Javascript Kram für diese Zeit ganz ausblendet.
Gerade erfolgt!
Und zur Übernahme bereit ?, wenn du möchtest.
Ich glaube vorerst aber nicht, dass solch kleine Fehlerchen ein Styx Punkt-Bugfix-Update erfordern, vor allem, wenn sie so gut versteckt sind und nicht wirklich etwas kaputt machen.
Hattest du mein Edit wegen des Fehlers im vorletzten Kommentar eigentlich mitbekommen?
(Das ist nur ein Hinweis, kein muss! ?)
Beat Post author am |
Hallo
Ja, ich habe Dein Edit gelesen. Dachte jedoch, dass dieser Mini-Fehler für mich bedeutungslos ist.
Vielleicht willst Du Deine Änderungen mal testen ?!? Habe deshalb hier nun V3.4 DEV heruntergezogen und aufgespielt. Kommentare dazu (der Übersichtlichkeit halber) bitte beim entsprechenden Beitrag anfügen. Danke.
Ähem, ? ich sagte doch es wäre nur als Hinweis gemeint, falls ungelesen.
Völlig unnötig da gleich noch ein ganzes Dev build raufzusetzen, vor allem, wenn die eigentliche Datei, in deinem beat theme, davon gar nicht berührt wird..., oder?!
Beat Post author am |
Gut gemeint ist halt oft das Gegenteil von gut gemacht. ?
Beat Post author am |
Görps!? Heute hat sich auf beatsblog.ch das history-plugin verschluckt. Im history_daylist.dat stand nur:
s:334:"<div class="serendipity_history_info">
<span class="serendipity_history_date">15.03.06</span> <a href="/151-Zuercher-Bloggertreffen.html" title="Zürcher Bloggertreffen">Zürcher Bloggertre [...]</a>
</div>
<div class="serendipity_history_outro">Keine Anzeige? Dann wurde an diesem Tag noch nie ein Beitrag geschrieben.</div>
";
Habe das File gelöscht und nun sieht die Anzeige im Live-Blog gleich aus wie hier.
PS: Styx V3.3.1 habe ich hier und auf beatsblog.ch installiert. ?
Ich hatte es gesehen, aber gedacht, dass das mit dem Zeitverschiebungsproblem und deinen Tages-Datierungen zu tun hätte welches ja hier noch ungelöst vor sich hindämmert.
Wenn dem nicht so ist, sollte es aber wohl eher nicht mit der ewigen Schaltjahrgeschichte, sondern entweder
mit einer bisher unberücksichtigten Sonderform deiner Eintrags-timestamps, bzw
mit einer eventuell diesbezüglichen Veränderung (Differenz) auf dem Server, oder
einfach nur mit einem mysteriösen Schluckauf zum Zeitpunkt des Abrufes
zu tun haben. Kannst du mal die genauen Datierungen der Einträge rausfischen und dann auch nochmal den Zeitunterschied des Servers in der Backend Konfiguration (siehe auch den info Kasten) überprüfen?
Bei meiner damaligen entries testdata Installation wegen der Zeitgeschichte - die ich Gott sei Dank noch nicht gelöscht hatte - ist das heutige Ergebnis sofort:
Beat Post author am |
? "super einfach selbst einfügen" -> you made my day! ?
Dafür habe ich Matthias 3x um (Nach-)Hilfe gebeten und das hat mich ein Video aus seiner Wishliste gekostet. ? Aber ja, wer's kann, der kann das super einfach einfügen. ?
Irgendwie möchte ich das Hamburger-Thema beenden...
Um es einfach nocheinmal zu erwähnen. Den pure-Hamburger habe ich verworfen, weil man unten auf den Hamburger klickt und dann von oben der Header mit Menü eingeblendet wird. Ich mag meinen go-to-top-Button und komme damit an das genau gleiche Ziel. Ohne, dass ich unten immer diese Menüzeile eingeblendet habe. Die pure-Hamburger Lösung hat den Vorteil, dass die Seite nicht scrollt (wenn man das einen Vorteil nennen will). Meine go-to-top Lösung hat den Vorteil, dass sie nicht nur nach oben scrollt, sondern auch noch das Menü einblendet. (Vielleicht müsste ich das nach oben zeigende Dreieck noch um drei Hamburger-Längsstriche ergänzen). ?
Ian Styx am |
Watn Freund... ?
Sorry für die Umstände!
Ja eben, das ist doch auch schick so.
Ich habe ja auch nicht rumgemäkelt das Beat keinen Hamburger hat... (obwohl, .. hat er ja doch, er weiß es nur nicht... tztztz!)
Ian Styx am |
Moin Beat
Ist dir schon mal aufgefallen, dass dein jAlbum mit einem > beginnt? Ich nehme an es ist ein versehen und wird wahrscheinlich durch das javascript res/all.min.js bzw einem dort aufgerufenen weiteren scriptes nach dem body und nach einem der property og: eingesetzt, siehe:
Vielleicht findest du das ja als >> irgendwo in den dazugehörigen Dateien.
Ansonstem immer wieder tolle Reise, tolle Bilder! ?
Beat Post author am |
Danke für den Hinweis. Hab das auch mal gesehen, doch so auf die Schnelle keine Lösung gefunden.
Heute habe ich nun das Skin/Theme auf den neusten Stand aktualisiert, das Album neu generiert und hochgeladen. Und siehe da: Dieses >Dingens ist weg! ?
Und: Ja... seufz... schön war's! Dieses Jahr wegen
CorinaCorona und Hausumbau wohl kein Bike-Urlaub. ?Ian Styx am |
??? tja
Ian Styx am |
...und offenbart, dass ich zu voreilig, und ein besonderer Fall eben doch noch nicht bedacht war, denn in Schaltjahren ist nach dieser Rechnung der 1. März eben doch eigentlich nur ein (eingeschobener) 29. Februar.
Der Algorithmus für multiyear Anzeigen zählt einfach den Tag + (365/366) hoch, damit man die Einträge mit wenig Aufwand aus dem timestamp der Datenbank auslesen kann. Morgen müsste also eigentlich alles wieder in Ordnung sein, bis zum nächsten 1. März.
Ich bin schlicht zu wenig Mathematiker um diesen Algorithmus so zu verändern, dass er dieses Schaltjahr mit verhältnismäßigem Aufwand richtig berücksichtigt und ich damit in der Lage wäre diesen Nagel endlich richtig einzuschlagen, so es überhaupt mit Tagen alleine ginge. Jetzt könnte man also sagen der 29. Februar sei ja auch ein schöner 1. März, aber man vergisst dabei, dass es eben auch Fälle gibt, wo es in Schaltjahren statt eines Eintrags am 29. Februar (auch) einen am 1. März gibt. So hatte ich gerade einen workaround bereitgestellt, der die gefundenen Schalttag-Einträge eben dann einfach nicht darstellt, wenn der heutige Tag nicht auch ein solcher Schalttag ist. Aber damit habe ich immer noch nicht die Einträge des 1. März in historischen Schaltjahren...
Ich kann das gerade nicht präzise genug denken wie man einen solchen 1. März in Schaltjahren mit der bisherigen Berechnung richtig ausgeben kann, außer man verwirft den jetzigen (365/366) Tag Zähler und macht die Datenbankanfrage strikt nach Tag/Monat.
Ian Styx am |
Forget it! Ich hab es doch noch hinbekommen ? (fingers crossed!)
Wäre natürlich toll wenn du das heute noch überprüfen könntest. Wie so oft nähert man sich einer Lösung wenn man sie zu beschreiben versucht. Und dann stellt sie sich als relativ einfach heraus...
Beat Post author am |
? Passt!
Olà... V3.3.0... es steht also noch ein Update an. Gab es Änderungen in pure (index.tpl, entries.tpl oder pure.js)?
Ian Styx am |
Klasse!
Für die index, ja! 2 Stück.
Siehe https://github.com/ophian/styx/commits/master/templates/pure/index.tpl
Beat Post author am |
Danke für die Hinweise
Öhm.. Die erste Änderung (on Jan 19, 2021) war einfach.
Bei der zweiten Änderung (Feb 21, 2021) war ich unsicher. In meiner index.tpl fehlte bisher der ganze "highlight.min.js"-Bereich. Habe nun ab Zeile 128 alles aus der original-pure-index.tpl in mein File (in dieser Installation) übernommen. Erste Tests zeigen keine Auffälligeiten. Ich weiss aber auch nicht genau, wie ich das prüfen kann.
Hmmm... ob das so passt?
Ian Styx am |
Passt schon, denke ich.
Jedenfalls wird bei single entry comments und bei /comments/ summary Seiten gehighlighted.
Aber irgendetwas ist falsch, denn es gibt einen javascript error. Du solltest also am besten ab Zeile 119 https://github.com/ophian/styx/blob/master/templates/pure/index.tpl#L119 die Übernahme starten.
Beat Post author am |
Danke! Was "gehighlighted" auch immer sein mag...
Dann kann ich ja morgen den Live-Blog auch auf V3.3.0 updaten. ?
Ian Styx am |
Wir sind uns gerade in die Quere gekommen. Bitte noch mal nachlesen.
gehighlighted = code farbig ?
Ian Styx am |
Ich hatte es schon geahnt, dass es nicht auf den ersten März beschränkt sein könnte...
Gerade neu commitet und gefixt! (Ab jetzt sage ich nur noch ..vorerst..) ?
Beat Post author am |
Sieht vorerst ganz gut aus! ?
Beat Post author am |
Habe jetzt die \pure-beat\index.tpl noch einmal überarbeitet und auch www.beatsblog.ch auf V3.3.0 upgedatet.
In der Konsole sehe ich keine Fehler (konnte jedoch vorher auch den von Dir genannten javascript-error nicht sehen). Kannst Du vielleicht kurz nachsehen, ob Du noch einen Fehler findest? Danke!
Ian Styx am |
Das war gestern als ich den letzten Kommentar verschickt hatte, der in die Moderation geschickt wurde, und ich dabei zufällig die Dev-F12-Konsole offen hatte. Es war ein Fehler des ckeditor javascriptes, welches meinte, irgendetwas nicht gefunden zu haben. Als ich heute Morgen meinen Kommentar schrieb habe ich das nachzustellen versucht, aber alles war in Ordnung.
Im Nachhinein konnte ich mir das nur dadurch erklären, dass du ja gestern das Styx Update gemacht hast, welches auch eine neue Version des assets Editors mitgebracht hat, mein Browser aber noch die vorherige Version aus dem Cache verwendet hat.
Jedenfalls hoffe ich dass es das war.
Edit: Und da dieser Kommentar mit dem Abschicken auch in der Moderation landete, trat der Fehler eben auch erneut auf. Diesmal habe ich dann richtig hingeschaut und gesehen, dass es ein valider und guter Fehler ist. Aber auch nichts schlimmes, eher eine Art von Status Information.
Wenn ein Kommentar abgeschickt wurde, wird ja die Kommentarform und damit auch die textarea nicht angezeigt; aus gutem Grund übrigens. Nun will aber CKE die textarea input form, die eben nicht da ist, mit seinen Rich Text Eigenschaften ersetzen und scheitert.
Ich werde nachher mal einen JS Gegencheck überall nachtragen wo es derart verwendet wird, was mir vorerst einfacher erscheint, als aufwendig eine PHP/Smarty Variable für diesen 1-minütigen Fall zu setzen, die den Javascript Kram für diese Zeit ganz ausblendet.
Ian Styx am |
Gerade erfolgt!
Und zur Übernahme bereit ?, wenn du möchtest.
Ich glaube vorerst aber nicht, dass solch kleine Fehlerchen ein Styx Punkt-Bugfix-Update erfordern, vor allem, wenn sie so gut versteckt sind und nicht wirklich etwas kaputt machen.
Ian Styx am |
Hattest du mein Edit wegen des Fehlers im vorletzten Kommentar eigentlich mitbekommen?
(Das ist nur ein Hinweis, kein muss! ?)
Beat Post author am |
Hallo
Ja, ich habe Dein Edit gelesen. Dachte jedoch, dass dieser Mini-Fehler für mich bedeutungslos ist.
Vielleicht willst Du Deine Änderungen mal testen ?!? Habe deshalb hier nun V3.4 DEV heruntergezogen und aufgespielt. Kommentare dazu (der Übersichtlichkeit halber) bitte beim entsprechenden Beitrag anfügen. Danke.
Ian Styx am |
Ähem, ? ich sagte doch es wäre nur als Hinweis gemeint, falls ungelesen.
Völlig unnötig da gleich noch ein ganzes Dev build raufzusetzen, vor allem, wenn die eigentliche Datei, in deinem beat theme, davon gar nicht berührt wird..., oder?!
Beat Post author am |
Gut gemeint ist halt oft das Gegenteil von gut gemacht. ?
Beat Post author am |
Görps!? Heute hat sich auf beatsblog.ch das history-plugin verschluckt. Im history_daylist.dat stand nur:
Habe das File gelöscht und nun sieht die Anzeige im Live-Blog gleich aus wie hier.
PS: Styx V3.3.1 habe ich hier und auf beatsblog.ch installiert. ?
Ian Styx am |
Ich hatte es gesehen, aber gedacht, dass das mit dem Zeitverschiebungsproblem und deinen Tages-Datierungen zu tun hätte welches ja hier noch ungelöst vor sich hindämmert.
Wenn dem nicht so ist, sollte es aber wohl eher nicht mit der ewigen Schaltjahrgeschichte, sondern entweder
zu tun haben. Kannst du mal die genauen Datierungen der Einträge rausfischen und dann auch nochmal den Zeitunterschied des Servers in der Backend Konfiguration (siehe auch den info Kasten) überprüfen?
Bei meiner damaligen entries testdata Installation wegen der Zeitgeschichte - die ich Gott sei Dank noch nicht gelöscht hatte - ist das heutige Ergebnis sofort:
Do, 15.03.2018 17:09 Inneres Feuer
Sa, 15.03.2014 23:59 Rikscha + eTukTuk
So, 15.03.2009 17:47 pampig
Sa, 15.03.2008 23:59 Irchel Hometrails
Do, 15.03.2007 21:34 Bewegungssucht
Mi, 15.03.2006 23:27 Biketeile - Trouvaille
Mi, 15.03.2006 17:10 Zürcher Bloggertreffen
Ich würde zu letzterem tendieren...