Route Error in Heroku when performing Updates/Create

[benjamintan]

First off, thank you for a wonderful plugin!

I encountered a weird issue, and a possible workaround, hopefully it would help some one out there.

On localhost, I've installed ActiveAdmin views to a "Badges" model, where I can upload pictures (via paperclip) of the badge, along with all the other CRUD actions.

CRUD works fine on localhost, however, once I deploy to Heroku, weird things happen:

(1) On first deploy, creating a new Badge would work, but editing/updating would fail. Looking at heroku logs, it shows a routing error at that /admin/badge/8. So I tried heroku restart

(2) Now, editing/updating works, but creating a new badge would fail, where its complaining that /admin/badges cannot be found.

So after fiddling around, I've just settled on including these in the routes.rb

get '/admin/badges/:id' => 'admin/badges#show'
match '/admin/badges/:id' => 'admin/badges#update'
match '/admin/badges' => 'admin/badges#create'
get '/admin/badges/new' => 'admin/badges#update'

And so far so good. Maybe ActiveAdmin.routes(self) has some issues with Heroku (or the other way round)? Either way, prior to this, "rake routes" works fine.

Any better suggestions?

[TheKidCoder]

I have seen this intermittent issue aswell on my Ubuntu VPS. I too was using paperclip and couldn’t find a solution. Sometimes updates would work, sometimes they wouldn’t....

I switched from paperclip to CarrierWave (which kicks the pants off of paperclip, btw) and the problem has seemed to stop. Give that a shot.

[rsalles]

Same issue for me. I use paperclip too.

[rsalles]

Have you tried to use the production environment on your localhost? For me, it doesn't work (whereas it works for dev).
So maybe we have to search there...

[timriley]

+1 on this issue. Have been experiencing it on models that use dragonfly for image uploads.

[benjamintanweihao]

Strange, then it seems like its not only happening to paperclip. So how did you get around this problem?

[timriley]

For now, I put in place some manual routes like the ones in the original bug report.

[rsalles]

In fact, it's related to multipart forms and PUT requests. They are transformed in POST: that s why your solution works timriley (btw, thx for it ;).

I have also noticed that in dev environment, it works whereas in prod it doesn't. Indeed, it s this line (in config/environments/production.rb): "config.cache_classes = true/false" which change the behavior.

I think we have to find a solution for that: a first hack should be to transform the PUT requests in POST. But I don't like this solution...

Any other idea?

[stungeye]

I am also experiencing this issue on an Ubuntu VPS. The routing errors only occur in production mode with admin forms that make use of a file upload input (for Paperclip).

I added the following routes to get things working again for a 'party' model:

post '/admin/parties/:id' => 'admin/parties#update'
get '/admin/parties/:id'   => 'admin/parties#show'
put '/admin/parties' => 'admin/parties#create'

[powow]

The real problem seems to be that the form_config is being cached if :multipart is true.

This means that if you restart the app and load the edit view then :method will always be "put",
and if you load the new view first, then the :method will always be non-existing.

But why does it cache the :method when multipart is set? And where?

[rolfb]

I posted as powow earlier, sorry.

This error relates to any custom :html options in the form setup, not just :multipart => true, and not just Heroku.

Found that it's actually the form_config[:html] object which is cached and subsequently modified by formtastic. It can be duped right before the call to semantic_form_for in /lib/active_admin/view_helpers/form_helper.rb to fix, but personally I find that to be a bit dirty, would love to have another solution.

Also wondering how to test an error which only happens in production (when config.cache_classes is set).

[pcreux]

Looks like this is fixed! :)