File vs Binary/Image fields

[Mark Orciuch]

Hello,

I am looking for some best practices in storing assets as File vs Binary/Image. It seems that the decision would be based on whether the asset would be re-used or not. If to be re-used, store as File Asset. If not to be re-used, embed as Binary. Is this a good reasoning?

For example, in a news articles, is it better to "embed" the article attachment as Binary object as opposed to point to a File Asset? 

Or is it better to store images associated with news or calendar events as Image rather than point to a File Asset? 

I am wondering what are the implications of taking either approach. Many thanks in advance for sharing your knowledge.

[Falzone, Chris]

I am not sure about Best Practices.  However, I try to always use Binary Images unless I know for certain I will only ever need 1 copy of an image (say a logo).  And even in cases of things like logos in content, I lean towards using Binary anyway.  It's more user friendly, better for maintenance, easier to work with in code, etc.  That being said, we don't have millions of contents that might share 10 images.  In this case it would matter on the storage-side.  So, yeah, the main consideration is probably reuse or not, but unless you are worried about massive scale, or very limited resources, it probably doesn't matter. 

One downside of binary is that you can't use them in WYSIWYG fields easily.  So if you need your users to insert images into something like a blog post in the middle of the page, you're better off allowing them to upload the images somewhere as fileAssets and using the image picker rather than trying to break up your body copy into several fields to facilitate images.  But for the header/hero image and maybe a logo that gets associated, where the placement is done programmatically, I find it much easier to work with Binary Images.  

Hope that helps, and I love to hear other people's experience and thoughts as well.

--
http://dotcms.com - Open Source Java Content Management
---
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/760ba881-f0e4-4417-8c8d-b14ff075fda5n%40googlegroups.com.

--

Christopher Falzone

DevOps Engineer

A Q U E N T  /  VITAMIN T

[Mark Pitely]

Excellent points from Chris. 

Except for template-resources (spacers and borders, etc), I use Binarys exclusively, even for my logos. Even my header and footers are structured content w/binary. I mean, you may want to serve that SVG as a PNG if their browser doesn't support SVGs (shudder). 

Especially for News-type content, you want Binary, since you also need to make a special entry for OpenGraph/Facebook for when the entry is shared! You also want the image gone when the story is gone. 

I get around the 'user wants to put an inline image' factor in my WYSIWYG content by, yes, Binary Image, but I allow them to choose a 'class' (which allows for more freedom in where it is placed).

This helps with putting thumbnails in the news listing pages, too. Content should have an associated image, for sure, but I decide where and how and if that associated image gets shown. 

Let's never forget that any content is going to be both mobile and desktop (and a watch!), letting users place and pick images is BAD. You always want control over this and also want Accessibility control. 

You can include a second Binary image for later if you like (or a third, and in some places I let them pick up to 5 where I choose randomly between). In the past I let them put a suggested number of paragraph breaks to place the image, but that was too hard to maintain for little gain. 

In the same vein, I actually have my 404 page serve an image (when the url has an unfound .jpg), so if an image is gone, I have a placeholder site-wide. 

Never use images as files unless you are using the same resources across multiple sites, and even then, I would say, figure out a way to use binary. 

Mark Pitely

Marywood University

To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/CAMAbHgVkpEL6qyHi7AeYG4%2B80Fyv2A-OG6tZ-nj7k7Wn2VkLnA%40mail.gmail.com.

[Mark Orciuch]

Thanks, Mark! I know you've made these points in another post before but I think I have the complete picture now. Quick question, though: if I want to allow users to still use WYSIWYG editor to build the body of the article, how do I disable the Image tool? Many thanks in advance.

[Falzone, Chris]

I was going to say that you have to do this via a plugin to customize TinyMCE, which is one way you can do it.  But then I was poking in the docs and found that you can use field variables to do this now:

https://dotcms.com/docs/latest/the-wysiwyg-field#Customizing

To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/3de3aa00-4ada-4262-acd5-e6d89ed7aa3bn%40googlegroups.com.

[Mark Pitely]

That varies from version to version. Some have built in ways to edit the WYSIWYG, others require a plugin.

I don't actually take it away. I just don't teach them it is there. For my power users (and me) it is nice as a backup. I guess I just discourage the use with others, and every once in a while, troll for <img src> in the Web Page Content. 

I also troll for docs >1mb in the File Structure and shrink what I can (images, PDFs, etc)

M

To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/3de3aa00-4ada-4262-acd5-e6d89ed7aa3bn%40googlegroups.com.

[Mark Orciuch]

Fantastic, now I also finally understood the purpose of the field variables. Thanks!