beats TEST blog

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!

Ich mache mir ab und zu Gedanken, wie ich nach dem Umzug des Live-Blogs auf die Styx-Edition und das Pure-Theme Beiträge gestalten soll. Der Hauptunterschied ist, dass im "alten" Next-Beat-Theme die maximale Anzeigebreite eines Beitrags exakt 667 Pixel betrug. Hier, mit Pure-Theme als Basis, ist die Breite dynamisch und auf meinem aktuellen Monitor erheblich breiter als 700px.

Weiter: "Gestaltung von Beiträgen"

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"

Ich habe hier jetzt viel Zeit investiert und denke, dass ich langsam bereit bin um die Migration anzupacken. Vermutlich mache ich das zwischen den Festtagen (so der aktuelle Plan).

Dafür werde ich eine Subdomain auf www.bbbeat.ch einrichten und da die Styx-Edition neu aufsetzen. Dann kopiere ich allen Inhalt von S9Y nach Styx-Edition (so ähnlich, wie ich das hier getan habe (plus dem, was ich hinzugelernt habe)). Die Installation des "alten" S9Y-Live-Blog lasse ich unangetastet bestehen. Wenn alles klappt und getestet ist, setze ich das Startverzeichnis von www.bbbeat.ch auf das gleiche Verzeichnis wie www.styx.bbbeat.ch.

Jetzt stellt sich die Frage, ob ich besser V 2.9.2 stable installiere oder ob ich die aktuelle Dev-Version nehmen soll.

Eine Anregung: Es wäre toll, wenn man im Backend Kommentare "umhängen" könnte. Manchmal vergesse ich beim Antworten den richtigen Kommentar auszuwählen, auf den ich mich beziehen will (das passiert anderen wohl auch). Nachträglich habe ich keine Möglichkeit gesehen/gefunden, um vorhandene Kommentare an einen anderen Kommentar (natürlich im gleichen Beitrag) anzuhängen (oder auf Beitrag-Root zu setzen), damit die Verschachtelung dann wirklich stimmt. -> Im "Bearbeite Kommentar"-Bereich fehlt das Auswahlfeld "Antwort zu"

Vermutlich gibt es gute Gründe weshalb das so ist. Für den Blogbetreiber wäre das einfach ein nettes Feature um die Kommentare "aufzuräumen". In meiner Live-Praxis, mit sehr wenigen Kommentaren, braucht es das nicht wirklich. Hier, mit bis zu 30 Kommentaren pro Beitrag, hätte mir das schon ein paar Mal geholfen.

Diese Anregung wurde implementiert und ist ab SW-Stand 22.12.2019, 19:11, im Kern enthalten.

Eine andere Frage: Bei Original-S9Y gibt es ein Plugin, mit dem man dem Kommentator die Möglichkeit gibt, seinen Kommentar bis zu X Minuten nach dem abschicken zu editieren. Ich fand das eine gute Sache, denn viele Tippfehler sieht man erst, wenn man den Kommentar (nach dem abschicken) nochmals liest. Dieses Plugin verursachte jedoch Probleme, weshalb ich es deinstallieren musste. Funktioniert das in Styx-Edition ohne negative Konsequenzen? Wenn ja, würde ich das nämlich gerne wieder einsetzen.

Kann ich in der Einzelansicht eines Beitrags auch das Erstellungsdatum angezeigt erhalten? Das macht vor allem mit dem Plugin Nächster/Voriger Artikel (entrypaging) Sinn, damit man sich besser orientieren kann, wo (zeitlich) man gerade steht.