EDV - 9

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)"

Die neusten Änderungen (08.01.2020, 12:08) haben tolle Features im Backend-Editor für Kommentare gebracht.

Als grosser Emoji-Fan würde ich mir nun glatt wünschen, dass ich im CKEditor für Einträge ebenfalls diese tolle Auswahl an utf8mb4-Emojis kriegen würde. Aktuell erhalte ich beim Klick auf den Smiley-Button des Eintrag-Editors die von mir zusammengestellten 26 Smileys zur Auswahl in einem Popup (siehe Bild rechts).

Ich weiss: Mit viel Nachlesen und Test-Aufwand könnte ich meine eigene CKEditor Button-Leiste erschaffen und darin dann denselben Emoji-Auswahl-Button -wie es ihn eben aktuell im Kommentar-Editor gibt- einbauen. Ein Profi könnte das aber bestimmt schneller, einfacher, besser...

? und wie durch Zauberhand! ✨ Schon implementiert! ? ? ?   Vielen Dank!

Die Darstellung im Kommentar-Editor, mit den Emojis via Smiley-Button des Editors und die Emoticonchooser-Smileys direkt dargestellt, unterhalb des Editorfensters, ist echt sexy! ?

... es ist ein Ärger mit diesen Usern... kaum macht man etwas Tolles, schreien sie gleich nach noch mehr...

---

Wenn man in Kommentaren Code einfügt, kann es bei hoher Verschachtelung der Kommentare dazu führen, dass die Code-Box rechts aus dem Kommentar herausragt und so die mobile Ansicht (unerwünscht) verbreitert. Es sieht so aus, als ob eine Mindestgrösse definiert ist.

Habe noch diverse Style-Anpassungen vorgenommen. Fast alle Ecken sind nun abgerundet, Die Eintrags-Fusszeile, Indexseite-Fusszeile, Nächster/Voriger Eintrag, Kommentarformular und die Kommentare in der Seitenleiste haben Farbverläufe erhalten. Zudem habe ich den Schatten der eingefügten Bilder etwas abgeschwächt. Das Ziel war, runder, weicher und somit etwas weniger technisch zu erscheinen.

Im Live-Blog werden die meisten Einträge ohne Kommentare bleiben (so wie im Moment bei diesem Beitrag). In der Einzelansicht kann man jetzt also gut sehen, wie es dann ausschauen wird. Gefällt mir ganz gut. ? (Mal sehen, wie lange...)

Habe nun Benutzername und Passwort für höhere Sicherheit verkompliziert. "Voller Name" bleibt simpel "Beat"

Die neusten Änderungen betrafen auch das Styling des Banners (vor allem für das mobilemenu). Nun ist mir aufgefallen, dass wenn ich das Browserfenster langsam im der Breite verkleinere (von Voll-Desktop bis zu kleines Mobile), dass die Menüzeile unterschiedlich umbricht. Die zweite Menüzeile wird zeitweise zentriert und zeitweise rechtsbündig dargestellt. 

Damit man besser vergleichen kann, habe ich die Menütexte auf styx.dokumenzi identisch wie hier gestaltet (ohne verknüpfte Links). Hier ist das pure-beat-Theme im Einsatz, auf syx.dokumenzi das originale Pure-Standard-Theme.

Zum besseren Verständnis und um die Sache etwas übersichtlicher zu gestalten dient dieser Beitrag betreffend der Auszeichnung als "Post author" in der Anzeige von Kommentaren.

Alle unten abgebildeten Kommentare wurden im Frontend geschrieben (manche später im Backend korrigiert/verändert). Dabei war ich meist nicht eingeloggt.

• Wenn der Kommentator Beat heisst, wurde im Kommentarformular im Feld Name "Beat" eingetragen.
• Wenn der Kommentator Beat Menzi heisst, wurde im Kommentarformular im Feld Name "Beat Menzi" eingetragen.
• Im Backend, Benutzereinstellungen, entspricht "Beat" dem Feldinhalt von "Benutzername" und "Beat Menzi" dem Feldinhalt von "Voller Name".
• Es wurde immer die gleiche E-Mail-Adresse angegeben (diese entspricht der E-Mail in den Benutzereinstellungen).

Vorgehen: Ich öffne den Chrome-Browser, besuche diesen Testblog und sehe mir diesen Eintrag in der Einzelansicht an. Die Kommentare werden mir wie auf dem Bild links dargestellt. Festhalten will ich hier: Beat wird als Post author dargestellt (unten).

Dann wechsle ich auf die Kommentarseite Nr.35 und erhalte die Ansicht wie im Bild rechts.. Augenscheinlich wird auf der Kommentarseite nicht Beat sondern Beat Menzi als Post author gekennzeichnet (oben).

Die Screenshots wurden vom Chrome-Browser erstellt. Dieser ist so konfiguriert, das beim Beenden alle gespeicherten Cookies und Webseiteninhalte gelöscht werden. Beim ersten Aufruf dieses Testblogs sah ich also den Datenschutzhinweis. Kein anderer Browser war geöffnet und ich war nicht und nirgends eingeloggt.

Daraus ergibt sich eine zweiteilige Fragestellung: Was sind die Kriterien für die Bestimmung des Post authors? Und weshalb wird an einem Ort "Beat" und am anderen Ort "Beat Menzi" als Post author ausgegeben?

Weiter: "Post author"