Spree Commerce

Try It Now

Spree Commerce Upgrades Amazon SES and ExactTarget Integrations

Posted on January 06, 2015 by Alexander Diegel

Spree Commerce Upgrades Amazon SES and ExactTarget Integrations for Wombat

Spree Commerce has upgraded the Amazon Simple Email Service (SES) and ExactTarget integrations for its automated ecommerce integration platform, Wombat. Now, connecting with these integrations takes just a few minutes.

Wombat connects ecommerce storefronts to all of its mission-critical services by offering a wide arsenal of integrations, simplifying the backend operations. By making the connection to integrations like Amazon SES and ExactTarget, Wombat users can automate key aspects of their customer and communication services.

Specific benefits users will gain with these integrations include the ability to:

  • Greet customers with an email after their first purchase, encouraging brand loyalty
  • Send confirmation emails when orders have been placed, updated or shipped
  • Allow customers to securely reset passwords with password reset emails

“Effective, efficient communication is a staple of any ecommerce brand,” said Spree Commerce CEO and co-founder Sean Schofield. “It keeps customers informed and updated, increasing brand loyalty in the process. By automating these aspects, store owners are given more time to do what they do best; grow their business.”

Get accurate and reliable access to Amazon SES and ExactTarget by signing up for a free, two-week integration platform trial of Wombat. For technical documentation on these integrations, visit the Wombat knowledge base.

To view this press release in its original format, visit Nasdaq GlobeNewswire.

Spree 2.2.9 & 2.1.12 Released

Posted on December 23, 2014 by Jeff Dutil


We have just released new Spree versions 2.2.9 & 2.1.12.

The primary focus of these releases was resolving security flaws in the API. While no user or credit card data could be exploited with this flaw, there is the potential to commit fraud by manipulating order prices. It is recommended that all Spree installations running 2.1.x, and 2.2.x upgrade as soon as possible.

Thanks to Jordan Brough for finding the issue, and providing a patch to resolve the issue.

You can review the Github Compare for a complete list of 2.2.x changes.
You can review the Github Compare for a complete list of 2.1.x changes.

Reporting Security Issues

Please do not announce potential security vulnerabilities in public. We have a dedicated email address security@spreecommerce.com. We will work quickly to determine the severity of the issue and provide a fix for the appropriate versions. We will credit you with the discovery of this patch by naming you in a blog post.

If you would like to provide a patch yourself for the security issue do not open a pull request for it. Instead, create a commit on your fork of Spree and run this command:

$ git format-patch HEAD~1..HEAD —stdout > patch.txt

This command will generate a file called `patch.txt` with your changes. Please email a description of the patch along with the patch itself to security@spreecommerce.com.

Older Versions of Spree

If you are using Spree versions 2.0.x and older you should consider upgrading as soon as possible. While this security flaw only affects versions 2.1.x & 2.2.x we have already reached the end of life for official 2.0.x support. Our current Release Policy is to only maintain the latest two versions of Spree along with the current master.

Follow Spree Commerce!

Spree Commerce Upgrades MK Data Integration

Posted on December 23, 2014 by Alexander Diegel

Spree Commerce has upgraded the MK Data Services integration for its automated ecommerce integration platform, Wombat. Now, connecting with MK Data is just a matter of a few minutes.

Built by Spree Commerce, Wombat connects ecommerce storefronts with all of their mission-critical services, offering a wide array of versatile integrations. By making the connection to MK Data’s Denial service, Wombat users will be able to quickly screen for potential customers who may be on the denied/restricted parties list, expediting the screening process. In the event that an entity or person lands on one of these lists, any dealings with the aforementioned party would violate the terms of its denial order.

“When dealing with international entities, screening the denied/restricted parties list is an ugly but necessary part of the process,” said Spree Commerce COO Josh Resnik. “When the situation comes up that someone does need to screen a potential business partner, Wombat users will have MK Data right at their fingertips, ready to give a fast and trustworthy answer.”

To get quick, accurate and reliable access to MK Data Services, sign up for free two-week integration platform trial of Wombat. For technical documentation on this integration, visit the Wombat knowledge base.

To read this press release in its original format, visit Nasdaq GlobeNewswire.

Contribute to Spree- Setup Git and Github

Posted on December 17, 2014 by Peter Berkenbosch

About the Author

Peter Berkenbosch is a Senior Developer and Technical Account Manager at Spree Commerce. He loves programming in dynamic languages such as Ruby, and mostly uses Ruby when developing web applications with the Rails framework.

In this small guide I will share the setup I use to contribute to Spree Commerce.

*Disclaimer: This post contains some content written by me and others for the developer guides at Spree Commerce.

Fork and setup upstream remote

Fork the Spree repository on github and clone the spree project on your local machine:

Make sure to run the tests. Spree is only taking pull requests with passing tests, and it’s great to know that you have a clean slate:

To setup the upstream branch to get the changes back from spree/spree you will need to setup a new remote for your repository. I always call this remote `upstream`. To setup spree/spree as an upstream remote you need to tell git about it like this:

Get Changes from Upstream Remote

When you need to get the changes in the spree/spree repository into your own fork I use this small script called `gitub`. You can find it on my dotfiles repository.

When you’re on the master branch, it will fetch all the changes from the upstream remote, rebase the upstream branch into your local master branch and then push it to your fork on github.

Create a new topic branch then make changes and add tests for your changes. Only refactoring and documentation changes require no new tests. If you are adding functionality or fixing a bug, we need tests!

Push to your fork and submit a pull request. If the changes will apply cleanly to the latest stable branches and master branch, you’ll only need to submit one pull request.

If a PR does not apply cleanly to one of its targeted branches, then a separate PR should be created that does. For instance, if a PR applied to master & 2-1-stable but not 2-0-stable, then there should be one PR for master & 2-1-stable and another, separate PR for 2-0-stable.

Topic Branches

Git branches are “cheap.” Creating branches in Git is incredibly easy and it’s an ideal way to isolate a specific set of changes. By keeping a specific set of changes isolated, it will help us to navigate your fork and apply only the changes we’re interested in. You should create a clean branch based on the latest spree/master when doing this. It’s important you follow these steps exactly, it will prevent you from accidentally including unrelated changes from your local repository into the branch.

For example, if we were submitting a patch to fix an issue with the CSS in the flash error message you could create a branch as follows:

The fetch command will grab all of the latest commits from the Spree master branch. Don’t worry, it doesn’t permanently alter your working repository and you can return to your master branch later. The track part of the command will tell git that this branch should track with the remote version of the upstream master. This is another way of saying that the branch should be based on a clean copy of the latest official source code (without any of your unrelated local changes).

You can then do work locally on this topic branch and push it up to your GitHub fork when you’re done. So in our previous example we do something like:

Commit Messages

Provide solid and clear commit messages so we can read from the commit what is fixed or added in this specific pull request.

When developing in the topic branch it’s a best practice to commit a lot with small changes. However, some of those commit messages are noise the moment they turn into a pull request. You should rebase and squash the noise commits. For example:

Rebase and squash this into:

When you’re done your work in the topic branch, rebase the topic branch against master (or the stable branch you’ve forked from)

Sample git rebase:

This will show you this next screen:

To make this neat you can do something like this:

The next screen will give you the ability to reword the 5 commits into one neat one.

For Larger Pull Request Create an Empty PR with a To Do List

Follow the link to see more information on how to create a task list.

To view this post in its original format, as well as more helpful guides and tips, visit the blog of Peter Berkenbosch.