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... 🙄😆
Ian Styx am |
Klasse!
... Abhandlung: ... (gelöscht) - Es ist einfach und kompliziert. Und auch noch unterschiedlich implementiert.
https://wiki.ubuntuusers.de/Benutzer_und_Gruppen/
https://debiananwenderhandbuch.de/gruppen-und-zugriffsrechte.html
Für den Webserver kommen dann also auch noch unterschiedliche PHP Arten (nicht Versionen) zur Geltung.
Einfach:
https://phlow.de/magazin/terminal/chmod-dateirechte-bearbeiten/
Beat Post author am |
Hat zwar nichts mit der aktiuellen Version zu tun, sondern ist ein altes Phänomen. Gestern und auch heute hat sich das History-Plugin auf www.beatsblog.ch wieder verschluckt. Komischerweise gleich zwei Tage hintereinander, nachdem es nun monatelang problemlos funktionierte (und auch hier problemlos funktioniert).
Ian Styx am |
Hmm. Neulich gab es das auch schon mal. Da war nur ein entry zu sehen, hier dafür mehr. Da ich keine Flattermänner aufscheuchen wollte, habe ich es (hier einfach) auf den unbereinigten Stundenversatz geschoben. 😁
Was das dann gestern und heute eventuell auch so ein Fall? Ansonsten spuckt es halt und keiner hat den Geist je zu Gesicht bekommen...
Alles gut soweit? Wie ich sehe musste deine Frau ja schon mal wieder LOB verteilen. 🤗 (Aus Ermangelung an anderen Kommentatoren die sich über deine wohldokumentierten Baufortschritte äußerten.)
Ansonsten nimmt der Styx DARK MODE Form an und scheint sich zu runden. Ich empfinde es als sehr wohltuend.
LG
Beat Post author am |
Es ist und bleibt ein Mysterium...🤔
Habe nun alle Beiträge des 26.07. angesehen. Im Vergleich zu hier, waren zwei davon 1 Std. zurückgesetzt (die Zeit in der Klammer am Ende der Zeile zeigt die Zeit hier).
26.07.2020 - 17:58 /2736-Jubilaeumsfahrt
ok = 26.07.2019 - 21:34 /2451-gleich-uebertreiben
26.07.2015 - 12:12 /2161-heisser-Juli
26.07.2012 - 22:59 /1914-In-Erinnerungen-schwelgen (23:59)
26.07.2011 - 22:54 /1789-hallo...
26.07.2011 - 22:46 /1788-43-Golf-von-Salerno-und-von-Neapel
ok = 26.07.2009 - 22:07 /1319-Sonntagstour
26.07.2009 - 22:04 /1318-wieder-daheim
26.07.2008 - 22:59 /1056-Faulhorn (23:59)
26.07.2007 - 22:42 /772-gut-genutzter-Tag
26.07.2006 - 22:38 /314-was-fuer-ein-Wetter!
Dubios ist halt, dass ich das history_daylist.dat auf dem Server löschen kann und danach wird mir ein neues, richtiges File erzeugt.
Egal. Solange das nicht häufiger vorkommt, stört es mich nicht sonderlich. Zudem haben wir schon so viel getestet und verbessert, dass wir diesem komischen Fehler wohl nicht auf die Spur kommen. Dies auch vor dem Hintergrund, dass dieser Fehler eigentlich immer nur auf der Manitu-Installation auftritt und hier nicht.
Ansonsten: Ja, es geht mir gut. 😎 Danke der Nachfrage. 🙏 An die homöopatische Menge der Kommentare habe ich mich in den Jahren gewöhnt. Ist halt vieles zu banal oder zu individuell, so dass es nicht zum Kommentieren anregt. Vielleicht sollte ich mehr Ratschläge erteilen oder Tipps und Tricks verraten. 🙄😆
Auf den Dark Mode bin ich ja mal gespannt. Ich muss gestehen, dass ich davon bisher nur gehört/gelesen, es bewusst aber noch nie wahrgenommen habe. Ich weiss noch nicht mal, ob man den Dark Mode manuell wählen muss oder ob er automagisch ein-/ausgeschalten wird. Wie gesagt - bin gespannt! 😇
Ich hoffe bei Dir ist auch alles in Ordnung und Du konntest Corona bisher erfolgreich ausweichen.
Ian Styx am |
Tja.... Sinn ist ja - kein Cache file oder abgelaufen, löst einen neuen DB Fetch aus. Da beide (ok) vom selben Tag sind, kann es eben sein, das es auch ein singulärer Entry war das den (unvollständigen) Fetch auslöste, so dass (möglicherweise) ein DB Cache vorlag und kein eigentlich neuer für die echte Hstorie generiert wurde. Es gibt einen solchen ja der ca 6 Minuten vorhält. Nur die genauen Umstände sind da bisher noch nicht reproduzierbar gewesen.
Edit: Ups! Da muss mir der Bill dazwischengefunkt haben. Als ich das schrieb hatte ich die vorherigen 2 zu sehenden Einträge im Sinn und mit deinen OK Einträgen, die ja etwas anderes beschreiben, zusammengemischt. Aber vielleicht ist es trotzdem etwas in dieser Richtung.
Ja soweit gut. Ich habe jetzt auch echtes intravenöses 5G vorliegen und kann sozusagen körperlich up/downloaden. Bill sei Dank, eine Rechnung weniger. Bing! Bing! 😄
Dafür habe ich bald Schwimmhäute. Ich mag diese schwüle Feuchte nicht!
Den Dark Mode muß man explizit anstellen. Alles andere - also automatisiert - wäre Quatsch!
Export/Import Datenbank
Ian Styx am |
Achtung lese auch im Backend.
Eigentlich sieht das ja entsprechend gut aus mit den 40101 Zeilen...
Bitte paste mal aus der dump.sql Datei die Datenbank-Struktur des comments tables als Beispiel. Vielleicht sind bei dir die Kollationen falsch gesetzt. Meine sieht zB. so aus:
CREATE TABLE `styx_comments` (
`id` int(11) NOT NULL,
`entry_id` int(10) UNSIGNED NOT NULL DEFAULT 0,
`parent_id` int(10) UNSIGNED NOT NULL DEFAULT 0,
`timestamp` int(10) UNSIGNED DEFAULT NULL,
`title` varchar(150) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
`author` varchar(80) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
`email` varchar(200) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
`url` varchar(200) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
`ip` varchar(64) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
`body` longtext COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
`type` varchar(100) COLLATE utf8mb4_unicode_520_ci DEFAULT 'regular',
`subscribed` enum('true','false') COLLATE utf8mb4_unicode_520_ci NOT NULL DEFAULT 'true',
`status` varchar(50) COLLATE utf8mb4_unicode_520_ci NOT NULL,
`referer` varchar(200) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL
) ENGINE=Aria DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci;
Auch wenn bei dir nur utf8mb4_unicode_ci stünde wäre noch alles in Ordnung. Alle Felder die etwas mit Text zu tun haben, also text oder varchar Felder, müssten eine Kollation für utf8mb4 aufzeigen. Selbst bei utf8mb4_general.ci, denn https://www.pixelfriese.de/unterschied-zwischen-utf8_general_ci-und-utf8_unicode_ci/
Wenn du den Dump in notepad++ betrachtest, müsste du an den Stellen an denen Emojis verwendet werden, ein kleines (umrahmtes) Kästchen sehen, a la "<p> 🔗 If you use issue" (in der Übertragung ist hier daraus ein Kettenglied geworden) das anzeigt, dass dort ein 4-Byte Zeichen hockt. Ist das nicht so kannst du schon recht sicher sein, dass du den Dump nicht zufriedenstellend verwenden wirst können.
Deinen Live Blog mt diesem Testblog zu vermischen ist auch keine wirklich gute Idee und führt zu Fehlern und Verwirrrungen, wie du schon erlebt hast.
Es ist eben durchaus möglich, dass dein dokumenzi blog gerade was die SQL Struktur angeht noch etwas bedürftig ist, denn es stammt ja aus der Zeit in der versucht haben einem System das noch nicht bereit dafür war einen entsprechenden Überzug zu verpassen und du demzufolge mit Strukturen und Inhalten herumexperimentert hast, will sagen: Dass es keine eigene neue Installation auf gefügigem Grund war, bzw nicht die in Styx gegebene Konvertierungs/Migrations Wartungsaufgabe einer alten DB benutzt hat.
Ian Styx am |
Im ersten screenshot der dumps (im linken) sieht man allerdings auch schon den Fehler! Da fehlen überall die Kollationen auch bei den einzelnen Feldern. Da steht zb nur "ENGINE=MyISAM DEFAULT CHARSET=utf8mb4". Beides ist in Ordnung. es fehlt aber das entscheidende, die Kollation. Die rechte Ansicht hat sie alle.
Ist das der der von hosttech gezogene Dump? Ach nee, da steht ja manitu. Wieso hat der denn fehlende Kollationen? Ich bin verwirrt. Wen hast du wie in was gesetzt?
Beat Post author am |
Tja, blöd. 😵 Der Screenshot links ist tatsächlich von der Manitu-DB. Ich habe beides Mal einfach mit phpMyAdmin einen Standard-Export der DB gemacht. Es könnte natürlich sein, dass die beiden Standards zwischen Hosttech und Manitu unterschiedlich sind.
Deine letzte Frage verstehe ich leider nicht.
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
$entry['comments'] = 0;Bitte ändere das mal zu
$entry['comments'] = (string)0;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!