Weblog Kommentare
Styx V3.4.0 und PHP 8.0.5
Beat Post author am |
Heute ist mir zum zweiten Mal aufgefallen, dass es bei Upgrades des ckeditor-Plugins (bei mir) ein Problem gibt. Folgender Fehler wird angezeigt:
Warning: ZipArchive::extractTo(/XXX/plugins/serendipity_event_ckeditor/ckeditor/lang/bg.js): Operation failed: Operation not permitted in /XXX/plugins/serendipity_event_ckeditor/serendipity_event_ckeditor.php: 106.
Administrative Login Error Warning only - not seen by visitors! Send us a note what happened where and when, please.
Wenn ich mit FileZilla das Verzeichnis betrachte, sehe ich eine 770-Berechtigung (wie bei allen anderen Plugin-Verzeichnissen auch).
Dies passiert nur auf dem Manitu-Server (www.beatsblog.ch). Ich gehe deshalb schon davon aus, dass es sich um einen Berechtigungsfehler handelt, da ich dort ja irgendwie ein Kuddelmuddel habe. Hier laufen die Updates ohne Probleme durch.
Ian Styx am |
Jo, hört sich stark danach an. Geschieht das nur für die Datei lang/bg.js ? Welche file Berechtigung hat sie denn? (Vielleicht auch im Gegensatz zu anderen.)
War das das upgrade auf 4.16.1.0 oder geschah das von 4.16.1.0 auf 4.16.1.1 ? Letzteres sollte ja gar kein entzippen benötigen..
Beat Post author am |
Berechtigung 660
Bei den zwei letzten Updates. Also 4.16.1.0 und 4.16.1.1
Es wurden jeweils eine ganze Reihe Files angemeckert (geschätzt um die 10). Es wird dann auch nicht die ckeditor-Konfig-Oberfläche angezeigt, sondern eine Fehlerseite (von welcher ich die obige Warnung kopiert habe).
Ich bin mir jetzt halt nicht sicher, ob der Upgade erfolgreich war oder nicht. Die Plugin-Version wird als 4.16.1.1 angezeigt.
Ian Styx am |
Ah so, hatte mich schon gewundert das es nur eine Datei betrifft. 🙂
Hm! Müsste das nicht 644 bzw 664 sein?!
Und dann kann man im Plugin ja auch manuell das entzippen anstossen.
Beat Post author am |
Danke für den Hinweis mit dem Entzippen. Nach dem Drehen von ein paar Berechtigungsschrauben hat es dann auch geklappt.
Blöd ist halt nur, dass ich dabei nach try-and-error vorgehe und nun auch nicht wirklich genau sagen kann, welche Einstellschraube den Erfolg brachte. Ich verstehe den Unterschied zwischen "Besitzer" und "Gruppe" halt einfach nicht. 🙄
Egal. Nun hat es geklappt und ich bin gespannt auf den nächsten Update des ckeditor-Plugins.
Schönen Sommer! 🌞
Beat Post author am |
Ich weiss nicht mehr, wo der entsprechende Kommentar ist, an den ich folgende Info anhängen könnte:
PHP-Mail funktioniert nun auf dem migrierten Server von Hostttech (also hier) wieder!
Seit wann genau dem so ist, kann ich nicht beantworten, da schon länger keine Kommentare (die E-Mail-Benachrichtigungen auslösen) mehr geschrieben wurden.
Manche Probleme lösen sich durch warten... 🙄😆
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!