Posts tagged ‘rc’

Spree 1.1.2 Release Candidate

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 —git=git://github.com/spree/spree.git<br />
  —branch=1-1-stable</p>

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

Gemfile
<p>gem ‘spree’, ‘1.1.2.rc1’</p>

and then install and run the migrations

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

Spree 1.1.0 Release Candidate

Spree 1.1.0 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. As part of this process we have created a new 1-1-stable branch in Github. As the branch name implies, the code in this branch should stay fairly stable over time as we move towards and beyond the 1.1 release.

What’s in the Upcoming Release?

  • Support for Rails 3.2.x
  • Product groups are now a stand alone extension
  • Major overhaul to the API
  • Replaced meta_search with ransack
  • Several other minor changes

Please see the edge version of the release notes for more details

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 —git=git://github.com/spree/spree.git<br />
	—branch=1-1-stable</p>

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

Gemfile
<p>gem ‘spree’, ‘1.1.0.rc1’</p>

and then install and run the migrations

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

Last Call for 1.0 Bug Fixes

We’ve just released a brand new Spree release candidate (1.0.0.rc3) as we prepare for the final 1.0.0 release. We have made quite a few minor fixes since the previous release candidate.

There are still a few known issues we’re working on but we’re asking everyone to try out this new gem and report any problems you find. We’ll be iterating on this very quickly in the next few days. Once we have a release candidate out there for 48 hours with no show-stopping issues we’ll do the final 1.0 release.

We had hoped to release 1.0 final before the end of this month but we’re going to take an extra few days to make sure everything is nice and stable. In the meantime we’ll be updating the guides and doing a few blog posts to get you ready.

Spree 1.0.0.rc1 is Now Available

We’re happy to announce Spree 1.0.0.rc1 is finally available! We’ve been working like crazy in order to meet our self-imposed deadline of “before Christmas.” Unfortunately in our drive to get the RC ready we did not have time to write a lot of explanatory posts and documentation. We’ll catch up in the next couple of weeks now that the major coding part is over.

One of the major changes in this release is related to taxation. You can see some of the recent taxation work on Github and look forward to completely revised documentation in the new year.

We have also started work on the 1.0.0 release notes. They’re still a work in progress but you may find some useful information in the edge guides. We still have some work to do in January but we’re on schedule to release 1.0.0 in time for SpreeConf.

New Security Vulnerabilties - Content Controller and Search Logic

The Spree team was recently alerted to two potential security vulnerabilities.

The first potential exploit, reported by John Hartzler, would allow a user to request a specially crafted URL and expose arbitrary files on the server. All prior versions of Spree are affected by this issue but it has since been patched in the edge code as well as the brand new Spree 0.50.1 release.

If you are not able to upgrade immediately there is a simple “hot fix” you can code into your site which should work with all prior versions of Spree. You need to create a file named `config/initializers/security_hotfix.rb` in your application and make sure it contains the following code:

config/initializers/security_hotfix.rb
ContentController.class_eval do<br />
  def show<br />
    render :template => params[:path]<br />
  end<br />
end

The second issue, reported by joernchen of Phenoelit, is a bug in the
rd_searchlogic gem which
would allow malacious users to execute arbitrary remote commands. The
rd_searchlogic gem was forked from the original searchlogic since the original still does not support Rails 3. The forked gem is the most vulnerable but the original searchlogic gem also contains a variation of this exploit.

This affects both the 0.30.x and the 0.40.x versions of Spree. Upgrading
your installation of Spree to 0.50.x is an easy solution to this problem (since we no longer use searchlogic.) If you are unable to upgrade at this time and are not using the search functionality provided by the REST API, then you can drop the following code into a new file titled `config/initializers/searchlogic_hotfix.rb`:

config/initializers/searchlogic_hotfix.rb
Api::BaseController.class_eval do<br />
  protected<br />
<br />
  def search<br />
    return nil<br />
  end<br />
end

Both of these fixes will require a restart of your production server to take effect.

Updating Searchlogic

Spree core now uses Searchlogic version 2.1.13 (unless a new version appears whilst I am writing). This has meant a few changes to how search and pagination are set up, but also allowed a few details of Spree to be improved at the same time. Extension developers will benefit too - the new gem is much more flexible, and easy to use. Marcin (Swistak) suggested that it might even go a fair way to providing the functionality we wanted in product groups, and I think he has a good point.

So, what’s new? Searchlogic has been completely rewritten in version 2, and uses a different approach to version 1. It now focuses more on key functionality and less on reinventing the wheel, e.g. control of pagination has passed back to the pagination gems. As a result, the code has gone from  ~2300 loc to ~420 loc. However, several useful bits of functionality have been added. For more information, see the github project and the rdoc documentation.

I think there’s two sides to this new version. Firstly, it provides a wide set of named scopes which you can use alongside existing ones. These are all dynamically generated, and able to follow model structure - including all associations, and to apply a range of tests to the fields identified. Here’s some examples from the documentation:

  • Within a model, filtering by various tests on fields:
    User.username_equals(“bjohnson”)<br />
    User.username_begins_with(“bjohnson”)<br />
    User.username_like(“bjohnson”)
  • Using associations (note the change of naming convention):
    User.orders_total_greater_than(20)
  • Scopes for ordering:
    User.ascend_by_email 
  • List modifiers, eg test on a list of values for any or all hits - this is very useful (and more efficient than doing it yourself)
    User.email_like_any([“joe”, “bill”])

Secondly, there’s the search aspect. This allows searches to be defined on top of some base scope, and customized in various ways. The search option names follow the same pattern as the named scopes above, and can be chained together or set separately. For example:

search = User.search(:username_equals => “bjohnson”, :age_less_than => 30)<br />
search.email_contains(“bjohnson”)<br />
search.age_gt = 20</p>

Gotcha #1: it isn’t possible in this version to over-ride the a search in the base scope by supplying options to the search, eg. check out the following example. It could be a bug.

scope = Product.ascend_by_master_price<br />
search = scope.search().order(“descend_by_master_price”)<br />
search.scope(:find)</p>

As for a chain of named scopes, you can get results out of a search with all, first, etc - or use some pagination library like will_paginate to handle limited fetches. See app/controllers/admin/product_controller.rb for an example of this in use.

Form handling is also much easier. There’s no need to include 'admin' in the submit path (it is detected automatically), and no need for fields_for to access associated records - you just need to adjust the field names to follow the new naming convention, eg for product search, you can search for variants_sku_contains to look for a substring in the sku field of any of the product’s variants. Particularly note how the check boxes have been brought within the searchlogic framework: the concepts represented by the check boxes map directly to one of the new-format searchlogic queries, so naming the box after the relevant condition is all you need to do.

Finally, if you are migrating from an earlier version, you need to run rake spree:upgrade and check that the will_paginate gem is listed in config/environment.rb, and also ensure that config/initializers/searchlogic.rb has been removed.

This project is maintained by a core team of developers and is freely available for commercial use under the terms of the New BSD License.

Spree, Spree Commerce and the Spree logo are all trademarks of Spree Commerce, Inc.