With #48, using devise-bootstrap-views without copying the templates with the view generator no longer works: Devise expects the views to be in views/devise and now they're in views/erb. This means Devise' default views are used instead.

It might be good to still have a branch called bootstrap4.

This gem was amazing that I used it in the very early stage. However, my services was down while auto scaling because the branch bootstrap4 was deleted and could not be found.

It was called by using gem 'devise-bootstrap-views', github: 'hisea/devise-bootstrap-views', branch: 'bootstrap4'

I have already fixed it and should be fine, but I don't know how many people have been using the same thing. I hope it never happens to anyone again.

This is just my suggestion and I don't think this slightly change affects anything with the project itself. Nevertheless, it might save many (or several? ) people's time.

Thank you for your works!

Hi,

When I create a custom layout for devise regarding devis doc (https://github.com/plataformatec/devise/wiki/How-To:-Create-custom-layouts) all the bootstrap devise views are erased and the ugly default views are back.

Do you know a way to do have a main devise custom layout and keep devise-bootstrap-views subviews?

The translation for devise.unlock_instructions.message on line 23 in locales/uk.yml contains a single quote which is escaped as \'.

According to the YAML specification a single quote is escaped with two single quotes '', not with \'.

MRI doesn't care, but JRuby crashes on this.

The devise-i18n gem has all the locales files we need. So if we use git submodules for the locales you can centralize them in one place and no need to update them in two different places anymore.

See https://github.com/hisea/devise-bootstrap-views/blob/master/locales/en.yml#L59. I can create a PR if wanted. Thanks for the gem!

This line should be changes as following:

-<p><%= link_to t('.action', default: 'Unlock my account'), unlock_url(@resource, unlock_token: @resource.unlock_token, locale: I18n.locale) %></p>
+<p><%= link_to t('.action', default: 'Unlock my account'), unlock_url(@resource, unlock_token: @token, locale: I18n.locale) %></p>

ref1: https://stackoverflow.com/a/22641026
ref2: heartcombo/devise#3559 (comment)

My devise version is 4.4.3.

@hisea First of all Thank you for your valuable contribution. I have used this gem in my project and it
really helped in cutting down the time it would have required to copy the original devise views and then adapt them to Bootstrap.

Recently I encountered an issue related to Confirmation Instructions being sent to a user after she signs up. The confirmation URL in the instructions (the following code) was generating a link with a link with original (encoded) confirmation token in database, instead of the Devise's friendly (raw) token (as mandated in recent versions of Devise).

<p><%= link_to t('.action', :default => "Confirm my account"),
confirmation_url(@resource, :confirmation_token => @resource.confirmation_token, locale: I18n.locale) %></p>

This was making the code Devise.token_generator.digest(self, :confirmation_token, confirmation_token) generate an invalid digest based on received token in Devise's confirm_by_token(confirmation_token) method defined in lib/devise/models/confirmable.rb and hence throwing the error. Fixed this error by using the friendly token in the confirmation url. After this fix user was successfully getting confirmed using the correct confirmation url.

The correct confirmation url should be

confirmation_url(@resource, :confirmation_token => @token, locale: I18n.locale)

References:

• http://stackoverflow.com/questions/18626544/devise-confirmation-token-is-invalid-when-user-signs-up
• http://blog.plataformatec.com.br/2013/08/devise-3-1-now-with-more-secure-defaults/

Please fix this so that others using your gem don't end up in the same problem I faced.

Thanks,
Jiggneshh

I have this error when run bundle
Your Gemfile lists the gem devise-bootstrap-views (>= 0) more than once.
You should probably keep only one of them.
While it's not a problem now, it could cause errors if you change the version of just one of them later.

There seems to be some sort of encoding issue with the devise_bootstrap_views_helper.rb file.

I had to manually add:

#!/bin/env ruby

encoding: utf-8

To the top of the file to get it to work.

rails 4.0.2
ruby ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-darwin10.8.0]

the remember me checkbox isn't translated by default because the text isn't in the t() method, right now is like this in the view

<%= f.check_box :remember_me %>remember me

needs to be in t('remember_me') to be translated

ruby version: ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux]
os version: ubuntu lucid 32bit inside vagrant
rails version: 5.0.0
devise version: 4.2.0

rails g devise:views:locale en

/home/vagrant/.rvm/gems/ruby-2.3.0/bundler/gems/devise-bootstrap-views-4175430cd32c/lib/generators/devise/views/locale/locale_generator.rb:7:in `download_locale': uninitialized constant Net::HTTP (NameError)
        from /home/vagrant/.rvm/gems/ruby-2.3.0/gems/thor-0.19.4/lib/thor/command.rb:27:in `run'
        from /home/vagrant/.rvm/gems/ruby-2.3.0/gems/thor-0.19.4/lib/thor/invocation.rb:126:in `invoke_command'
        from /home/vagrant/.rvm/gems/ruby-2.3.0/gems/thor-0.19.4/lib/thor/invocation.rb:133:in `block in invoke_all'
        from /home/vagrant/.rvm/gems/ruby-2.3.0/gems/thor-0.19.4/lib/thor/invocation.rb:133:in `each'
        from /home/vagrant/.rvm/gems/ruby-2.3.0/gems/thor-0.19.4/lib/thor/invocation.rb:133:in `map'
        from /home/vagrant/.rvm/gems/ruby-2.3.0/gems/thor-0.19.4/lib/thor/invocation.rb:133:in `invoke_all'
        from /home/vagrant/.rvm/gems/ruby-2.3.0/gems/thor-0.19.4/lib/thor/group.rb:232:in `dispatch'
        from /home/vagrant/.rvm/gems/ruby-2.3.0/gems/thor-0.19.4/lib/thor/base.rb:444:in `start'
        from /home/vagrant/.rvm/gems/ruby-2.3.0/gems/railties-5.0.2/lib/rails/generators.rb:180:in `invoke'
        from /home/vagrant/.rvm/gems/ruby-2.3.0/gems/railties-5.0.2/lib/rails/commands/generate.rb:13:in `<top (required)>'
        from /home/vagrant/.rvm/gems/ruby-2.3.0/gems/railties-5.0.2/lib/rails/commands/commands_tasks.rb:138:in `require_command!'
        from /home/vagrant/.rvm/gems/ruby-2.3.0/gems/railties-5.0.2/lib/rails/commands/commands_tasks.rb:145:in `generate_or_destroy'
        from /home/vagrant/.rvm/gems/ruby-2.3.0/gems/railties-5.0.2/lib/rails/commands/commands_tasks.rb:60:in `generate'
        from /home/vagrant/.rvm/gems/ruby-2.3.0/gems/railties-5.0.2/lib/rails/commands/commands_tasks.rb:49:in `run_command!'
        from /home/vagrant/.rvm/gems/ruby-2.3.0/gems/railties-5.0.2/lib/rails/commands.rb:18:in `<top (required)>'
        from bin/rails:4:in `require'
        from bin/rails:4:in `<main>'

Currently the model name is lowercased to create the summary sentence

2 errors prevent from beeing saved

sentence = I18n.t('errors.messages.not_saved',
        count: resource.errors.count,
        resource: resource.class.model_name.human.downcase)
        resource: resource.class.model_name.human)

This does not work in German, where nouns are capitalized.

Originally I created this little commit to fix this, thinking uppercase or lowercase spelling should just be controlled by the translations.

However, I found out that .model_name.human always capitalizes the translated model name, so with my fix we would end up with capitalized words in English, too (probably undesired).

Any ideas how to deal with this? A possible solution would be to gather the translated model names directly (instead of using .model_name.human), but this looks rather hacky to me.

Is nobody else bothered by this? To me, showing the model name lowercased in German just looks really wrong, like a quickly typed email with no uppercase letters at all.

devise-i18n-views has been merged into devise-i18n. You should stop using devise-i18n-views and start using devise-i18n 1.0.0 or later. There will be no further releases of devise-i18n-views.

what does this refer to?

Would be nice to have an option to use Simple Form if available

Bootstrap provides helper classes for inputs with errors like .has-error or .has-warning. Rails wraps all fields with errors in blocks with .field_with_errors class. There're many options:

• Extend .field_with_errors class with Bootstrap .has-danger class
• Provide an initializer via generator that will add .has-danger class to blocks with errors in config.action_view.field_error_proc
• Add the same configuration option but in a Railtie initializer

Bootstrap styles are not applied with the following Gemfile:

# Views
gem 'devise-bootstrap-views', '~> 1.0.0.alpha1'
# I18n
gem 'devise-i18n'

However, it works if the gem is listed after devise-i18n:

# I18n
gem 'devise-i18n'
# Views
gem 'devise-bootstrap-views', '~> 1.0.0.alpha1'

It seems that devise-i18n is overriding views from devise-bootstrap-views. It should be fixed somehow or mentioned in README.

when creating the views with rails generate devise:views:bootstrap_templates, the newly generated file sessions/new.html.erb does not contain the error messages block (<%= bootstrap_devise_error_messages! %>) which is available in registrations/new.html.erb.

Therefore, when entering faulty data during login, the user isn't informed. The registration form does show the errors as expected.

I tried adding the block to the file, but it has no effect. I also followed the wiki entry about izitoast, but it doesn't work either. The only way I can see the errors is by using <p class="notice"><%= notice %></p> <p class="alert"><%= alert %></p>, but then it's not inside the bootstrap error message box.

And should be generated separately.