beats TEST blog

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.

Solange ich nur einen Absatz schreibe, fügt der Editor keine < p >-Tags an und dadurch wird der Abstand oben zum Titel und unten zu der Fusszeile kleiner als mit < p >-Tags. Sobald ich "Return" betätige, für einen neuen Absatz, werden < p >-Tags angefügt (auch an den ersten Absatz). Ist das so richtig? Um die Abstände gleich zu halten, habe ich in den Einträgen unten (mit nur einem Satz/Absatz) manuell < p >-Tags in den Quelltext eingefügt. Das geht zwar, schöner wäre jedoch, wenn immer < p >-Tags erstellt würden.

Das hat unter Anderem zur Folge, dass wenn ich Vorschaubilder links oder rechts zu Beginn eines Eintrags einfüge, diese dann gegenüber dem Text (mit < p >-Tags) leicht erhöht dargestellt werden. Siehe z.B. den Eintrag "Suche" auf statischer Seite.

Ich möchte das Vollbild mittig zentriert. Im Quellcode des Editors steht auch "serendipity_image_center", weshalb wird es dann doch linksbündig angezeigt? Muss wohl die Pure-style.css entsprechend durchsuchen.

Gefunden und erledigt. In der style.css steht u.A.: .serendipity_image_center {margin: 0 auto 1em auto;}. Habe jetzt in meine user.css geschrieben: {margin: auto auto 1em auto;} siehe Kommentar.

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"