technoweenie / attachment_fu
- Source
- Commits
- Network (182)
- Issues (8)
- Downloads (0)
- Wiki (1)
- Graphs
-
Branch:
master
-
validates_as_attachment does not allow for custom error messages
0 comments Created 6 months ago by vrinekvalidates_as_attachment replaced validates_attachment but the former seems to not have support for custom error messages (which we use for other languages)
this a workaround I use: http://gist.github.com/135810
Comments
-
Comments
for this issue, you can set a ruby timeout (http://ruby-doc.org/stdlib/libdoc/timeout/rdoc/index.html)
however if cloudfiles is down more than once, id probably choose another host!
-
When using attachment_fu alongside Yard, launching the Rails server throws an error that constant Technoweenie::AttachmentFu can not be found. It is failing on:
ActiveRecord::Base.send(:extend, Technoweenie::AttachmentFu::ActMethods)When using attachment_fu alongside Shoulda, the same error is thrown when attempting to run tests.
In "init.rb", only TempFile and Geometry are required. Adding the following resolves the aforementioned issue, and should be added to the repo:
require 'technoweenie/attachment_fu' Dir.glob(File.join(File.dirname(__FILE__), 'lib/backends/*.rb')).each {|f| require f } Dir.glob(File.join(File.dirname(__FILE__), 'lib/processors/*.rb')).each {|f| require f }Comments
-
Tempfiles in tmp/attachment_fu are not proactively deleted
1 comment Created 4 months ago by dkindlundAttachment_fu generates lots of tempfiles in tmp/attachment_fu, which are never deleted until the process exits. This is a problem with long running processes, which can generate tons of tempfiles. When attachment_fu is done with a tempfile, it should be proactively deleted in order to conserve disk space.
Comments
penguintux
Tue Oct 06 00:46:17 -0700 2009
| link
I have the same problem - a lot of files remain in the temp directory.
-
With GD2 processor, the image file is not well loaded and the format can't be determine.
Here is the patch http://gist.github.com/169214
Comments
-
Size restrictions are not properly applied to separate thumbnail class.
0 comments Created 2 months ago by eviltwinI have two classes, one which manages the "child" images and one for the "parent" images.
In the parent image class I have:
class Photo < ActiveRecord::Base has_attachment :content_type => :image, :storage => :file_system, :size => 1..5.megabytes, :thumbnails => { :thumb => 'c100x100' }, :thumbnail_class => ChildPhoto, :path_prefix => "Photos" validates_as_attachment endAnd in the child class:
class ChildPhoto < ActiveRecord::Base has_attachment :content_type => :image, :storage => :file_system, :path_prefix => "Photos", validates_as_attachment endI've removed the :belongs_to stuff because mine is quite funky and gets in the way of reading :)
Anyways, this is code for a friend's photography portfolio and so obviously the images can be quite large when first uploaded. The issue, though, is that I left the size parameter as the default for the child class as I figured thumbnails wouldn't be very large at all. However, the image size is checked before the resize operation and so the child class throws its toys out of the pram because it has an image that is larger than it is expecting. Is this expected behavior? The solution, obviously, is to also apply the :size option to the ChildImage class, but this feels wrong to me...
Comments
-
Comments
technoweenie
Wed Nov 25 15:28:10 -0800 2009
| link
I don't use DataMapper anymore, but I welcome support for it. Be sure to work off the rewrite branch of attachment-fu.
-
If there is a model saved without a file uploaded and model.destroy is called the following error can occur:
TypeError (can't convert nil into String)
I've found a few instances and simple fixes.
logger.info "Exception destroying #{full_filename.inspect}: [#{$!.class.name}] #{$1.to_s}"http://github.com/technoweenie/attachment_fu/blob/master/lib/technoweenie/attachment_fu/backends/file_system_backend.rb#LID91
Suggested fix, change the contents of the rescue on line 91 to the following:
if $1 logger.info "Exception destroying #{full_filename.inspect}: [#{$!.class.name}] #{$1.to_s}" else logger.info "Exception destroying file: no filename" end logger.warn $!.backtrace.collect { |b| " > #{b}" }.join("\n")http://github.com/technoweenie/attachment_fu/blob/master/lib/technoweenie/attachment_fu.rb#L365
# Gets an array of the currently used temp paths. Defaults to a copy of #full_filename. def temp_paths @temp_paths ||= (new_record? || !respond_to?(:full_filename) || !File.exist?(full_filename) ? [] : [copy_to_temp_file(full_filename)]) endfixed:
# Gets an array of the currently used temp paths. Defaults to a copy of #full_filename. def temp_paths if self.filename @temp_paths ||= (new_record? || !respond_to?(:full_filename) || !File.exist?(full_filename) ? [] : [copy_to_temp_file(full_filename)]) else [] end enddef full_filename(thumbnail = nil) file_system_path = (thumbnail ? thumbnail_class : self).attachment_options[:path_prefix].to_s File.join(RAILS_ROOT, file_system_path, *partitioned_path(thumbnail_name_for(thumbnail))) endfixed:
def full_filename(thumbnail = nil) if (self.filename) file_system_path = (thumbnail ? thumbnail_class : self).attachment_options[:path_prefix].to_s File.join(RAILS_ROOT, file_system_path, *partitioned_path(thumbnail_name_for(thumbnail))) end endComments
I was having a similar issue, and it seems that it was that the "uploaded_data" attribute provided by attachment_fu is not mass-assignable by default (so it is silently ignored).
Changing the following to attachment_fu.rb ~line 61
module InstanceMethods def self.included(base) base.define_callbacks *[:after_resize, :after_attachment_saved, :before_thumbnail_saved] if base.respond_to?(:define_callbacks) endto
module InstanceMethods def self.included(base) base.define_callbacks *[:after_resize, :after_attachment_saved, :before_thumbnail_saved] if base.respond_to?(:define_callbacks) # Allow mass-assignment to :uploaded_data base.attr_accessible :uploaded_data enddid the trick for me.
It may be worth further noting that I had to back out the suggested fix in the original issue report above, as it broke thumbnail generation for me (resulting in warnings along the lines of "Validation failed: Size can't be blank, Size is not included in the list"), as the 'else [] end' clause returns an array that is never stored, so in create_or_update_thumbnail when temp_file is unshifted into the temp_paths, it is not preserved in the object. Something like 'else @temp_paths ||= [] end' might work, but I found I no longer needed the changes once I made :uploaded_data mass-assignable.
It might be that the correct fix would be for the object using "has_attachment" to declare :uploaded_data as attr_accessible, but I thought it was nicer if the framework did it for me.





