Support for PHP 8.1

Tiny Tiny RSS Development
1

Hello,

is it planned to support PHP 8.1 in the near future? Anything I could help with to make it compatible?

Best
David

2

8.1 will likely work fine. If you feel like it, try it out and let us know if you run into any issues :slight_smile:

It doesn’t look like 8.1 has landed in the Alpine package repo yet (edit: Roadmap to PHP 8.1 (#12966) · Issues · alpine / aports · GitLab), so the tt-rss Docker image making the jump is still a ways out.

3

I tried it and there is some issue with autoloading the ORM class. The first page load errors out with 500 because the reference in classes/logger/sql.php:7 to ORM can’t be resolved.

Not so pressing, but a bunch of warnings come from using the now deprecated strftime function.

4

post full backtrace, etc.

5 
PHP message: PHP Fatal error:  During inheritance of ArrayAccess: Uncaught Error: Class "ORM" not found in /var/www/ttrss/classes/logger/sql.php:7
Stack trace:
#0 /var/www/ttrss/classes/logger.php(62): Logger_SQL->__construct()
#1 /var/www/ttrss/classes/logger.php(80): Logger->__construct()
#2 /var/www/ttrss/classes/logger.php(32): Logger::get_instance()
#3 /var/www/ttrss/include/errorhandler.php(60): Logger::log_error()
#4 /var/www/ttrss/vendor/j4mie/idiorm/idiorm.php(115): ttrss_error_handler()
#5 /var/www/ttrss/vendor/composer/ClassLoader.php(571): include('...')
#6 /var/www/ttrss/vendor/composer/ClassLoader.php(428): Composer\Autoload\includeFile()
#7 /var/www/ttrss/classes/db.php(11): Composer\Autoload\ClassLoader->loadClass()
#8 /var/www/ttrss/classes/db.php(82): Db->__construct()
#9 /var/www/ttrss/classes/db/migrations.php(33): Db::pdo()
#10 /var/www/ttrss/classes/config.php(386): Db_Migrations->__construct()
#11 /var/www/ttrss/classes/config.php(381): Config->_get_migrations()
#12 /var/www...PHP message: PHP Fatal error:  Uncaught Error: Class "ORM" not found in /var/www/ttrss/classes/logger/sql.php:7
Stack trace:
#0 /var/www/ttrss/classes/logger.php(62): Logger_SQL->__construct()
#1 /var/www/ttrss/classes/logger.php(80): Logger->__construct()
#2 /var/www/ttrss/classes/logger.php(32): Logger::get_instance()
#3 /var/www/ttrss/include/errorhandler.php(81): Logger::log_error()
#4 [internal function]: ttrss_fatal_handler()
#5 {main}
  thrown in /var/www/ttrss/classes/logger/sql.php on line 7
6

Nevermind, I had local changes that lead to the autoloading issue.

7

Added a pull request to get rid of some warnings: https://git.tt-rss.org/fox/tt-rss/pulls/56

8

thanks, commented on the PR.

9

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}
10

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.

11

tbh its somewhat tempting to drop php 7 compatibility altogether.

12

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

13

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

14

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.

15

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

16

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

17

:+1:

/20char-r-r-r-r

18

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:

19

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.

20

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.