Skip to main content
Version: Next

Solidus v3.3 (2022-01-24)

Minimal requirements:

Ruby
v2.7
Rails
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:

config/initializers/spree.rb
Rails.application.config.to_prepare do
  Spree::Config.static_model_preferences.add(
    AmazingStore::Greeter,
    'greeter_preferences',
    name: ENV["GREETER_NAME"],
  )
end

with:

config/initializers/spree.rb
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.

config/initializers/spree.rb
Spree.config do |config|
  # ...
  config.store_credit_prioritizer_class = 'MyStore::StoreCreditPrioritizer'
end
app/models/my_store/store_credit_prioritizer.rb
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