One major improvement is that it is now possible to configure multiple gateways for each of your Rails environments. Its also possible to use the live production server in development mode when previously, you were required to run in test mode. One unfortunate side effect of this improvement is that your existing gateway configuration information will be lost and you will need to reconfigure your gateway in the admin interface.

You should make a note of your gateway configuration setting before upgrading since you will need to reconfigure your gateway when you’re done.

This approach to implementing and configuring gateways is extremely flexible. It makes it trivial to implement a new gateway that is already supported by Active Merchant. There are other useful benefits to this approach that a developer may be interested in knowing.

Support of Non Active Merchant Gateways

This architecture allows Spree to support gateways that are not officially supported by Active Merchant. Many times a new gateway is donated by someone in the community but its languishing in the queue waiting for someone to test and accept the patch. You have the option of taking that code (or writing your own from scratch) and implementing it within Spree. Instead of delegating to an Active Merchant class, you can simply implement that functionality yourself. You could also include the new gateway code from an Active Merchant fork inside your implementation and delegate the standard authorize, capture, etc operations to it.

Ability to “Patch” Active Merchant Gateways

We’ve noticed that sometimes it takes a while for a crucial Active Merchant patch to be applied. That’s certainly understandable, the Shopify guys have a business to run and its probably not a high priority for them to make sure that the latest obscure gateway patch is applied in a timely fashion. Fortunately, the Spree approach to wrapping these gateways provides you with a convenient option.

Lets say there is a bug with the authorize method. You could simply provide an implementation of the gateway that has the patched version of the authorize method and then delegates to the Active Merchant class for everything else (since that works just fine.)

Additional Functionality Beyond Active Merchant

Another benefit of the architecture is that it makes it possible for Spree to provide additional common functionality that was not envisioned by Active Merchant. Specifically, it is possible to provide an abstraction for storing credit card profiles to be used with recurring payments. There’s a good reason for Active Merchant to not care about this functionality. Its designed for people who just want to drop a single gateway provider into their application. Most programmers don’t need three different gateways at once. Spree is a specialized use case. Its providing multiple gateways for you to choose from and so its desirable to have a standard method for operations such as this.

Recurring payments are not yet supported in Spree although there are plans to provide this in the near future.

This is probably also a good opportunity to talk a bit about the criteria for becoming a core member.

• Sustained Commitment to the General Project – Core members need to demonstrate a commitment to the overall well being of the project (not just fixing or contributing in areas that are specific to their needs.) Examples of this include: Answering questions on #spree and spree-user, contributing/fixing documentation and helping with releases. We also look for members whose interest lasts beyond a short period of time. Lots of people contribute actively to Spree for a month or two and then fade away. That’s certainly fine - we appreciate all levels of contribution. Core members, however, tend to stick around for longer.

• Demonstrated Communication and Decision Making Skills – Spree is now a very big project with hundreds of real world deployments. It is important that major changes to Spree are only done after consultation with other core members and the community. Core members will be presented with all sorts of patches and feature enhancements. They need to be able to ask themselves if this represents a major change to how things are done in the current code. We have a pretty good system for making these kinds of decisions already, new core members need to become familiar with how these kinds of decisions are made and learn to make the same types of judgements as the existing core team.

• Treat Other Community Members with Respect – Treating people with respect is probably the most important of all the rules. I list it last only because it should be obvious and its also relatively easy to do. The power of open source comes is in the collective efforts of the community. Everyone’s ideas and work should be treated with respect.

Much of the core team now works for Rails Dog. Working for our company is not a requirement for core team membership, nor does it ensure that you will be offered membership. We have over ten different people working for Rails Dog right now and only four of them are on the core team.

Hopefully this clears up any questions people might have as to how the project is run and how these decisions are made.

Add this filter to the top of your controller:

before_filter :prevent_editing_complete_order, :only => [:edit, :update]

Then add the following method to your controller as well:

def prevent_editing_complete_order      
  load_object
  redirect_to order_url(parent_object) if @order.checkout_complete
end

In the future if you suspect a security bug. Please send an email to security@railsdog.com. Please do not send a message to spree-user until we have a chance to verify the issue and hopefully provide a timely fix.

This work was actually completed several weeks ago but we delayed moving it into core until after the 0.9.0 release. Please report any bugs you find in our issue tracker. Roman has actually been contributing a lot of great patches lately and we have several more of them in the pipeline that we need to get around to. The Spree community is still going strong. Keep those awesome contributions coming!

The new release is also compatible with Rails 2.3.4 which contains some crucial security fixes. This release also contains some signficiant improvements to product variants. It is now possible to configure different product images for each variant and to display the specific variant image in the shopping cart. Please also see the very detailed release notes for more information on the release and how to upgrade an existing version of Spree.

Spree continues to improve its i18n support and is proud to announce the addition of the following localizations:

• Thai
• Hebrew
• Dutch
• Finnish
• Mexican Spanish

If you have a new localization to add or wish to make improvements to an existing one, please see our contribution guidelines for information on how you can contribute.

We are already hard at work on the next major release. The massive growth in real world deployments of Spree has provided us with valuable insight into possible new features and improvements. We’ll be doing a major push to add core features as well as new extensions. There will also be a concerted effort to document and update the existing extensions. Stay tuned!

  spree --update

You can also use the abbreviated form:

  spree --u

After installing a new version of the Spree gem, simply run either one of these commands from inside RAILS_ROOT (your application directory) and your application will be upgraded.

The update process is also now less “destructive” than in previous versions of Spree. Instead of silently replacing crucial files in your application, Spree now checks the content of files it needs to replace, and if the old version differs, it will be saved with a ~ suffix.

This makes it easier to see when and how some file has changed - which is often useful if you need to update a customized version. The update command will also no longer copy the routes.rb file - the original version just loads the core Spree routes file, so has no need to change. (Recall that you can define new routes in your extensions.)

Spree was mentioned a few weeks ago on a French language blog post. Right around this time we also started to see a few new Spree sites in French. We recently learned about this great looking model RC helicopter site. There’s also this interesting fashion site which makes some interesting use of Flash.

I thought the developer of this paper product site did a nice job making an engaging site for what I would otherwise consider to be a pretty dull product. Simple design but it looks nice. While we’re on the subject of design, you should definitely take a look at the Yellow Bird Project site which received a nice writeup on the Web Designers Depot blog .

If you’d like to share your Spree site with the rest of us, please drop us a line on spree-user.

• Always create an issue in Lighthouse before coding
• Create one branch for each LH ticket
• Please do not send Github pull requests
• Use the optional Github service hook to inform us of your patch when done (see the guide for details)
• The Spree guides themselves are open source, see the instructions on how to contribute fixes (typos, outdated examples, etc.)