The error message tells you what you need to do: Install the PHP intl module.
Sorry we can’t all be php genius’ right off the bat.
And even “install the php intl module” implies knowing how. But in the end we managed to figure it out about 11 hours ago.
I know nothing of php whatsoever. It has nothing to do with code or knowledge of the language or whatnot.
This points to a deeper problem: you need to learn how to do basic system administration tasks if you want to administer a server. Just trying to help here: there are plenty of good documentation, generally on the OS’s own page as to how to do that. I strongly suggest you spend the time to learn.
@coleadve thanks for the pointer to the code change
I don’t know whether this is considered outside of scope of the project, so appologies if it is: My scenario - running tt-rss on a mac using php 7.3.4 from the brew package manager. php -m lists intl as installed. However, this new UConverter test is failing for me. If I comment out the check in sanity_check.php everything works fine again.
Is there anything I can do to help resolve this, or is running tt-rss on a mac my own fault so I should just deal with it 
I don’t know, it took me a bit to figure out what package UConverter existed in, and then a bit more for getting in install in my environment.
Are there varying versions depending on your minor php version? ie, I think i was php 7.0, so installed php7-intl, you look like you’re a 7.3, is there a higher intl version needed. As you you can see from above I definitely wasn’t an expert.
Interesting - well according to info.php, I have intl icu version 64.2
@coleadve if you had a moment, could you check to see which version you have? Cheers
Also interesting: If I create just a standalone php script and run that check:
if (!class_exists(“UConverter”)
It works fine (ie passes the check and php confirms that the UConverter class is there.
So from that I think something else might be going on?
|Internationalization support|enabled|
|---|---|
|version|1.1.0|
|ICU version|59.1|
|ICU Data version|59.1|
so my version is newer - which would make sense I guess. I wonder if that’s the issue? Is anyone else in the thread ruinning php 7.3.x and seeing issues?
I just updated tt-rss, hadn’t done that in a few weeks. Installed php-intl. Haven’t noticed any problems so far.
PHP 7.3.5, ICU 64.2
Fixed my own issue by installing the module, but this seems like an unusually noticeable breaking change for tt-rss.
@Zeikzeil and @wn_name thanks for the info - so I guess it’s something specific to the mac platform then? If anyone has any pointers as to where I could look next, that would be most appreciated
I had the same error message plus found php7-intl was already installed. What I didn’t realize is apache was using php5. My debian system is rather old and has been through multiple upgrades. When php7 was installed at one of the upgrades, I missed removing php5. Now all is working fine. Hope this helps someone else.
DOH! Figured it out - it was my own stupid fault. In config.php php_executable was set to the system php, rather than the brew one. It caught me out because I was assuming that the php used would be the same as the one I set in apache, which is why info.php looked fine but I was still having issues. So in case anyone else has the same issue, in config.php change:
define(‘PHP_EXECUTABLE’, '/usr/bin/php);
to
define(‘PHP_EXECUTABLE’, '/usr/local/bin/php);
Found a solution that works for me:
I cannot paste the URL here. Found on the apachefriends forum. viewtopic.php?t=75044
Running XAMPP 7.2.12-0 (PHP 7.2.12) on macOS Mojave 10.14.4
xuo
25
Hi,
Under Mageia, I had to do the following :
urpmi php-intl
and
restart the apache server :
systemctl restart httpd
systemctl restart ttrssd
Hope this can help.
Regards.
Xuo.
DAA
26
This maybe very that’s my config on Synology specific:
With PHP 7.2.13, intl 1.1.0, icu 56.1 tt-rss update missed the Uconverter class.
Digging in my config I found a mismatch between PHP_EXECUTABLE (pointed to an also existing 7.0 binary) and the one used by the web server (7.2), setting PHP_EXECUTABLE to PHP_BINARY solved this issue immediately.
jplatte
27
In my case, the issue wasn’t that the intl module wasn’t installed, but rather that it wasn’t enabled. So if anyone else is still stuck after installing the package, make sure you have extension=intl in your php.ini.
Quirin
28
Had the same error - and this was driving me crazy.
Here is my problem to solution approach.
Find the PHP version your daemon is using
$ ps ax | grep update_daemon2.php
31332 ? Ss 0:00 /usr/bin/php7.0 ./update_daemon2.php
==> I am using /usr/bin/php7.0
Check if the class is available:
$ /usr/bin/php7.0 -c /etc/php/7.0/cli/php.ini --re intl | grep UConverter
Class [ <internal:intl> class UConverter ] {
If no output the module intl is not installed or loaded. ==> install it or have a look if the module is not enabled in php.ini
Try to load the class:
$ /usr/bin/php7.0 -a -c /etc/php/7.0/cli/php.ini <<< 'print(class_exists("UConverter")); exit();'
Interactive mode enabled
1
Must print “1” in output - otherwise intl is not installed.
Run the daemon
$ /usr/bin/php7.0 -c /etc/php/7.0/cli/php.ini ./update_daemon2.php
Still gives an error with UConverter missing?
$ grep PHP_EXECUTABLE config.php
define('PHP_EXECUTABLE', '/usr/bin/php');
Now you nailed the error:
==> Edit config.php to:
define('PHP_EXECUTABLE', '/usr/bin/php7.0');