Sonntag, 5. September 2021
Styx 3.5.0 und PHP 8.0.7
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. 😉
Trackback-URL für diesen Eintrag
Dieser Link ist nicht aktiv. Er enthält eine kopierbare Trackback-URI, um manuell ein Ping- und Trackback zu diesem Eintrag für ältere Blogsysteme zu generieren; zB (immer noch valide) über das zur Verfügung gestellte Eintragsfeld des serendipity_event_trackback Plugins. Serendipity und andere Blogsysteme erkennen die Trackback-URL heutzutage aber automatisch anhand der Artikel-URL. Die Trackback-URI für ihren Link des Sender-Eintrages lautet daher wie folgt: »https://www.blog.dokumenzi.ch/2663-Styx-3.5.0-und-PHP-8.0.7.html«
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Ian Styx am :
Dann werde ich dich noch ein wenig im Dunklen tappen lassen....😀
Ian Styx am :
Ei - wie doch die Zeit vergeht... 💡
Hast du den 🌃 Schalter inzwischen gefunden ... oder irrst du noch umher ?
Beat Post author am :
Ich hab's mal gesucht, nicht gefunden und dann wieder vergessen... 🙄
Mittlerweile bin ich mir auch nicht mehr sicher, ob ich verstehe um was es bei "Dark Mode" wirklich geht. Ich habe das bisher nie benutzt und kann deshalb nicht auf Erfahrungen zurückgreifen. Ich dachte, dass jemand den "Dark Mode" nutzt um entweder die Augen zu schonen (weniger blaues Licht des Monitors) oder um nachts (oder bei dunkler Umgebung) mit weniger Kontrast konfrontiert zu werden. Deshalb ging ich davon aus, dass der Webseitenbesucher "per Klick" den Dark Mode ein- und ausschalten kann. Oder, dass ein Browser-AddOn die gesamte Anzeige quasi Ortszeitabhängig umstellt.
Die Browser-Idee habe ich verworfen, denn dafür hättest Du ja nicht einen Styx-eigenen Dark Mode entwickeln müssen, da diese Browser-AddOns wohl einfach die Farben auslesen und negativ/komplementär darstelllen. Was aber auch nur eine Annahme ist, da ich selbst noch nie mit einem solchen AddOn experimentiert habe.
Auf dem Styx-Frontend habe ich nichts gefunden. Das heisst, ich habee keine Möglichkeit gefunden, wie ein x-beliebiger Besucher zwischen normalem Mode und Dark Mode umschalten kann.
Das Einzige was ich fand, war im Backend bei den Benutzereinstellungen. Da kann ich den Schalter "Styx Theme Dark Mode" auf "Ja" stellen und dadurch wird das Backend für mich als Benutzer dann auch im Dark Mode angezeigt. Auf das Frontend hat dies jedoch keinen Einfluss.
Das ist also mein aktueller Wissensstand.
Wie gesagt. Ich habe keine Erfahrungen mit einem DarkMode und deshalb ist es mir auch nicht wichtig. Und weil ich es nicht kenne, kann ich es auch nicht vermissen. 😏 Einmal pro Woche habe ich hier oder im ophian-Forum vorbeigeschaut um zu sehen, ob es neue Infos dazu gibt.
Beat Post author am :
Möglich wäre natürlich auch, dass dies mit dem PURE-Theme zusammenhängt und ich die entsprechenden Änderungen/Neuerungen nicht in mein PURE-BEAT-Theme übernommen habe.
Ian Styx am :
Ja darum gings. Ganz simpel: Das Backend theme in Dunkel! 😄
Alles andere ist mir ja auch nur bedingt zugänglich, denn wie sollte ich einem customized frontend theme einem Dunkel Modus geben..., was an sich ja ginge, wenn es nur eines der default themes wäre; doch alle eventuellen user styles wären davon unberührt. Zuviel noise um das wirklich gehaltvoll meinerseits zu beeinflussen. Immerhin wäre es schick, vielleicht dem standard (pure) theme auch einen beispielhaften Dunkelmodus für Besucher zu geben ... und vielleicht mache ich dies auch eines Tages.
Trotzdem - wenn dir im Backend irgend etwas auffällt - was noch nicht dem Dunkel pattern unterworfen ist - bitte melden! ☺ Der "Durchsuchen" upload button ist ein ein solcher, der aber nicht von mir geprägt werden kann. Er ist vom Browser Client-seitig gestyled.
Beat Post author am :
Aha! 😎
Für wirkliche Tests dürfte ich aber der Falsche sein. Ich habe auf https://styx.beatsblog.ch/ damit herumexperimentiert. Im Live-Blog werde ich das mit grösster Wahrscheinlichkeit nicht brauchen, denn ich mag schwarz auf weiss, mit starkem Kontrast 😏.
Das Einzige, was mir auf die Schnelle aufgefallen ist, dass das Infofeld über dem Beitrag nach dem speichern eines neuen oder geänderten Beitrags mit weissen Hintergrund erscheint. Aber wie gesagt: Ich hab's mir nur kurz angeschaut und für mich selbst als wenig praktikabel befunden.
Das soll Deine Anstrengungen in keinster Weise schmälern. Du weisst ja: "Was der Hund nicht kennt, das frisst er nicht." 😉 Ich müsste es wirklich mal ein paar Wochen einschalten und ausprobieren, bevor ich einen qualifizierten Kommentar dazu abgeben kann.
Ian Styx am :
Ja, das genau ist die zweite Ausnahme! So nun die eine als Button clientseitig generiert wird, basiert die iframe Backend Vorschau eines Eintrages auf dem Frontend theme und seinen templates und eben dessen styles.
Ich habe tatsächlich mit mir gerungen, ob ich es für den Dark mode einfach überschreibe, doch glaubte ich zuletzt, dass es dann doch so konsistenter sei und damit auch leichter verständlich. 🙄
Fühl dich bloß nicht gedrängt. Ich selber nutze fast nur noch den Dark Mode, außer vielleicht bei starker Sonneneinstrahlung, das heißt sehr selten. 😢
Beat Post author am :
Ich bin mir grad nicht sicher, ob wir vom Selben sprechen. Habe deshalb zur Verdeutlichung einen Screenshot in den Beitrag eingefügt. Guckst Du hier: https://styx.beatsblog.ch/2640-Styx-3.5.0-und-PHP-8.0.8.html
Ian Styx am :
Doch doch. Es ist ein iframe Fenster, in dem die Ausgaben vom preview_iframe.tpl template stattfinden. Und das können sein, die Eintrags-Vorschau, oder die messages der (erfolgten) Eintrags-Bearbeitung. Die preview_iframe ist als Fenster zum Frontend zwitterhaft zwischen dem Back- und dem Frontend angesiedelt, hat ihren Ursprung und damit ihre Auszeichnung aber im Letzteren.
Beat Post author am :
Upps! 🤨
Habe soeben festgestellt, dass ich alte Blogeinträge nicht mehr editieren kann. Dies ist hier der Fall, genauso wie auf dem Live-Blog und der Testumgebung auf dem Manitu-Server. Nachdem ich eine Beitragsnummer eingebe und Enter drücke, erhalte ich folgende Fehlermeldung:
Da es auf beiden Hostingumgebungen und mit Chrom- wie auch Firefox-Browser vorkommt, weiss ich jetzt nicht wirklich, wie ich den Fehler eingrenzen kann.
Ian Styx am :
Hmm.. Also bei beiden unterschiedlichen Hostern gleichzeitig? Sonst hätte ich darauf getippt, dass vielleicht Manitu irgendwelche "Wartungsarbeiten" macht, aber so ..... Das kann ja eigentlich auf nicht mit der 3.5 Version zusammenhängen, das es sonst ja die letzten 2 Wochen auch schon so gewesen wäre. Herumgerate: PHP update? Kein Apache/Nginx reload danach, oder ähnliches? Hat dein Betriebssystem ein Update bekommen und kann irgendetwas nicht mehr.... oder dein Browser.... (können die beiden Letzteren überhaupt damit zusammenhängen?)
Ich kenne die Meldung allerdings, zB wenn ich es irgendwie (aber sehr selten) schaffe, eine bestimmte Seite unter bestimmten Umständen, irgendwie aus einer Art Schlaf geholt zu haben, in dem dann der HTTP-Referrer (also die Absendeseite) nicht mehr gültig war. Das ist aber immer sofort weg, wenn man ein wenig herumklickt und dann genau dahin wiederkommt. Aber dass das auf zwei unterschiedlichen Hostern zu gleichen Zeit auftritt ist seltsam...
Beat Post author am :
Viele Fragen. 😉
Ich kann nicht wirklich sagen, ob es mit 3.5.0 zusammenhängt, da ich nur gelegentlich alte Beiträge redigiere, rsp. Rechtschreibfehler korrigiere. So bin ich heute im ersten Satz des Beitrags aus 2011 auf einen Grammatikfehler gestossen, den ich rasch korrigieren wollte. So bin ich auf den Fehler gestossen.
Ich habe es nun nochmals durchgetestet. Der Fehler tritt bei allen Installationen, bei allen Hostern, und bei jedem Browser (Edge, Chrome, Firefox) auf. Mein Vorgehen:
Wenn ich nun via die Schaltfläche "Sortierung" auf 100 Beiträge pro Seite umstelle und soweit zurückblättere, dass ich den Beitrag aus 2011 anklicken kann, dann kann ich den Beitrag ohne Fehlermeldung bearbeiten.
Aufgrund dieser Tests denke ich, dass das Problem irgendwie mit "Eintrag bearbeiten #" zusammenhängt.
Ich kann dies sogar auf https://www.styx.dokumenzi.ch/ reproduzieren, wo es gesamthaft nur 20 Einträge gibt. Sobald ich über die Beitragsnummer einen Eintrag editieren will, erhalte ich die Fehlermeldung. Dabei spielt es keine Rolle, wie alt dieser Beitrag ist.
Ian Styx am :
Gerade mal getestet hier auf styx.doku 2. Beitrag, ohne diese Meldung und alles OK - ohne die # Geschichte allerdings. Das werde ich Morgen in Ruhe mal machen... hört sich merkwürdig an....
Ian Styx am :
Ich danke dir! Das war tatsächlich ein regression Bug. Bzw., hatte ich einfach vergessen, dass ich den entries access abgesichert hatte. Da es im entsprechenden Template aber 2 form Elemente gibt, vermisste das Erstere (für die Filter) den token. Bitte schau dir den Commit an. Es ist sehr leicht selbst nachzutragen, denn ich werde deswegen wohl vorerst kein minor Update machen.
Beat Post author am :
👍 Passt!
Habe im Live-Blog die entries.inc.php entsprechend angepasst/erweitert und nun funktioniert das editieren via Blogpost-Nummer wieder einwandfrei. Danke! 👋
Ian Styx am :
Moin Beat.
Ich habe gerade einen blöden Bug gefixt, der verhinderte, dass die Theme Konfiguration seit der 3.5.0 gespeichert werden konnte. Mehr darüber in den Discussions.
Beat Post author am :
Danke für die Info. 👍
Mich betrifft das nicht, da ich die Theme-Konfiguration (resp. die Menüleiste) in den letzten Monaten nicht verändert habe und wohl auch nicht so schnell etwas daran ändern werde. Ich habe die nötigen Änderungen deshalb nicht übernaommen und warte damit bis zum nächsten Styx-Update.
Ian Styx am :
Das dachte ich mir schon 🙂
Aber als allgemeine Info ist es gut zu gebrauchen. Ich schwanke immer noch ob ich nicht zwischenzeitlich doch noch ein Point Bugfix-Release rausgebe, da PHP 8.1 erst gegen Ende November erscheint und Styx 3.6 u.a. darauf und auf der kompletten Einarbeitung des neuen AVIF (AV1 Image File) supports beruht. Das wird im Übrigen etwas auf das man sich wirklich freuen kann, denn der Quantensprung ist nochmal ähnlich zu dem von WebP.
Oder ich gebe die 3.6 als grundlegende Vorbereitung anfang November heraus und schalte die Benutzung von AVIF dann erst mit 3.7 frei, ... mal sehen. 😷 🍁
Beat Post author am :
Nur so als Info: Die Versionen 3.6.2 und 3.6.3 wurden mir bisher in keiner Installation via Autoupgrade vorgeschlagen. Noch ist überall 3.5.0 im Einsatz.
3.6.0 und 3.6.1 gab es gar nie?
Ian Styx am :
Danke der Benachrichtigung.
Doch gab es.... aber nur kurz!
Tja und das lag daran, dass ich die Fehler schneller gefunden habe und dann (meistens) den autoupgrade pointer zurückgesetzt und die jeweilen release notes am Ende gelöscht habe. Es war aber auch irgendwie verhext die zwei Tage und die fatalen Fehler komischerweise alleine auf PHP 7 beschränkt von dem ich mich schon lange verabschiedet habe. Natürlich doof von mir, da das in der realen Welt ja genau umgekehrt ist. 🙄
Zum Autoupgrade - meine ich - müsstest du der Prozedur vielleicht noch ein paar mehr Stunden Zeit geben, je nachdem wann der letzte checkup war. Ich habe auf ein paar meiner DEV blogs jedenfalls schon den Sprung gehabt, auf anderen auch noch nicht. Und so hoffe ich das kein Fehler vorliegt.
Wir können das ja heute Abend noch mal überprüfen.
Beat Post author am :
Nach dem Update auf 3.6.3 kann ich hier keine neuen Beiträge mehr abspeichern. Ich erhalte folgende Fehlermeldung:
Diese Meldung wird mir in schwarzer Schrift auf dem DarkMode Hintergrund angezeigt. Ich konnte sie zuerst gar nicht sehen/lesen. 🧐
Hoffentlich gibt es diesen Fehler nicht auch im Live-Blog... Gleich mal testen.
Beat Post author am :
Glück gehabt! Im Live-Blog funktioniert Styx 3.6.2 mit PHP 8.0.8 👍
Hier ist PHP 8.0.11 im Einsatz. Ansonsten kann ich so auf die Schnelle keinen (noch nicht bekannten) Unterschied ausmachen.
Ian Styx am :
Arrrgh!! Das ist was ich mit verhext meinte. Es ist auf verschiedenen PHP Versionen sooooo unterschiedlich.
In include/function_entries.inc.php auf Zeile 1527 steht
Bitte ändere das mal zu
Ich habe es auch gerade nachstellen können, auf PHP 7.3 (ohne das der iframe mit der schwarzen error Meldung überhaupt erschien und ich im error log nachschauen musste).
Ja bitte hilf mit diese blöden Dinger auszumerzen. Es müssten -wenn- nur noch sehr wenige sein (hoffentlich).
(live blog 3.6.3 nicht 2 😉)
Beat Post author am :
👍 Funktioniert!
Ian Styx am :
Wunderbar! Danke. 👍 Ich warte noch ein wenig mit dem neuen Release-Update ....
Was mir komisch vorkommt ist, dass hier 8.0.11 vorliegt und auf dem LIVE blog PHP 8.0.8 und der Fehler trotzdem und bzw eben auch nicht auftrat. Das hatte ich gar nicht so realisiert.
Ist es vielleicht doch nicht nur auf PHP 7 beschränkt..? Und inkludiert es eventuell auch noch die verschiedenen Datenbankversionen selbst?
Wie auch immer, jedenfalls sind es alles Sachen die vorher einfach nur gnädigerweise und stillschweigend durchgewunken wurden, und liegt an dem Bemühen von PHP all die Jahre des genügsamen laissez-faire, das PHP in den guten alten Zeiten eben auch groß gemacht hat, bis in die Untiefen der Typisierung konsequent den heute gültigen Regeln der guten Programmierung anzupassen. Damit sind sie schon mächtig vorangekommen!