beats TEST blog

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"

Kommentare zur neuen menubar_mobile (mit Hamburger, unten) bitte hier anheften. Danke!

Gestern hatte ich (in meinen Augen) eine ziemlich gute Idee: Wenn ich die "Suche" aus dem Banner entfernen und in einen eigenen Menüpunkt einbinden könnte, dann würde die mobile Ansicht des Banners um einiges besser aussehen.

Das Entfernen der "Suche" aus dem Banner ist einfach. Dafür muss ich nur den entsprechenden Code aus der index.tpl löschen.

Schwieriger wird es, die "Suche" in einer statischen Seite unterzubringen. Als erstes erstellte ich mal eine leere statische Seite mit dem Namen Suche und der URL /pages/suche.html. Dann begann das üben und pröbeln...

Die jeweilige Schritte habe ich auf der statischen Seite dokumentiert. Bis jetzt konnte ich noch kein brauchbares Resultat erzielen. Das braucht wohl noch ein paar Stunden...

Einen sehr guten Hinweis/Tipp erhielt ich in diesem Kommentar. Das war super! ? Die Suche ist jetzt im entsprechenden Menü. Nun muss ich nur noch herausfinden, wie ich das Wort (label) "Suche" davor wegkriege und das Suchfeld in der Breite dynamisch hinkriege.

Test, ob der Admin im Backend Kommentare umhängen kann.

Heute habe ich die Fusszeile auf der Indexseite umgestaltet.

1. Einfügen der Pfeile nach links und rechts (gleich wie im entypaging-Plugin)
2. Permanent in entries.tpl eingefügte Texte "ältere Einträge" und "neuere Einträge" (ich wollte das Sprachfile nicht abändern, da es bei Updates jeweils überschrieben wird)
3. Umkehrung der Reihenfolge. Nun geht es zeitlich rückwärts auf der linken Seite und vorwärts auf der rechten Seite (damit die Darstellung und das Verhalten identisch ist wie im entrypaging-Plugin). Siehe Konversation ab hier.
4. Änderung der Hintergrunfarbe (ohne Farbverlauf)

Ich war heute den ganzen Tag auswärts und hatte Zeit, mit meinem Android-Mobile die Darstellung des Blogs zu testen. Dabei fiel mir auf, dass das Plugin Nächster/Voriger Artikel (entrypaging) in der aktuellen Ausprägung nicht responsible ist. D.h.: Bei zwei langen Beitragstiteln bricht der Inhalt nicht um und dadurch "verbreitert" sich die Darstellung in der mobilen Ansicht. Die Lösung für dieses Problem lieferte der freundliche Herr Styx umgehend ? ? .

Zur Dokumentation nachfolgend die Zusammenfassung aller Eintragungen betreffend entrypaging-Plugin in der entries.tpl und der user.css des Pure-Beat Theme.

Weiter: "entrypaging-Plugin > responsible"