Spree Commerce

Try It Now

New on Edge: Improved Gateway Configuration

Posted on November 04, 2009 by Sean Schofield

The edge code now contains significant improvements to how payment gateways are configured. Gateways are no longer supported by database migrations, this scheme has been replaced by Active Record models that extend Gateway. The configuration of gateways is now done through standard Spree preference configuration. The documentation has also been updated and contains a detailed explanation.

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.

New Team Member: Jorge Calas Lozano

Posted on October 27, 2009 by Sean Schofield

We are pleased to announce the addition of Jorge Calas Lozano to the core team. Here at the Spree project we all call him Calás because that is user name in IRC. Calás has been contributing to the Spree projects since the very early days. He is responsible for much of the early work in making Spree i18n friendly using the Globalite plugin and many other related improvements. Calás has rejoined the Spree project recently and has been providing a ton of great fixes and patches. He’s also now a full time member of the Rails Dog team so we’re going to keep him busy on Spree work 24/7.

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.

Spree 0.9.2 Released

Posted on October 21, 2009 by Sean Schofield

This is a patch release containing a single important security fix. The security vulnerability was reported late yesterday and affects only the 0.9.0 and 0.9.1 versions of Spree. Sites running older versions of Spree (0.8.x, etc.) are not affected. If your site provides its own custom version of checkout_controller.rb then you will want to make some modifications.

Add this filter to the top of your controller:

<p>before_filter :prevent_editing_complete_order, :only =&gt; [:edit, :update]</p>

Then add the following method to your controller as well:

<p>def prevent_editing_complete_order<br />
  load_object<br />
  redirect_to order_url(parent_object) if @order.checkout_complete<br />

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.

Spree 0.9.1 Released

Posted on October 13, 2009 by Sean Schofield

Spree 0.9.1 is a trivial patch release which addresses a gem dependency issue caused by a recent change in the Github gem repository. If you are already running Spree 0.9.0 you do not need to update. The new version simply uses a slightly newer version of the compass and haml gems. The older versions were no longer available in a public repo so we did this release to make sure that new users were able to run things without a hitch.