Spree Commerce

Try It Now

Upcoming Changes to Checkout Customization

Posted on July 11, 2012 by radar

A lot of our users have complained about how hard it is to customize the checkout flow of Spree. Some of our users wanted to remove the delivery step when
shoppers had only digital goods in their cart. Others wanted to remove all the steps except for address. Another group wanted to be able to add steps to the
checkout process in between the currently existing steps.

Currently, you need to override the entire state machine inside the Spree::Order class to do this, even including events that you shouldn’t need to care
about, such as cancel and return authorizations.

We’ve recently had a long discussion about this on an issue brought up by one of our users, Colin Gemmell. In this
instance, Colin wanted to re-define the state machine, but ran into problems where in doing so, it would raise spammy warnings about method redefinitions.
It would seem that the current practice of overriding the entire state machine is a bad idea.

So to fix this, we thought about the problem for quite a while. What we’ve come up with after quite a lot of thinking about it is a tidy DSL that will allow you to define the checkout flow for orders in a Spree store. This DSL is built on top of the DSL that the state_machine gem provides, and looks like this:

Order.class_eval do
  checkout_flow do
    go_to_state :address
    go_to_state :delivery
    go_to_state :payment, :if => lambda { payment_required? }
    go_to_state :confirm, :if => lambda { confirmation_required? }
    go_to_state :complete
    remove_transition :from => :delivery, :to => :confirm

This new DSL is all about not redefining the entire state machine. Everyone who’s attempted to customize the checkout process has inevitably done so because they wanted to alter the checkout flow. That’s what this new DSL will allow you to do. Rather than editing the entire state machine, the new DSL will only define the transitions that are to happen during the next event, which is what is used during the checkout process.

This new checkout_flow is used to define the flow of the checkout around each Order object. The go_to_state method will define a transition from the previous state into the new state. If the go_to_state call has an if on the end of it, it will keep track of all states until it finds a state that does not have a conditional. Once that happens, transitions will be defined for the intermediary states.

The remove_transition method will remove the transition specified, if it exists.

To understand this better, take a look at this handy image:

Given the above state machine, the following transitions will be defined:

  • Cart to Address
  • Address to Delivery
  • Delivery to Payment
  • Delivery to Confirm
  • Delivery to Complete
  • Payment to Confirm
  • Payment to Complete
  • Confirm to Complete

The “Delivery to Confirm” transition will be removed by the remove_transition call however, meaning that it will be impossible for orders to transition from delivery to confirm.

We believe this will make it easier for people to customize the state machine than has ever been possible before. Look for it in the next Spree release!

Important Security Updates

Posted on July 05, 2012 by Andrew Hooker

We have just released several new versions of Spree which contain important security fixes. A vulnerability exists in Product Scopes that could allow for unauthenticated remote command execution. There is also a potential XSS vulnerability related to the analytics dashboard. Finally, the new releases also upgrade to the latest version of Rails which include additional security fixes which were addressed by the Rails team.

The remote command execution vulnerability is quite serious and affects all versions of Spree. You should upgrade to one of the following secure versions of Spree immediately: 0.11.4, 0.70.6, 1.0.5 or 1.1.2.

Thanks to joernchen from Phenoelit and Michael Bianco from Ascension Press for bringing these issues to our attention.

If you believe you’ve found a security vulnerability, please do not post publicly about it. Email us at security@spreecommerce.com and we will investigate and fix the issue as quickly as possible.

Please consult the following list of scenarios to find out what the recommendations are for your particular version of Spree.

Spree Versions Affected


The patch has been applied to the repo with the following commits 7f1e5d3 and 3db9a6e . Update to 7f1e5d3 or a more recent one to be protected.


It’s recommended that you update to v1.1.2. This contains the security fix as well as other bug and stability fixes.

See the Github compare view for the full details.


It’s recommended that you update to v1.0.5. This contains the security fix as well as other bug and stability fixes.


It’s recommended that you update to v0.70.6. This release contains only the security fix.

0.20.x – 0.60.x

It’s recommended that you update to v0.70.6. This is a fairly easy upgrade (no major changes in Rails version, etc.) and we cannot continue to support older versions of Spree indefinitely.


It’s recommended that you update to v0.11.4. This release contains only the security fix.

Spree Analytics Extension

If you are using the spree_analytics extension you need to update to 079949fd to receive the most recent security fix. If you are using Spree 1.0.x or greater the analytics is included in Spree and updating to the latest secure Spree version will take care of this for you.

Spree Commitment to Security

The Spree team remains committed to the highest standard of security in it’s software. Spree is used by thousands of stores worldwide and the source code is under constant review by the community. We believe in disclosing all security vulnerabilities to the public in a timely and responsible fashion. Thanks again to joernchen from Phenoelit and Michael Bianco from Ascension Press for working with us while we resolved this issue.

Spree 1.1.2 Release Candidate

Posted on June 25, 2012 by Sean Schofield

Spree 1.1.2 is now available as a release candidate (rc1.) This means that the official release is imminent and we request your assistance in testing the code before we do so. We recommend you upgrade to 1.1.2 as soon as possible due to security issues that have been recently fixed in Rails 3.2.4 as well as Rails 3.2.6.

Using the RC in your project

Since the spree_cmd gem defaults to the latest official releases for Spree (and the associated payment gateway gems), it is recommended that you use the following approach to install the RC in a new project:

<p>spree install mystore &#8212;git=git://github.com/spree/spree.git<br />

For existing stores you can follow the standard process of updating your Gemfile


<p>gem &#8216;spree&#8217;, &#8216;1.1.2.rc1&#8217;</p>

and then install and run the migrations

<p>bundle exec rake spree:install:migrations<br />
bundle exec rake db:migrate</p>

Missing Features in Spree

Posted on June 18, 2012 by Sean Schofield

Someone recently complained on the spree-user mailing list that they were disappointed with the lack of certain i18n features in Spree. We certainly have no problem with constructive criticism and we often have friendly debates about the merits of including/excluding a particular feature. I did, however, think this was a good opportunity to provide a more detailed answer to the following general question:

“Why is feature X not currently in Spree?”

  • You’re the only one to ask for it
  • You’re part of a vocal minority that feels strongly about it
  • You’re not willing to help implement it
  • You’re not willing to help us understand your idea
  • Including your idea would make it harder to maintain other useful features
  • It could be easily handled by writing an extension
  • It is not a problem specific to e-commerce (or Spree)
  • There is no consensus on the best solution

No decision is final

If the feature you’re looking for is not in Spree, it’s usually the result of an intentional decision as opposed to an oversight. That doesn’t mean our decision is final or that we don’t welcome additional discussion on the matter. If you’re willing to keep an open mind during the discussion you can expect thoughtful consideration by the members of our community.