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
wn_name
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.
fox
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.
wn_name
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.
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
hnz101
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 
fox
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.
wn_name
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.
mamil
21
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.
a9db0
22
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.
fox
23
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.
martywd
25
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?
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.
fox
29
https://git-gitea.tt-rss.org/fox/tt-rss/pulls/67#issuecomment-559
dependency issues like this is one of the reasons why everyone has switched to docker.
thanks very much, fox. i haven’t used docker and i did give it a try but I obviously made a mistake and couldn’t figure it out without learning more. I also use nginx and a non-standard port, so I’ll have to read about that interaction as well. Know there are threads here on that as well.
I just hate extra layers. Have to trust the OS distribution and I am trusting your code. But the docker repository adds another layer or more of trust. Given some of the issues with open source being hijacked and some devs intentionally breaking their code as protest, I like to keep things simpler. But I do udnerstand that docker makes your life easier.
But the docker repository adds another layer or more of trust
If you’re that concerned run your own docker repository, build the base images yourself and then use/modify the dynamic docker-compose repo to satisfy your personal level of paranoia.
Docker can be painfully transparent despite what many seem to say
