File and Image Handling in Content Management

By Deane Barker on June 21, 2007

Here’s something that frustrates me in a lot of content management systems: file handling. Specifically, the inability to tightly bind a file to one or more content objects, and ensure that it lives and dies solely within the scope of those objects.

Most systems will put files in a common file library. This is good for some things — if you’re going to have an image of the CEO that will be accessed a lot, then it’s handy to have it in one place. But there’s also a danger in managing that file independent of the content that uses it. If the file disappears, you have broken content.

Put another way, the association of file to content is too loose. It’s as loose as plain ‘ol static HTML, and it’s one of the problems content management was invented to fix.

What I like is when you can upload and manage supporting files within a specific content object. Either have a file be an explicit, named property on a content object, or have a “files” section for each content object where you store the files required for that piece of content to function.

What this means is that those files cannot be accidentally deleted and break a reference. Additionally, it’s cleaner — you don’t have this huge mass of files sitting around for which you have no idea of the corresponding content objects that need them. Every file lives within the scope of a piece of content, is managed with that content, and is deleted with that content. Bonus points if you version it with the content as well.

Common file libraries are good, but if they exist, you need to be able to bind content objects to each file. You need to be able to say, “This file is being used by these content objects. And so long as these content objects are still in the system, you cannot delete this file.” You can also have a quick reference to what content objects are using what file, and the reverse: what files a particular content object uses.

In short: watch the binding between files and content. In a lot of systems, it needs to be tighter than it is.

Gadgetopia
What Links Here

Comments

  1. Good stuff, Deane. Here’s how Big Medium handles these associations. When you add an image, document or podcast media to a page, for example, it does add that item to a common library for reuse, but it also saves and monitors the page-specific relationship. It remembers that the image appears on that page.

    If you choose to have it “live or die” in the context of that page only, you can choose not to have the media appear in the library, preventing it from being reused. In that case, it’s a private element that’s associated only with that page.

    Either way, Big Medium keeps up with the relationships between objects. So if you decide to trash an image, that image is quietly removed from all pages that contain it. Never any broken images or links. Big Medium handles the cleanup for you. Not sure where an image is used? Just go to the edit page for that image in the image library and it gives you a list of pages where it appears.

    It’s not just about files and images, though; I’d say the same monitoring, management and cleanup of node associations has to happen between all content (pages, categories, entire site objects, you name it).

    As you suggested a few weeks ago in “The Necessity of Subcontent,” a good content management system should let you make arbitrary associations and ownership claims between any other nodes/objects. And likewise, a good CMS should be able to clean up those associations when you decide to remove the content, so that you don’t have to fret about it yourself.

    Keep up the great work!

Comments are closed. If you have something you really want to say, email editors@gadgetopia.com and we‘ll get it added for you.