Feed specific purge intervals doesn’t seem to be exported in the OPML file with the rest of the settings.
To reproduce: change the purge interval of one of your feeds, then create on OPML export including your settings. The feed specific purge interval is not present in the file.
My understanding was that all the settings are supposed to be exported into the OPML file. However, it appears to me that the OPML file doesn’t contain many other feed specific settings either, but I haven’t tested these specifically. I am not sure if this is a bug or just not implemented yet?..
OPML is there so that you could get your feeds and add them to a different RSS reader / service. it has some tt-rss specific things in it but allowing perfect import/export of everything tt-rss related via OPML was never a goal and it’s not going to happen.
if you want that, use database dump/restore.
e: this is one of those situations where maybe allowing preference export/import was a mistake in the first place because having this creates an expectation for OPML being something more than what it’s supposed to be (and going past that road leads to a neverending feature creep and bloat)
There could be a plugin for this but I couldn’t find anything. In the wiki of ‘ttrss-data-migration’ it says: “Note that this only migrates articles. You can transfer your tt-rss settings and feed subscriptions via OPML import/export before migrating data with this plugin.” This also kind of suggests that with the OPML file, your settings are covered. As you said, there seems to be such an expectation.
So just to be clear: there is no single (text) file that would store all the settings of a user and could be used to easily transfer these to a new installation (of the same version) of TTRSS?
So complete transfer of settings is really only possible via database dump and restore? These is no user-friendlier way to do this? In this case, can we escalate this to a feature request?
you’re right, README should say some settings - or most settings: only main profile, excluding feed-specific ones, plugin settings, maybe something else i’m forgetting.
i don’t have the code in front of me right now but technically data-migration would autocreate feeds for you, i think. maybe not category structure.
this whole thing looks a bit disjointed but you have to understand that preferences-in-OPML appeared literally years[1] before data migration plugin (maybe even plugins in general) became a thing. tt-rss has been around for a while.
anyway, we could bloat up OPML with some per-feed settings, those would be optional and only added to the export if preferences checkbox is enabled. i don’t think there’s any harm in it.
i’m not sure how annoying this would be to implement and what subset of per-feed settings makes sense to migrate (there’s a lot of fields in that table). i’ll make a note to take a look at this.
Author: Andrew Dolgov <[email protected]>
Date: Tue Jun 29 14:26:10 2010 +0400
support import and export of tt-rss preferences in OPML with DOMDocument OPML path
Instead of creating attributes for every little parameter, how about dumping all the settings and base64 encoding them into 1 attribute. I.e. something more generic that will expand easily w/o extra coding. It would be less editable by a user but easier on the maintainer.
To me this sounds like a perfect solution. From the users’ point of view at least. Otherwise I can imagine that this would involve quite some coding. But maybe there are solutions that are easier to scale like what @rodneys_mission is suggesting?..
On the first place, what I had in mind is to migrate user preferences to another installation of TT-RSS, not to another news aggregator. And if we assume that this other installation is also of the same version (maybe even on the same platform), then I would naively assume that maybe all user preferences would make sense to migrate? But I may very well be wrong here of course…
looks like tt-rss already exports some feed settings to OPML (update interval, position in category) so adding a few more things shouldn’t be a problem.
