Kommentare von

beats TEST blog

Weblog Kommentare

Styx 3.7-beta1 und PHP 8.0.13

Ian Styx am |

Zur Info: Du wirst leider nicht umhin kommen vor dem nächsten Update deine Zusätze nochmal zu überarbeiten, da dein beat theme seine Original styles ja aus dem pure parent theme bezieht. Ich habe die letzten Tage das dark theme Präfix getauscht. Eigentlich musst du in deiner user.css nur den  .dark-theme selector in das neue Präfix  [data-dark-theme="dark"] tauschen (mit suche und ersetzen) und beim obersten statt 

.dark-theme { ... }
als 
[data-dark-theme="dark"] body { ... }
schreiben. Und natürlich das scriptlet ändern.

Beat Post author am |

O.K. Behalte ich im Auge. Mit dem "scriptlet" meinst Du wohl die index.tpl

Übrigens noch eine Kleinigkeit: Wenn man einmal in den Dark-Mode gewechselt hat und wieder zurückwechselt, bleibt das Kommentareingabefeld "dark". Zumindest bei mir. (Mein Browser ist nicht auf Dark-Mode konfiguriert. Die Seite startet also täglich im Light-Modus. Das ändert nichts daran, dass das Kommentareingabefeld "dark" erscheint. Erst wenn ich den Browsercache lösche, wird es "light". Bis ich dann das nächste Mal auf Dark-Mode wechsle. Danach bleibt es wieder "dark")

Beat Post author am |

Weil der dark-theme selector ein class selector des body Elementes ist.

Das ist demzufolge nach dem nächsten Update nicht mehr so. Richtig? Dark-Mode ist dann eine ganz eigene Klasse.

Beat Post author am |

Danke für die Hilfestellung! 👍

Ich habe das noch nicht angepackt, weil mein Banner im Dark-Mode gar keinen Gradient hat sondern transparent geschaltet ist (ich nehme mal an, dass dadurch der body für die Farbgebung zuständig ist). Das muss ich wohl beim nächsten Upgrade berücksichtigen...

Was macht denn "

background-blend-mode: multiply;
"? Auf sehr hochauflösenden Monitoren ist mir schon aufgefallen, dass die Evo-Grafik mehrfach hintereinander dargestellt wird (wenn es der Platz zulässt). Das würde ich eigentlich gerne vermeiden.

Ian Styx am |

Nein. Mit scriptlet meine ich das javascript das den button event steuert.

Das CKE textarea Feld Problem beim Mode-Wechsel habe ich inzwischen gelöst. Das liegt daran dass das ein iframe mit eigenen cke styles ist, die nur beim reload der Seite Rücksicht auf den aktuellen dark/light mode nehmen. Ich habe versucht wenigstens soweit einen workaround zu schreiben das wenigsten das Schreibfeld und der toolbar Hintergrund auf einen Wechsel ohne Seitenreload reagieren. Browsercache löschen ist sowieso unnötig, F5 reicht.

Ian Styx am |

Genau. Der neue attribute Präfix wandert in das < html > Element.
(Das war nötig wegen den neuen dark mode scrollbar styles)

Ian Styx am |

Dafür ist 

background-blend-mode
nicht zuständig (ein Verfahren zur Vermischung von Hintergrundbildern und -farbe).
Was du meinst wäre ein background attribute "no-repeat" Zusatz.
Du spielst doch gerne, insofern kannst du meine Beispiele doch einfach ausprobieren, sogar auch nur im Browser.
Dann siehst du was beim Wechsel von hell auf dark mode anders ist.

Das waren ja auch keine Endergebniss sondern nur Beispiele für deine bluebox ... 😀

Beat Post author am |

🙄 mea culpa! 😇

Ja, ich hätte es wirklich zuerst testen können/sollen...

Ich habe das heute nun endlich nachgeholt und die dunklere Variante dann gleich übernommen. Vielen Dank! 👍

Beat Post author am |

Etwas ganz anderes: Das "Statische Seiten"-Plugin wurde mehrfach upgedatet, ohne dass ich das wirklich beachtet hätte. Nun ist mir aufgefallen, dass ganz oben rechts ein "Backend Template" ausgewählt werden kann. Es gibt dort 3 Varianten (Default, Responsive, Custom) und hier, wie auch im Live-Blog steht die Einstellung auf "Responsive Template". Ich verstehe das nicht wirklich. Worauf bezieht sich das?

 

Und: Ich habe am Ende der Frontseite ein paar umtf8mb4-Emojis angefügt. Hier werden mir die Emojis korrekt angezeigt und im Live-Blog sehe ich nur fünf Fragezeichen. Hmmm... 🤔 Zeichensatzkonvertierung... komisch...

Nachtrag: Es war tatsächlich so, dass in der DB des Live-Blogs die Textfelder der staticpages-Tabelle auf utf8_unicode_ci standen (vermutlich habe ich diese Tabelle vom alten Serendipity-Blog so importiert). Habe die Kollation nun auf utf8mb4_unicode_ci umgestellt und nun klappt es auch dort mit den Emojis. Das hat sich also erledigt. 👍

Ian Styx am |

Ah super. Trotzdem werden wir nicht umhin kommen deine Backupstrategie mit deinen tatsächlichen Tabellendaten und PhpMyAdmin nochmals genauer zu untersuchen, damit im Falle ein Export auch wirklich klappt. Ich finde es immer noch schade dass da so viel verloren ging (und manches Fragezeichen nur im Kontext und das auch nur von uns beiden zu verstehen ist).

Zum Statische Seiten Plugin. Ähem! Das ist da schon sechs Jahre!
Früher gab es nur das Standard (default) template für das statische Seiten Eintragsform. Simpel ausgedrückt, ein Formular das aus einem Hauptteil und einem Seitenteil besteht. Das ist aber schwierig zu handeln wenn man es responisiv machen will. Deswegen habe ich damals das responsive Template entwickelt und es zum neuen Standard gemacht. Das default template gibt es also nur noch aus Kompatibilitätsgründen. Ich denke dass das heute niemand mehr nutzen will. Das custom template ist ein erweitertes responsives template mit einer custom Abteilung, in der sich Optionen verstecken, die das Plugin selbst (als Erweiterungen des Normalen) in seinen Untiefen hergibt. Sozusagen die extended version. 😀

Ian Styx am |

Ich würde inzwischen background-blend-mode und background-size: cover wieder rausnehmen. Wenn das Bildschirmfenster groß bzw breit wird, hat das unangenehme Folgen. Und dafür lieber ein background-repeat: no-repeat; einsetzen.

Beat Post author am |

Zu utf8 - utf8mb4:

Man muss unterscheiden zwischen hier (hosttech) und Live-Blog (manitu).

Hier (hosttech) sind alle Emojis mit Erstelldatum vor dem 07.05.2021 (Serverumzug) unwiderruflich weg. Seither habe ich keinen Backup mehr gemacht (und scheue mich auch davor).

Der letzte Backup des Live-Blog (manitu) wurde am 06.01.21 gemacht. Die exportierte DB habe ich zu Testzwecken wieder importiert und die Emojis blieben erhalten. Anfang 2022 möchte ich dort den nächsten Full-Backup machen und werde dieses Verhalten dann mit einem Export aus beatsblog.ch und einem Import auf styx.beatsblog.ch vorgängig testen.

Das oben geschilderte Problem mit den statischen Seiten kam wohl davon, dass ich die DB-Tabellen der alten Serendipity-Original-Installation als Ganzes in die Styx-Installation übernommen habe. Das heisst: Ich habe nicht den Inhalt der alten Tabelle in die neue (leere) Tabelle importiert, sondern gleich die ganze Tabelle ersetzt. Das verursachte den Fehler, weil dadurch die alten Zeichensatzinformationen natürlich mitkamen.

Die Frage zu den Templates der statischen Seiten kam daher weil ich mir überlege, www.bikebutler.ch abzuspecken und von Joomla! nach Serendipity zu migrieren. Dafür würden dann einige statische Seiten als Eltern- und Kind-Seiten benötigt und deshalb habe ich mir die Möglichkeiten der statischen Seiten etwas genauer angesehen. Der grösste Knackpunkt an der Idee ist jedoch die Online-Gutscheingeschichte, die mit einer Joomla!-Extension sehr gut funktioniert. Da habe ich keine Ahnung, wie ich das ohne Joomla! lösen könnte. Aber das ist ein ganz anderes Thema...

Beat Post author am |

Danke für den Hinweis. Das habe ich nun so umgesetzt. Ich kann das leider nicht testen, da mein Laptop-Monitor keine wirklich riesige Auflösung hergibt.

Ian Styx am |

Eine Joomla!-Extension ist doch auch nix weiter als eine Art Plugin, oder?
Müsste man sehen ob man die wesentlichen Sachen nicht einfach in ein eigenes Serendipity Plugin portieren kann.. meld dich einfach wenns konkret ist, dann schau ich (vielleicht) mal... 😉

Oh, das ist eine gute Info mit dem Live Blog. Dann hast du ja konkrete Vergleichsmöglichkeiten.

Ian Styx am |

Ist ok. Allerdings hast du den light mode vergessen.

Beat Post author am |

Hmmm... das ist tricky (oder: ich scheitere wieder einmal an meiner Inkompetenz).

Sobald ich im Light-Mode

background-blend-mode: multiply;
background-size: cover;

entferne, wird im Dark-Mode die Grafik nicht mehr dargestellt (oder hinter dem Background). Ich weiss, dies klingt unglaublich, doch ich habe es mehrfach versucht und bin immer wieder gescheitert.

Ian Styx am |

Tja lustig...

Mache einfach im "light mode"

background-image: url(/uploads/bb-head_1024.png) !important;

Die background Kurzform ist einfach ein container für die verschiedenen sub-attribute und gleichzeitig höherwertig als seine Einzelteile. Ich nehme an das da irgendwer irgendwen überschreibt, obwohl er ja alle Attribute hat. Vielleicht sind sie nur falsch angeordnet...?! 🙄

Styx 3.7.0 ist released!

Edit: Übrigens Danke für die richtige "lässig" Interpretation und Korrektur. Das muss Gedanken Übertragung gewesen sein! 😚

Beat Post author am |

Styx 3.7.0 ist released!

Wird mir im Live-Blog angeboten, hier aber noch nicht. Ich kann ja schon mal diese Änderungen angehen:

Eigentlich musst du in deiner user.css nur den  .dark-theme selector in das neue Präfix  [data-dark-theme="dark"] tauschen (mit suche und ersetzen) und beim obersten statt 

.dark-theme { ... }
als 
[data-dark-theme="dark"] body { ... }
schreiben. Und natürlich das scriptlet ändern.

Beat Post author am |

Ne, ich kriege es nicht hin. 😕

Mit dem !important im light mode ist dann zwar im Dark-Mode die Grafik da, doch der background-Gradient ist dann weg. Und der gefällt mir super. Darauf möchte ich nicht verzichten.

Das hat mir irgendetwas anderem zu tun. Wenn man rasch zwischen Light- und Dark-Mode umschaltet sieht man auch, dass die Grafik leicht andres positioniert ist. Vielleicht hat es etwas damit zu tun (ganz zu unterst in meiner user.css):

@media screen and (min-width: 540px) {
  
#serendipity_banner {
    display: initial;
    position: initial;
    top: initial;
    padding-bottom: initial;
	}
}

🤔

Ian Styx am |

Ok wie bereits vermutet ist es die Reihenfolge. Im light mode setze:

#serendipity_banner {
    background-image: url(/uploads/bb-head_1024.png);
    background-repeat: no-repeat;
}

und im dark mode

.dark-theme #serendipity_banner {
    background: url(/uploads/bb-head_1024.png), -webkit-linear-gradient(bottom, rgb(2, 2, 54) 16%, rgb(140, 140, 150) 100%);
    background: url(/uploads/bb-head_1024.png), linear-gradient(0deg, rgb(2, 2, 54) 16%, rgb(140, 140, 150) 100%);
}

 

Ian Styx am |

Die Verschiebung ergab sich durch das size cover.

Doch auch mit den neuen Styles ist noch eine kleine Verschiebung da. Du wirst es sehen. Und wenn man genau hinschaut sieht man auch warum, denn man muss das Große und Ganze im Auge haben. So viel zum heutigen Tagesrätsel. 😋

Beat Post author am |

  

Danke für die Hilfe. 👍

Sobald ich im CSS des Light-Modes

background-blend-mode: multiply;

rausnehme, verschwindet die Grafik im Dark-Mode. Also bleibt das nun drin.

Wie Du unten richtig geschrieben hast, kam die Grafik-Verschiebung von:

background-size: cover;

das habe ich nun rausgenommen. Jetzt passt es mir! Danke!

Ian Styx am |

Jupp, aber du hast nicht genau hingeschaut. Die beiden rules waren der komplette Ersatz und die Frage der Reihenfolge im background container: erst das image url, dann linear gradient!

Beat Post author am |

Peinlich. 😶

Habe es jetzt hier so gemacht und ja, dann kann

background-blend-mode: multiply;

raus. Interessanterweise ändert dann die Farbe der Grafik. Nun wird sie im Dark-Mode im Original mit #060689 dargestellt. Im Live-Blog habe ich noch die user.css mit dem multiply drin und da dunkelt die Grafik-Farbe dann ab. Gefällt mir fast eine Spur besser als hier.