Take advantage of PHP7+ null-coalescing operator `??` to make code more standard, shorter, and faster instead of custom function with no extra functionality.
Allows code to be better tested and fix two PHPstan errors:
```
------ -----------------------------------------
Line app/Controllers/configureController.php
------ -----------------------------------------
410 Cannot unset offset 'rid' on string.
------ -----------------------------------------
------ ------------------------------------
Line lib/Minz/FrontController.php
------ ------------------------------------
70 Cannot unset offset 'c' on string.
71 Cannot unset offset 'a' on string.
------ ------------------------------------
```
https://github.com/FreshRSS/FreshRSS/issues/4016
#fix https://github.com/FreshRSS/FreshRSS/issues/3735
Before, we were relying on an exception during the first stages of user initalisation. Now the check is explicit and cleaner, producing a more appropriate HTTP response for the API.
When a feed returns an HTTP 410 Gone, mute the corresponding feed, i.e. stop refreshing it.
Example of such feed, Les Décodeurs (Libération) https://rss.liberation.fr/rss/100893/
* Reload full content when changed
If an article is changed, reload also its full content when applicable.
* Compute hash before getting full content
* Revert mix two PRs
* Update app/Controllers/feedController.php
* Update Travis line length
* Also check whitespace in CSS files
* Fix line length ext.php
* More syntax, string templates
* Fix exclude-pattern
* Test JS files as well
Before, every + sign was converted to a space to allow to search for
spaces. But the documentation stated that to search for space one has
to enclose the string in quotes. This has a confusing behavior when
searching for a string containing a + sign.
Now, the + conversion is kept only for the tag search since it's the
only one documented that way.
See #3454
Before, the feeds in the list weren't properly ordered. Uppercase
values were before lowercase values.
Now, the feed order is forced to ignore the case.
See #3228
Before, when appending or prepending the content of the CSS selector
content, it was added to the content. It was working fine for the
first call but every subsequent calls were pilling the retrieved
content on top of the already retrieved content. Thus we had an ever
growing content with a lot of duplication.
Now, the CSS selector content is identified by an HTML comment which
is used to remove the content for every subsequent calls.
The bug was introduced in #3453
Before, when retrieving article contents with CSS selector, the content
of the RSS feed was replaced by the content of the CSS selector. It works
well in most of the cases but if there is a different content in the feed
and in the selector, the former is lost.
Now, there is a parameter to decide which action is performed after retrieving
the content. By default, the previous behavior is kept. But now, it is
possible to append or prepend the CSS selector content to the feed content.
See #3451
There was an erroneous '; at the end of the commitNewEntries DELETE query, resulting in an exception during actualization with this output:
```
FreshRSS starting feeds actualization at 2021-01-11T14:06:09+00:00
FreshRSS actualize candrews...
PHP Fatal error: Uncaught PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ''' at line 1 in /var/www/localhost/htdocs/FreshRSS/lib/Minz/Pdo.php:45
Stack trace:
#0 /var/www/localhost/htdocs/FreshRSS/lib/Minz/Pdo.php(45): PDO->exec()
#1 /var/www/localhost/htdocs/FreshRSS/app/Models/EntryDAO.php(167): Minz_Pdo->exec()
#2 /var/www/localhost/htdocs/FreshRSS/app/Controllers/feedController.php(505): FreshRSS_EntryDAO->commitNewEntries()
#3 /var/www/localhost/htdocs/FreshRSS/app/Controllers/feedController.php(548): FreshRSS_feed_Controller::actualizeFeed()
#4 /var/www/localhost/htdocs/FreshRSS/lib/Minz/Dispatcher.php(119): FreshRSS_feed_Controller->actualizeAction()
#5 /var/www/localhost/htdocs/FreshRSS/lib/Minz/Dispatcher.php(47): Minz_Dispatcher->launchAction()
#6 /var/www/localhost/htdocs/FreshRSS/lib/Minz/FrontController.php(81): Minz_Dispatcher->run()
#7 /var/www/localhost/htdocs/FreshRSS/app/actualize_script.php(75): Minz_FrontController->run()
#8 {main}
thrown in /var/www/localhost/htdocs/FreshRSS/lib/Minz/Pdo.php on line 45
Results:
```
* Do not import feed causing DB error
The DB error might be that the new feed tries to redirect to an already
existing feed, in which case
#fix https://github.com/FreshRSS/FreshRSS/issues/3339
* Add feed bug
* Change user query wording
There was some misunderstanding in the use of the user query feature,
probably because of the wording. I've change it to make it more obvious.
* Fix feedback when a query is bookmarked
Before, the displayed query name was not the one intended. Now, the name is the one of the current bookmark
* Document user queries
I've added a few words on how to use the user queries because it seems there was some misunderstanding. See #3219
Before, share options were displayed in the order defined in the
configuration file. So the order reflected the share history and
was not really usable.
Now, share options are displayed in alphabetical order which makes
much more sense.
* Avoid manual intialisations of system or user configuration
More consistent use of Context
* Simplify FreshRSS_Context::initUser
* Remove a few manual get_user_configuration
* A bit of debugging
* Fix context user init
* Fix install
* Fix concurrency
Concurrent requests could lead to bad race condition
* Fix actualize cron
Fix case when system i initialised several times
Before, we had 5 classes in the ModelPdo file. It was bad for 2 reasons.
The first reason is that it is considered bad practice to have multiple
class in one file. This is especially true when using autoloading. On top
of that it is less readable considering the size of the file. The second
reason is that so far we were lucky. Everytime we needed to access the
database, it was through the ModelPdo class which loads all the other
classes. If we want to access directly the connection, it wont be loaded.
On top of that, the system is configured to work on a single database,
but as we have every connection definition in a single file, all classes
were loaded at the same time. Thus using memory and processing time for
nothing.
Now, we have a file for each class. To work with autoloading, classes
were slightly renamed to match autoloading rules.
Before, we had 5 classes in the ModelPdo file. It was bad for 2 reasons.
The first reason is that it is considered bad practice to have multiple
class in one file. This is especially true when using autoloading. On top
of that it is less readable considering the size of the file. The second
reason is that so far we were lucky. Everytime we needed to access the
database, it was through the ModelPdo class which loads all the other
classes. If we want to access directly the connection, it wont be loaded.
On top of that, the system is configured to work on a single database,
but as we have every connection definition in a single file, all classes
were loaded at the same time. Thus using memory and processing time for
nothing.
Now, we have a file for each class. To work with autoloading, classes
were slightly renamed to match autoloading rules.
* bump default logout from 30 to 365 days
* * Change cookie duration to constant
* Change cookie duration to three months
* use class
* use 90 days (otherwise login form says 91.3 days)
* change class
* also this works now
Co-authored-by: Martin Rys <martin@rys.pw>
Co-authored-by: Frans de Jonge <fransdejonge@gmail.com>
