Files and the database

You will often see statements that imply an image file is contained "in" a node (Image module), "attached to" a node (Inline'/core Upload module) or "in" a CCK field (Imagefield, Asset, Embedded Media Field), or sometimes even that an image is stored "in" the database. In fact, neither nodes nor database records actually "contain" images, they just refer to the image files stored in the site's filesystem.

File handling limitations

Keep in mind that all of these file-related modules depend to some extent on the underlying functionality made available to them by the file handling code in Drupal core. This area is undergoing major changes from one version to the next, but most mainstream modules in this category have been slow to fully take advantage of these improvements.

For example, most modules just put all files into a single directory; Asset and Upload Path modules are exceptions.

Another limitation that will hopefully be removed in the future is that each module "owns" its own set of files; they cannot be re-used or managed by other modules. In fact, some modules don't even allow files under their own management to be displayed in more than one node - see this page for further details.

How files are "managed" in the database

Along with the relationship between nodes and images, image-handling modules differ in the relationship between the image files they manage and Drupal's database tables.

At one end of the spectrum, Image module could be said to "fully manage" image files by storing them as nodes, exposing each image to all the features Drupal offers for node management. At the other end, a user with proper permissions could upload files directly via SSH or FTP to a directory in the filesystem and reference them via standard HTML <img> tags within their content's text.

Many experienced Drupal developers would consider these files to be completely "unmanaged" and don't recommend such an approach. For example, if a content node is going to be deleted it becomes relatively difficult for the administrator to determine if an image linked from that node can be deleted or not, as it may be referred to by other nodes as well. Many people feel this problem, which has always existed with traditional websites, should be handled more systematically when using a CMS.

However some sites have content being contributed by a large number and variety of visitors, and many of the WYWIWYG rich text editors and modules like IMCE and Image Picker, whose main purpose is to help non-technical content authors, take this approach. The challenge is to strike a balance between ease of use and these administrative considerations.

If a given site will only have a handful of images, or if its content is only contributed by a small group of users available for training, or if perhaps nodes will never be deleted from a site but only flagged as unpublished, then these issues are less critical.

Most image-handling modules are in the middle ground between these two ends of the file-management spectrum. Although the image-as-node adherents would claim they don't really manage their files properly, modules like Upload, Imagefield and Asset do keep their filepath references in Drupal's files table and have their own tables in the database for tracking various other attributes of the images they handle.

Files used by themes

Note that images used by theming layer are traditionally not tracked at all in the database. A possible exception to this rule would be if you are using a tool like Audit Files to help manage your filesystem; this tool checks for orphaned file references in Drupal's files table. In order to avoid the theming files getting flagged as orphans, the administrator needs to ensure that they get entries in that table.

One method to accomplish this would be to use core Upload, or perhaps one of the contrib file management modules like WebFM, to upload all a theme's files, possibly attaching them to a single unpublished administrative node per theme. A side benefit of this would be if you stop using a specific theme, it would be easy to delete all its associated files by simply deleting that node.