Rails has changed the way helpers are loaded. It's a bit weird. It was throwing lots of errors, and recommended using this setting, but now requires that all helpers are loaded explicitly. I'm not sure about this.
Rails 5.2 has changed the way initializers are called during certain rake tasks including `db:create`. Initializers that were previously not loaded are now loaded (basically the whole app is loaded). This means any calls to #table_exists? that appear in the app will throw fatal errors as the database doesn't exist yet during that task, but those calls are made before `db:create` has even started, which means the database can't be created.
There are also a few other places in Spree code where #table_exists? is called, and they already call #connected? first to guard against this issue.
Since we adopted Skylight to get response times across endpoints and
instances, we failed to get accurate numbers. Our Rails version is not
supported and thus Skylight fails to provide data for the slowest
endpoints, the ones we care about the most. Even with a supported one we
could potentially hit any limits on tracing and have the same problem.
Recently, we started paying for Datadog's APM and the experience,
although it's still early, has been better. It makes it possible to
correlate between services and other metrics which helps spotting the
underlying issues.
Therefore, having two agents running on the server consumes system
resources so we better get rid of Skylight's one.
In OFN we cannot split the orders because one order can only have one shipment
Additionally, add spec to validate that the order workflow now works with products with different shipping categories
See this commit for more details: 18e5b98f5c (diff-b0846898827183f530c113ad7b83b8ea)
Also:
- remove shipping method restriction on calculators to inherit from Spree::Shipping::ShippingCalculator so that OFN customized calculators keep working
- add shipping method serializer spec to test serialization of all shipping methods configured
This setting defines which locales will be exported to the frontend.
In general, ofn currently functions under a single locale
(which is also the default locale) but all translations are made from
the `en` locale.
The current process of ensuring translations are translated and make
their way into code is manual and prone to issues so occasionally
translations for keys in the default locale of a particular instance
are not deployed and the UI displays `missing translation` messages.
In these cases, it is far friendlier for the user to see fallbacks to
`en` rather than these errors so this commit ensure that at the very
least apart from the current default locale, `en` is also made available
and as such will be exported to the frontend so that it's translations
are available as a fallback in JS land.
I18n fallback config was already enabled in both frontend and backend.
Until now, available locales may not have been set (determined by the
`AVAILABLE_LOCALES` env var) and the translations for `en` not therefore
be present in the frontend for fallback to actually work.
This commit will ensure that a fallback to `en` is always possible in the
case of missing translations.
