Alexandre Alapetite 1f466d7a2e Implement custom order-by (#7149)
Add option to sort results by received date (existing, default), publication date, title, URL (link), random.

fix https://github.com/FreshRSS/FreshRSS/issues/1771
fix https://github.com/FreshRSS/FreshRSS/issues/2083
fix https://github.com/FreshRSS/FreshRSS/issues/2119
fix https://github.com/FreshRSS/FreshRSS/issues/2596
fix https://github.com/FreshRSS/FreshRSS/issues/3204
fix https://github.com/FreshRSS/FreshRSS/issues/4405
fix https://github.com/FreshRSS/FreshRSS/issues/5529
fix https://github.com/FreshRSS/FreshRSS/issues/5864
fix https://github.com/FreshRSS/Extensions/issues/161

URL parameters:
* `&sort=id` (current behaviour, sorting according to newest received articles)
* `&sort=date` (publication date, which is not indicative of how new an article is)
* `&sort=title`
* `&sort=link`
* `&sort=rand` (random order - which disables infinite scrolling, at least for now)

combined with `&order=ASC` or `&order=DESC`

![image](https://github.com/user-attachments/assets/2de5aef1-604e-4a73-a147-569f6f42a1be)

## Implementation notes

The sorting criteria by *received date* (id), which is the default, and which was the only one before this PR, is the one that has the best sorting characteristics:
* *uniqueness*: no entries have the exact same received date
* *monotonicity*: new entries always have a higher received date
* *performance*: this field is efficiently indexed in database for fast usage, including for paging (indexing could also be done to other fields, but with lower effective performance)

In contrary, sorting criteria such as by *publication date*, by *title*, or by *link* are neither unique nor monotonic. In particular, multiple articles may share the same *publication date*, and we may receive articles with a *publication date* far in the future, and then later some new articles with a *publication date* far in the past.

To understand why sorting by *publication date* is problematic, it helps to think about sorting by *title* or by *link*, as sorting by *title* and by *publication date* share more or less the same characteristics.

### Problem 1: new articles

New articles may be received in the background after what is shown on screen, and before the next user action such as *mark all as read*. Due to the lack of *monotonicity* when sorting by e.g. *publication date* or *title*, users risk marking as read a batch of articles containing some fresh articles without seeing them.

Mitigation: A parameter `idMax` tracks the maximum ID related to a batch of actions such as *mark all as read* to exclude articles received after those that are displayed.

### Problem 2: paging / pagination

When navigating articles, only a few articles are displayed, and a new "page" of articles needs to be received from the database when scrolling down or when clicking the button to show more articles. When sorting by e.g. *publication date* or *title*, it is not trivial to show the next page without re-showing some of the same articles, and without skipping any. Indeed, views are often with additional criteria such as showing only unread articles, and users may mark some articles as read while viewing them, hereby removing some articles from the previous pages. And like for *Problem 1*, new articles may have been received in the background. Consequently, it is not possible to use `OFFSET` to implement pagination (so the patches suggested by a few users were wrong due to that, in particular).

Mitigation: `idMax` is also used (just like for *Problem 1*) and a *Keyset Pagination* approach is used, combining an unstable sorting criterion such as *publication date* or *title*, together with *id* to ensure stable sorting. (So, 2 sorting criteria + 1 filter criteria)

See e.g. https://www.alwaysdeveloping.net/dailydrop/2022/07/01-keyset-pagination/

### Problem 3: performance

Sorting by anything else than *received date* (id) is doomed to be slow(er) due to the combination of 3 criteria (see *Problem 2*). An `OFFSET` approach (which is not possible anyway as explained) would be even slower. Furthermore, we have no SQL index at the moment, but they would not necessarily help much due to the multiple sorting criteria needed and involving some `OR` logic which is difficult to optimise for databases.

The nicest syntax would be using tuples and corresponding indexes, but that is poorly supported by MySQL https://bugs.mysql.com/bug.php?id=104128

Mitigation: a compatibility SQL syntax is used to implement *Keyset Pagination*

### Problem 4: user confusion

Several users have shown that they do not fully understand the difference between *received date* and *publication date*, and particularly not the pitfalls of *publication date*.

Mitigation: the menus to mark-as-read *before 1 day* and *before 1 week* are disabled when sorting by anything else than *received date*. Likewise, the separation headers *Today* and *Yesterday* and *Before yesterday* are only shown when sorting by *received date*.

Again here, to better understand why, it helps to think about sorting by *title* or by *link*, as sorting by *title* and by *publication date* share more or less the same characteristics.

* [ ] We should write a Q&A and/or documentation about the problems associated to *sorting by publication date*: risks of not noticing new publication, of inadvertently marking them as read, of having some articles with a date in the future hanging at the top of the views (vice versa when sorting in ascending order), performance, etc.

### Problem 5: APIs

Sorting by anything else than *received date* breaks the guarantees needed for a successful synchronisation via API.

Mitigation: sorting by *received date* is ensured for all API calls.
2025-01-06 16:00:00 +01:00
2024-12-07 12:11:58 +01:00
2024-12-27 12:12:49 +01:00
2025-01-06 16:00:00 +01:00
2024-12-27 12:12:49 +01:00
2025-01-06 16:00:00 +01:00
2025-01-06 16:00:00 +01:00
2023-12-29 13:36:30 +01:00
2022-06-19 20:03:17 +02:00
2019-07-23 10:01:52 +02:00
2024-12-29 12:54:50 +01:00
2023-11-24 14:50:03 +01:00
2021-10-21 11:44:03 +02:00
2022-11-06 19:05:09 -05:00
2024-12-23 11:48:43 +01:00
2024-12-27 12:12:49 +01:00
2024-12-27 12:12:49 +01:00
2024-09-06 09:35:58 +02:00
2024-12-06 16:39:59 +01:00
2024-08-04 19:40:14 +02:00
2015-10-25 00:01:13 +02:00
2023-11-16 22:43:00 +01:00
2018-12-22 11:39:08 +01:00
2024-10-15 10:56:33 +02:00
2024-12-27 12:12:49 +01:00
2024-12-27 12:12:49 +01:00
2023-06-09 08:26:53 +02:00

Liberapay donations

FreshRSS

FreshRSS is a self-hosted RSS feed aggregator.

It is lightweight, easy to work with, powerful, and customizable.

It is a multi-user application with an anonymous reading mode. It supports custom tags. There is an API for (mobile) clients, and a Command-Line Interface.

Thanks to the WebSub standard, FreshRSS is able to receive instant push notifications from compatible sources, such as Friendica, WordPress, Blogger, Medium, etc.

FreshRSS natively supports basic Web scraping, based on XPath, for Web sites not providing any RSS / Atom feed. Also supports JSON documents.

FreshRSS offers the ability to reshare selections of articles by HTML, RSS, and OPML.

Different login methods are supported: Web form (including an anonymous option), HTTP Authentication (compatible with proxy delegation), OpenID Connect.

Finally, FreshRSS supports extensions for further tuning.

FreshRSS logo

Feedback and contributions

Feature requests, bug reports, and other contributions are welcome. The best way is to open an issue on GitHub. We are a friendly community.

To facilitate contributions, the following option is available:

Open in GitHub Codespaces

Screenshot

FreshRSS screenshot

Disclaimer

FreshRSS comes with absolutely no warranty.

Documentation

Requirements

  • A recent browser like Firefox / IceCat, Edge, Chromium / Chrome, Opera, Safari.
    • Works on mobile (except a few features)
  • Light server running Linux or Windows
    • It even works on Raspberry Pi 1 with response time under a second (tested with 150 feeds, 22k articles)
  • A Web server: Apache2.4+ (recommended), nginx, lighttpd (not tested on others)
  • PHP 8.1+
  • PostgreSQL 10+ or SQLite or MariaDB 10.0.5+ or MySQL 8.0+

Installation

The latest stable release can be found here. New versions are released every two to three months.

If you want a rolling release with the newest features, or want to help testing or developing the next stable version, you can use the edge branch.

Automated install

  • Docker
  • YunoHost
  • Cloudron
  • PikaPods
  • Deploy on Elestio

Manual install

  1. Get FreshRSS with git or by downloading the archive
  2. Put the application somewhere on your server (expose only the ./p/ folder to the Web)
  3. Add write access to the ./data/ folder for the webserver user
  4. Access FreshRSS with your browser and follow the installation process
  5. Everything should be working :) If you encounter any problems, feel free to contact us.
  6. Advanced configuration settings can be found in config.default.php and modified in data/config.php.
  7. When using Apache, enable AllowEncodedSlashes for better compatibility with mobile clients.

More detailed information about installation and server configuration can be found in our documentation.

Advice

  • For better security, expose only the ./p/ folder to the Web.
    • Be aware that the ./data/ folder contains all personal data, so it is a bad idea to expose it.
  • The ./constants.php file defines access to the application folder. If you want to customize your installation, look here first.
  • If you encounter any problem, logs are accessible from the interface or manually in ./data/users/*/log*.txt files.
    • The special folder ./data/users/_/ contains the part of the logs that are shared by all users.

FAQ

  • The date and time in the right-hand column is the date declared by the feed, not the time at which the article was received by FreshRSS, and it is not used for sorting.
    • In particular, when importing a new feed, all of its articles will appear at the top of the feed list regardless of their declared date.

Extensions

FreshRSS supports further customizations by adding extensions on top of its core functionality. See the repository dedicated to those extensions.

APIs & native apps

FreshRSS supports access from mobile / native apps for Linux, Android, iOS, Windows and macOS, via two distinct APIs: Google Reader API (best), and Fever API (limited features, less efficient, less safe).

App Platform Free Software Maintained & Developed API Works offline Fast sync Fetch more in individual views Fetch read articles Favourites Labels Podcasts Manage feeds
Readrops Android ✔️ ✔️✔️ GReader ✔️ ⭐⭐⭐ ➖ ✔️ ✔️ ➖ ➖ ✔️
Capy Reader Android ✔️ ✔️✔️ GReader ✔️ ⭐⭐ ➖ ➖ ✔️ ➖ ➖ ✔️
FeedMe Android ➖ ✔️✔️ GReader ✔️ ⭐⭐ ➖ ➖ ✔️ ✓ ✔️ ✔️
FocusReader Android ➖ ✔️✔️ GReader ✔️ ⭐⭐ ➖ ➖ ✔️ ✓ ✓ ✔️
Fluent Reader Lite Android, iOS ✔️ ✔️ GReader ✔️ ⭐⭐ ➖ ➖ ✓ ➖ ➖ ➖
Read You Android ✔️ Work in progress GReader ➖ ⭐ ➖ ✔️ ✔️ ➖ ➖ ✔️
App Platform Free Software Maintained & Developed API Works offline Fast sync Fetch more in individual views Fetch read articles Favourites Labels Podcasts Manage feeds
Fluent Reader Windows, Linux, macOS ✔️ ✔️✔️ GReader ✔️ ⭐ ➖ ✔️ ✓ ➖ ➖ ➖
RSS Guard Windows, GNU/Linux, macOS, OS/2 ✔️ ✔️✔️ GReader ✔️ ⭐⭐ ➖ ✔️ ✔️ ✔️ ✔️ ✔️
NewsFlash GNU/Linux ✔️ ✔️✔️ GReader ➖ ⭐⭐ ➖ ✔️ ✔️ ✔️ ➖ ➖
Newsboat GNU/Linux, macOS, FreeBSD ✔️ ✔️✔️ GReader ➖ ⭐ ➖ ✔️ ✔️ ➖ ✔️ ➖
App Platform Free Software Maintained & Developed API Works offline Fast sync Fetch more in individual views Fetch read articles Favourites Labels Podcasts Manage feeds
Vienna RSS macOS ✔️ ✔️✔️ GReader ❔ ❔ ❔ ❔ ❔ ❔ ❔ ❔
Readkit iOS, macOS ➖ ✔️✔️ GReader ✔️ ⭐⭐⭐ ➖ ✔️ ✔️ ➖ ✓ 💲
Reeder iOS, macOS ➖ ✔️✔️ GReader ✔️ ⭐⭐⭐ ➖ ✔️ ✔️ ➖ ➖ ✔️
lire iOS, macOS ➖ ✔️✔️ GReader ❔ ❔ ❔ ❔ ❔ ❔ ❔ ❔
Unread iOS ➖ ✔️✔️ Fever ✔️ ❔ ❔ ❔ ✔️ ➖ ➖ ➖
Fiery Feeds iOS ➖ ✔️✔️ Fever ❔ ❔ ❔ ❔ ❔ ➖ ➖ ➖
Netnewswire iOS, macOS ✔️ Work in progress GReader ✔️ ❔ ❔ ❔ ✔️ ➖ ❔ ✔️

Included libraries

Only for some options or configurations

Alternatives

If FreshRSS does not suit you for one reason or another, here are alternative solutions to consider:

S
Description
No description provided
Readme AGPL-3.0
80 MiB
0 Stars 0 Watchers 0 Forks
Languages
PHP 81.4%
CSS 9.5%
HTML 6.6%
JavaScript 2.2%
Shell 0.1%
Other 0.1%