When user searches `something SPACE SPACE something`, there is an empty keyword between the two spaces, which has to be ignored.
This also ignores the case of empty queries between double quotes, such as `""` or `" "`, because PostgreSQL Full Text Search does not support them.
* Make the 'Recently read' max age configurable via preference.
Also: don't attempt to filter by unread articles when using the 'Unread' view mode in the 'Recently read' feed.
* Rebase translations.
Prior to this 'DAEMON_UNSUCCESSFUL_DAYS_LIMIT' would disable empty (but otherwise valid) feeds due to 'last_successful_update' not getting set/updated.
Since there might be valid reasons for a feed to be empty, and tt-rss doesn't currently treat such a feed as invalid or surface info that it will be disabled, we'll just treat that situation as a successful update.
As indicated in the current help page, searching a date keyword does not work as expected due to UTC comparison.
For example, if the current time is November 18th at 16:14 UTC, then in Japan (GMT+9), it's November 19th at 01:14. A Japanese user who searches for _@yesterday_ means November 18th. However the current implementation uses _strtotime()_ with a default timezone of UTC, so _strtotime("yesterday")_ returns November 17th (because it's still the 18th in UK). There is a time shift after, but it can't solve this first issue. Then, a second issue is related to the conversion of the _updated_ SQL column to a string "YYYY-MM-DD", but there is no time shift.
I choose to fully rewrite this code, using the modern PHP DateTime class, and to use a _true_ Unix timestamp range, instead of a shifted timestamp.
A search query can now use _label:true_ to find articles with a label, whatever its name is.
A search query can now use _tag:true_ to find articles with a tag, whatever its name is.
This change is straightforward, because more complex queries about label/tag matching were already implemented.
By using two SQL fragments, there is no redundancy in the code.
When a search is performed, the found text should be highlighted.
However:
- successive words are not highlighted because the SQL query with "<->" is used
- operators are highlighted
tt-rss is currently supporting complex text search queries like _( one | two )_.
However, simple queries containing only _!_, _(_ or _)_ were not supported.
This is because the regexp only matched _&_ and _|_.
A search filter can for example contain spaces such as _title:" be "_.
In this case, the user as explicitly added spaces (instead of using _title:be_), so she clearly indicates her intent to search the word _be_, and not _cyBErspace_.
This patch supports these cases, for keywords title, author and notes.
Also, do a _mb_strtolower()_ globally, because it was in every keyword processing.
Also process the double quoting magic with a consistent regexp in the three needed cases. This change was needed because the previous regexp did not support leading spaces in the value part of a keyword pair.
When a user searches _-note:store_ the results now contains:
- articles with a note different of "store"
- articles with no notes
Indeed, the NULL case was not handled, so articles without a note were not displayed.
'Pref_Prefs::_plugin_needs_update()' can return null if a plugin directory is a git repo but an issue occurs (e.g. not on an allowed branch, not able to fetch from origin).
Closestt-rss/tt-rss#171.
A known issue was that the Search Query _title_ was searched using LIKE instead of Full Text Search. It was the same for all keys of an invalid key pair. Solving this suppresses a lot of redundant code.
The Search Queries _start:false_, _pub:false_ and _unread:false_ are now checked.
If the check fails, the SQL error message is bold/strong to be more visible.
The Search Query _@invalid-date_ is now also searched as Full Text Search. Unfortunately, there is no error message, but document it in the source code.
The function _search_to_sql() processes the query string.
It contained a few bugs.
While analyzing it, I also added comments about the known limitations of this function.
When a user adds tags to an article, a textarea is used to retrieve the values. The form indicates that tags have to be separated by commas.
However, it is also convenient to separate them by linefeeds. A user can also enter a linefeed thinking it is a separator.
Keeping tags with new lines in the middle is not useful. So, split the string on commas and linefeeds.
The table ttrss_user_prefs was replaced by ttrss_user_prefs2 in database version 141.
However, the profile cloning feature still uses twice the old table name, so nothing is really cloned.
The getProfiles() function also uses this old table, so the attribute "initialized" is always false, so there is always "(empty)" at the end of cloned profile names.
In the dialog showing hotkeys, the '?' key explanation was Show help dialog. However, it does not open an help page, but the list of keyboard shortcuts. This sentence is more clear.
When a filter is edited, the Match tab contains one line per rule.
Rules which are not inverted should appear in green color. However, every rule line appears in red.
This is due to $rrow['inverse'] not being unset before calling _get_rule_name().
Indeed, function _get_rule_name() expects $rrow['inverse'] to be unset to mean "false", in order to have a behavior similar to the HTML checkbox which is unset when not checked on the web page.
