README.md

Paperclip

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. It can transform its assigned image into thumbnails if
needed, and the prerequisites are as simple as installing ImageMagick (which,
for most modern Unix-based systems, is as easy as installing the right
packages). Attached files are saved to the filesystem and referenced in the
browser by an easily understandable specification, which has sensible and
useful defaults.

Requirements

Ruby and Rails

Paperclip now requires Ruby version >= 1.9.2 and Rails version >= 3.0 (Only if you're going to use Paperclip with Ruby on Rails.)

If you're still on Ruby 1.8.7 or Ruby on Rails 2.3.x, you can still use Paperclip 2.7.x with your project. Also, everything in this README might not apply to your version of Paperclip, and you should read the README for version 2.7 instead.

Image Processor

ImageMagick must be installed and Paperclip must have access to it. To ensure
that it does, on your command line, run which convert (one of the ImageMagick
utilities). This will give you the path where that utility is installed. For
example, it might return /usr/local/bin/convert.

Then, in your environment config file, let Paperclip know to look there by adding that
directory to its path.

In development mode, you might add this line to config/environments/development.rb):

Paperclip.options[:command_path] = "/usr/local/bin/"

If you're on Mac OS X, you'll want to run the following with Homebrew:

brew install imagemagick

If you are dealing with pdf uploads or running the test suite, you'll also need
GhostScript to be installed. On Mac OS X, you can also install that using Homebrew:

brew install gs

Installation

Paperclip is distributed as a gem, which is how it should be used in your app.

Include the gem in your Gemfile:

gem "paperclip", "~> 3.0"

If you're still using Rails 2.3.x, you should do this instead:

gem "paperclip", "~> 2.7"

Or, if you want to get the latest, you can get master from the main paperclip repository:

gem "paperclip", :git => "git://github.com/thoughtbot/paperclip.git"

If you're trying to use features that don't seem to be in the latest released gem, but are
mentioned in this README, then you probably need to specify the master branch if you want to
use them. This README is probably ahead of the latest released version, if you're reading it
on GitHub.

Usage

The basics of paperclip are quite simple: Declare that your model has an
attachment with the has_attached_file method, and give it a name.

Paperclip will wrap up up to four attributes (all prefixed with that attachment's name,
so you can have multiple attachments per model if you wish) and give them a
friendly front end. These attributes are:

<attachment>_file_name

<attachment>_file_size

<attachment>_content_type

<attachment>_updated_at

By default, only <attachment>_file_name is required for paperclip to operate.
You'll need to add <attachment>_content_type in case you want to use content type
validation.

More information about the options to has_attached_file is available in the
documentation of Paperclip::ClassMethods.

For validations, Paperclip introduces several validators to validate your attachment:

Defaults

Global defaults for all your paperclip attachments can be defined by changing the Paperclip::Attachment.default_options Hash, this can be useful for setting your default storage settings per example so you won't have to define them in every has_attached_file definition.

If you're using Rails you can define a Hash with default options in config/application.rb or in any of the config/environments/*.rb files on config.paperclip_defaults, these well get merged into Paperclip::Attachment.default_options as your Rails app boots. An example:

Another option is to directly modify the Paperclip::Attachment.default_options Hash, this method works for non-Rails applications or is an option if you prefer to place the Paperclip default settings in an initializer.

Understanding Storage

The files that are assigned as attachments are, by default, placed in the
directory specified by the :path option to has_attached_file. By default, this
location is :rails_root/public/system/:class/:attachment/:id_partition/:style/:filename.
This location was chosen because on standard Capistrano deployments, the
public/system directory is symlinked to the app's shared directory, meaning it
will survive between deployments. For example, using that :path, you may have a
file at

Files on the local filesystem (and in the Rails app's public directory) will be
available to the internet at large. If you require access control, it's
possible to place your files in a different location. You will need to change
both the :path and :url options in order to make sure the files are unavailable
to the public. Both :path and :url allow the same set of interpolated
variables.

Post Processing

Paperclip supports an extensible selection of post-processors. When you define
a set of styles for an attachment, by default it is expected that those
"styles" are actually "thumbnails". However, you can do much more than just
thumbnail images. By defining a subclass of Paperclip::Processor, you can
perform any processing you want on the files that are attached. Any file in
your Rails app's lib/paperclip_processors directory is automatically loaded by
paperclip, allowing you to easily define custom processors. You can specify a
processor with the :processors option to has_attached_file:

This would load the hypothetical class Paperclip::Ocr, which would have the
hash "{ :quality => :better }" passed to it along with the uploaded file. For
more information about defining processors, see Paperclip::Processor.

The default processor is Paperclip::Thumbnail. For backwards compatibility
reasons, you can pass a single geometry string or an array containing a
geometry and a format, which the file will be converted to, like so:

has_attached_file :avatar, :styles => { :thumb => ["32x32#", :png] }

This will convert the "thumb" style to a 32x32 square in png format, regardless
of what was uploaded. If the format is not specified, it is kept the same (i.e.
jpgs will remain jpgs). For more information on the accepted style formats, see
here.

Multiple processors can be specified, and they will be invoked in the order
they are defined in the :processors array. Each successive processor will
be given the result of the previous processor's execution. All processors will
receive the same parameters, which are what you define in the :styles hash.
For example, assuming we had this definition:

then both the :rotator processor and the :ocr processor would receive the
options "{ :quality => :better }". This parameter may not mean anything to one
or more or the processors, and they are expected to ignore it.

NOTE: Because processors operate by turning the original attachment into the
styles, no processors will be run if there are no styles defined.

If you're interested in caching your thumbnail's width, height and size in the
database, take a look at the paperclip-meta gem.

Also, if you're interested in generating the thumbnail on-the-fly, you might want
to look into the attachment_on_the_fly gem.

Events

Before and after the Post Processing step, Paperclip calls back to the model
with a few callbacks, allowing the model to change or cancel the processing
step. The callbacks are before_post_process and after_post_process (which
are called before and after the processing of each attachment), and the
attachment-specific before_<attachment>_post_process and
after_<attachment>_post_process. The callbacks are intended to be as close to
normal ActiveRecord callbacks as possible, so if you return false (specifically
- returning nil is not the same) in a before_filter, the post processing step
will halt. Returning false in an after_filter will not halt anything, but you
can access the model and the attachment if necessary.

NOTE: Post processing will not even start if the attachment is not valid
according to the validations. Your callbacks and processors will only be
called with valid attachments.

MD5 Checksum / Fingerprint

A MD5 checksum of the original file assigned will be placed in the model if it
has an attribute named fingerprint. Following the user model migration example
above, the migration would look like the following.

Custom Attachment Processors

Custom attachment processors can be implemented and their only requirement is
to inherit from Paperclip::Processor (see lib/paperclip/processor.rb).
For example, when :styles are specified for an image attachment, the
thumbnail processor (see lib/paperclip/thumbnail.rb) is loaded without having
to specify it as a :processor parameter to has_attached_file. When any
other processor is defined it must be called out in the :processors
parameter if it is to be applied to the attachment. The thumbnail processor
uses the imagemagick convert command to do the work of resizing image
thumbnails. It would be easy to create a custom processor that watermarks
an image using imagemagick's composite command. Following the
implementation pattern of the thumbnail processor would be a way to implement a
watermark processor. All kinds of attachment processors can be created;
a few utility examples would be compression and encryption processors.

Dynamic Configuration

Callable objects (lambdas, Procs) can be used in a number of places for dynamic
configuration throughout Paperclip. This strategy exists in a number of
components of the library but is most significant in the possibilities for
allowing custom styles and processors to be applied for specific model
instances, rather than applying defined styles and processors across all
instances.

Dynamic Styles:

Imagine a user model that had different styles based on the role of the user.
Perhaps some users are bosses (e.g. a User model instance responds to #boss?)
and merit a bigger avatar thumbnail than regular users. The configuration to
determine what style parameters are to be used based on the user role might
look as follows where a boss will receive a 300x300 thumbnail otherwise a
100x100 thumbnail will be created.

Dynamic Processors:

Another contrived example is a user model that is aware of which file processors
should be applied to it (beyond the implied thumbnail processor invoked when
:styles are defined). Perhaps we have a watermark processor available and it is
only used on the avatars of certain models. The configuration for this might be
where the instance is queried for which processors should be applied to it.
Presumably some users might return [:thumbnail, :watermark] for its
processors, where a defined watermark processor is invoked after the
thumbnail processor already defined by Paperclip.

Deployment

Paperclip is aware of new attachment styles you have added in previous deploys. The only thing you should do after each deployment is to call
rake paperclip:refresh:missing_styles. It will store current attachment styles in RAILS_ROOT/public/system/paperclip_attachments.yml
by default. You can change it by:

Now you don't have to remember to refresh thumbnails in production every time you add a new style.
Unfortunately it does not work with dynamic styles - it just ignores them.

If you already have a working app and don't want rake paperclip:refresh:missing_styles to refresh old pictures, you need to tell
Paperclip about existing styles. Simply create a paperclip_attachments.yml file by hand. For example:

Make sure there are tests! We will not accept any patch that is not tested.
It's a rare time when explicit tests aren't needed. If you have questions
about writing tests for paperclip, please ask the mailing list.

Please see CONTRIBUTING.md for more details on contributing and running test.