FreshRSS (Customized)/p/api/fever.php, branch 1.26.3

Fix favicon hashing in GReader API (#7573)

2025-05-09T21:41:31+00:00

* Fix favicon hashing in GReader API (#7570) This allows the correct iconUrl to be returned from the GReader API for a given feed. * Fix method signature * Fix Fever API --------- Co-authored-by: CarelessCaution <189675655+CarelessCaution@users.noreply.github.com> Co-authored-by: Alexandre Alapetite

Reduce undeeded use of elvis operator ?: (#7204)

2025-01-10T07:13:09+00:00

Implement custom order-by (#7149)

2025-01-06T15:00:00+00:00

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.

PHPStan 2.0 (#7131)

2024-12-27T11:12:49+00:00

* PHPStan 2.0 fix https://github.com/FreshRSS/FreshRSS/issues/6989 https://github.com/phpstan/phpstan/releases/tag/2.0.0 https://github.com/phpstan/phpstan/blob/2.0.x/UPGRADING.md * More * More * Done * fix i18n CLI * Restore a PHPStan Next test For work towards PHPStan Level 10 * 4 more on Level 10 * fix getTagsForEntry * API at Level 10 * More Level 10 * Finish Minz at Level 10 * Finish CLI at Level 10 * Finish Controllers at Level 10 * More Level 10 * More * Pass bleedingEdge * Clean PHPStan options and add TODOs * Level 10 for main config * More * Consitency array vs. list * Sanitize themes get_infos * Simplify TagDAO->getTagsForEntries() * Finish reportAnyTypeWideningInVarTag * Prepare checkBenevolentUnionTypes and checkImplicitMixed * Fixes * Refix * Another fix * Casing of __METHOD__ constant

Optimize code: (#6983)

2024-12-07T11:09:29+00:00

before count(...)' is used in a loop and is a low performing construction. after Foreach instead (easier to read and support) Co-authored-by: LucS

Upgrade code to php 8.1 (#6748)

2024-11-28T16:11:04+00:00

* revert Fix code indentation Fix code Upgrade code to php 8.1 * fix remarques * code review * code review * code review * Apply suggestions from code review * code review * Fixes * Many remainging updates of array syntax * Lost case 'reading-list' * Uneeded PHPDoc --------- Co-authored-by: Luc Sanchez Co-authored-by: Alexandre Alapetite

Upgrade to PHP 8.1 (#6711)

2024-09-06T07:06:46+00:00

* Upgrade to PHP 8.1 As discussed in https://github.com/FreshRSS/FreshRSS/discussions/5474 https://www.php.net/releases/8.0/en.php https://www.php.net/releases/8.1/en.php Upgrade to available native type declarations https://php.net/language.types.declarations Upgrade to https://phpunit.de/announcements/phpunit-10.html which requires PHP 8.1+ (good timing, as version 9 was not maintained anymore) Upgrade `:oldest` Docker dev image to oldest Alpine version supporting PHP 8.1: Alpine 3.16, which includes PHP 8.1.22. * Include 6736 https://github.com/FreshRSS/FreshRSS/pull/6736

Minor update whitespace PHPCS rules (#6666)

2024-08-01T18:31:40+00:00

* Minor update whitespace PHPCS rules To simplify our configuration, apply more rules, and be clearer about what is added or removed compared with PSR12. Does not change our current conventions, but just a bit more consistent. * Forgotten *.phtml * Sort exclusion patterns + add a few for Extensions repo * Relaxed some rules

Remove dependency to exif extension (#6624)

2024-07-17T15:33:17+00:00

* Remove dependency to exit extension fix https://github.com/FreshRSS/FreshRSS/issues/6573 * Fix return

Pass PHPStan level 9 (#6544)

2024-06-09T18:32:12+00:00

* More PHPStan * More, passing * 4 more files * Update to PHPStan 1.11.4 Needed for fixed bug: Consider numeric-string types after string concat https://github.com/phpstan/phpstan/releases/tag/1.11.4 * Pass PHPStan level 9 Start tracking booleansInConditions * Fix mark as read * Fix doctype * ctype_digit