See previous commit.
This isn't nice, but it does the same job as the gem did. We can also update this code now as Rails changes (the gem was incompatible with Rails 7).
This:
```
DEPRECATION WARNING: Initialization autoloaded the constant User.
Being able to do this is deprecated. Autoloading during initialization is going
to be an error condition in future versions of Rails.
Reloading does not reboot the application, and therefore code executed during
initialization does not run again. So, if you reload User, for example,
the expected changes won't be reflected in that stale Class object.
This autoloaded constant has been unloaded.
In order to autoload safely at boot time, please wrap your code in a reloader
callback this way:
Rails.application.reloader.to_prepare do
# Autoload classes and modules needed at boot time here.
end
That block runs when the application boots, and every time there is a reload.
For historical reasons, it may run twice, so it has to be idempotent.
Check the "Autoloading and Reloading Constants" guide to learn more about how
Rails autoloads and reloads.
```
This construct was previously used in Spree to switch out the user class with a dummy class during certain tests. We don't use this any more, so it's just mess.
🔥
Fixes deprecation warnings in Paperclip::UrlGenerator#escape_url
On a side note: we shouldn't be using Paperclip at all, and should migrate to ActiveStorage.
Currently sessions set on (www.openfoodnetwork.xxx) are not usable on the bare domain (openfoonetwork.xxx). When transitioning from one to the other, the user's session is completely lost.
This change means sessions on subdomains (including www) will be transferable.
This setting is now deprecated and triggers this message:
Association Tracking for PaperTrail has been extracted to a separate gem. To use it, please add `paper_trail-association_tracking` to your Gemfile. If you don't use it (most people don't, that's the default) and you set `track_associations = false` somewhere (probably a rails initializer) you can remove that line now.
Previously we only set these part-way through deployment, so the values could be out of sync between our ENV vars and Spree::Config (which itself is a mix of both cached values and database-persisted values).
