Freitag, 5. September 2025
Styx 5.0-rc1 und PHP 8.2.29
Mit der Änderung der serendipity_admin.php hat nun auch der Upgrade auf rc1 geklappt.
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/2704-Styx-5.0-rc1-und-PHP-8.2.29.html«
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Ian Styx am :
👍😃
Beat Post author am :
Seit ein paar Tagen stelle ich beim History-Plugin ein komisches Verhalten fest. Wenn ich da auf einen Link klicke, so wird mir der gewünschte Beitrag angezeigt, doch der Fokus verschiebt sich sofort auf die Cursor-Position im Kommentarfeld. Das heisst: Um den Beitrag zu lesen, muss ich zuerst wieder hoch zum Titel scrollen.
Dies ist interessanterweise nicht immer so. Aber, ich kann es auf beiden Servern beobachten. Ich denke, das hat etwas mit dem neuen Editor zu tun, der wie ein Ankerpunkt wirkt.
Kannst Du das bitte mal testen ob Du das reproduzieren kannst? Wenn ja, würde ich es natürlich begrüssen, wenn der Anker auf dem Beitragstitel liegen würde (so wie früher).
Ian Styx am :
Hi Beat
Ich kenne das Verhalten. Es liegt daran, dass eben jenes Javascript frame des Editors einen Auto-Fokus hat. Dies ist eigentlich ein erwünschtes Feature, hat aber den Nachteil eben immer als letztes bei jedem Seitenaufruf eines Artikels mit Kommentarfeld abgefeuert zu werden und neigt deshalb dazu vorherige Ankerpunkte, so überhaupt vorhanden, zu überschreiben. In diesem Fall der History Links gibt es ja nicht einmal einen # Anker, so auch wenn man einen Artikel aus der Artikelliste (entries) als einzelnen Artikel aufruft. Soweit ich erinnere, habe ich für jene mit Anker Ausnahmen erschaffen, zb für die reply links. Ich habe bisher noch keine halbwegs saubere Lösung für das auftretende Verhalten/Problem mit vollständig neuen Links gefunden.
Leider ist es mir zur Zeit nicht möglich mich damit auseinanderzusetzen. Ich werde einige Zeit brauchen um halbwegs wieder arbeitsfähig zu werden (Computerprobleme). Solange muss das warten.
In der Zwischenzeit sammele bitte weiter alle Punkte wo dies klappt bzw eben nicht. Und was man eventuell dagegen tun könnte....
Gibt es das im Backend auch? Oder ist dies nur ein reines Frontend Problem?
Beat Post author am :
Schön, von Dir zu lesen. Habe mir schon fast Sorgen gemacht. 👋
Sch... 💩
Ähm. Ich verstehe die Frage nicht richtig. Im Backend? Nein... Ich kenne jedoch auch nur im Frontend Links auf einzelne Artikel (Comments-, History- und Imagesidebar-Plugin).
Interessanterweise geschieht diese Fokusverschiebung auf den Editor nur bei Plugins. Wenn ich sonst im Blogfrontend, z.B. via "Archiv" oder "Suche" oder Anklicken der Artikel-Titelzeile auf einen einzelnen Artikel zugreife, dann geschieht dies nicht.
Beat Post author am :
Hilft Dir das irgendwie?
Ian Styx am :
Ah Danke. Wahrscheinlich hilft das wirklich das Problem näher einzugrenzen. Es ist sogar noch näher zu beschreiben als irgendwie related zum aktiven (Re-)load der Seite.
In manchen Situationen scheint das Javascript das den Auto Fokus des Editors überschreibt noch nicht (re-)aktiv zu sein. Erst beim zweiten Seitenaufruf tut es was es soll. Und trotzdem verliert es manchmal diese Reaktionsfähigkeit und ist dann wieder erst beim zweiten Mal aktiv.
Ich kann noch nicht sagen ob dies nur an einer bestimmten Stelle geschieht (für die man dann vielleicht eine Ausnahmebehandlung schreiben könnte) oder ein generelles Problem aufgrund der nachträglichen Behandlung auf Userseite per Javascript ist.
Ich teste das hier mit den Kommentaren und mit den History Beiträgen und bin zur folgenden Beobachtung gelangt.
Klicke ich auf Kommentare die früher (also weiter oben) geschrieben wurden kann man dieses Verhalten erproben. Wenn ich zb nur bei den History Beiträgen herumklicke (also mehrere nacheinander anwähle) kann ich, solange es einmal richtig funktioniert hat, stabil weiteragieren ohne das der Editor Fokus aktiv wird und alles nach unten zieht. Wechsel ich dann zu einem (früheren) Kommentarlink aus dem Kommentar Seitenleistenplugin fällt der Fokus wieder herunter. Nutze ich den selben Link noch einmal ordnet sich alles richtig und bleibt für die Kommentare stabil, solange diese sich auf den selben Blog Artikel beziehen. Sobald ich zu einem Kommentar eines anderen Artikels linke fängt das Spiel von Neuem an.
Ich habe das Gefühl, dass wenn man dieses noch intensiver testen würde könnte man diesen Bruch im Verhalten recht genau bescheiben und damit auch eine Idee bekommen wo man für eine Verbesserung/Fix ansetzen könnte.
Es sieht also so aus, als ob die Ursache aus zwei Gegebenheiten besteht:
1. Dem aktiven Reload bzw Zugang zur Seite, so dass die Javascript Resourcen geladen und aktiv sind und
2. Dem Wechsel zwischen Artikeln und dem Wechsel zwischen den Links der beiden Plugins (was ja auch allermeist ein Wechsel des Artikels ist)
Ich kann bisher nur ahnen das es eventuell in diese Richtung gehen könnte und wäre dankbar wenn du das Verhalten weiter beobachtest und vielleicht so bestätigen kannst, dass wir definitiv sagen können wo der Bruch reproduzierbar stattfindet und wo nicht (zB auch in Relation mit anderen Links deiner Seite).
Nachtrag 1: Ein Seitenreload über F5 ist auch noch einmal anders als das aktive Absenden eines Links im Browser Adressfeld und scheint diesen Bruch auch zu erzeugen (außer beim Wechsel des Artikels (wie beschrieben). ..... Verwirrend 🤕
Nachtrag 2: Wann tritt denn genau der Fall auf dass die History Links sich ins Kommentarfeld fokussieren?
Nachtrag 3: Das die Links mit einem #Anker (zB verschiedene Kommentare eines Artikels nacheinander funktionieren ist sehr wahrscheinlich einfach der Tatsache geschuldet, dass diese eben keinen wirklichen Seitenreload auslösen, sondern nur so eine Art Verlinkungssprung innerhalb der aktuellen bereits stattgefundenen Seitenanforderung sind. Da ist dann der Editor bereits initialisiert und wird nicht erneut ausgelöst. Deshalb klappt das dann auch, da kein automatischer Re-Fokus stattfindet. Bei einem Wechsel des Artikels erfolgt ebenso wie bei F5 ein neuer Load der eben auch den Editor Fokus wieder aktiviert. Wenn ein Link keinen Anker hat (sollte bzw) tritt mein Workaround in Kraft der wieder nach oben scrollt. Siehe: if (!h) { $(window).on('load', function () { $('html, body').animate({ scrollTop: 0 }, 'smooth'); }); } Allerdings stelle ich bei mir lokal fest, dass es durchaus Probleme gibt oder "altbekannt" geben kann, wenn dies in einem inline script so wie momentan stattfindet (jedenfalls bei Mozilla). Ich hätte also vielleicht eine Lösung die wir bei dir dann mal ausprobieren könnten, um zu sehen ob sie die eigentlichen Probleme beseitigt ohne neue zu schaffen... Aber ich warte erstmal ab was du zu meinen Beobachtungen sagst und ob du Weiteres anfügen kannst.
Ian Styx am :
Versuche bitte meine allzu lange vorige Erklärung mit allen Nachträgen trotzdem noch zu lesen und enthaltene Fragen zu klären... aber ich habe dir etwas hinterlassen.😌
Beat Post author am :
Das ist alles sehr verwirrend und ich erhalte den Eindruck, dass es auch unterschiedlich ist. Ich habe jetzt etwa 20 Minuten im Live-Blog herumgeklickt und ich hatte die Fokusverschiebung auf den Editor jeweils nur ein Mal bei einem Klick auf einen Link in einem Seitenleisten-Plugin. Danach konnte ich herumklicken wie ich lustig war, der Fokus blieb jeweils beim Beitragstitel. Ich habe das dann auch noch mit dem Chrome-Browser getestet, mit dem gleichen Ergebnis.
Schwierig wird es bei Klicks auf Links im comments-Plugin, da hier der Fokus ja auf dem angeklickten Kommentar liegt und (bei meinen wenigen Kommentaren) dieser jeweils ganz nah am Editor-Feld liegt.
Hmm... Das ist eine blöde Sache.
Soll ich die hinterlegten Änderungen in der index.tpl noch einspielen (hier und im Live-Blog)? Das könnte ich morgen Nachmittag tun.
Ian Styx am :
Ehrlichweise wird das nur marginale Verbesserungen bringen und dann gibt es immer noch Zustände die damit wohl nicht abgedeckt werden. Jedenfalls war das meine Erfahrung ....
Abends dachte ich immer ich habe es jetzt und morgens stellte ich fest das es doch nicht stimmte.🤪
Deshalb habe ich letztendlich aufgegeben und versucht diesen editor focus ganz zu unterdrücken. (siehe meine heutigen commits)
Trotzdem wüßte ich gerne wann bei dir ein link click aus dem history plugin direkt nach unten in den editor gescrollt hat, denn das hätte eigentlich auch mit der jetzigen Formnicht passieren dürfen (meine ich).
Ian Styx am :
Ich bin nach reiflicher Überlegung letztendlich zum Schluss gekommen diesen Fokus im RichText Editor generell zu unterdrücken, auch im Backend. Er macht einfach mehr Probleme als er wirklich etwas an Vorteilen bringt. Jetzt muss man halt mit der Maus die textarea erst manuell fokussieren bevor man darin schreiben kann, so man denn will. Aber das ist m.E. das kleinere Übel !
👍Danke das du mich darauf gestossen hast mich damit erneut zu beschäftigen. Ich glaube es ist jetzt dann wirklich besser, und die RC2 oder final kann in ein paar Tagen herausgegeben werden.
Beat Post author am :
Entschuldige, dass ich derzeit nicht mehr so wirklich die grosse Test-Hilfe bin. Irgendwie fehlt mir dafür gerade die Motivation.
Nach ein paar zusätzlichen Tests kann ich noch folgende Aussage machen. Das Problem tritt immer dann auf, wenn ich nach dem Aufruf von beatsblog.ch zum ersten Mal einen Link im History-Plugin anklicke. Danach verschiebt sich der Fokus nicht mehr auf den Editor und ich kann beliebig alte Beiträge anklicken.
Beim Comments-Plugin springt der Fokus immer auf das Editor-Eingabefeld.
Danke! Das finde ich eine gute Idee!
Soll ich noch irgendwelche Änderungen hier einspielen oder kann ich bis zum nächsten Release warten?
Ian Styx am :
Leider habe ich anhaltende Computer Probleme und bin im Moment wieder total offline. Die RC2 bzw Final von Styx 5 muss also noch etwas warten. Leider.... 🥺
Ian Styx am :
RC2 ist draußen 😎☺️
Beat Post author am :
Und RC2 hat die Fokusverschiebung auf den Editor tatsächlich eliminiert. VIELEN DANK! 💯 👍
Ian Styx am :
JA das ist wesentlich besser jetzt. Danke für den PUSH!
Jetzt musst du nur noch das scriptlet deiner copy index.tpl anpassen wie im Changelog vermerkt.
Beat Post author am :
Ups!
Ich habe im Live-Blog zwei Beiträge nachgereicht und darin je einen Trackback zu einem früheren Beitrag gesetzt. Dann wollte ich im Backend beide auf einmal bewilligen. Darauf kriegte ich einen white screen mit folgender Meldung:
Ich konnte mich dann erneut im Backend anmelden und die beiden Trackbacks einzeln bewilligen.
Ian Styx am :
Oha! Super Fund!
Gerade gefixt und damit auch zum ersten mal ausprobiert ob ich langsam wieder Zugang zu den wesentlichen Sachen bekomme. Auch mental ...😂
Der fix ist ganz einfach in der 'include/functions_comments.inc.php in Zeile:1002': Finde das vierte Argument
und ändere es in
Damit sollten multi-trackback approvements wieder gehen, wenn es nicht eventuell einen Folgefehler gibt. Ich kann das momentan noch nicht selbst ausprobieren.
Ian Styx am :
Gerade getestet. Funktioniert ! ☺️
Ist dann im nächsten Release update, ... außer du testest diesen kleinen Fix selber.
Beat Post author am :
Ich warte wohl auf das nächste Release... 😉
Noch eine Kleinigkeit. Wenn man Bilder in die Mediathek hochladen will und den Button "Durchsuchen" klickt, öffnet sich das nachfolgende Fenster immer im Hell-Modus, egal, ob man im Backend im Darkmode unterwegs ist. Dann ist das kommende Fenster jeweils etwas grell 😎. Kann man das auch im Darkmode öffnen lassen?
Ian Styx am :
Ich meine das Thema hatten wir schon mal....
Nein das geht nicht. Jedenfalls nicht von meiner Seite.
Dieser Button ist ein Button deines OS Systems, ebenso wie das daraufhin sich öffnende Fenster, denn du bist da ja auf dem Dateisystem deines Betriebssystems, von dem du ja dann Dateien/Bilder auf den Server hochladen willst.
Beat Post author am :
Das kann ich so nicht bestätigen.
In keinem anderem als dem oben beschriebenen Fall sehe ich je ein weisses/helles Fenster.
Ian Styx am :
Wenn ich dich richtig verstehe...
Aber dieser button ist wirklich kein Styx Button. Er generiert sich aus der Anforderung etwas hochladen zu wollen und wird von deinem Browser auf deinem Betriebssystem bereitgestellt. Deshalb sieht er auch etwas anders aus als alle anderen Buttons.
https://www.mediaevent.de/css/input-type-file.html
Umso mehr das sich daraufhin öffnende Fenster. Auf Windows ist es sozusagen der Datei Explorer von Windows. Dito für andere Betriebssysteme. Da wird kein Fenster vom Server geschickt, sondern eher umgekehrt.
https://www.mediaevent.de/html/input-type-file.html
Mehr kann ich dazu auch nicht sagen ...als das ich keine Möglichkeit sehe mit geringen Mitteln dieses Uploadfenster zu stylen. Ich habe das auch irgendwann einsehen müssen und mich damit abgefunden. Aber vielleicht ist es ja doch mit relativ einfachen Mitteln serverseitig beeinflussbar... dann bräuchte ich aber wirklich Hilfe. 😏 Sicher lässt sich der Button sowohl als auch das Fenster irgendwie klonend mit Javascript Magie überschreiben und dann irgendwie beeinflussen ... nur ist der Aufwand dafür viel zu hoch, ebenso wie auch mögliche Nebeneffekte.
https://wiki.selfhtml.org/wiki/File_Upload
https://developer.mozilla.org/de/docs/Web/HTML/Reference/Elements/input/file
Solch einen Fall gibt es auch nicht woanders in Serendipity. Außer vielleicht wenn du ein serverseitiges Bilder Tool verwendest dass ebenso ein Uploadform bereitstellt. Ich nehme an das dein jAlbum oder wie es heißt bei dir über Javascript implementiert ist und somit alles auf deinem PC stattfindet bis du das Resultat auf einen Server sendest. Das wäre dann etwas anderes.
Beat Post author am :
Ich verstehe deine Erklärung. Danke dafür. Trotzdem... 🧐
Solch einen Fall (dass mir ein helles Dateimanager-Fenster angezeigt wird) kann ich auf meinem Linux-System sonst überhaupt nirgends finden.
Aber das ist ja auch egal oder zumindest eine rein kosmetische Geschichte mit der ich ohne Probleme leben kann. Störender finde ich nach wie vor die Auto-Fokus Geschichte des neuen Editors beim Aufruf einzelner Artikel.
Ian Styx am :
Genau. Also müsste man die Theme Ersteller deines lokalen Darkthemes fragen warum sich das auf Anforderung von input type="file" in komplett weiß öffnet.
Ich werde eine (zumindest bessere) Lösung finden für die Auto Fokus Geschichte...