deprecations.txtfile. You will find that this file contains a lot of duplicates, but you may remove them with another command:
Spree.load_defaults(version)method to ensure that the implicit defaults (those you're not overriding on
spree.rb) stay the same after an upgrade. This method is called on top of the
If you upgrade from Solidus 3.0 to Solidus 3.1, you won't have the
Spree.load_defaultscall in your initializer yet. Please, ensure that you add it before performing the upgrade!
Spree.load_defaultsmethod. However, before that, you need to check which defaults have changed and decide what to do with them. You have a couple of options:
spree.rbif you're sure you still want to use it.
new_solidus_defaults.rb. All the defaults that have changed in the latest version are displayed, each in a commented out line. That allows you to act on each individual new preference performing one of the options given above. If you want to integrate a new preference, you only need to uncomment its line. When you're done with all the defaults, you can flip the version used in
Spree.load_defaultscall and remove the
Spree.load_defaultsis a shortcut that forwards the same method to the configuration object for every available Solidus component: core, backend, frontend & API. You'll see that the
#load_defaultscall, with the previous version as argument, is disassembled into the individual components in
new_solidus_defaults.rb. It gives you more fine-grained control as you can flag as done an individual component by updating its
#load_defaultsversion when you're done with it.
falseand now is
falseand now is
'this'and now is
new_solidus_defaults.rbfile would look something like the following:
trueand uncomment its line in the initializer.
true, remove lines for
core_pref_two, and update the
config.load_defaultcall within the
Spree.configblock to take
'that'. Remove the
new_solidus_defaults.rbinitializer and bump the