We just added support to the core Tax Calculation extension for displaying Product prices including VAT on all customer facing pages. This feature will enable stores based in the EU that are required to add VAT to products to display the final price to the customer.

When enabled the VAT amount will be calculated, added to the product’s price and displayed as: €19.99 (inc. VAT). The currency symbol and format used will continue to be the appropriate symbol used for your locale.

Previously VAT amounts were only added at the checkout phase, so for certain countries / products this could mean a 25% jump in the total order price, which would lead to high cart abandonment rates.

You can enable this by changing the :show_price_inc_vat preference value to true, to learn more see the wiki.

We have just fixed a potential security vulnerability in Spree. The Order model was not using attr_accessible to protect its attributes from a potential mass assignment exploit. Now that Spree is starting to grow in popularity we are going to start addressing some of these issues.

This problem has been fixed in the latest source code and will be included in the upcoming 0.3.0 release. Special thanks to Eric Chapweske of rails spikes for reporting this issue. If you notice a potential security issue with Spree, please report it to us directly (preferably not on the mailing list.)

I’ve gone ahead and disabled locale switching by default. Locale switching refers to the ability of individual users to control the site locale for their specific session. An example of this is the language bar at the top of the demo site which allows users to change languages, etc.

The local switching feature requires a time consuming filter to be run on every request which results in the parsing of the lang files over and over again. This could be improved through caching but since Spree will soon be using the i18n features of Rails 2.2, it didn’t seem like a good idea to invest in that now.

You can still enable cache switching by tweaking the :allow_locale_switching preference. For sites running in a non-english locale, you’ll want to make sure you have the :default_locale preference set to the desired locale. This is a global (application-wide) setting. Please see the wiki for more information on the i18n features of Spree.

That flood in your Github feed can only mean one thing. Yup, the second phase of restful refactoring is now complete. We may eventually discover a few minor areas that still need to be addressed but at this point we’re basically done with the refactoring.

One big change is that we have dropped the Cart and CartItem models. Customers still have a shopping cart (from their perspective) but beind the scenes they are editing an order in various states.

Speaking of states, we’ve now incorporated the concept of Finite State Machine (FSM) into several aspects of the logic. There is a FSM for modelling both orders and inventories. If you haven’t used the state_machine plugin, be sure to give it a try. This is a new plugin that is not to be confused with the very similar acts_as_state_machine which apparently is not under active development.

One benefit of the FSM is that it makes it much easier to modify the checkout process. Take the tax_calculator extension (which is part of the Spree core) as an example. The idea is to calculate the tax after the user chooses a shipping address. We can do this simply by adding the following code in the activate method of the extension.

Order.class_eval do
  include Spree::TaxCalculator
  Order.state_machines['state'].after_transition(:to => 'payment', 
    :do => lambda {|order| order.update_attribute(:tax_amount, order.calculate_tax)})
end

It should also be relatively easy to add new steps to a checkout process this way. Its still possible that upgrading to a future version of Spree might break your extension, but its much less likely to happen with this type of customization.

Speaking of future versions of Spree, please keep in mind that Spree is still in active development. Its definitely ready for use in a production environment but the architecture is still in a bit of flux (as evidenced by this recent refactoring.) As we get more people contributing to Spree and more experience deploying Spree in real world environments, there are just some things that are worth “breaking” in order to make significant reductions in lines of code, etc.

Please keep in mind that one of the ultimate goals of the Spree project is to make it as easy as possible to upgrade to future versions of Spree. In the future, new versions of Spree will contain rake tasks, etc. to assist in migrating from a previous version. We also hope to include more detailed documentation on changes between versions and suggestions for how to design your application in order to minimize problems with future migrations.

Please report any problems to spree-user or the issue tracker.