beats TEST blog

In den Kommentaren schreibe ich Dinge/Verhalten/Vorkommnisse auf, die mir im Umgang mit der Styx-Edition auffallen. Ich erwarte dazu kein Feedback oder irgendwelche Aktionen/Reaktionen. Wenn es zu etwas nütz ist, dann ist es gut, ansonsten einfach ignorieren.

Man hätte sich ja auch einfach mal vertieft damit auseinander setzen können, welches Plugin wird beim Aufruf eines einzelnen Beitrags aktiv, welches in der Index-Darstellung inaktiv bleibt... und? Es ist das entrypaging-Plugin für Nächster/Voriger Artikel.

Sobald ich dieses Plugin auf www.beatsblog.ch deaktiviere, verkürzt sich die Ladezeit für einzelne Beiträge auf unter eine Sekunde. z.B.:

https://www.beatsblog.ch/2630-relax-and-enjoy-life.html -> 2,0MB, 48 Requests, 679ms davon 272 Wait

Wieso das hier nicht der Fall ist und nur auf dem Manitu-Host für diese Verzögerung sorgt, weiss der Geier. Ganz persönlich mag ich dieses Plugin sehr und möchte nur ungern darauf verzichten. Ich versuche es nun mal abzuspecken (kein Smarty-Templating) und schaue, ob es in vereinfachter Form genutzt werden kann.

Nee.. Auch ohne Smarty frisst das Ding gleich 3 bis 4 Sekunden. Moment: Zuerst schmeisse ich noch alle zugehörigen Einträge in der user.css weg und schaue nocheinmal. Nee, auch nicht. Bringt alles nichts. Muss mich wohl oder übel davon trennen... ?

Schon seit Anbeginn von www.beatsblog.ch stellen wir eine signifikante Verlangsamung fest, sobald ein einzelner Beitrag aufgerufen wird. Dies habe ich vor über einem Monat auch dem Manitu-Support gemeldet. Seither gab es ein paar Mails, vorwärts und zurück, doch das Problem ist immer noch da und keiner weiss so genau, wie weiter. Hier ein Beispiel:

www.beatsblog.ch (hosted by manitu) https://www.beatsblog.ch/1230-zum-zweiten-Mal.html -> Seitenaufbau 4.19 sec. davon 3.77 Wait ?

www.blog.dokumenzi.ch (hosted by hosttech) https://www.blog.dokumenzi.ch/1230-zum-zweiten-Mal.html -> Seitenaufbau 0,52 sec. davon 0.18 Wait ?

Heute nun habe ich mir Zeit genommen um auf dem Manitu-Webspace eine Subdomaine einzurichten. Darauf installierte ich eine aktuelle Styx Dev 3.0 alpha4 Version. Danach exportierte ich aus der DB von www.beatsblog.ch die entries-Tabelle und importierte diese in den leeren Blog. Das heisst, keine Plugins, keine Bilder, kein spezielles Template, keine Kategorien, keine Tags, kein irgendwas...

Das Resultat:

www.styx.beatsblog.ch (hosted by manitu) https://styx.beatsblog.ch/1230-zum-zweiten-Mal.html -> Seitenaufbau 0,43 sec. davon 0.1 Wait ??

Grummel... Es sieht also verdammt so aus, als ob ich selbst die Verzögerung irgendwo eingebaut habe. ?

Alle weiteren Schritte im Erweiterten Beitrag

 

Weiter: "Need for Speed"

Weiss man eigentlich, weshalb die h2-Titel unterschiedlich animiert werden? Bei den Beiträgen werden sie von links nach rechts getippt (*typing 5s").

Im Archiv oder auf der Kommentarübersichtsseite "fliegen" die h2-Titel von der Mitte an den linken Rand. Das gefällt mir eigentlich noch bessar als das *typing 5s" der Beitragstitel. Ich wollte dies gleich stellen, kann CSS-mässig aber keinen Unterschied erkennen. Beide Titel referenzieren auf "#content h2" und trotzdem verhalten sie sich unterschiedlich. ?

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque ultricies, mauris id convallis vulputate, quam justo hendrerit dolor, a mattis libero justo sed purus. Vivamus quis lorem ut erat aliquam commodo. Vivamus sit amet diam sed turpis mollis imperdiet quis aliquam massa. Vivamus luctus, risus eu blandit fringilla, nunc risus scelerisque erat, ut rutrum augue enim id ante. Vivamus luctus massa gravida, placerat augue quis, mattis ante. Sed faucibus mattis varius. Cras quis ligula vel est ullamcorper maximus sit amet et nisl. Mauris dolor nisl, congue id magna sit amet, finibus rutrum odio.

Duis lacinia enim id eros blandit tincidunt. Maecenas venenatis est lectus, quis euismod massa fermentum ut. Cras in purus non ipsum ultricies porta et et ipsum. Integer pharetra rutrum lacinia. Duis tincidunt eu nisi at pretium. Ut egestas sem quis nunc vehicula hendrerit. Phasellus eget bibendum odio, in sollicitudin velit. Sed quis elit mattis, accumsan nisl a, congue lectus. In facilisis arcu efficitur tempor posuere. Vestibulum mollis vitae augue a viverra. Sed lorem metus, venenatis sit amet nisl sed, elementum porta orci. Nam sit amet diam egestas, accumsan erat viverra, efficitur sem. Sed varius tellus vel urna dapibus rhoncus. Sed quis eros in nunc efficitur gravida a in nisi.

Es ist mir ein Anliegen, wirklich Danke zu sagen. Der neue Blog unter www.beatsblog.ch funktioniert nun wie er soll. Nach den Ferien werde ich ihn offiziell ankündigen/einführen und somit wird er quasi ab sofort www.bbbeat.ch ersetzen. Wie man in älteren Beiträgen nachlesen kann, gab es ein paar Geburtswehen -wie immer-, doch nun flutscht die Mediathek, ImageMagick läuft und zumindest bis jetzt habe ich keine weiteren Fehler erkannt. Für die erhaltene technische und moralische Unterstützung bin ich wirklich sehr dankbar!

Ich blicke nun also nach vorne und gerade in Bezug auf Medien/Bilder stellen sich mit noch ein paar Fragen:

1. Beim Einfügen von Bildern steht ein neuer Button "Als <picture> Element" zur Verfügung. Dafür heisst der alte Button nun "Medien hinzufügen". Heisst das, dass ich zukünftig unterscheiden soll zwischen Bildern und Videos/Sounddateien/PDF/etc? D.h. Bilder explizit mit "Als <picture> Einfügen"?
2. Die Vorschaubilder heissen nun .styxThumb. Um über den ganzen Blog eine einheitliche Regelung zu finden überlege ich mir nun, ob ich in der Konfiguration/Bildkonvertierung dies auf SerendipityThumb umstellen soll oder ob ich alle alten serendipityThumb-Files löschen soll und neue styxThumb generieren. Mir ist klar, dass ich dafür entsprechende Anpassungen in den DB-Tabellen entries, images und mediaproperties vornehmen müsste.
3. Was bedeutet "Erstelle alle Bild-WebP-Format-Variationen"? Soll ich zukünftige Bilder nur noch als webp-Bilder speichern/hochladen? Wie viele Variationen gibt es denn und was passiert mit Apple-Safari-Besuchern?

Und zum Schluss: Ich konnte mich bei den Vorschaubildern nicht für eine grössere Grösse als 200px (Breite) entscheiden. Smartphones zeigen aktuell ca. 400-500 Pixel in der Breite. Oft platziere ich links und rechts im Text ein Vorschaubild. Bei 200px Breite können diese noch nebeneinander dargestellt werden. Und ausserdem will ich ein Vorschaubild halt auch als Vorschaubild nutzen und wer die Vollansicht will, klickt/tippt für die Lightbox.

So, der neue Webspace bei manitu ist eingerichtet und beatsblog.net ist zum Leben erwacht! (Betrieben mit Serendipity Styx 3.0-alpha4 und PHP 7.3.13). Ausser dem CKEditor Plus Plugin habe ich noch nichts installiert oder konfiguriert.

Leider funktioniert auch da utf8mb4_unicode.ci nicht "Out of the box". Die gelben Warnhinweise sind da und die Emojis werden nicht korrekt angezeigt. Ich muss also die alten Beiträge hier durchforsten um dies lauffähig zu kriegen. Hier der Link: www.beatsblog.net

Viele Kommentare zum History-Plugin finden sich ab hier und ab hier

Dieser Beitrag soll die Informationen zusammenfassen und die Diskussion spätestens ab diesem Kommentar hier weiterführen. Um den Einstieg zu erleichtern, dies das Zitat des zuletzt verlinkten Kommentars:

Es müsste auch "Heute und vor X Jahren" heißen, denn ich habe die History jetzt so eingestellt, dass auch ein heutiges entry angezeigt wird. Wenn es Sinn macht das Optional zu machen oder wegzulassen musst du mich überzeugen!

Ich fürchte mich ja etwas vor der möglichen Beitragsbreite an Bildschirmen mit hoher Auflösung. Die integrierten Bilder treten in den Hintergrung und es entstehen grössere, leere Flächen. Deshalb kam ich auf die Idee, anstatt nur rechts, neu auf beiden Seiten Plugin-Leisten anzeigen zu lassen. Das Pure-Template ist ja für 2 Seitenleisten vorbereitet.

Bei 1'024 Pixeln liegt die Grenze, ob Seitenleisten angezeigt werden oder nicht. So gesehen kann ich gedanklich davon ausgehen, dass Die Beitragsbreite kaum je 1'024 Pixel übersteigen wird (mit zwei Seitenleisten müsste die Auflösung schon sehr hoch sein, damit der mittige Platz für den Beitrag grösser als 1'024 Pixel wird). Auf kleineren Displays werden die Seitenleisten-Plugins unterhalb der Beiträge angeordnet und dabei glit: links vor rechts. Das heisst: Hier spielt es gar keine Rolle, ob eine oder zwei Seitenleisten. Soweit zur Ausgangslage. Als ich dann also das Kommentar-Plugin in die linke Seitenleiste schob und mir die Sache genauer ansah, sind mir folgende Punkte aufgefallen:

1. BLOG Seite 1: auf meinem Bildschirm passend (3'840 x 2'160px). Bei einer minimalen Auflösung von 1'025px wird jedoch ein Teil der rechten Seitenleiste abgeschnitten.
2. BLOG Seite 2: selbst bei meiner Auflösung passt die Seitenleiste rechts nicht mehr ganz ins Bild. Bei einer Auflösung von 1'025px ist sie überhaupt nicht mehr zu sehen (auch nicht die vollständige Breite des Eintrags). Zudem werden ein paar der history-Plugins der rechten Seitenleiste verschluckt/nicht angezeigt.
3. BLOG Seite 3 ff: Die Anzeigebreite stimmt wieder, doch alle history-Plugins der rechten Seitenleiste werden nicht mehr angezeigt. Bei 1'025px, Darstellung wie auf Seite 1, jedoch ohne die history-Plugins

Die Darstellung verbessert sich auch nicht, wenn ich das Pure-Standard-Template verwende.

 

---

Temporary added by Ian to test figure image behaviour

 

Weiter: "Seitenleisten links & rechts"

Auf meiner letzten Radreise im Frühjahr 2019 habe ich zu jedem Reisetag die Tourdaten meines Garmin GPS-Geräts in den jeweiligen Blogeintrag integriert. Ein Beispiel davon sieht man weiter unten, im erweiterten Beitrag.

Generell bin ich von der integrierten/eingebetteten Lösung nicht mehr überzeugt. Einerseits verursacht die Einbettung recht lange Ladezeiten und andererseits werden mir durch das Garmin-Snippet gleich 4 Tracker auf meine Seite geschleust. Das mag ich eigentlich gar nicht.

Die einfachste Lösung wäre ein Textlink auf die Garmin-Seite. Die schönere (aber natürlich aufwendigere) Lösung wäre, ein Screenshot von Garmin als JPG abzuspeichern, in die Mediendatenbank hochladen, in den Beitrag einfügen und von da auf die Garminseite zu verlinken. Ich mach das hier mal als Beispiel:

Ein weiterer Vorteil dieser Lösung ist, dass der Screenshot "ewig" verfügbar ist. Ob in z.B. 10 Jahren das Garmin-Snippet noch angezeigt wird oder die Linkadresse auf die Garmin-Seite noch stimmt, weiss ja niemand so wirklich...

Weiter: "iframe einbinden (oder doch nicht)"