Announcing Solidus 2.8.0
Thanks to all contributors, testers, and users who made this release possible.
Added Api::CouponCodesController#destroy endpoint
A new endpoint has been added to Solidus API. It allows to remove a coupon code from an order. It has currently no backend or frontend implementation but it's common for custom stores to require it.
Moved Reports into an extension
We removed the reports section from admin to an extension. If you use it you have to add it back manually by adding
gem 'solidus_reports', github: "solidusio-contrib/solidus_reports"
Add a store credit reasons UI in Admin
The only way to manage store credit reasons was via console or using a data migration.
Skip forgery protection in api controllers
Rails is now enabling forgery protection by default so we need to explicitly disable it for api requests, as described here:
This PR also enables forgery protection by default in the specs dummy app so that we can really test that the api code is working in a real Rails 5.2+ environment.
Add a Gallery to handle variants and products images
All images that we send to the view layer is now using these classes that contain the logic to retrieve images and are easier to extend. If you have a lot of customization on how you display images you probably need to take a look at how this has been implemented.
Replace jquery_ujs with rails-ujs
This is the Rails standard now. There could be some action required, depending on if the manifest provided by solidus has been changed. Please read the PR description for more info.
Removed code from Spree::Promotion
Previously Solidus used
code column on
spree_promotions to add a code
to promotions that could be used as coupon code by users. This is no more a
thing since we support multiple coupon codes associated to a single promotion.
This change is important because it's quite common for old stores to have some
code field still present in the database, even if it's not used.
When performing the migration present in this PR it will raise an exception if
there are records in the
spree_promotions table with that field present.
It's up to each store to understand how to handle this scenario before running
this migration. We also provide other two ways to handle this, and users can
just change the migration after it has been copied into their store.
It's just matter of changing the content of the
RemoveCodeFromSpreePromotions.promotions_with_code_handler method and make it
return one of the following:
Solidus::Migrations::PromotionWithCodeHandlers::MoveToSpreePromotionCode: it will convert Spree::Promotion#code to a
Spree::PromotionCodebefore removing the
Solidus::Migrations::PromotionWithCodeHandlers::DoNothing: it will print a message to track what we are deleting.
Alternatively users can create their own class to handle data and return that
class. The new class could inherit from
should respond to
frontendcheckout flow #3023 (spaghetticode)
add-configurationguide page #3001 (spaghetticode)