v2
v2 copied to clipboard
miniflux
Allow multiple categories for a feed
- [x] I have read this document: https://miniflux.app/opinionated.html#feature-request
Improving existing features is more important than adding new ones.
I believe this feature meets this requirement.
Hi,
I would like to be able to add multiple categories to a feed. Several feeds I subscribe to have overlapping categories, and it's awkward putting a feed under one category when really it fits two or more. So what I end up doing is either have everything under the existing "All" category, or have super vague and generic categories which somewhat defeats the purpose.
This is where I am drawing inspiration from:
What are your thoughts on this? 😄
Hi,
I submitted an issue here with this idea too.
I proposed 3 different ways of implementation for the UX, the #2 fits your issue!
Check here:
https://github.com/miniflux/v2/issues/2573
I would be happy to implement any of the three options.
Don't know why you wait for my feedback :). Personally I thing it is ok, people that do not want multiple categories can just use one category. Reading the miniflux website I found that https://miniflux.app/docs/migration.html. It was possible to use multiple categories for a feed in Miniflux v1 but this was removed in v2 by the author. The author doesn't want a feature that goes against the philosophy of the software (minimalism) so don't know if this is a wanted feature (there is no formal definition of the minimalism).
oh sorry @rdelaage , i meant to tag @fguillot , whom I assume is the main maintainer. I must have confused you because of the profile picture. oops :)
Like you said though:
The author doesn't want a feature that goes against the philosophy of the software (minimalism) so don't know if this is a wanted feature (there is no formal definition of the minimalism).
This is why I want to hear approval before submitting a PR.
This feature has been requested several times in the past if you search through this issue tracker.
I'm not against this feature, but I am concerned about the number of changes required to implement it properly.
Not only does the database schema have to be modified, but it also impacts different parts of the application, such as the Miniflux API, the Fever API, the web UI, etc.
Not really looking for this feature, but here's my 2 cents: probably the easiest way to implement this is by introducing the new concept of "tags". Each feed is associated with at most one category, and may be associated with an arbitrary number of tags.
Not really looking for this feature, but here's my 2 cents: probably the easiest way to implement this is by introducing the new concept of "tags". Each feed is associated with at most one category, and may be associated with an arbitrary number of tags.
That sounds like a good idea. However, there is a tags field in the entries table that was introduced in PR #1501. This is not a blocker, but it could potentially cause confusion between tags that come from the feeds and the tags defined by Miniflux users in the application. An easy workaround is to use a different naming, for example labels could work.
#1501 started parsing the <category> tags on the entry level, but RSS and Atom specifications also allow <category> tags on the feed level.
I could see a tags array getting added to the feeds table just like what was done in #1501 for entries. When adding a feed, the tags would be auto-filled from the feed itself, but the user could later edit the tags (just like how title, description, etc. can be edited after adding a feed). I don't think it makes sense to create two different fields where one is user-editable and the other is not.
I still have some questions about how this would be fully implemented though:
How would you surface the feed tags in the UI? Maybe different colored pills next to the feed category (like OP's screenshot)? Clicking on a tag pill on either a feed or an entry would send you to the page tags/<tag>/entries/all, but we could add a "Feeds" link at the top of the page (same as the one on the category page), that would send you to a new page tags/<tag>/feeds/all which shows feeds that have that tag.
Since the tags are still just strings in arrays in the DB, it would be hard to create a top-level Tags page. I suppose there's probably some SQL query you could write that would collect all the tag strings and sort them by number of occurrences but that sounds like an expensive operation. But, without the Tags page, tags are hard to discover and users would have to bookmark the tag searches outside the app.
Should entries inherit tags from their feeds?
How do you make feed categories and feed tags separate enough concepts that they don't get confused for each other? I think in an ideal world feeds would have allowed multiple categories and there would be no need for feed tags, but it sounds like that schema change would be too onerous to do at this point.
