The hiredis client was praised as being faster parsing bulk responses
but it seems to have multiple issues now:
- The redis release 5.0 moved hiredis support to another gem.
- I tried the hiredis-client gem and it raised errors.
- There are claims of worse performance of hiredis [1].
- Maintenance responsiveness has been questioned [2].
Using the default redis driver seems to work fine though.
[1]: https://discuss.rubyonrails.org/t/hiredis-does-not-support-ssl-action-cable/75945
[2]: https://github.com/redis/hiredis/issues/655
This fixes the following deprecation warnings
```
DEPRECATION WARNING: `config.serve_static_files` is deprecated and will be removed in Rails 5.1.
Please use `config.public_file_server.enabled = true` instead.
(called from block in <top (required)> at /home/runner/work/openfoodnetwork/openfoodnetwork/config/environments/test.rb:13)
DEPRECATION WARNING: `config.static_cache_control` is deprecated and will be removed in Rails 5.1.
Please use
`config.public_file_server.headers = { 'Cache-Control' => 'public, max-age=3600' }`
instead.
(called from block in <top (required)> at /home/runner/work/openfoodnetwork/openfoodnetwork/config/environments/test.rb:14)
```
Fixes the following deprecation warning:
```
DEPRECATION WARNING: The configuration option `config.serve_static_assets` has been renamed to `config.serve_static_files` to clarify its role (it merely enables serving everything in the `public` folder and is unrelated to the asset pipeline). The `serve_
static_assets` alias will be removed in Rails 5.0. Please migrate your configuration files accordingly. (called from block in <top (required)> at /usr/src/app/config/environments/test.rb:13)
```
The default was being ignored in our new logging configuration, and the actual log output was way too high. This was causing serious disk space issues.
For some reason running `bundle exec rake db:migrate RAILS_ENV=staging`
fails with:
```
rake aborted!
NameError: uninitialized constant Spree::Config
```
Running `bundle exec rails server` for instance, does not. There must be
a difference on the way a rake task and the rails commands load the app.
Moving this configuration to an initializer, at the end of the
initialization process, fixes it. The constant `Spree::Config` is
already loaded.
**This is preventing the release v1.22.0 from being staged and tested**
Since `en` is considered as the main fallback for all locales
ensure that it is present in all environments.
Note: Setting `config.i18n.fallbacks` to `true` means use the default locale
which means that if a particular instance is not using an `en` based locale
(the parent `en` locale is automatically derived as a fallback) then `en` will
not be available as a fallback.
Otherwise, there are no log lines for any request, which makes it
impossible to find out anything about the app in production.
Obviously this increases the size of the log files but this has to be
dealt with log rotation. The data is our most important asset.
