Skip to content

Show admin warning when php-intl is missing #12767

Closed

Description

@MichaIng

Steps to reproduce

  1. Uninstall php-intl module
  2. Update Nextcloud to 15 Beta/RC
  3. Have Nextcloud Windows client active (not sure if required)
  4. Check Nextcloud logs

Expected behaviour

No repeating error messages

Actual behaviour

You are using a fallback implementation of the intl extension. Installing the native one is highly recommended instead. at /var/www/nextcloud/3rdparty/patchwork/utf8/src/Patchwork/Utf8/Bootup/intl.php#18
appearing several times a second.
Obviously leads to Nextcloud Windows client failing to sync (just check, no actual sync). After installing php-intl the error spam stops and desktop client succeeds to sync.

Not sure why I didn't have this module installed (is actually on my list..), so great to throw an error about this. But a single message or warning on admin panel is enough, not a massive repeating spam of this.

€: Just found now that this was already the case with Beta 2, recognized it just now after RC2 update, because Nextcloud Windows client failed. On Beta 2 it was appearing a bid irregularly 2-10 times a minute. After RC2 upgrade it appeared 2-3 times a second. I could imagine that it was triggered by client sync attempt, since it failed?

Server configuration

Operating system: Raspbian Buster

Web server: Apache 2.4

Database: MariaDB 10.1

PHP version: 7.2

Nextcloud version: 15 RC2

Updated from an older Nextcloud/ownCloud or fresh install: Updated from 15 Beta 2

Where did you install Nextcloud from: Official download source

List of activated apps:

App list
Enabled:
  - activity: 2.8.2
  - apporder: 0.6.0
  - calendar: 1.6.4
  - checksum: 0.4.1
  - cloud_federation_api: 0.1.0
  - contacts: 2.1.7
  - dav: 1.8.0
  - federatedfilesharing: 1.5.0
  - files: 1.10.0
  - files_downloadactivity: 1.3.0
  - files_rightclick: 0.8.4
  - files_sharing: 1.7.0
  - files_trashbin: 1.5.0
  - files_versions: 1.8.0
  - gallery: 18.2.0
  - impersonate: 1.2.0
  - logreader: 2.0.0
  - lookup_server_connector: 1.3.0
  - notes: 2.5.1
  - notifications: 2.3.0
  - oauth2: 1.3.0
  - polls: 0.8.3
  - previewgenerator: 2.0.0
  - provisioning_api: 1.5.0
  - serverinfo: 1.5.0
  - sharerenamer: 2.3.0
  - spreed: 4.99.0
  - survey_client: 1.3.0
  - tasks: 0.9.8
  - twofactor_backupcodes: 1.4.1
  - updatenotification: 1.5.0
  - workflowengine: 1.5.0
Disabled:
  - accessibility
  - admin_audit
  - comments
  - encryption
  - federation
  - files_external
  - files_pdfviewer
  - files_texteditor
  - files_videoplayer
  - firstrunwizard
  - nextcloud_announcements
  - password_policy
  - ransomware_protection
  - sharebymail
  - support
  - systemtags
  - theming
  - user_external
  - user_ldap

Nextcloud configuration:

Config report
{
    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost",
            "my.domain.org"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "15.0.0.8",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "filelocking.enabled": true,
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0
        },
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "loglevel": 1,
        "logtimezone": "Europe\/Berlin",
        "trashbin_retention_obligation": "disabled",
        "versions_retention_obligation": "disabled",
        "skeletondirectory": "",
        "defaultapp": "apporder",
        "maintenance": false,
        "overwrite.cli.url": "https:\/\/localhost\/nextcloud",
        "htaccess.RewriteBase": "\/nextcloud",
        "mail_smtpmode": "smtp",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpsecure": "ssl",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauth": 1,
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "465",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "theme": "",
        "mysql.utf8mb4": true,
        "updater.release.channel": "beta",
        "updater.secret": "***REMOVED SENSITIVE VALUE***"
    }
}

Are you using external storage, if yes which one: no

Are you using encryption: no

Are you using an external user-backend, if yes which one: no

Client configuration

Browser: Opera 59

Operating system: Windows 10 1809

Logs

Nextcloud log (data/nextcloud.log)

Nextcloud log
[PHP] Error: You are using a fallback implementation of the intl extension. Installing the native one is highly recommended instead. at /var/www/nextcloud/3rdparty/patchwork/utf8/src/Patchwork/Utf8/Bootup/intl.php#18

GET /nextcloud/ocs/v2.php/cloud/activity?page=0&pagesize=100&format=json
from 46.59.179.64 by Micha at 2018-12-01T00:31:04+01:00

Activity

  1. changed the title [-]Nextcloud 15 RC2 | After update: Mass "fallback intl extension" error spam[/-] [+]Nextcloud 15 RC2 | After update: Mass "fallback intl extension" log spam[/+] on Dec 1, 2018
  2. kesselb commented on Dec 1, 2018

    @kesselb
    Contributor

    Thank you for testing 👍 See #10655 for details and solution.

  3. MichaIng commented on Dec 1, 2018

    @MichaIng
    MemberAuthor

    @danielkesselberg
    Jep thx, solution for the error itself is obvious.

    However same question as in the other topic, perhaps instead of repeatedly within Nextcloud log (only), the error could be shown either:

    • On admin panel together with security warnings
    • Meaningful on Nextcloud clients, so users can't overlook it

    Currently it leads to overspammed logs without users forced to recognize fast. E.g. web interface works well and I had missing intl for several days, at last since the time when I installed NC15 Beta 2 and didn't recognize until now.

  4. kesselb commented on Dec 1, 2018

    @kesselb
    Contributor

    I see your point. The message is generated by https://github.com/tchwork/utf8/blob/master/src/Patchwork/Utf8/Bootup/intl.php a 3rdparty library used by nextcloud. There are two ways to get rid of this error message:

    A) write a patch and apply it for the library in https://github.com/nextcloud/3rdparty/ (not popular because you have to reapply the patch with each upgrade but sometimes there is no other way)

    B) hook into the error_logger and check if a error message with category E_USER_DEPCREATED match You are using a fallback implementation of the intl extension. Installing the native one is highly recommended instead. and ignore then.

    Hmm. I think we should add intl as required php module and show a setup warning when not available. @rullzer @MorrisJobke

  5. reopened this on Dec 1, 2018
  6. changed the title [-]Nextcloud 15 RC2 | After update: Mass "fallback intl extension" log spam[/-] [+]Show admin warning when php-intl is missing[/+] on Dec 1, 2018
  7. MichaIng commented on Dec 1, 2018

    @MichaIng
    MemberAuthor

    @danielkesselberg

    Hmm. I think we should add intl as required php module and show a setup warning when not available.

    Actually I though I read already somewhere that intl was promoted from recommendation to requirement. But at least this had not yet found it's way into the docs: https://docs.nextcloud.com/server/15/admin_manual/installation/source_installation.html#prerequisites-for-manual-installation
    Totally makes sense to move it to requirements (and refuse Nextcloud install/update steps otherwise), since now those errors occur that (at least since v15 RC2) break clients and most properly other core functionality.

    About error handling, perhaps lower priority for now:

    • Not sure how it is handled in case of other missing PHP modules. APCu and Redis e.g., if configured for caching, but missing, leads to most Nextcloud access failing and/or meaningful web UI output, thus will be recognized fast. Also if I remember right, the error logs are not written in such a high frequency, so log will not blow up that much.
    • Would be generally great, if such major issues could be handled in a way, that they only show up once in log (or with hard-limited frequency) and/or meaningful presented on all official Nextcloud clients + web UI + occ. I personally would leave 3rd party libraries untouched as well (to not increase maintenance effort), but use/implement a log handler for such known definite outputs.

    NB: It is a pain to navigate through blown log files on e.g. RPi to even find, copy&paste the errors. nano respectively the system is totally overloaded with enabling line breaks page up/down and such 🤣. Okay copy and analyse logs on an external systems is always a solution, but it is always great, if possible, to reduce logs as much as possible, especially repeating ones.

  8. kesselb commented on Dec 1, 2018

    @kesselb
    Contributor

    Are u sure about that? I could not reproduce it with master. Obviously leads to Nextcloud Windows client failing to sync (just check, no actual sync). After installing php-intl the error spam stops and desktop client succeeds to sync.

  9. MichaIng commented on Dec 1, 2018

    @MichaIng
    MemberAuthor

    @danielkesselberg
    Now that you ask, actually not 100%.
    After RC2 upgrade, Windows client definitely failed. On activity page it was blinking, looked like it fast repeatedly tried to update/retrieve recent activities. That seemed to match with the repeating errors, one for each client request. But just a guess.

    After installing php-intl and restarting apache (mod-php), the desktop client again was able to connect and everything worked well, until... https://help.nextcloud.com/t/nextcloud-15-rc2-dav-errors-and-broken-access-after-daily-backup/42338

    Perhaps going off-topic now:

    When checking the logs, I now found that most properly one of my events failed to sync and the daily backup procedure (incl. maintenance mode) then broke it, lead to a corrupted calendar entry. I am trying to fix this now.

    So it MIGHT be possible, but from my point of view unlikely, that the failing Windows client is related with the initial CalDAV sync/database error.
    BUT:

    • I faced the intl error (and failing Windows client) directly after RC2 update and fixed it quite fast afterwards.
    • Everything worked well then, besides DAVdroid failing to sync a repeating event, which I did not recognize immediately.
    • From what I can see now, comparing time stamps and such, the first (failed) sync attempt happened AFTER I already fixed intl.

    Only relation I could think of:

    • With RC2, the CalDAV module uses php-intl to, dunno, translate german Ä Ö Ü (?), which is inside the failed event name, which is then the reason why this even could not be synced? But this definitely was not the case with Beta 2, where I used Nextcloud and the calendar for some days without any issues.

    Damn that I purged the logs after fixing intl and copying one example here, since it was blown, so I cannot assure the log history from initial NC v15 Beta update...

  10. MichaIng commented on Dec 3, 2018

    @MichaIng
    MemberAuthor

    As an additional vote to do something about this logs: https://help.nextcloud.com/t/nextcloud-deletes-my-files-on-server-every-few-hours/42438/9

    On shared hostings users are not always able to install this module and hosting provider might not react fast, if ever. As long as the internal fallback is working, the repeated warning in logs should be suppressed/handled which otherwise will make it hard to find more urgent logs related to other issues as mentioned in the links topic.

  11. added this to the Nextcloud 15 milestone on Dec 3, 2018
  12. added and removed
    1. to developAccepted and waiting to be taken care of
    on Dec 3, 2018
  13. MorrisJobke commented on Dec 4, 2018

    @MorrisJobke
    Member

    Fix is in #12821

  14. MichaIng commented on Dec 4, 2018

    @MichaIng
    MemberAuthor

    My comment, why I think it's not the best solution 😉: #12821 (comment)

  15. MorrisJobke commented on Dec 4, 2018

    @MorrisJobke
    Member

    My comment, why I think it's not the best solution 😉: #12821 (comment)

    My comment why I still think it is a good solution: #12821 (comment)

    Anyways: Thanks for this feedback - it's absolutely necessary to get also an outside view and a need to explain itself again to know that it's still the right direction where we are going. 😃👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions