BLOG

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.

Am 29.04.2021 migrierte Hosttech mein Hostingpaket auf eine neue Serverumgebung.

Dieser Beitrag dient dazu, das Problem der fehlenden utf8mb4-Emojis darzustellen, welche vor der Migration alle sichtbar waren, nach der Migration aber zu 99% nur noch als "?" angezeigt werden.

Hier 10 utf8mb4-Emojis hintereinander: ??????????.

Nach der Migration geschrieben und soweit korrekt dargestellt.  So sieht dieser Abschnitt in der Datenbank aus:

<p>Hier 10 utf8mb4-Emojis hintereinander: ??????????</p>

Im Vergleich dazu dieser Beitrag vom 08.01.2020. Nach dem Wort "Zauberhand" wird ein einziges utf8mb4-Emoji dargestellt. Alle anderen fehlen, respektive werden auch im Frontend nur noch als "?" dargestellt. Die anderen sichtbaren Emojis sind Serendipity-interne und haben nichts mit utf8mb4 zu tun (siehe z.B. :bow). So sieht der entsprechende Abschnitt in der Datenbank aus:

<p>? <strong>und wie durch Zauberhand! </strong>✨ <strong>Schon implementiert!</strong> ? ? ?&nbsp;&nbsp; Vielen Dank! :bow:</p>

Bei der nächsten Support-Anfrage werde ich diesen Beitrag verlinken. Vielleicht hilft es ja... ?

Zeitstempel: 29.04.2021, 18:41 CET

Alles zur neusten alpha-Version im Zusammenhang mit PHP 8.0.3

aktueller Entwicklungsstand

Bemerkungen zu der aktuellen Version

Autoupdate durchgeführt... BOAH EY! Das neue Bootstrap-Theme B46 hat aus meiner Sicht viel Potential! Ich mochte Bootstrap schon vorher, denn das bietet u.A. ein Hamburger-Menü für mobile Browser ?.... ?

Im Live-Blog wird mir die V3.2.0 noch nicht angeboten. Da muss ich wohl noch einen Tag warten...

Habe zuerst alle Plugins aktualisiert und danach die neusten styx-master Daten heruntergeladen und installiert.

Auffälligkeiten oder Anmerkungen folgen in den Kommentaren