* [core] replace everything except bridge name to get a valid whitelist.txt
* [core] do not use hard code repository name to improve working with forks
* [core] trim bridge names from whitelist.txt to reduce chance of failure
* refactor
* fix: bug in previous refactor
* chore: exclude phpcompat sniff due to bug in phpcompat
* fix: do not leak absolute paths
* refactor/fix: batch extensions checking, fix DOS issue
This fixes a future problem when code is placed under a namespace because `get_class($bridge)` will then return e.g. `RssBridge\Bridge\TwitterBridge` instead of the the current value `TwitterBridge`.
Also a bit refactoring of `Configuration.php`.
* docs: Do not use constant names when referring to config options
The options are customizable using a config file and no longer hardcoded in index.php since 8ac8e08abf
* Do not use constants for configuration
Since <8ac8e08abf>, they are just set to the configuration object values.
It was just getting out of sync:
- Minimum PHP version was bumped in 8365a7a34d
- Cache directory permission check was removed in 8e2b65556f
- Whitelist permission check was removed in d4e867f240
Error reporting currently takes place for each error. This can result
in many error messages if a server has connectivity issues (i.e. when
it re-connects to the internet every 24 hours).
This commit adds a new option to the configuration file to define the
number of error reports to suppress before returning an error message
to the user.
Error reports are cached and therefore automatically purged after 24
hours. A successful bridge request does **not** clear the error count
as sporadic issues can be the result of actual problems on the server.
The implementation currently makes no assumption on the type of error,
which means it also suppresses bridge errors in debug mode. The default
value is, however, set to 1 which means all errors are reported.
References #994
Bridge errors are currently included as part of the feed to
notify users about erroneous bridges (before that, bridges
silently failed).
This solution, however, can produce a high load of error
messages if servers are down (see #994 for more details).
Admins may also not want to include error messages in feeds
in order to keep those kind of problems away from users or
simply to silently fail by choice.
This commit adds a new configuration section "error" with
one option "output" which can be set to following values:
"feed": To include error messages in the feed (default)
"http": To return a HTTP header for each error
"none": To disable error reporting
Note that errors are always logged to 'error.log' independent
of the settings above.
Closes#1066
