Showing posts with label heroku. Show all posts
Showing posts with label heroku. Show all posts

Sunday, October 9, 2016

Uninitialized constant error with Rails 5, Paperclip and Amazon S3

I haven't used Heroku to host anything in quite a while, but had a personal project that I wanted to put up and show someone. Unfortunately, every time you push an update to Heroku or the app reboots, it clears any files you've uploaded to it. I went ahead with setting up Amazon S3 for file storage and thought everything would be gravy to my dismay. Heroku gave me a 500 error when I tried uploading an image: NameError (uninitialized constant Paperclip::Storage::S3::AWS)
I wondered if it was an issue specific to Heroku, so I setup the Paperclip AWS config to test locally to no avail; I was still getting the same error. I immediately went to Google and tried all of the solutions I came across on Github and Stack Overflow to no avail; my problem persisted. I finally came across a post on Stack Overflow that had a similar error, and in the comments, someone suggested using the 5.0.0.beta2 version of the Paperclip gem. I updated my Gemfile to use that version: gem 'paperclip', '5.0.0.beta2' and after a bundle install - file uploads were working! I did have to specify the s3_host_name in my paperclip config to get images to display, but it worked. Since I haven't come across much information on this on the web, I thought I'd make a post about it. So if anyone else is having this issue, update your Gemfile to use a version of the Paperclip gem > 5.0. I updated mine to use Paperclip 5.1.0 and everything is working great.
gem 'paperclip', '5.1.0'
With the paperclip config as follows:
config.paperclip_defaults = {
    storage: :s3,
    s3_credentials: {
      bucket: ENV.fetch('S3_BUCKET_NAME'),
      access_key_id: ENV.fetch('AWS_ACCESS_KEY_ID'),
      secret_access_key: ENV.fetch('AWS_SECRET_ACCESS_KEY'),
      s3_region: ENV.fetch('AWS_REGION'),
      s3_host_name: ENV.fetch('S3_HOST_NAME'),
    }
  }

Cheers.

Tuesday, July 9, 2013

Heroku fails precompiling assets with MySQL and Rails 4

I've been having a hell of a time deploying this app I'm working on to Heroku. For some reason, during the deployment process, while Heroku was precompiling assets, it would attempt to access the database at 127.0.0.1 and fail (obviously). I could precompile the assets locally, and deploy without a problem. At least, I thought it was without a problem. After implementing a WYSIWYG text editor into part of the app, the icons weren't showing up on the various buttons (for bold, italic, etc). So I decided to further investigate WHY my assets weren't precompiling on Heroku. I hopped in the Rails IRC channel, and a suggestion was proposed to try precompiling locally, with the environment set to production, but with a database that does not exist. Doing so should help to debug where the root of the cause was, and it did: Rails was failing on one of my validations. Enter: confusion. Why on earth is Rails attempting to run this validation whilst precompiling my assets? The validation in question is as follows:
validates :agree_to_contract, :acceptance => { :accept => true }, :on => :update, :if => :signer_full_name

agree_to_contract is a boolean, and signer_full_name is a string. I wanted the two fields to depend upon each other, and fail if one of them did not exist (there was a similar validation on signer_full_name for going in the other direction).
None of my initializers accessed the model which contained these validations, but yet - there was no way for me to remedy the issue. I attempted to wrap the validation in an ActiveSupport.on_load do end; still, the error persisted. This method seemed to be the culprit. It appeared as though the :acceptance block on the validation was causing the issue, but I was pretty much out of information to gather, so I headed over to the Rails issues tracker, to report a bug. After a bit of deliberation, and me producing some sample apps that displayed said behavior, it turned out that that this is, indeed, a bug. The cause is presently unknown, however, one of the contributors to the post hypothesized that the cause was eager_load! Hopefully the issue is resolved soon, and we can deploy checkboxes with validations to our heart's content ;)

Update:
A fix has been proposed, and it's working in my app! It's a pretty simple fix, too. edit config/environments/production.rb in your own app with the following:

replace config.eager_load = true with config.eager_load = true if config.eager_load.nil?

That's it. You should no longer have precompiling assets break with the :acceptance validation.