Support for Ruby 1.8.7 is going away in this major release. If you are still using 1.8.7, it is time to upgrade. Ruby 1.8.7 is End of Life’d at the end of June
Upgrading to Ruby 1.9.3 or higher is highly encouraged. Spree 2.0 and above supports Ruby 2.
A lot of people have requested the ability to use either the backend or the frontend separately from the other. We did a lot of work toward this goal as part of <%= issue 2225 %> and now Spree is split up into the following components:
The Backend component provides the admin interface for Spree and the Frontend component provides the frontend user-facaing checkout interface. These components were extracted out of Core to allow for users of Spree to override the frontend or backend functionality of Spree as they choose. Core now contains just the very basic needs for Spree.
Along with this work, the Promo engine has now been merged with Spree core. We saw that there was a lot of hackery going on to get promos to work with Core, and a lot of stores want promos anyway, and so merging them made sense.
Additionally, as part of this work, the spreecore assets have been renamed.
store/all.js, you will need to rename the references
. Similarly to this, inadmin/all.css
, you will need to rename the references fromspreecore
Complex Spree stores require sophisticated shipping and warehouse logic that Spree hasn’t had a general solution for until now. Split shipments in Spree allows for multiple shipments per order and for those shipments to be shipped from multiple locations.
There are 4 main components that make up split shipments: Stock Locations, Stock Items, Stock Movements and Stock Transfers.
Stock locations are the locations where your inventory is shipped from. Each stock location can have many stock items. When creating a new stock location, stock items for that location are automatically created for each variant in your store.
Having multiple stock locations allows for more robust shipping options. For example, if an item in an order is out of stock at the location of the other items in a order, a new shipment may be created if that item is found to be in stock at another location.
You are also able to create and manage orders that have items from multiple locations by using the improved admin interface.
Stock Items represent the inventory at a stock location for a specific variant. Stock item count on hand can be increased or decreased by creating stock movements. Because these are created automatically for each location you create, there is no need to manually manage these.
Stock movements allow you to manage the inventory of a stock item for a stock location. Stock movements are created in the admin interface by first navigating to the product you want to manage. Then, follow the Stock Management link in the sidebar.
For more information on split shipments and how they pertain to inventory management, read the Inventory Guide.
For more information on the classes introduced by split shipments and how to work with them programmatically, see the Shipments Guide.
Stock transfers allow you to move inventory in bulk from one stock location to another stock location.
Stock transfers generally consist of a source location, a destination location, one or more variants and an optional reference number. Stock transfers can also be used as a way to track new stock, in which case only a stock location destination and variant are required.
Spree 2.0 now comes with namespaced translations so that translations in your application will no longer conflict with those within Spree. It’s recommended that if you have extension that uses Spree to move its translations into the Spree namespace to avoid the same problem.
Translations within Spree views should now use the
Spree.t helper, rather than the
helper so that they are namespaced correctly.
API clients can now manage the following resources through the API:
- Option Types
- Option Values
- Inventory Units
- Stock Items
- Stock Locations
- Stock Movements
The documentation for these endpoints hasn’t been written yet, but will be shortly.
The API now can enforce instance-level permissions on objects. This means that some users would be able to access a single item within a resource, rather than an “all or none” approach to the API.
<%= commit “548dc0c58e4400501bc67cddea942fda1c7dbad3” %>
If you wish to use a custom template for an API response you can do this by
passing in a
template parameter to API requests.
Adjustments can now be open, closed or finalized, allowing for a more flexible adjustments system. An ‘open’ adjustment can be modified, whereas a ‘closed’ adjustment cannot. Finalized adjustments are never altered.
<%= commit “43a3cca49180b1572e41bc3638d3ca0f0e9116d9” %>
Order population responsibility has been moved out to its own class. This has been done so that the API, Core and any other extensions that wish to use the order population logic have an easy way to do so.
See <%= issue 2341 %> and <%= commit “432d129c86e03597347cd223507d9386e9613d62” %> for more information.
Coupon application responsibility has been moved out to its own class too. This has been done so that the API, Core and any other extensions that wish to apply coupons have an easy way to do so.
<%= commit “8ac9ac1c56fe1e471dd5b0124edbe383a8c70c48” %>
Product duplication code has been moved out to its own class as well.
<%= issue 2641 %>
To add or remove steps to the checkout flow, you can now use the
remove_checkout_step helpers respectively. This patch has been backported
to 1-3-stable as well, and will be available in Spree releases >= 1.3.3.
insert_checkout_step takes a
after option to determine where to
insert the step: