search

jrgifford / delayed_paperclip

Process your Paperclip attachments in the background with delayed_job or Resque.
http://www.jstorimer.com/ruby/2010/01/30/delayed-paperclip.html
MIT License
402 stars 155 forks source link

#reprocess! does not function as described when split processing #142

Open jimryan opened 9 years ago

jimryan commented 9 years ago

The README says this:

Take note, normal reprocess! does not accept styles as arguments anymore. https://github.com/jrgifford/delayed_paperclip#reprocess-without-delay

That's not entirely accurate, as Delayed Paperclip doesn't appear to touch this method. This happens to work as expected, though, when not split processing - but fails when split processing.

Paperclip's #reprocess! method accepts zero or more style arguments. The caveat, though, is that zero arguments means "all styles", without regard for whatever styles you've passed to the :only_process option on the Paperclip attachment.

The end result here is that #reprocess! does not function as expected when split processing, and called without arguments, will end up processing the delayed styles twice. Once immediately, and then again delayed. To get the behavior that one would expect when split processing, you'd need to call #reprocess! with the :only_process value on the attachment.

I'm happy to work up a PR to either fix the documentation or Delayed Paperclip, but I'm not sure what direction to head in. Should we alias_method_chain #reprocess! to call the original with the styles passed to :only_process when split processing? That would get us the expected behavior when split processing.

greendog99 commented 8 years ago

Thank you for this! I was going crazy trying to figure out why my images were being processed twice. At the very least the delayed_paperclip documentation could be updated to reflect the need for arguments in #reprocess!. It would be great if #reprocess! would just honor the existing only_process array but I can work with either solution.