File and Image Handling in Content Management
Often, a binary file needs to be bound to a specific content item, and needs to “live” in the context of that item.
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…
The document discusses the issue of file and image handling in content management systems, particularly the inability to tightly bind files to one or more content objects. It criticizes the current system’s loose association of files to content, suggesting that it could lead to broken content if a file disappears. The author advocates for the use of explicit, named properties on content objects or specific “files” sections for each content object to ensure file management within the scope of the content.
Generated by Azure AI on June 24, 2024Here’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 old 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.