Also, wenn ich mal im Netz suche, dann scheint die Abhilfe zu sein das Modul "php-intl" zu aktivieren und dann sollte das Problem weg sein.
Habe jetzt gerade mal geschaut. Füge einfach in die php.ini
extension="intl.so"
hinzu. Dann sollte es klappen.
Dann wären mehr Informationen hilfreich...
Ich setze Nextcloud 19 ein. Ausgeführt wird es mit FPM und PHP Version 7.4. Installiert ist die SE 6-0.369. Ich habe keinerlei derartige Meldungen.
Ich würde auch vermuten, dass die 3rd Party App "Patchwork" hier die Meldungen erzeugt und nicht Nextcloud selbst. Müsste man also einmal schauen welche Vorgaben der Hersteller für die App hat.
Nur mal so zur Info:
Die intl.so Meldung bekommt man auch, wenn beispielsweise der Nextcloud cron-Job "cron.php" regelmäßig ausgeführt werden soll.
Wer das beispielsweise in seiner crontab einträgt, sollte daran denken den Pfad zur php.ini mitzugeben:
/usr/local/pd-admin2/bin/php-7.4-cli -c /home/<user>/php.ini -f /home/<user>/<domain>/<pfad zur Nextcloud Instanz>/cron.php
Anderenfalls habt ihr auch wieder die Meldung mit der Fallback implementation.
Ich habe die Ursache gefunden...
Problem war das ich die php.ini nicht in das Kunden-Verzeichnis, /home/k1xxxdbo/php.ini gesetzt habe sondern erst in das Subdomain-Root: /home/k1xxxdbo/go.domain.de/nextcloud_2020_1_JM/php.ini
Das hat dazu geführt das nextcloud zwar die php.ini gelesen hat, aber die Plugins die in einem anderen Verzeichnis starten wohl nicht.
Der Grund warum ich das eigentlich so gemacht habe war weil der der kunde unter http://www.domain.de eine wordpress installation hat und die php.ini nicht die gleiche sein sollte wie die für nextcloud unter go.domain.de.
Aber mit der gleichen php.ini für beides geht jetzt alles korrekt.
Nextcloud selbst lädt/liest die php.ini auch nicht, sondern der PHP Interpreter. Dieser lädt immer die php.ini im Home Verzeichnis. Ist dort keine vorhanden wird eine Standard php.ini geladen.
Wird PHP mittels cgiwrap ausgeführt, kann man per htaccess Datei eine abweichende php.ini angeben. Zum Beispiel
Bei Verwendung von fpm geht dies nicht, da die php.ini beim Start des fpm Prozesses einmalig geladen wird.
Die php.ini im Dokument Root der nextcloud Instanz würde ich entfernen. Diese ist dadurch öffentlich abrufbar. Angreifer können so Informationen zur PHP Konfiguration bekommen.
Alles anzeigenNur mal so zur Info:
Die intl.so Meldung bekommt man auch, wenn beispielsweise der Nextcloud cron-Job "cron.php" regelmäßig ausgeführt werden soll.
Wer das beispielsweise in seiner crontab einträgt, sollte daran denken den Pfad zur php.ini mitzugeben:
/usr/local/pd-admin2/bin/php-7.4-cli -c /home/<user>/php.ini -f /home/<user>/<domain>/<pfad zur Nextcloud Instanz>/cron.php
Anderenfalls habt ihr auch wieder die Meldung mit der Fallback implementation.
Wird der Cronjob mit der php-x.x-cli ausgeführt, muss auch eine php.ini angegeben werden. Andernfalls wird nur die Standard php.ini geladen. Wäre also das gleiche Verhalten wie oben.
Ich würde auch über pd-admin im Endkundenbereich die php-cli setzen und den Haken bei "lokale php.ini verwenden" zu setzen. Dann muss man nur noch ~/bin/php ~/pfad/zu/skript.php beim Cronjob angeben 😉
ZitatIch würde auch über pd-admin im Endkundenbereich die php-cli setzen und den Haken bei "lokale php.ini verwenden" zu setzen. Dann muss man nur noch ~/bin/php ~/pfad/zu/skript.php beim Cronjob angeben 😉
Das hat zumindest bei mir nicht funktioniert. Erst die direkte Angabe auf die php.ini Datei hat bei mir beim php-x.x-cli Aufruf funktioniert.
Aber damals habe ich es noch mit einer älteren Version der SE / PD-Admin Version probiert; vielleicht hat sich das ja jetzt gebessert.
Dann würde ich einmal /home/user/bin/php mit einem Editor anschauen. Wenn der Haken gesetzt wurde, dann sollte dort die Binary mit der php.ini angegeben sein.
