Can't sort feed categories



I can’t sort my feeds via prefs/Feeds. The category tree is displayed an I am able to drag and drop categories around, but when I leave the prefs menu, the main window shows the old sort order.

I tried resetting the sort order, which worked, but the problem persisted – all the categories are now sorted alphabetically, another sort order is initially displayed in prefs/Feeds, but when I leave prefs: Back to alphabetically.

I tried deleting the cookies, opening TT-RSS in an incognito browser session, disabling plugins, exporting feeds to OPML and changing the sort order manually in the OPML file before importing: Nothing changed the behaviour. Still can’t sort.

I’m currently running Tiny Tiny RSS v17.12 (c30f5e1) on CentOS 6 with MySQL 5.1 and PHP 5.4.16. Unfortunately, I can’t say since what version I encounter this problem, as I didn’t try to chance the sort order for some time until now.

Is there anything I am missing? How can I change feed sort order again?

Also, a related question: in prefs/Feeds the category tree is always fully expanded. Is there an easy way to collapse every category so sorting is easier?

Looking forwards to your ideas!




drag and drop sorting works fine here. if there’s no logged errors idk what could be wrong.

category and feed order is done via the database so it’s not affected by anything in your browser like cookies.

it could be some incompatibility with php 5.4 specifically which is seriously old at this point.


Thanks for your input! I updated PHP, but it didn’t solve the problem, also nothing in the error log. Switching to a newly initialized database worked though, so I guess I just have to ditch the old database and migrate my feeds into a new one. Bit of work, but at least my PHP installation is up to date now.



It didn’t work. I imported my feeds via OPML, and the problem was there again. I even set up an entirely new instance, same problem as soon as I import the OPML: Every manual change in the order is ignored, the only thing that works is renaming the categories (I put numbers before them, so that the automatic order corresponds to the intended display order.)

Can an OPML file (generated by TT-RSS) be somehow corrupted? Maybe it is because of the names of the categories – some contain blanks, some German umlauts (ä, ö, ü).

And also: As soon as I drag and drop a category in the Feeds tree, all categories are expanded, so I constantly have to collapse all categories manually when I want to move a category or scroll endlessly. (Is the sheer number a problem? I have > 400 Feeds in about 20 categories, some of them nested.)



Have you checked both the server logs for errors and your browser console when you’re attempting to move the feeds? It helps to have the console open since you’ll see errors as they happen.

Do other aspects of TT-RSS work properly (e.g. marking feeds as read, starring articles, etc.)? In other words, thinking of your usage over the entirety is there anything that now stands out as being unusual or not working intermittently?


I tried again moving categories, this time with the console on – no error is displayed.

Most things work as intended. After the PDO update in December I had some problems: Some feeds didn’t refresh at first, but most of them worked again without intervention after some days. Then only one problem remained: I had a filter which marked every article (via regex “.*”) in a certain subcategory as read and starred it. The feeds in this subcategory weren’t updated, but when I removed that filter, the updates came flowing in.

I noticed the problems with the category moving when I moved this subcategory out of its parent category, I wanted to try if the filter problem hat something to do with subcategories. This worked, but after moving the subcategory up (so it hasn’t a parent category), I couldn’t change anything, yet my custom category order remained. I tried resetting it, and from this point on only the default alphabetical order worked.

I looked directly in the database; in *_feed_categories, for every category order_id is 0. Is this correct?



So 0 means they’ll all get sorted the same, which is what you’re experiencing. It does mean the changes are not making it to the database, though that’s not exactly new information given what you’ve posted so far.

Then it’s probably a server-side issue.

By default TT-RSS logs server-side errors to the database; you can view them by logging in as the admin, going to Preferences and it’s one of the last tabs. That assumes you have not changed the default logging destination in TT-RSS’s config.php file. If you’re checking for errors in a log file on the server itself (like in /var/log or similar) they wouldn’t show up there. I don’t know your skill-level or knowledge with this so if you’ve already checked the correct location, great; but I’m mentioning for thoroughness. Be sure to check and confirm back with us. It’s technically also possible for the error to be in logs in /var/log (for example) if the error occurs before TT-RSS hooks error logging. It seems to me that would more obvious since things would be really broken then, but it’s worth checking both spots.

It’s difficult to troubleshoot with no errors so if the correct location has no errors, try explicitly turning PHP error logging on (just temporarily) to see if that makes a difference with what’s reported.


that’s the default value

if sorting stops working after you import opml than it’s something to do with your feeds - could be the amount or dojo rendering code reacting to the amount, could be sorting code failing because the upload is too big or has unexpected syntax. without looking at the data and with no errors reported in tt-rss error log it’s impossible to guess why this could happen.

dojo sends a pretty huge JSON object on drag and drop which needs to be parsed, something can go wrong there, somehow.

if all else fails you can set order_id manually via database frontend of some kind. :man_shrugging: either that or send me your opml, i’ll take a look.

e: to answer your previous question about preferences: feeds are expanded because this works better for people who don’t subscribe to hundreds of feeds i.e. there’s more visibility. i think there’s some kind of threshold where it stops doing that (or not, don’t remember right now).

e2: looks like there’s no such threshold atm, maybe this should be added. set it to hundred or something.


I really appreciate all the effort you put in that, thank you very much! Indeed my skill level regarding such things is not that high; enough to google and use what I find in documentations and stackoverflow.

I try to get some meaningful error message and get back to you!



I sent you a link via DM to my OPML, thanks for caring!

Regarding the expansion/collapse of the feed tree: Maybe a toggle in the first menu item collapse/expand all would be a solution people with fewer feeds than the threshold could use, too.



Over night, the error log filled. Here’s an error and a warning, both entries appear repeatedly:

E_ERROR (1) classes/rssutils.php:1159 Uncaught exception ‘PDOException’ with message ‘There is no active transaction’ in /var/www/virtual/fxn/XXX/classes/rssutils.php:1159 Stack trace: #0 /var/www/virtual/fxn/XXX/classes/rssutils.php(1159): PDO->commit() #1 /var/www/virtual/fxn/XXX/classes/rssutils.php(185): RSSUtils::update_rss_feed(‘220’, true, false) #2 /var/www/virtual/fxn/XXX/update.php(199): RSSUtils::update_daemon_common(50) #3 {main} thrown

PDOStatement::execute(): SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (fxn_ttrss.ttrss_tags, CONSTRAINT ttrss_tags_ibfk_1 FOREIGN KEY (post_int_id) REFERENCES ttrss_user_entries (int_id) ON DELETE CASCADE)

E_WARNING (2) classes/rssutils.php:1139 PDOStatement::execute(): SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (fxn_ttrss.ttrss_tags, CONSTRAINT ttrss_tags_ibfk_1 FOREIGN KEY (post_int_id) REFERENCES ttrss_user_entries (int_id) ON DELETE CASCADE)

  1. classes/rssutils.php(1139): execute(Array)
  2. classes/rssutils.php(185): update_rss_feed(220, 1, )
  3. update.php(199): update_daemon_common(50)

(XXX replaces parts of the path)



this is not related to categories or sorting, search the forum for details.

tldr it’s a known issue maybe connected to concurrent feed updates.


Thanks! I looked up all the threads concerning PDO Exceptions, but with no success:

The error message in this thread is the most similar to the one I got. I’m already on the trunk version containing the solution there, and I can’t find a line similar to the one fixed for that problem near the positions my error indicates.

This one is update-related, there was a problem with a plugin. But I use neither the plugin mentioned there nor does the error go away when I deactivate all plugins.

Something about Unicode problems, doesn’t seem like my problem.

Seems to be the same as the first one.

Regarding concurrent feed updates: I use daemontools to run the feed updates (as described here:; front end feed update is disabled. In the services’ logs I don’t see any errors.

Maybe you could point me to the solution I missed in the threads I looked at.



There isn’t a solution. Fox said it was a “known issue”; in other words, people have reported before but a fix hasn’t been worked out at this time. Nothing really breaks as a result of it so for now don’t worry about it.

Besides, it’s not related to the issue you have. And running the updater with error reporting wouldn’t report any relevant errors for your original issue anyway since the updater runs in the background and you are having a front end issue. You should keep error reporting on and try to organize those categories and see if anything gets logged.


i’ve imported your OPML (made a new user, imported the file, enabled feed categories which were disabled for some reason after import - do you actually have categories enabled?) on my instance (debian 9, postgresql, php7) and unfortunately reordering worked as expected: i dragged categories and feeds around a bit and everything saved correctly, that is preferences tree showed correct user-specified order after page reload.

also, i agree that preferences feed tree is not really prepared to handle so many entries. i’ll make a note to add the threshold i’ve posted about upthread tomorrow.

e: about the tags thing, the reason it’s not fixed is a) i never have this problem here and b) i might just be too dumb to realise why it happens for others. either that or error is somehow misleading.