Einträge von Beat

Beobachtungen zur aktuellen Version.

Ganz frisch und bereit für 2022! 🚀🌟✨

Soeben auf die neuste Version upgedatet. Bin etwas überrascht, dass Light-/Dark-Mode gleich ohne jegliche Anpassunen von pure.js und user.css funktioniert. Muss ich jedoch noch genauer ansehen.

Neu mit Dark-Mode im pure-Theme. -> lass die Spiele beginnen! 😎😉

Bei der nächsten stable-Version an diesen Kommentar denken!

Blogsoftware und Plugins auf dem neusten Stand.

Mal sehen, ob es mit einer kleinen Anpassung in der functions_entries.inc.php nun funktioniert.

Seit etwa einem Monat nutze ich nun im Backend das Dark Theme und gestehe gerne ein, dass der Umgang damit sehr angenehm ist. 😎 👍

Es kommen nun die Wintermonate und da habe ich wieder vermehrt Zeit um mich etwas um meinen Blog zu kümmern. In diesem Zusammenhang überlegte ich mir, wie ich Lesern einen Dark Mode im Frontend anbieten kann. Meine Überlegungen dazu sind ziemlich simpel. Ich brauche zwei verschiedene user.css-Files. Einmal das bestehende als Light-Mode und ein neues für Dark-Mode.  Es stellt sich dann die Frage, wie der Leser die beiden Modi ein-/aus-/umschalten kann.

Da gäbe es bereits ein Seitenleisten-Plugin, mit dem man sich verschiedene Theme anzeigen lassen kann. Das betrifft dann jedoch nicht nur die user.css sondern auch alle Theme-spezifischen Dateien. Man müsste also zwei komplette Child-Theme erstellen (und aktuell halten). Das erscheint mir nicht so praktisch. Deshalb kam ich auf folgende Ideen:

1. Eine einfachere Lösung wäre ein neues Seitenleisten-Plugin mit einem simplen, graphischen Umschalter. Klickt/tippt man darauf, wird ein Refresh durchgeführt und die hinterlegte user.css aktiviert.
2. Noch schöner wäre eine Integration direkt in das Master-Theme. Wenn dieser CSS-Umschalter in die Menüleiste integriert werden könnte, dann wäre der grosse Vorteil, dass diese beim Seitenaufruf auch auf dem Mobile zuoberst erscheint und so direkt angewählt werden könnte (ohne dass man nach unten scrollen muss, bis dann die Seitenleisten-Plugins angezeigt werden).

Seit gestern besitze ich ein neues Smartphone und zwar ein Google Pixel 4a mit Android 12. In diesem Zusammenhang ist erwähnenswert, dass ich die Anzeige permanent auf Dark-Mode umstellen kann (was ich auch gemacht habe). Und das Interessante dabei ist, dass mir im Firefox-Browser nun gewisse Seiten ebenfalls, automatisch, Dark dargestellt werden (z.B. www.spiegel.de oder www.tagesanzeiger.ch). Es sieht also so aus, als ob der Seitenanbieter feststellen kann, dass der ankommende Leser den Dark-Mode aktiviert hat und eine demenstprechende CSS ausliefert. Das ist natürlich die Luxus-Lösung.  (Mein Blog wird immer noch Light dargestellt, weshalb ich eben vermute, dass nicht der Browser auf Dark umstellt, sondern der Seitenbetreiber ein Dark-CSS ausliefert).

Wie auch immer. Ich wollte Dich einfach wissen lassen, dass ich diese Geschichte als Winter-Projekt im Kopf habe.

Um eine Dark-css werde ich nicht herumkommen und das wird doch einiges an Aufwand brauchen. Wie dann die Aktivierung/Umschaltung für den Frontend-Besucher wirklich erfolgen kann, das werde ich erst später angehen. Vielleicht können wir diesbezüglich ja ein paar Ideen austauschen.

Kurz vor dem zu Bett gehen habe ich diesen Testblog noch kurz auf die neuste Version upgedated. Bin gespannt, wie das im DarkMode aussieht, auch wenn ich derzeit noch keine Ahnung habe, wie ich das testen kann. 😉

Blog-System und alle Plugins aktualisiert.

Trotz aller möglicher Tests konnte der Hosttech-Support keinen Fehler finden und hatte auch keinerlei Erklärung, weshalb die vor dem Export der DB geschriebenen utf8mb4-Emojis nach dem Import nicht mehr sichtbar sind. Mir wurde ein DB-Dump der Datenbank zur Verfügung gestellt, welcher vor der Migration auf den neuen Server gezogen wurde.

Ich bin dann wie folgt vorgegangen:

1. DB-Export der aktuellen DB
2. Import der DB vom 29.04.2021
3. Sichtkontolle auf diesem Testblog -> keine Emojis
4. Import der heute exportierten DB (unter Punkt 1.)
5. Sichtkontrolle auf diesem Testblog -> keine Emojis (auch diejenigen zwischen dem 29.04. und heute sind verschwunden). 😭

Zu Vergleichszwecken öffnete ich mit phpMyAdmin die Kommentar-Tabelle des Live-Blogs (Manitu). Hier sieht man im body-Eintrag effektiv die Emojis. Daneben die Ansicht der selben Tabelle von hier (Hosttech). Hier sieht man im body-Eintrag eben nur "?" anstelle der Emojis.

...

Dann exportierte ich beide Datenbanken und schaute mir mit Notepad++ den Anfang der jeweiligen Datei an. Ich konnte dabei keine Unterschiede feststellen.

Als nächstes werde ich wohl mal einen DB-Export des Live-Blogs machen und hier importieren... mal sehen...

Nachtrag: 🤔 so einfach geht das nicht. Nachdem ich die beatsblog-DB eingelesen habe, kann ich diese Testinstallation nicht mehr erreichen. Ich erhalten folgende Fehlermeldung:

Fatal error: Uncaught Error: Undefined constant "IN_installer" in /include/serendipity_smarty_class.inc.php:166 Stack trace: #0 /include/serendipity_smarty_class.inc.php(106): Serendipity_Smarty->setParams() #1 /include/serendipity_smarty_class.inc.php(94): Serendipity_Smarty->__construct() #2 /include/functions_smarty.inc.php(1043): Serendipity_Smarty::getInstance() #3 /include/genpage.inc.php(27): serendipity_smarty_init(Array) #4 /include/functions_routing.inc.php(22): include('/var/www/vhosts...') #5 /index.php(113): serveIndex() #6 {main} thrown in /include/serendipity_smarty_class.inc.php on line 166

Da wird Smaty (Spartacus) angemäkelt. Das liegt wohl daran, dass ich nicht die gleichen Plugins auf beiden Instanzen installiert habe.

Habe jetzt keine Zeit mehr für diesen Kram. Kümmere mich später wieder darum.

Klar ist jedoch, dass ich bei jedem Ex- und Import die utf8mb4-Emojis verliere, denn nun sind auch die Emojis des letzten Kommentars weg und diejenigen in diesem Beitrag habe ich gerade jetzt wieder ersetzt. Ich denke so langsam, dass die DB schon falsch befüllt wird, denn die Inhalte sind ja "?" und eben keine Emojis. Wenn ich diese nun ex- und wieder importiere, kommt halt nichts anderes als "?" heraus.