Support for PHP 8.1

After last pull :

  thrown in /var/www/tt-rss/classes/logger/sql.php on line 7" while reading response header from upstream, client: 2001:660:3004:5:a28c:fdff:fee6:5f25, server: pl.palsembl.eu, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.4-fpm.sock:", host: "pl.palsembl.eu"
2021/12/01 10:46:23 [error] 2798859#2798859: *1 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Declaration of ORM::offsetExists(mixed $offset): bool must be compatible with ArrayAccess::offsetExists($offset) in /var/www/tt-rss/vendor/j4mie/idiorm/idiorm.php on line 2212PHP message: PHP Fatal error:  Uncaught Error: Class 'ORM' not found in /var/www/tt-rss/classes/logger/sql.php:7
Stack trace:
#0 /var/www/tt-rss/classes/logger.php(62): Logger_SQL->__construct()
#1 /var/www/tt-rss/classes/logger.php(80): Logger->__construct()
#2 /var/www/tt-rss/classes/logger.php(32): Logger::get_instance()
#3 /var/www/tt-rss/include/errorhandler.php(81): Logger::log_error()
#4 [internal function]: ttrss_fatal_handler()
#5 {main}

i guess it’s either 8.x or 7.x. very nice.

i’ve reverted that PR for the time being. it seems that we won’t be able to move to 8.1 while supporting 7.0 because of idiorm. either that or choose between two (!) libraries or something.

tbh its somewhat tempting to drop php 7 compatibility altogether.

Thanks, it’s working again.
It’s php 7, and I just checked on my vps which has last debian release (bullseye) and they don’t offer php8

+1. The supported installation method has been on 8 for some time now. It’d be nice to use stuff introduced after 7.1.0 (released December 2016, support ended December 2019), and 7.x (7.4) is close to (officially) dead. Those that can’t move to 8.x could stick with the last compatible tt-rss commit (although plugin updates might get weird… disable in-app updates for 7.x?).

I thought stripping out ArrayAccess might be an option since we’re using -> to access results in the majority of places (0ecf6dc8a7), but there are probably more interfaces that got typed and are breaking.

maybe we could end 7.x support in 2023. that would be giving people a 2 year window to finally switch to docker, which seems like enough.

i don’t do any proactive testing whatsoever on php7 anyway, which recent commits, breaking it again and again, certainly demonstrate.

@MagicDave Do things work under 8.1 if you go back to master and then add #[\ReturnTypeWillChange] to the (multiple) offsetExists, offsetGet, offsetSet, and offsetUnset methods in vendor/j4mie/idiorm/idiorm.php? If so, that’d be something that upstream could safely implement.

Nice idea, yeah the \ReturnTypeWillChange annotation works well. I updated my pull request upstream to use this approach. So it will be compatible with new php 8.1 and backwards compatible as well: Various fixes for php 8.1 compatibility by edlerd · Pull Request #370 · j4mie/idiorm · GitHub

:+1:

/20char-r-r-r-r

I have to admit running an “unsupported installation”. I am also running pretty much everything else in docker, so switching wouldn’t be a problem.

But I guess many users don’t have the ability to run Docker (shared hosting and whatnot).
And dropping support for whatever Debian Stable is using (which is PHP 7.4) will leave many users behind.
just my two cents :v:

debian stable users are stuck with tt-rss from february 2021 for many years to come, and if they don’t want to use tt-rss from the repositories, they might as well use docker.

i’ll give you shared hosting, but this ‘whatnot’ usually involves regressive thinking (you know the type, these people also tend to rant against systemd, etc.).

if they want to keep doing things as if its still 2010, its their prerogative, but i’m not going to limit myself to PHP features from 2010 forever because of them.

the ‘many’ part: i don’t collect any statistics from tt-rss users so i don’t know whether its actually many or few.

Thoughts on introducing a “modern” non-master branch (e.g. main) that’d enable taking advantage of 8.x before then? master could essentially be in maintenance mode for a year while the Docker image tracked the modern branch. Offhand I can think of some concerns about keeping plugin-related compatibility, new version checking, and a potential eventual merge back to master… but moving stuff to 8.x would be nice.

Count me in as someone who has been running tt-rss on Debian for several years now and who sees Docker as a needless complexity.

Same here. Hate to think how long I’ve been a user. My install still runs on Debian. I prefer the flexibility a native install gives me over docker.

nope. too much effort.

this stuff is exactly what i was talking about earlier.

I run TT-RSS in a Linux Container (LXC) because that’s how I prefer things. It’s unfortunate that Debian 11 doesn’t include a more recent version of PHP, but not the end of the world. For those running Debian, you can add deb.sury.org as a source and get more recent versions of PHP from there. It’s what I use when needed.

And ubuntu, too, I see. Thanks for that clue!
.

For ubuntu I can recommend a custom ppa called “ondrej/php”. It has delivered new PHP releases always in short time. You can add it via sudo add-apt-repository ppa:ondrej/php. With it you can even run multiple php-fpm versions in parallel. More info on its launchpad site: ***** The main PPA for supported PHP versions with many PECL ext... : Ondřej Surý

Maybe also an option for the Docker container to switch from alpine to ubuntu and use that ppa?

:face_with_raised_eyebrow:

/20char

I searched and couldn’t find a clear answer. Is there a resolution to this?

I am using the git method and not docker. I just updated to Ubuntu 22.04 beta which delviers final later this month amd it uses 8.1 / Postgresql 14. I am seeing the errorr, “Class “ORM” not found in /usr/share/nginx/html/ttrss/classes/logger/sql.php:7”. I can use the update.php to dump opml and users, so I have the data transfered to Postgresql14 and it seems this is the 8.1 issue discussed above.

BTW, Fedora 36 also uses php8.1

I guess that 8.1 is not officially supported but for Ubuntu that is about to create a problem. If the issue is still avoiding updating because of the need to support php7, can you post a code change we can manually add? Thanks in advance.