My project tonight is to get image hosting working. After a recent upgrade it looks like something got screwed up. When I redeploy, the images get b0rked.
There are 3 option I’m exploring and dang nabbit, I’m going to try to get one working tonight.
1. Uploading to S3.
This is my preferred solution, but it isn’t currently working.
2. Uploading to Imgur
Second best… I got an API key from them. Config seems fine. Similar failure.
3. Uploading to my server
This seems to usually work… but when I deploy, the file disappears. Seems I need to figure out how to config to save it in a different directory so I don’t deploy over it.
Wish me luck! If I figure out any answers I’ll post them here.
I had the same error for S3. If you visit the doc that is linked in the log you’ll find out this has nothing to do with Discourse but probably that you use a non-US bucket.
I’m having no luck with S3 or Imgur either. Both seem so tantalizingly close. I’m not competent to fix the code, but at least I can point out the current state of affairs. This applies to 0.9.2
S3 Issues
It seems like the format has changed for AWS resources. I created a bucket, and the only option for region is “US Standard”. On the setup page, I entered the keys, and figured out that the region had to be set to “us-east-1”. With that, I can upload successfully, but the image URL is incorrect, the image appears broken. Discourse creates code like this:
Imgur uploads fail with an error “Sorry, but we couldn’t determine the size of the image. Maybe your image is corrupted?” … @benbeltran seems to have found a fix for this, but I haven’t been able to replicate it. More details here:
This works fine, but I gather from @colin above that this approach doesn’t survive (re?)deployment. I’m not exactly sure what that means… Is there a problem preserving local images through an upgrade cycle? Are there any issues with starting off using local storage, then switching later when Imgur/S3 get sorted out?
Hey, I responded in the github issue, but I’ll reply here as well. I haven’t had the time to read up / implement the changes to comply with pull request guidelines. But the fix is basically this:
• Use https for the default endpoint instead of http (imgur no longer accepts http requests)
• Rewind the file after reading it. (The library in charge of extracting the size needs to read it afterwards, if not rewound it will fail)
Thanks @benbeltran! The good news: I understood your original explanation well enough to modify my code such that it was identical to the imgur.rb that you used. Also added the https.The bad news: my revision had the same result as your version – same error. Here’s the line that gets written to production.log
Started POST “/uploads” for 75.144.241.86 at 2013-06-03 02:41:39 +0000
Processing by UploadsController#create as JSON
Parameters: {“topic_id”=>“1234”, “file”=>#<ActionDispatch::Http::UploadedFile:0x007f5b51a675a8 @content_type=“image/png”, @headers=“Content-Disposition: form-data; name=“file”; filename=“filename.png”\r\nContent-Type: image/png\r\n”, @original_filename=“filename.png”, @tempfile=#<File:/tmp/RackMultipart20130603-25805-1b7gg7l>>}
Rendered text template (0.0ms)
Completed 422 Unprocessable Entity in 404ms (Views: 0.6ms | ActiveRecord: 5.1ms)
So maybe there’s something else that is contributing. If I can figure it out, I will comment again here.
Hmm. I don’t get any errors. Those fixes actually fixed it for me. Is it possible that the 422 may be caused by inclusion of some other plugin? … Unprocessable entity means it didn’t pass validation, so maybe it’s going through more than one provider (e.g. s3 + imgur) and they’re borking each other? I’m only using imgur fwiw.
EDIT: Ahhh wait wait. Are you sure you’re doing File.size(file.tempfile)? 422 is probably caused by a FastImage Exception, you’re not seeing it because it rescues it in the controller. Test locally w/o entering the rescues to see what exception it’s bringing.
EDIT II: @cbonsig about the local file disappearing. I don’t know what you’re using to deploy, but make sure you’re uploading to a directory that is symlinked from outside of the releases dir. For example: link project/shared/uploads => project/current/uploads … If you’re not doing something like that, the next deploy will surely eat your uploads.
good thought, but I confirmed that only imgur was active
yep. i trashed my imgur.rb and replaced it with yours. and triple checked it!
I don’t know what that means … I tried commenting out the rescue code, and there didn’t seem to be any difference. I kinda have the feeling that Imgur is just completely hosed in my installation at this point. So I’m not going to worry about it for now.
Got it. I moved the whole /htdocs/public/ folder outside to a different spot, and created a symbolic link. That seems to be working fine.
We are thinking of pulling official Imgur support, since you’d need a Pro account and entirely different API mechanisms to guarantee your images are still there in a year or two years.
As long as images are getting at least 1 view per 6 months, they will stick around forever. If an image does not receive even 1 view in 6 months, it may be removed to make room for new images. Images on pro accounts will never be removed.
We would rather offer just S3 image hosting support for reliability, and let Imgur support come as a plugin at a later date. The current Imgur code we will leave in the vendor plugins folder as a todo if anyone wants to take it.
… I tried commenting out the 