I have a pre-existing CDN with images for Spree::Products. I already imported the products but the pictures are yet to be somehow taken care of.
Sure, I can import all 400000 images, but that would take really, really long and caused duplication.
Is there any way to replace paperclip with some simple mechanism that would just serve existing pictures? I want all the pictures to be transferred through the Rails app, because otherwise it would cause unsecure content warnings on a SSL site...
So I'm thinking this: Can I just override the paperclip gem and serve existing images instead? Or can I replace paperclip entirely? Or can I do something about this at all?
Additional info: I have a database of all urls of all images with their PN/SKU/ID relations.
There is no simple mechanism to replace Paperclip. You should just be able to code your own solution, override any calls to paperclips methods to call your method pretty easily enough though. It just may be a bit time consuming, and possibly more time consuming than it would be for you to just deal with importing the images instead.
Related
Multiple question around the same issue, the way active storage returns file urls
For now with the default setup, the following (cloud or local), returns somehow the following :
_domain/_path/_superlong_hash/_original_filename._ext
Given paperclip or many other existing gems, the _path/_superlong_hash/_original_filename._ext part is in hand to be customised, could end up in a clean url for any files
Meaning by that :
is there a way to "proxy" the _path with something more custom ?
is there a way to avoid the _superlong_hash ?
is there a way to customize the filename on the fly (or on uploads) ?
To make it a one-liner, how one would customize the files urls ?
I've seen here and there people ending up creating custom controllers to serve file with decent urls, but let's admit this is a no go (IMHO)
I hope that ActiveStorage proves me wrong soon, but at the time of writing Rails 5.2, the straight answer seems to be that you have to go with your 'no go' option, hacking your own controllers together and heavily patching ActiveStorage to expose files.
For proxying see:
https://github.com/rails/rails/issues/31419
https://github.com/rails/rails/pull/30465
especially georgeclaghorn responses are interesting
For renaming file:
#user.avatar.blob.update(filename: 'NewFilename.jpg')
Manipulating the _superlong_hash / url
I have no good answer for this one. Although ActiveStorage makes it breathtakingly easy to upload (and somewhat easy to manipulate) files it takes Rails opinionated software philosophy to the edge, making it quite difficult to bypass it's obscurity by abstraction approach to url generation. ActiveStorage provides no built-in methods to do rudimentary things like permanent or direct links to files and variants once generated. File/image caching and nice urls seem therefore not to be possible to accomplish out of the box with ActiveStorage at this point in time.
I am working on a little app and I am curious if there is a way for a user to use the generated scaffolding to both (1) assign an image file name to a field, and (2) to automatically upload that file to the server when successful.
The idea is to create a simpler editorial process. My understanding is that including a blob in the table would not be good coding standards, so... if I can't store it in the database directly, then we need to store the image file name. But at the same time we need to ensure that that image is truly available on the server. In which case I'd like to cover both cases at the same time - allowing the editor to do their job.
is there an existing gem that I can leverage? Thanks
I'm not quite sure about your use case, and it seems like that's important, something about adding an image in a text editing field?
To answer one question, no, you can't do it with the default Rails scoffolding, although RailsAdmin and ActiveAdmin have paperclip support (and yes, to second #emaillenin, paperclip is probably the most common option).
Also check out JQuery File Upload for my favorite "scaffolding"-esque file uploader; although it's more work than say RailsAdmin, it's a great experience because you get thumbnail previews while the upload is going and progress bars all for free.
If it helps, I have a photo gallery project stored on Github, not "open source" in the sense that I attempted to make it useful to others, but I don't care if people browse it. It uses jquery-file-upload. Useful files:
Gemfile has:
gem 'paperclip'
gem 'jquery-fileupload-rails'
Then the photo model, categories controller for uploading photos as a nested resource, and the file-upload template translated to HAML.
How about Paperclip gem? - It lets you upload images, assign filename to a column in your model, validations on your attachments and helper functions to display them in your views.
Paperclip is intended as an easy file attachment library for Active
Record. The intent behind it was to keep setup as easy as possible and
to treat files as much like other attributes as possible. This means
they aren't saved to their final locations on disk, nor are they
deleted if set to nil, until ActiveRecord::Base#save is called. It
manages validations based on size and presence, if required.
Some alternatives - CarrierWave and more.
I like to use heroku and paperclip for image uploads. Usually my users don't need to upload many images.
I'm now embarking on a website where many users will be trying to upload images at the same time. Unfortunately on heroku, it seems I need a separate dyno for every image upload, otherwise the site becomes unresponsive. Or am I missing something?
What is an optimal way to set up a rails application (not necessarily on Heroku) where the site can easily deal with (in a scalable way, ideally) multiple uploads at the same time?
This is a shortcoming with Heroku - it doesn't handle file uploads very efficiently. See this article that discusses this point, among others. The author suggests using the carrierwave_direct gem or the Cloudinary service. Neither concept will work well for Paperclip as it doesn't provide cloud storage support. You might want to move to CarrierWave for easier implementation of these concepts.
I've looked at the available options and it seems like everything is optimized for image uploading as display. I just need simple file upload and retrieval. Are there any good options?
Paperclip is a popular choice for uploading and sizing images, but you can upload any type of file with it (doc, zip, txt, pdf... anything). Highly recommended. https://github.com/thoughtbot/paperclip
I like carrierwave. It has built in support for s3, has no workaround for setting up apps on heeroku unlike paperclip.
I use Carrierwave for mine and have been happy with it. I am just uploading general files, not specifically images. It is easy to implement and has good advanced features if you need them later. It also integrates with Fog to make using remote storage sources (like s3 or rackspace cloud files) easy.
Carrierwave benefits:
With carrierwave, the attachment is a seperate model instead of an attribute on an existing model, which might make things cleaner to work with.
It comes with the ability to attach a file via url (user passes in a url to a file) instead of uploading with a form).
It comes with some sort of way to remember files across form validation failures, although I've never used this and I'm not sure how it's done... maybe with two forms and ajax?
It seems to have a more engaged and enthusiastic community around it, with more projects extending it.
For S3, they use fog instead of aws-s3, and fog has much more active development.
That said, paperclip is pretty great and is actively maintained, and might come with handier default image manipulation stuff, I'm not sure.
I'm wondering if there's a way to store CSS asset paths, like background images, in the database so that they're customizable without accessing or rewriting the code. I've looked at some template engines, like liquid, but think they're a overkill for what I want to do. I only want a tiny bit of customization in my views between various deployments of the same app codebase, not anything for various users.
I've not looked much at Rails 3.1, but from what I understand the CSS assets are compiled and aren't static any longer, so -- does that mean I can write something like that into my CSS in rails 3.1 that pulls from the database? I usually deploy to Heroku and aren't sure if they're supporting 3.1 yet.
Anyone have any better strategies or ideas?
Storing binary files like images in the database can quickly become cumbersome. There was a time when we were storing user uploads like PDF's and such in the DB but it became unmanageable. We quickly moved it all over to S3 and made Paperclip store and retrieve the files there (encrypting the files before saving them to S3, and sending them over SSL since the files were potentially sensitive) and it made things much saner.
I'd say best bet for you is to use S3. Since
On heroku you have a limited
database size (depending on your
plan) and could quickly run out if
you're storing binaries there.
You can't dynamically save new files
to the filesystem on heroku, and
S3 is cheap as hell (and free for
most casual use) to store and
retrieve files.
EDIT based on your comment:
Ok I mis-understood the question. Either store the image path in the database or have the image stored with such a path & naming convention that the code itself can figure out where to get the image (which is what paperclip does). Both ways are acceptable. NOTE that SASS is not truly dynamic, you can't pull paths from the database and make the sass change on-the-fly. I've run into a similar situation and the solution was to make the CSS point to a background-image that was in fact a route in the application. In our instance we were able to change the image displayed based on the subdomain or domain of the incoming user, but you could just as easily display that image based on a session cookie that gets set before the views are rendered.
While SASS is compiled, after it's been generated it is static. The syntax, and 'dynamic' nature of it are just to make writing CSS easier.
What about using something like S3(Paperclip) + a "css assets" table/model?
That way in an "admin" page you can pull all of the possible CSS assets, allow someone to select a new one or even upload a new image to s3. This means you wouldn't have to actually rewrite any code just have an admin portal where they can select possible images.