Hatte jetzt parallel noch ein zweite Projekt am laufen. Da haben die Zugriffe geklappt.
Hatte dann in der .NET 10 WebAPI das NugetPaket im Verdacht. Doch bis ich das ausgetauscht hatte ging's da auch wieder.
Und auch der MySqlWorkbench verbindet sich wieder wie gewohnt.
Damit alles wieder grün
Hey,
ich bin mir nicht sicher ob das vielleicht mit den Wartungsarbeiten vom Wochenende zusammen hängt, doch seltsamerweise kann ich mich auf die Datenbanken von 'extern' nicht mehr mit der Adresse: mysqlf997.netcup.net verbinden und erhalte immer einen Verbindungstimeout.
Auch um MySqlWorkbensch bei Verbindung testen läuft das ewig (>30 Sekunden) verbindet sich dann aber irgendwann mal doch.
Gebe ich statt der URL die IP (46.38.249.151) an, klappt die Verbindung ad hoc.
nslookup löst die Adresse lokal auch im Bruchteil einer Sekunde auf. Bin daher etwas verwundert, wo das Problem stecken könnte.
Mir ist das jetzt zufällig bei der lokalen Entwicklung aufgefallen. Die Anwendungen die 'live' sind haben scheinbar keine Probleme.
Hab' die Cron Ereignisse geprüft. Das Plugin führt dort in der Tat auch Events aus, passte jedoch zeitlich nicht zu den Fehlermails.
Das Problem wird sich jetzt aber gelöst haben, denn von dem Plugin kam heute ein Update
Fix: possible syntax error on sites with very old PHP versions.Und die Stelle mit dem 'fn' Aufruf wurde ersetzt.
Damit verschieben wir das zwar nur in die Zukunft, wenn ich aber noch irgendwelche Erkenntnisse gewinne, dann werde ich das hier ergänzen.
Gibt es Cron-Jobs, die noch eine alte PHP-Version verwenden? Geben die Header in der Mail vielleicht irgendwelche Hinweise?
Die Mail ist so eine automatisierte von Wordpress. Da werden wohl die PHP Fehler abgefangen so dass nicht die Ganze Seite abstürzt.
Das mit den Cron Jobs finde ich noch einen interessanten Ansatzpunkt. Aktiv habe ich da zwar nichts eingerichtet, doch wer weiß was da immer alles im Hintergrund passiert.
Hatte das Plugin mal kurzzeitigt deaktiviert, da konnte man auch ein Feedback senden, da habe ich das Problem auch mal geschildert.
Ich lasse ein Feedback da, wenn ich was neues raus finde.
Finde das seltsam, dass dort 72 hinterlegt ist, wenn das Plugin ja mit 7.3.33 ausgeführt wird.
Mit dem Verdacht lag ich dann leider auch richtig. Habe auf '74' umgestellt und nach einer Stunde hat die PHP CLI auch 7.4 ausgegeben.
Doch vor wenigen Minuten erreichte mich die Fehlermail wieder und immer noch der Verweis auf PHP 7.3.33
WordPress-Version 6.8.3
Aktives Theme: Ribosome (Version 2.5.0)
Aktuelles Plugin: Featured Image from URL (FIFU) (Version 5.2.8)
PHP-Version 7.3.33
Da ich leider noch nicht rausgefunden habe, wann/wodurch der Fehler ausgelöst wird (Mails kamen immer zu unterschiedlichen Tagen / Zeiten) kann man die Änderungen auch nicht einfach 'schnell testen'.
Das Plugin hat auch eine eigene Status Seite bei der - wie auch beim Wordpress Status - die eigentlich aktivierte PHP Version 8.2.28 angezeigt wird.
Zusammengefasst:
Webhosting-Control Panel ist 8.2 beim Blog und allen Subdomains eingestellt
Webhosting-Control Panel ist 8.2 bei der hosting100216.af996.netcup.net eingestellt.
.htaccess, die eine PHP Version festlegt, gibt es nicht.
Version in der phpversion ist auf 74 eingestellt (php -v liefert 'PHP 7.4.33 (cli) (built: Jun 6 2024 11:29:53) ( NTS )')
Fehlermail verweist weiterhin auf PHP 7.3.33
Ich teste das mal ...
Finde das seltsam, dass dort 72 hinterlegt ist, wenn das Plugin ja mit 7.3.33 ausgeführt wird.
Für alle die, die über den Beitrag stolpern:
https://helpcenter.netcup.com/de/wiki/webhosting/php-shell
Wenn man noch keine Berührungspunkte damit hatte: In der Tat gibt's auch SSH Zugriff. Hab' das die letzten >15 Jahre nie gebraucht.
Login Daten sind (vermutlich) die selben wie beim FTP.
Und da findet man dann auch den conf Ordner mit der phpversion Datei die man bequem mit nano (oder welchen Editor man auch immer bevorzugt) bearbeiten kann.
Auf die Datei habe ich glaube ich beim Webhosting Paket keinen Zugriff.
Bin grade noch im Webhosting Control Panel auf die 'WP-CLI' gestoßen.
Die gibt auch PHP 8.2 aus. 
Edit: Das war noch der Beitrag von Stackoverflow der darauf hindeutet, dass es verschiedene Versionen zwischen Apache & CLI gibt
Hallo,
ich würde hier mal ein Glück versuchen, vielleicht hat noch einer eine Idee oder einen Tipp.
Ich habe auf meinem Webhosting Paket (Webhosting 4000 de ) ein Wordpress am laufen (Seit 2009)
Aktuell nutze ich die PHP Version 8.2. Das ist so im Webhosting Control Panel eingestellt.
Vor kurzem gab es ein Update eines Plugins. Dieses Plugin verwendet wohl die 'fn' Funktion von PHP, die
in der PHP Version 7.4 irgendwann hinzugefügt wurde.
Doch seit dem Update bekomme ich immer wieder automatische Mails von Wordpress:
Deine Website hat ein technisches Problem
WordPress-Version 6.8.2
Aktives Theme: Ribosome (Version 2.5.0)
Aktuelles Plugin: Featured Image from URL (FIFU) (Version 5.2.8)
PHP-Version 7.3.33
Fehler-Details
==============
Ein Fehler vom Typ E_PARSE wurde in der Zeile 755 der Datei
/var/www/vhosts/hosting100216.af996.netcup.net/httpdocs/medlan/wordpress/wp-content/plugins/featured-image-from-url/admin/db.php verursacht.
Fehlermeldung: syntax error, unexpected 'fn' (T_STRING), expecting :: (T_PAAMAYIM_NEKUDOTAYIM)
Also ich nochmal alles geprüft. PHPInfo sagt auch Version 8.2.28.
Eine Subdomain wäre nicht relevant, doch auch die sind alle auf PHP 8.2.
Eine Idee hatte ich dann aber noch: Die Hosting Basis URL:
hosting100216.af996.netcup.net
Und in der Tat. Da war noch 7.3.33 aktiv. Umgestellt. Fehler bleibt.
Über die Fehlermeldung bin ich auf einen Artikel zu einem andere Produkt gestoßen.
Dort ging es auch um die Problematik (https://discourse.laminas.dev/t/php-parse-er…iactoros/3466/4)
und für mich klang das so als ob man theoretisch über die CLI eine andere PHP Version hat als das, was z.B.
beim Webhosting aktiv ist.
Aber auf eine Kommandozeile komme ich ja im Webhosting nirgends drauf, um das prüfen zu können.
Mein Fazit so weit:
Alle relevanten URLs und Stellen, wo ich meiner Meinung nach die PHP Version umstellen kann, habe ich auf 8.2 gestellt
Es gibt keine .htaccess Datei die eine andere Version festlegen würde.
PHPInfo, Wordpress und Webhosting Control Panel zeigen auch PHP 8.2 an.
Trivia:
Die Seite läuft an sich ohne Probleme. Ich weiß auch nicht was die Mail auslöst
Die WordPress-Version ist eigentlich 6.8.3 nicht 6.8.2 wir in der Fehlermail angegeben.
Fragen:
Gibt's noch was, wo ich die PHP Version beeinflussen oder was prüfen könnte?
Bzw. kann man für den eigenen Webhosting Bereich allgemein die Minimum PHP Version hochsetzen?
(Man kann's ja dann immer noch pro Domain feiner einstellen bei Bedarf)
Vielen Dank für eure Aufmerksamkeit
PS: Auch wenn's vermutlich nicht relevant ist: Die Domain ist http://www.medlan.de
Moin,
bei einem Kunden, welchen ich Verwalte, tritt das selbe seit dem 15.11. unregelmäßig auf.
Den Support habe ich soeben auch informiert.
Also wird wohl bald etwas passieren
Gucken wir mal. Bin frisch aus dem Urlaub zurück und bin sowohl gestern als auch heute bei meinen beiden Seiten über den 502er Fehler gestolpert. Zufällig. Aber das ich zufällig an zwei Tagen die Seite genau dann aufrufe, wenn sie offline ist bei einem 24h Zeitfenster? Vermutlich sind die auch häufiger 'down' als mir lieb ist. Ein Monitoring habe ich da leider nicht eingerichtet
Und hier noch das Feedback vom Support:
Guten Tag,
wir bieten verschiedene PHP Versionen an. Die Versionen mit nur einer Nachkommastelle sind dabei von uns kompiliert und verwaltet. Die Versionen mit dem vollständigen Versionsstring, kommen direkt von Plesk. Dadurch kann sich ein unterschiedliches Set an zur Verfügung stehenden Extensions ergeben. Wir werden Ihren Wunsch nach sqlite bei der Kompilierung künftiger Updates der von uns bereitgestellten Versionen berücksichtigen.
Mit freundlichen Grüße
Und hier noch das Feedback vom Support:
Guten Tag,
wir bieten verschiedene PHP Versionen an. Die Versionen mit nur einer Nachkommastelle sind dabei von uns kompiliert und verwaltet. Die Versionen mit dem vollständigen Versionsstring, kommen direkt von Plesk. Dadurch kann sich ein unterschiedliches Set an zur Verfügung stehenden Extensions ergeben. Wir werden Ihren Wunsch nach sqlite bei der Kompilierung künftiger Updates der von uns bereitgestellten Versionen berücksichtigen.
Mit freundlichen Grüßen
Abschließendes Feedback von meiner Seite:
Auf eine neue PHP Version wechseln dauert ja nur maximal 5 Minuten, daher habe ich jetzt alle 7er PHP Fälle mal durch getestet:
PHP Version 7.0.33: OK (Bei der Liste der geladenen PDO Treiber auch mit dabei)
PHP Version 7.1.29: OK (Bei der Liste der geladenen PDO Treiber auch mit dabei)
PHP Version 7.2.18: OK (Bei der Liste der geladenen PDO Treiber auch mit dabei)
PHP Version 7.2 (=7.2.16): Connection failed: could not find driver (Bei der Liste der geladenen PDO Treiber auch nicht mit dabei)
PHP Version 7.3 (=7.3.3): Connection failed: could not find driver (Bei der Liste der geladenen PDO Treiber auch nicht mit dabei)
Abschließendes Feedback:
Auf eine neue PHP Version wechseln dauert ja nur maximal 5 Minuten, daher habe ich jetzt alle 7er PHP Fälle mal durch getestet:
PHP Version 7.0.33: OK (Bei der Liste der geladenen PDO Treiber auch mit dabei)
PHP Version 7.1.29: OK (Bei der Liste der geladenen PDO Treiber auch mit dabei)
PHP Version 7.2.18: OK (Bei der Liste der geladenen PDO Treiber auch mit dabei)
PHP Version 7.2 (=7.2.16): Connection failed: could not find driver (Bei der Liste der geladenen PDO Treiber auch nicht mit dabei)
PHP Version 7.3 (=7.3.3): Connection failed: could not find driver (Bei der Liste der geladenen PDO Treiber auch nicht mit dabei)
Das ist bei mir auch so. Der Driver für SQLite wird bei mir bei PDO auch nicht aufgelistet.
In der Doku steht:
"The PDO_SQLITE PDO driver is enabled by default. To disable, --without-pdo-sqlite[=DIR] may be used, where the optional [=DIR] is the sqlite base install directory. As of PHP 7.4.0 » libsqlite ≥ 3.5.0 is required. Formerly, the bundled libsqlite could have been used instead, and was the default, if [=DIR] has been omitted"
Deshalb habe ich es einfach mal ausprobiert.
Hmm, bleibt nur noch die Frage warum mein funktionierendes Skript dann mit 7.X die Meldung "Connection failed: could not find driver" erhält.
Aber Danke für dein Feedback. Dann teste ich da nochmal ein paar Sachen ...
Wie kommst du darauf?
Lasse ich die Einstellung auf 5.6 steht unter PHPInfo bei PDO -> pdo_sqlite enabled mit einer Versionsnummer
Wenn ich bei mir auf 7.2 oder 7.3 umstelle ist bei PHPInfo die Info nicht mehr dabei. Bei PDO Support steht bei PDO drivers auch nur noch "mysql"
Oder ist das nur ein Problem bei mir, dass die nicht mehr geladen werden kann bei der 7.Xer Version. Ganz oben im phpinfo stehe ich noch bei Configure Command ''--with-pdo-sqlite=shared,/usr'
Edit. Und beim Versuch eine Verbindung aufzubauen erhalten ich: "Connection failed: could not find driver"
Vor dem Problem stehe ich jetzt aber: Habe eine SQLite Datenbank, aus der ich Infos ziehe. Mit der PHP 7.X kann ich die jetzt nicht mehr nutzen.
Weil ich auch gerade an dem Thema dran bin und alles auf 7.X umstelle. (Bei mir war auch alles noch auf 5.6).
Weiß zufällig jemand warum die PDO Unterstürzung für SQLlite mit der 7er PHP Version raus geworfen wurde?
Daran scheitert die vollständige Umstellung gerade bei mir
So. Jetzt wurde alles (dauerhaft) behoben. 
Phu. Am nächsten Tag ist mir aufgefallen, dass die Subdomains immer noch nicht korrekt geleitet wurden (Auch wieder IPV6)
Support -> Erledigt
Dann ist mir aufgefallen, dass einige Domains keine Zertifikate erneuert bekommen
Support -> War auch ein IPv& Problem -> Erledigt
Und jetzt gehen 2 von drei Seiten über IPv4 nicht mehr (wieder Weiterleitung zu ccp.netcup.net)
...
Thema als 'erledigt' markiert
