Not planned Attachment Thumbnails (and other content type specific attachment data)

[xf_phantom]

Would't it be better to move the data like the max size, max width, thumbnail data to the handlers?

After a quick look at the code, it seems that the global used size is saved in XenForo_Application::get('options')->attachmentThumbnailDimensions

And this size is used in the attachment model and in the defered script to rebuild the thumbnails

What if i want to have different thumbail sizes?

e.g. my Gallery thumbails should be 200x200, my post thumbails only 150x150 and my cms thumbails 250x250

If the data would come from the attachment handler, it would be much easier to use different sizes for the thumbails.


You could even add the attachment handler name / content ty eas parameter to attachmentModel::getAttachmentContraints, which could return then the content type specific attachment sizes. so we wouldn't have to implement / overwrite this method for own types

 

[Paul B]

You need to move any add-on thumbnails to their own directory.

This is what @Chris Deeming has done for his gallery.

 

[Mike]

Attachment data is content agnostic and reusable if desired, so the general thumbnail that's created is therefore content agnostic too. If you want content specific thumbs, you should build them yourself and store them separately.

 

[Chris D]

Also, I wrote my own getAttachmentParams and getAttachmentConstraints functions and fetch those params rather than the default attachment params.

There's nothing wrong with specifying them in the attachment handler, I guess, but they need to be available somehow in the controller as the parameters from both are passed to the attachment upload form. Attachment handlers aren't usually required in controllers.

 

[xf_phantom]

There's nothing wrong with specifying them in the attachment handler, I guess, but they need to be available somehow in the controller as the parameters from both are passed to the attachment upload form. Attachment handlers aren't usually required in controllers.

that's why my idea was to pass the content type to the getContraints method, which calls the handler and returns the content type specific data.

You could even add the attachment handler name / content as parameter to attachmentModel::getAttachmentContraints, which could return then the content type specific attachment sizes. so we wouldn't have to implement / overwrite this method for own types

b2w what do you do to avoid the rebuild by the deferred actions?

Attachment data is content agnostic and reusable if desired, so the general thumbnail that's created is therefore content agnostic too. If you want content specific thumbs, you should build them yourself and store them separately.

Yes it is content agnostic and that's why we have the xf_attachment and xf_attachment_data table, right?
But i don't know WHY this is the reason, to not provide more reusable code. (it seems that we're not talking about the same thing again )

ATM it seems that we have to:

• create a method returning the content type specific data like max attachment count, max size, max thumbail size
• create a new deferred action (or however you call it) to let the user rebuild the attachments if needed
  
• care about the thumbnail management

And this all are actions, which are already handled by xenforo. if they would be more dynamic and accept the content type specific data, the addon developers could reuse them and avoid copy and paste code)


Another reason why i'm saying is e.g. the thumbnail rebuild process.....
if you check XenForo_Deferred_AttachmentThumb

$attach = $dw->getMergedData();
         $attachFile = $attachmentModel->getAttachmentDataFilePath($attach);
         $imageInfo = @getimagesize($attachFile);
         if ($imageInfo)
         {
           $image = XenForo_Image_Abstract::createFromFile($attachFile, $imageInfo[2]);
           if ($image)
           {
             if ($image->thumbnail(XenForo_Application::get('options')->attachmentThumbnailDimensions))

it seems that no MATHER where the thumb is saved, the deferred process will replace it with the dimension saved in attachmentThumbnailDimensions.



But yea, it was marked as "no thx" so i'll leave it here and see how (IF) the above suggested implemention way will work for me

 

[Chris D]

Exactly.

I have extended the AttachmentData DataWriter so that when my Gallery content thumbs are created, they are done so in data/xengallery rather than data/attachments.

Yes. When the AttachmentThumb rebuild runs, it will actually create a thumbnail for my content that will never be used. But because my real thumbnails are stored elsewhere, they aren't affected.

I have written my own rebuild for my thumbnails which only rebuilds the thumbnails for my content.

 

[xf_phantom]

Exactly.

I have extended the AttachmentData DataWriter so that when my Gallery content thumbs are created, they are done so in data/xengallery rather than data/attachments.

Yes. When the AttachmentThumb rebuild runs, it will actually create a thumbnail for my content that will never be used. But because my real thumbnails are stored elsewhere, they aren't affected.

I have written my own rebuild for my thumbnails which only rebuilds the thumbnails for my content.

thx

this just confirms that it's not really optimal on xf side, but i'll leave it here

 

[Chris D]

I don't disagree with you with regards to thumbnail creation. But it is the lesser of two evils.

I think we're all pleased that there's a way to rebuild forum thumbnails and although it's not necessarily an optimal process - potentially storing thousands of thumbs for add ons that have a thumb elsewhere - it's still better than not having that feature and its easy enough for us to adapt.