1

My rails application has a two stage registration, for which I use the Devise gem. It seems to be working just fine on my local server, but on heroku (using a postgres database), completing the first form redirects to an error page (heroku's charming "something went wrong") rather than to the second form. I couldn't find the cause within heroku's logs.

Here is the first form page:

<h3>Create your Profile</h3>
<%= form_for(resource, as: resource_name, url: registration_path(resource_name)) do |f| %>
    <%= render 'shared/error_messages'%>
    <div class="form-group">
    <%= f.text_field :name, class: 'form-control', autofocus: true, placeholder: 'Name Shown to Providers' %>
    </div>
    <div class= "form-group">
        <%= f.text_field :email, class: 'form-control', autofocus: true, placeholder: 'Email'%>
    </div>
    <div class="form-group">
    <%= f.password_field :password, class: 'form-control', autofocus: true, placeholder: 'Password'%>
    </div>
    <div class="form-group">
        <%= f.password_field :password_confirmation, class: 'form-control', autofocus: true, placeholder: 'Confirm Password'%>
    </div>

    <%= f.submit "Submit", class: "btn btn-large btn-primary" %>
<% end %>

And here is the second:

<h3>Populate Your Profile</h3>
<div id="popform">
<div class="row">
    <aside class="span4">
    <section>
    <img src=<%= @user.avatar.url(:small) %> id="prof" class= "img-circle"/>
    <h1> 
        <%= @user.name %>
    </h1>
    </section>
    </aside>
</div>
<div id='usereditform'>
    <%= form_for(resource, as: resource_name, url: registration_path(resource_name), html: { method: :put }) do |f| %>
        <div class="form-group">
            <%= f.label :avatar%>
            <%= f.file_field :avatar%>
        </div>
        <div class="form-group">
            <%= f.label :industry%>
            <%= f.select :industry, [['Please select an industry',nil],'Professional Services','Graphic Design','Marketing','Web Development'], class: 'form-control'%>
        </div>
        <div class= "form-group">
            <%= f.text_field :city, class: 'form-control', autofocus: true, placeholder: 'City'%>
        </div>
        <div class="form-group">
            <%= f.label :state%>
            <%= f.select :state, options_for_select(us_states, "CA"), class: 'form-control'%>
        </div>
        <div class="form-group">
            <%= f.text_field :website, class: 'form-control', autofocus: true, placeholder: 'Website (if applicable)'%>
        </div>
        <div class= "form-group">
            <%= f.text_field :description, class: 'form-control', id: 'dfield', autofocus:true,placeholder: 'Description' %>
        </div>
        <div class= "form-group">
            <%= f.submit "Submit", class: "btn btn-large btn-primary" %>
        </div>
    </div>
<% end%>

Here is my slightly overrode devise registrations controller:

class RegistrationsController < Devise::RegistrationsController
    protected
    def after_sign_up_path_for(resource)
        if resource.is_a?(User)
            edit_user_registration_path
        else
            super
        end
    end
    def after_inactive_sign_up_path_for(resource)
        if resource.is_a?(User)
            edit_user_registration_path
        else
            super
        end
    end
end

As requested, here is my config/routes.rb:

Rails.application.routes.draw do
    devise_for :providers
    devise_for :users, :controllers => {:registrations => "registrations"}
    resources :users
    resources :providers
    root :to=>'pages#home'
    match '/home', to: 'pages#home', via: 'get'
end

And finally, here are the last several lines of my heroku logs:

2014-06-21T21:32:44.872651+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/activerecord     4.1.1/lib/active_record/query_cache.rb:36:in `call'
2014-06-21T21:32:44.872662+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_dispatch/middleware/remote_ip.rb:76:in `call'
2014-06-21T21:32:44.872664+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_dispatch/middleware/debug_exceptions.rb:17:in `call'
2014-06-21T21:32:44.872665+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
2014-06-21T21:32:44.872644+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_dispatch/middleware/params_parser.rb:27:in `call'
2014-06-21T21:32:44.872650+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_dispatch/middleware/cookies.rb:560:in `call'
2014-06-21T21:32:44.872673+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/railties-4.1.1/lib/rails/rack/logger.rb:20:in `call'
2014-06-21T21:32:44.872675+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_dispatch/middleware/request_id.rb:21:in `call'
2014-06-21T21:32:44.872676+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/methodoverride.rb:21:in `call'
2014-06-21T21:32:44.872682+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/sendfile.rb:112:in `call'
2014-06-21T21:32:44.872666+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/railties-4.1.1/lib/rails/rack/logger.rb:38:in `call_app'
2014-06-21T21:32:44.872654+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_dispatch/middleware/callbacks.rb:29:in `block in call'
2014-06-21T21:32:44.872672+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.1/lib/active_support/tagged_logging.rb:68:in `tagged'
2014-06-21T21:32:44.872594+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_controller/metal/params_wrapper.rb:250:in `process_action'
2014-06-21T21:32:44.872592+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_controller/metal/instrumentation.rb:30:in `process_action'
2014-06-21T21:32:44.872585+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_controller/metal/instrumentation.rb:31:in `block in process_action'
2014-06-21T21:32:44.872603+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_controller/metal.rb:231:in `block in action'
2014-06-21T21:32:44.872597+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/abstract_controller/base.rb:136:in `process'
2014-06-21T21:32:44.872605+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_dispatch/routing/route_set.rb:80:in `dispatch'
2014-06-21T21:32:44.872678+00:00 app[web.1]:   vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/runtime.rb:17:in `call'
cbartondock
  • 663
  • 6
  • 17

2 Answers2

2

Are you sure you've correctly configured your database? Your error log seems to indicate the last thing it was trying to do was access the DB, probably to insert information into your user table. A failure of this type in production wouldn't just lead to a failed transaction but would cause the entire app to crash.

Ryan B
  • 166
  • 2
  • 13
  • Thanks Ryan, I'm fairly new to this, what kind of configuration error do you mean? In my configuration of heroku's Postgres database? It was working earlier, the only things I've changed have been in my code. It makes sense that it would be a database issue, but I'm sort of at a loss as to what to change. – cbartondock Jun 23 '14 at 04:45
  • When you say it was working do you mean it was working locally or on Heroku? If locally then it could definitely be a server config problem. If it was working on Heroku then maybe you forgot to do add some migrations to the DB. Also, your Devise override looks a little strange. I'm also curious how you setup your routes. Overriding Devise controllers can be a tricky process, we actually ran into a related problem today developing a custom Devise-based gem. – Ryan B Jun 24 '14 at 00:10
  • It was working locally. I've edited my question to include the routes setup, but no I don't believe so the database should be fully migrated. I think it must be a database issue however, as that's the only thing that's different between my local server and heroku (I think). – cbartondock Jun 24 '14 at 17:33
  • Fixed! All I had to do was `heroku run rake db:schema:load` – cbartondock Jun 24 '14 at 18:13
  • Nice! Can I get a check for helping you get to the root of the problem? – Ryan B Jun 24 '14 at 19:29
  • Just a PSA, but `rake db:schema:load` [deletes all your production data](https://stackoverflow.com/a/5905958/5783745), so **be careful** – stevec May 12 '21 at 18:13
0

I had a form that worked perfectly on localhost, and wouldn't work on heroku.

For me, I had to restart heroku before migrations would work properly:

heroku restart

And then everything worked as expected. I now run heroku restart after every set of migrations. I'm not sure if it's documented anywhere, but they don't always work unless a restart has happened, so I do it just to be safe.

stevec
  • 41,291
  • 27
  • 223
  • 311