We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Changes for Rails 4
Confirmation token should be unique. If there are more than 1 existing user it will violate the constraint with the same 'Grandfathered account' token and migration won't pass. It works without it or constraint should be created after update_all.
Updated How To: Override confirmations so users can pick their own passwords as part of confirmation activation (markdown)
Remove title from body.
roll my changes back. would help if I'd read that the Rails 3 and Devise 2 were just modifications to the Rails 3 and Devise 1.2 instructions. Sigh.
Added code to change routes when using Rails 3 and Devise 2
Explicitly set self.resource as @confirmable to handle a re-confirmation attempt. If a User is already confirmed, and attempts to GET the resource for setting the password and confirming, the confirmation_token is unable to find a valid User object, and therefore throws an ActionView::TemplateError when trying to render devise_error_messages! with an undefined method `errors` for nil:NilClass.
Add example for testing controller inheritance (based on 9bc8950)
Inherit ConfirmationsController from Devise::ConfirmationsController; otherwise, reset password email template will be used for the mailer.
Remove link to non-existent page (was it renamed?)
minor spelling and grammar
Modify url for two-step confirmation how-to
minor edit re alternate method
reference an alternate approach that is simpler
Added 4) Update `config/intializers/devise.rb`
Added the section 3) Lists the database fields explicitly for your migrations
Adding Support for Rails 3 and devise 2.0.0
Revert 180907a649b14aa5f56c31c9a1e79ea0e51e758f ... 6c2205f07d392009e1f197fc8873667f7b4d7de6
Destroyed How To: Override confirmations so users can pick their own passwords as part of confirmation activation (markdown)
Edit a typo (using for user), correct alignment
allow logged users to reach the confirmation page