ror ecommerce 2.0.0.beta1 (Rails 4 upgrade) May 08
Today ror_ecommerce's rail4 branch has been tagged as 2.0.0.beta1. All deprecation warning have been resolved and all test pass. This release will now have ruby 2.0 be the supported ruby version and the project has been upgraded to rails 4.
I'm guessing people will want to hear about the pain points to upgrading a large project to rails 4. So the remaining of teh post will highlight my findings.
Strong Parameters
I had originally thought the upgrade would be much more smooth to simply add the protected_attributes gem. It appears to just be the same functionality as rails 3 right? WELL, not exactly. The problem has to do with the gems in your project. You can expect maintainers of gems to support rails4 (and have rails 4 branches of the gems). You can not expect them to support the protected_attributes gem. Hence the guy maintaining protected_attributes either have to cover a bunch of "one off" issues or there are going to be cases where things just won't be supported.
Instead of looking into every gem that has issues working with protected_attributes, upgrading to use strong parameters is an option that should be best long term and in this case for the short term.
I had originally thought the admin area could be ignored but it appears passing raw parameters blows up. So the main task was to edit every controller with a create or update action. In most cases I created a prvate method called allowed_params like the following:
def update
@address = current_user.addresses.new(allowed_params)
#...
end
private
def allowed_params
params.require(:address).permit(:first_name, :last_name...)
end
I had two gotchas. First nested forms were not always working. I don't know the exact issue but luckily this only effected forms in the admin area. Given that it was just the admin my work-around was to use:
private
def allowed_params
params.require(:address).permit!
end
Yes I did try the examples for nested forms but that didn't work out of the box in my case.
The second Gotchas was forgetting about my custom setters. For example a Purchase order form has a "receive_po" field that the receive_po method handles. I had to remember all teh use cases where forms used custom setters and put those params within the permitted params.
This was/is tedious work but generally the process was pretty quick.
GEM Upgrades
Some gems that needed to be upgraded were compass, database_cleaner, friendly_id, sass-rails and ZenTest.
gem 'compass-rails', :git => 'git://github.com/milgner/compass-rails.git', :branch => 'rails4'
gem 'database_cleaner', :git => 'git@github.com:bmabey/database_cleaner.git'
gem "friendly_id", :git => "git@github.com:FriendlyId/friendly_id.git", :branch => 'rails4'
gem 'sass-rails', '~> 4.0.0.beta1'
gem "ZenTest", '4.9.1'
Deprecation Warnings
Wow I can not explain the number of deprecation warning I had at first. Most were straight forward to address.
First it was obvious authlogic and awesome_nested_set had issues. Luckily I found two pull requests that addressed the issues. I simply added the following to my gem file:
gem 'awesome_nested_set', :git => "git@github.com:cschramm/awesome_nested_set.git", :branch => 'rails4'
gem 'authlogic', :git => 'git@github.com:christophemaximin/authlogic.git', :branch => 'fix_deprecated_with_scope'
These solutions looked simple enough and will probably be added to the gems soon enough.
Next up were Deprecation Warnings internal to the ror_ecommerce app. Luckily these were pretty straight forward to address. I need to give credit to the rails core team for explaining the solution to the issues within the warning log. Just following those instruction was pretty straight forward.
One warning I didn't expect had to do with a reg-ex I had.
The provided regular expression is using multiline anchors (^ or $), which may present a security risk. Did you mean to use \A and \z, or forgot to add the :multiline => true option?
This is a security threat having to do with using a reg-ex that allows multiple lines in a field and hence add "something bad" like javascript. Very interesting... I'm glad to see the rails team protecting me from myself. Thanks. To read more take a look at this article: http://homakov.blogspot.co.uk/2012/05/saferweb-injects-in-various-ruby.html
Conclusion
The upgrade process did take some time but was pretty straight forward. I recommend upgrading to any app in production within a month of the final rails 4 release. This was not the same headache that upgrading from Rails 2 to Rails 3 was.
Also the forced security model with strong parameters might make beginners have a larger learning curve but it REALLY is great for enforcing security. I was not a believer until I started applying the upgrade.
GREAT job to everyone that contributed to Rails 4!
