1

I have edited max_input_vars in php.ini from 1000 to 9000 because I have a filter with more than 1000 rules. When ttrss updated to php 8.1, it created a new php.ini file at a different path, so the next time I clicked Save on the filter, ttrss deleted all my rules over 996. I had to restore the database from backup.

Is there already a way to override php.ini from docker-compose, so I can set max_input_vars without relying on editing php.ini?

If not, I have some ideas:

  1. change the default value from 1000 to 9999. Why not?
  2. allow ttrss to override php.ini values by setting an environment variable that starts with “TTRSS_”, like “TTRSS_max_input_vars”
  3. in the official docker image, change php.ini’s max_input_vars to be set to an environment variable, which we can then set in docker-compose.yml.
  4. change the path to the php.ini from /etc/php81/php.ini to /etc/php/php.ini, and keep that exact path even after php updates.

Either way, I hope ttrss will at least NOT delete excess rules when saving a filter. That causes unexpected data loss. Instead, just show an error message if too many rules were provided.

thanks!

2

the UI would not be very usable with so many filter rules. i suggest making multiple filters instead.

there’s no way to determine whether the user decided to delete excess rules or those were simply not passed by PHP.

if this is a PHP limitation, again, there’s likely no way to know there was some kind of extra data.

TLDR: just make multiple filters.

3

True, it was pretty sluggish with 3000 rules in a filter. Instead of trying to figure out the PHP thing, I took your advice and broke it into multiple filters with 900 rules each.

It probably would be wise to prevent the user from clicking Add once the limit has been reached to prevent accidental data loss. Clicking Save with more than 996 rules just silently deletes some of them, which is hard to notice on a long list.

thank you for the reply

4

this makes sense, however i would limit the amount of rules to 200 or so. the UI is really not fit to handle a lot of those.

instead of hardcoding this could be a tunable.

UI performance is almost entirely frontend JS code (= browser), not much to do with php. there’s just too many elements i suppose and no lazy-loading or any other tricks.