EDV - 10

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"

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.

Mal sehen, ob es schon funktioniert.

? ? ✈ ? ? ? ? ?

Habe bisher in der DB in (fast) allen Tabellen die Kollation von utf8_general_ci auf utf8mb4_general_ci geändert und danach in der config-Tabelle einen Datensatz (name:dbUtf8mb4_converted, value:true, authorid:0) hinzugefügt.

Nun steht im Backend unter Wartung UTF-8-MB4 Zeichensatz und die Emojis funktionieren. Dies obwohl ich die vom Hosting-Supporter beschriebene Änderung nicht vorgenommen habe.

Im Backend unter Kommentare wird bei >80% aller Kommentare dieser rote Trichter dargestellt und bei Mouseover heisst es: Stripped by security! Review content in VIEW or EDIT mode. Was soll mir das sagen? Ich kann den Kommentar ansehen (VIEW) oder editieren (EDIT), doch der rote Trichter geht nicht weg.