Weblog Kommentare
Styx Version 3.4-DEV (05.03.2021, 10:16)
Beat Post author am |
PHP8?
Ich habe gesehen, dass Du die Styx-Edition schon weitgehend für PHP8 vorbereitet hast. Manitu bietet die neuste PHP-Version bereits an. Ich könnte also meinen Live-Blog auf PHP8 umstellen.
Hier, bei Hosttech, ist PHP8 noch nicht verfügbar.
Soll ich noch warten, bis PHP8 bei Hosttech verfügbar wird, damit ich das zuerst hier, auf der Testumgebung, umstellen kann? Oder kann ich unabhängig davon, www.beatsblog.ch bereits auf PHP8 anheben?
?? - Frohe Ostern!
Ian Styx am |
Frohe Ostern auch! ?☘
Der Frühling hat sich leider verkrochen..
Styx und PHP 8 ist ready to use. Und überall, meine ich.
Höchstens in ein paar alten Plugins schlummern eventuell noch ein paar Fallen, aber die benutzt du meines Wissens nicht. Und wenn, könnten wir sie vermutlich schnell erledigen.
Wie steht es denn mit deinen Rückkehrplänen? Hat hosttech inzwischen die verkündete Migration vollzogen?
Beat Post author am |
Wie steht es denn mit deinen Rückkehrplänen? Hat hosttech inzwischen die verkündete Migration vollzogen?
Auf Eis gelegt. Zu faul um das wirklich anzupacken.
Habe beide Hostings um ein Jahr verlängert (und "das Problem" so vor mir hergeschoben).
Proaktive Infos von Seiten Provider sind links wie rechts inexistent. Dass Manitu bereits PHP8 anbietet, habe ich auch nur zufällig bemerkt.
Zum Glück kostet Webhosting heutzutage nur mehr kleines Geld. So kann ich mir hier den Luxus leisten, zwei überdimensionierte Hostings zu bezahlen ?.
Styx und PHP 8 ist ready to use.
Na dann! Schau' mer mal!
www.beatsblog.ch = Betrieben mit Serendipity Styx 3.3.1 und PHP 8.0.1
Beat Post author am |
Wenn ich in einem Fenster ins Backend eingeloggt bin und in einem anderen Fenster den Blog aufrufe, erscheint oben folgender Warnhinweis:
Warning: Undefined array key "id" in /home/sites/site100015826/web/styx-master/plugins/serendipity_event_social/serendipity_event_social.php: 178.
Administrative Login Error Warning only - not seen by visitors! Send us a note what happened where and when, please.
Beat Post author am |
Wenn ich das sharebuttons-Plugin deaktiviere, verschwindet diese Fehlermeldung.
Es scheint jedoch so, dass irgendwo noch ein anderer Fehler schlummert.
Während ich im Backend eingeloggt bin, kann in einem anderen Fenster im Frontend kein Menü aufgerufen werden, welches eine Kategorie auflistet, wie z.B. /categories/BLOG oder /categories/Link. Die Menülinks auf statische Seiten funktionieren. Nur die auf categories nicht. (Content-Encoding-Fehler)
Sobald ich ausgeloggt bin, verschwinden alle diese Fehler wieder.
Beat Post author am |
Sobald ich ausgeloggt bin, verschwinden alle diese Fehler wieder.
Der für mich einzige, sichtbare Fehler der bleibt, ist, dass der Link "Suche" eine leere Seite zurückgibt.
PS: Ich lass das mal so stehen. Habe heute Nachmittag noch anderes vor und werde abends nochmal reinschauen.
Beat Post author am |
Beliebter Fehler ? kicher..
Ich habe inwischen die mediasidebar rotate time wieder auf 5 Minuten gesetzt ... und ... et voilà ! ?
Beat Post author am |
Klingt gut ?.
Ehrlich gesagt weiss ich mittlerweile gar nicht mehr, weshalb wir diesem Fehler nachgerannt sind. Vielleicht sehe ich das falsch, doch das scheint doch eine Hosttech-PHP8.03-Plesk Eigenheit zu sein, die in dieser Form wohl nicht häufig vorkommt. Bei Manitu-PHP8.0.1 hatten wir diese Probleme gar nie.
Aber schön, wenn Du irgendeine Erkenntnis daraus gewinnen konntest. ?
Ian Styx am |
OK und jetzt einmal statt
(also dem true) mal mit dem
was, wenn es ginge, den ganzen Unsinn der genannten Einstellung offenbart! ?
Beat Post author am |
O.K. AdapterOpCache.php noch einmal angepasst.
Ian Styx am |
Deshalb https://www.blog.dokumenzi.ch/index.php?url=2658-Styx-3.4-alpha2-und-PHP-8.0.3.html#c7831
Ja es ist eine Plesk default "security" Einstellung für PHP, die ein Hoster natürlich überschreiben kann. Diese Funktion zu disablen bedeutet nur ein Gewinn an Sicherheit, dass man Informationen zum OPCache nicht ganz so leicht anderweitig abrufen kann. Sie wollten ursprünglich damit verhindern, dass auf einem Multi-User Server ein Hacker nicht ganz so einfach Informationen über User Nachbarn und Container Verteilung erhalten kann. Siehe Kommentar von https://www.php.net/manual/de/function.opcache-get-status.php zur Status Rückgabe. Mehr aber auch nicht. Das die Funktion opcache_get_configuration() aber dann doch verwendet werden kann (wenn du das bestätigst) macht es uns einfacher.
Manitu war vielleicht einfach klüger oder benutzt diese PLESK Version nicht.
Beat Post author am |
Dass es mit dem verlinkten Kommentar angefangen hat, ist mir klar. Doch diese Fehlermeldung ist ja schon länger weg. Aber egal. Ich muss nicht wirklich alles verstehen ?.
Ja, opcache_get_configuration() scheint zu funktionieren, denn das habe ich in der letzten Änderung ja eingefügt.
Manitu verwendet PLESK gar nicht. Ich denke, dass Sie die Benutzer-Oberfläche selber stricken (obwohl im footer etwas von "gentoo linux" steht).
Ian Styx am |
PlesK und Gentoo Linux sind zwei verschiedene Paar Stiefel. Das erstere ist eine eingekaufte Software für die Userverwaltung, ein AdministrationsBackend auf das du als Kunde ja auch Zugang erhälst, in PHP geschrieben. Das geben sie natürlich auch preislich weiter.
Das zweite ist das zugrundeliegende Server Linux OS. Bei hosttech wahrscheinlich eher ein anderes.
Ian Styx am |
und last but not least ?
Bitte!
Ian Styx am |
Ja damit:
https://www.blog.dokumenzi.ch/2658-Styx-3.4-alpha2-und-PHP-8.0.3.html#c7844 (Minus Klammer als Edit3 ?)
Und die haben wir ja jetzt auch wieder außer Kraft gesetzt, so dass der Fehler eigenltich wiederkommen müsste.
Beat Post author am |
O.K. AdapterOpCache.php erneut angepasst.
Und dann hat es wieder in Zeile 36 geknallt ?. Habe dann diesen Teil gelöscht:
also quasi einen Schritt zurück.
Ian Styx am |
Sehr apart ... macht aber auch Sinn - danke - jetzt kann ich es dann wohl selbst weiter anpassen, wir werden bei dir vorerst bei
bleiben. Aber eigentlich bräuchten wir eine Art Rückgabe als in etwa
für die Genauigkeit. Ich werde den voku Author mal befragen.
Ian Styx am |
Mir schwant gerade was ...setze mal in die functions.inc das hier ein.
und zwar vor das $opcache = true;//....
In der Seitenausgabe müsste dann soetwas wie bool true / bool true stehen...
Ian Styx am |
Puh OK habs gesehen. Kann wieder weg.
Ist alles in Ordnung!
Beat Post author am |
So gefällt es mir auch besser. ?
Beat Post author am |
Habe im Live-Blog soeben einen Beitrag geschrieben und darin einen Trackback gesetzt. Als ich diesen im Backend bewilligen wollte, habe ich wohl irgend einen falschen Knopf gedrückt (war schon müde und kann mich nicht mehr erinnern, worauf ich geklickt habe).?
Darauf erhielt ich folgende Anzeige:
Der Trackback wurde nicht gelöscht. Ich konnte ihn danach problemlos bewilligen.
Ian Styx am |
Oh Danke! committet.
Beat Post author am |
Ah, hier war es:
Wie durch Zauberhand funktioniert nun PHP-Mail auch mit PHP 8.0.5
Ich habe nichts gemacht. Es scheint, dass Hosttech den Fehler (im Stillen) korrigiert hat.
Wie auch immer: Problem erledigt! 👍
PS: Vielleicht war es auch ein PHP-Problem, denn damals war V8.0.3 aktiv und nun V8.0.5 (auch wieder ohne eine Aktion von meiner Seite).
Ian Styx am |
Eher das Erstere, würde ich sagen. Aber besser spät als nie! 😀