Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Upgrade to rails 4 #1958
This updates Whitehall to run on Rails 4.0. For the most part the changes deal with various deprecations and breakages due to changes in Rails' behaviour. There are a few key areas where more comprehensive changes were required:
The whitehall application patches Rails' routing code to support our particular flavour of localisation URLs, for example:
This patch had to be rewritten as the routing code had changed significantly in the move from Rails 3 to 4 (73d17ac).
Rails routing bug
There is a bug in the Rails routing code that was causing an issue with some of the localised routing, specifically when generating a localised route with a default format set. A fix has been submitted to Rails, and a monkey patch added to whitehall to cope with this in the meantime (6129a6f).
friendly_id conflict resolution change
The Rails 4 compatible version of friendly_id changes behaviour significantly, particularly around slug conflict resolution. Pre-Rails 4, slug conflicts were resolved by appending a sequence number to the end of the slug. friendly_id now resolves conflicts by appending a UUID to the end (simpler solution and also threadsafe). To maintain the previous behaviour in whitehall, the conflict resolution code in friendly_id is being overridden to generate sequential slugs again (5203d32)
friendly_id magic finders
Rails 4 compatible friendly_id no longer overrides
To keep the changes in this pull request to a minimum, the magic
Globlize feature/Rails bug workaround
A change was made to the globalize gem that means a translated model is
Other Globalize validation issue
There appears to be a bug in globalize that means presence validations are not being triggered when saving a translation using
shared_mustache gem change
The newest version of sprockets-rails is not correctly choosing the local
Changes to cookie signing
Rails 4 introduces a new way to generate and verify signed cookies. It has a mechanism to automatically upgrade old cookies transparently. However, because the new cookies are not backwards compatible, this has intentionally been left off until we are certain that the upgrade has gone smoothly and that we don't need to roll back to the Rails 3 version. Once the dust has settled, steps should be taken to enable the new cookie code and begin the upgrade process. See http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html#action-pack for more details.
There's a strange thing happening to the
@tekin following the apidocs through text areas were initialized using
Though looking they have removed that default in rails 4.
So looks like my fix for "Other Globalize validation issue" (5e6e665#diff-095e6f47d7355ba033961aeb9dd441b6R7) is causing another issue - although it causes the presence validations to kick-in, setting the
Looking at this now, I think the presence of an attribute called "locale" on the
ok I've finished reviewing this. All looks good, nice work! There were quite a few thorny issues to deal with along the way!
My only slight concern is the globalize fork. I'm not clear whether fixes in rails (ie rails 4.1+) will avoid the lock version issues or not. If we do need to patch globalize, it might be good to also work with them to develop an alternative solution, as it would be good to develop some confidence that we can avoid forking in the medium term.
Obviously there is also the issue with 5e6e665 which you mentioned.
This branch now includes a fix for the issue with non-english editions. The fix is to use a column not called "locale" to signify the primary locale of the edition as this conflicts with some of the internal behaviour of globalize: globalize uses a
Nice work on getting a patch for the optimistic locking issue into globalize @heathd!