nextcloud intl.so

  • Bei einer Nextcloud-Installation tritt immer folgende Meldung auf, im Sekundentakt.


    You are using a fallback implementation of the intl extension. Installing the native one is highly recommended instead. at /home/k1xxxdbo/go.domain.de/nextcloud_2020_1_JM/3rdparty/patchwork/utf8/src/Patchwork/Utf8/Bootup/intl.php#18


    Hat jemand eine idee was man da tun kann und soll?

  • 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.

  • genau damit hakt es ja. in der php.ini ist es drin und in der phpinfo steht auch:


    intl

    ICU version 58.3
    ICU Data version 58.3
    ICU TZData version 2019a
    ICU Unicode version 9.0
    intl.default_locale utf8 utf8
    intl.error_level 2 2
    intl.use_exceptions 0 0
  • 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.

  • 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.

  • 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

    Code
    SetENV PHPRC /home/user/php-nextcloud.ini

    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.

    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 😉

  • monderka

    Hat das Label [erledigt] hinzugefügt
  • Zitat
    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 😉

    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.