Show admin warning when php-intl is missing

[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

[kesselb]

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

[MichaIng]

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

[kesselb]

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

[MichaIng]

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

[kesselb]

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.

[MichaIng]

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

[MichaIng]

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.