Solidus v3.3 (2022-01-24)
Minimal requirements:
- v2.7
- v6.0
New year, new Solidus release! This time, we acknowledge our new policy around Ruby & Rails support. It also comes with new features, bug fixes, as well as some deprecations that will be removed in the next major release. Take the time to upgrade. We've committed with the community to release more often, so keeping up to date will help you when Solidus v4.0 is out, which will happen sooner than later.
Before getting hands-on, please review our generic upgrade guides. You can also check the complete Changelog in our repository.
Added support for Ruby v3.2
Solidus v3.3 comes with support for the recently released v3.2 of Ruby. You can safely upgrade to it without Solidus getting in your way.
Removed support for Ruby v2.5
With v3.3, Solidus performs a long-due cleanup of its codebase, removing support for EOL's Ruby versions v2.5 & v2.6. If you're on Solidus v3.2 and you want to upgrade to v3.3:
- Update your Solidus v3.2 store to Ruby v2.6.
- Update your Solidus v3.2 store to Ruby v2.7.
- Update your Solidus v3.2 store to v3.3.
Removed support for Ruby v2.6
Solidus v3.3 no longer supports Ruby v2.6, which reached the EOL status. You'll need to:
- Update your Solidus v3.2 store to Ruby v2.7.
- Update your Solidus v3.2 store to v3.3.
Removed support for Rails v5.2
Rails v5.2 (EOL) support has been removed from Solidus v3.3:
- Update your Solidus v3.2 store to Rails v6.0.
- Update your Solidus v3.2 store to v3.3.
Support for the new Colorado delivery fee
We've updated our taxation system to support the new Colorado retail delivery fee. Please, check the corresponding guide page to setup this new tax on your store.
Deprecate discriminatory wording for Ransack methods
We're deprecating .whitelisted_ransackable_attributes
& .whitelisted_ransackable_associations
in favor of .allowed_ransackable_attributes
& .allowed_ransackable_associations
, respectively. The old terms won't be available on the next major.
Version upgraded for packaged underscore.js
We've upgraded the packaged version of underscore.js from v1.8.3 to v1.13.6. In case you were using it, check compatibility.
Deprecated #mails_from preference
We've deprecated the #mails_from
preference, as it wasn't used in the Solidus codebase anymore. Make sure you aren't using it for anything else. Otherwise, the expected way to handle the default From:
field for transactional emails is the Spree::Store#mail_from_address
attribute.
Store static preferences using string class names
It's no longer necessary to wrap the definition of static preferences within a .to_prepare
block to avoid referencing a constant on an initializer.
You can change code like:
Rails.application.config.to_prepare do
Spree::Config.static_model_preferences.add(
AmazingStore::Greeter,
'greeter_preferences',
name: ENV["GREETER_NAME"],
)
end
with:
Spree::Config.static_model_preferences.add(
'AmazingStore::Greeter',
'greeter_preferences',
name: ENV["GREETER_NAME"],
)
Configurable promotion adjuster
You can now change what the default promotion adjuster does. Configure the Spree::Config.promotion_adjuster_class
preference with a class that takes the order on initialization and responds to the #call
method.
Read the corresponding how-to for more information.
Configurable algorithm to prioritize store credits
Before v3.3, store credits were always sorted by the priority of their type. Now you can change that behavior by configuring the Spree::Config.store_credit_prioritizer_class
preference with a class that takes the store credits and the order on initialization and responds to the #call
method.
Spree.config do |config|
# ...
config.store_credit_prioritizer_class = 'MyStore::StoreCreditPrioritizer'
end
module MyStore
class StoreCreditPrioritizer
def initialize(store_credits, order)
@store_credits = store_credits
@order = order
end
def call
# ...
end
end
end
Allow shipping category on variants
It was already possible for a variant to have a different tax category than its product. Now, that's also true for the shipping category.
Default implementation for PaymentMethod#try_void
When adding a new payment integration, it was required to implement the PaymentMethod#try_void
method. However, it turned out that the logic was always very similar. We now provide a default implementation that would be enough in most situations.
Improved bogus credit card voiding
Before this change, all attempts to void a payment with this testing payment method in the admin panel were successful. It's now possible to simulate a failure by trying to cancel an order with a captured payment.
Variant and product autocomplete functions flexibility with Ransack
It's now possible to customize the autocompletion for variants and products on the backend via a callback returning a Ransack query. E.x.:
$('#product-dropdown').productAutocomplete({
multiple: false,
searchCallback: (searchString) => ({
q: {
name_cont: searchString,
available_on_not_null: true
})
}
})
Add available in product's Ransack scopes
.available
is now available to be used as a Ransack scope in Spree::Product