Kommentare von

beats TEST blog

Styx 3.4-alpha2 und PHP 8.0.3

Beat Post author am |

Natürlich. ?

Contact your provider if it still does not work. Tell your provider that the standard php "mail()" function returns TRUE, but not mail will be sent.
It's recommended to include the used php test script to show your provider, that the problem is not caused by the php script used.

Wie empfohlen, habe ich dann auch den Code des Scripts angefügt.

Ian Styx am |

Sorry ? aber bei älteren Herrschaften bin ich mir nicht immer so sicher.... ?

Und Spam / Junk Ordner natürlich ebenfalls!?!

Beat Post author am |

Werd nicht frech! ? Nicht an einem Sonntag! ?

SPAM/Junk? Gibt es sowas?

Nein, auch dort nichts zu finden.

Beat Post author am |

Antwort des Helpdesk:

Besten Dank für Ihre Anfrage.

Wenn Ihr PHP-Skript unter der Version 8.0 nicht so funktioniert wie Sie es erwarten, würde ich Ihnen zunächst empfehlen wieder auf die Version 7.4 zu wechseln.

?hier werden sie geholfen? 

Beat Post author am |

Antwort auf die erneute Nachfrage:

Besten Dank für Ihre Rückmeldung.

Die Einstellungen von pcache_get_status ist bei uns auf dem Standard eingestellt, der vom Hersteller Plesk definiert wurde.

Wenn Sie etwas anderes wollen, müssen Sie auf einen eigenen vServer umziehen, da Sie dort die Einstellungen wie Sie wollen und brauchen vornehmen können.

Denn sie wissen nicht, was sie tun... ?

Ian Styx am |

Tatsächlich:
Plesk 17.8.11 - PHP value "disable_functions" changed to default value "opcache_get_status"

Aber ehrlich, das hat deinen hoster doch vorher doch auch nicht gestört. Rant: Und es stört sie auch nicht, dass sie immer noch eine alte openssl version OpenSSL 1.0.2k 26 Jan 2017 fahren. Das ist ein viel größeres Risiko! Weil viele der Verbesserungen erst in 1.1.1 eingeflossen sind. Und es stört sie scheinbar auch nicht das man opcache_get_staus() mit PHP 7.4 wohl auf ihrem Server dennoch verwenden(*) darf. Das macht doch keinen Sinn! (* Ehrlichwerweise muss man sagen dass wir das aber nicht so genau wissen, denn die Funktion ist ge@silenced, was mit PHP 7.4 noch geht, aber nicht mehr mit 8.)

Die Frage also ist, kann man den opcache trotzdem verwenden? Da er ja scheinbar trotz alledem enabled ist, denn die funktion fragt tatsächlich nur den Status ab.

Ian Styx am |

HALLLOOOOOOO... ? OOOH

PHP 8 mail() ist abgeschaltet bzw verweist ins Nirwana! Die sollen das gefälligst selbst mal ausprobieren! Das ist doch wirklich kein Zustand.
Und hattest du nicht gesagt es würde mit PHP 7.4 auch nicht klappem...?

Ian Styx am |

Setz mal unseren workaround in der functions.inc auf

$opcache = true;//function_exists('opcache_get_status') ? true : false;

Und bearbeite mal /bundled-libs/voku/simple-cache/src/voku/cache/AdapterOpCache.php in Zeile 36 von

                !empty(@\opcache_get_status())

auf

                true)

Das wäre ja mal spannend!

Beat Post author am |

O.K. Hab ich gemacht.

Musste jedoch die schliessende Klammer nach true entfernen, sonst knallt es in Zeile 37.

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 |

et voilà !  ?

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

                !empty(@\opcache_get_status())

(also dem true) mal mit dem

                !empty(@\opcache_get_configuration())

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 ?

                (!empty(@\opcache_get_status()) || !empty(@\opcache_get_configuration()))

Bitte!

Ian Styx am |

Dass es mit dem verlinkten Kommentar angefangen hat, ist mir klar. Doch diese Fehlermeldung ist ja schon länger weg.

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:

(!empty(@\opcache_get_status()) || 

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

!empty(@\opcache_get_configuration())

bleiben. Aber eigentlich bräuchten wir eine Art Rückgabe als in etwa

$opcache_get_configuration['directives']['opcache.enable'] === true

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.

var_dump(function_exists('opcache_compile_file'));
var_dump(function_exists('opcache_get_configuration'));

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:

Warning: Undefined array key "delete" in /home/sites/site100015826/web/styx-master/include/admin/comments.inc.php: 22.
Administrative Login Error Warning only - not seen by visitors! Send us a note what happened where and when, please.

Der Trackback wurde nicht gelöscht. Ich konnte ihn danach problemlos bewilligen.