Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.What is a node?
In Drupal a "node" is commonly thought of as a post to be presented to a site's visitors. More specifically, a node is any item that you want to be treated as a full-fledged piece of content on your site. Extended definition of a Drupal node.
Not all content is stored as a node in Drupal. For example, users, comments, and files are not treated as nodes in Drupal. Although, using contributed modules it is possible to treat any content as a node in Drupal. This document explains the pros and cons of treating images as nodes.
Images as nodes
The "images as nodes" approach creates a one-to-one relationship between each image and its containing node. The image module follows this model; every image it handles is linked to a node of the "image" content type (not a CCK type node). This node references one image in the site's filesystem. This node can be displayed directly with a Title, Image, and Body. This node and its image can be displayed in other nodes and views, using various other contrib modules.
Advantages of the "images as nodes" approach
- Each image has a title and body, which can be used as a caption.
- CCK fields can be added to this image node, storing additional information about the image, e.g. exif/iptc data, geo-location information, attribution, and references to other nodes.
- Taxonomy terms can be used to "tag" images by topic or other classification schemes.
- Images can be published/unpublished to control their display
- Images can be tracked by date submitted, e.g. to be shown in a "recent images" block.
- Images can be tracked by the submitting user, e.g. "my pictures" display.
- Images can be integrated with other modules, e.g. become part of a standardized queue or workflow system.
- Image nodes allow for revision control.
- Users can comment/vote on or rate images.
- Images can be grouped for display (e.g. as galleries), separately from their original context.
- Access control can restrict certain images or galleries to particular users or roles/groups.
Generally, people associate Image module with this images-as-nodes paradigm, and in fact Image requires that all of the images it handles are each represented by a unique node. However, it is possible to take full advantage of all the above benefits with any image-handling module. For example, using Imagefield, you could create a custom content type that contains one CCK imagefield, and configure that field to "contain" (refer to) only a single file. However, note that this custom CCK node type would not be compatible with Image module or its add-ons, and should be named something other than "Image" to avoid confusion.
Potential disadvantages of "Images as nodes"
- It is theoretically possible that, for sites with lots (say hundreds of thousands) of images, storing them all as individual nodes could result in a performance hit from the extra database overhead. See Performance issues for related information.
- It is also possible that the unnecessary "clutter" of all those nodes would create extra administrative overhead, but setting up administrative Views and perhaps the use of tools like Views Bulk Operations would help with that.
- Many people claim that their favorite image-handling solution is much easier to use specifically because it doesn't require the creation of a node for every image displayed. Note however that this factor can be very complex to evaluate based on a site's specific needs, and is more of a user-interface implementation issue for specific modules, not directly pertaining to the nodes-as-images paradigm itself. See the Ease of use section for more information on usability.
Other image-to-node relationships
It is important in this discussion to distinguish the difference between a "containing" node, and a "displaying" node, which is the post where you want to show the image to visitors.
For example, Image-type nodes are often thought of as being "containing" nodes, but they can be also be used for display, e.g. clicking on a thumbnail in a taxonomy-based gallery will open the Image node itself, which will display a Title (possibly used as the caption in the gallery) and perhaps commentary in the Body field and other information as outlined above.
Other modules in the "Image module family" will enable another node, of any content type, to display one or more pictures "contained" in the Image type nodes, and on some sites visitors may never view the Image nodes directly.
Displaying images in multiple nodes
Nearly all the various image-handling modules allow you ways like this to display a given image in multiple nodes. These methods of linking between nodes may strictly control where and how the image appears, or involve the use of "macro tags" that users can insert in line with their content. See Display models for more information on this distinction.
Displaying image in one node only
Some modules however, are designed to "embed" a file into a specific containing node, and don't have a built-in way to allow other nodes to display that image without re-uploading a duplicate of the original file. See Image re-usability for more information on this issue.
No containing node needed
Some image-handling modules allow a user to upload files to the site's filesystem directly without necessarily associating it with any node at all, similar to the use of FTP in traditional non-CMS based websites.
IMCE is in fact designed to support RTEs (rich text editors), add-ons that make it easy for non-technical users to insert traditional HTML code into their post includingimg. See also the page on img tags and the page discussing WYSIWYG/RTEs for more information.
Other modules avoid the use of the containing node specifically to avoid past Drupal versions' file-handling limitations. Asset module (not maintained anymore) provides user directory management of your site's filesystem, including role-based quotas and access control, without implementing the concept of a "containing" node at all. This enables CCK and Views integration similar to Imagefield's, as well as helping users place images in line with content with macro tag similarly to Inline's, without the re-usability problems of those two modules.
One method or a mix?
Some people feel quite strongly that all images on a site should be stored "as nodes" (1:1 relationship). They want to use Drupal's built-in features to help them manage all the images used on the site - see the case for images-as-nodes above.
Some people hate the idea of images as nodes; their site's use case may not treat images as important content in their own right, and/or perhaps they already have a well-developed "off-site" image workflow and management system.
Yet a third group would like to "mix and match" these paradigms, choosing certain images as important enough to warrant "first class" treatment as nodes, while leaving the rest relatively unmanaged. If you want to take this path, then you will need to develop your own rules for how to decide how to handle a given image.
Perhaps the most important distinction is between images used only for decoration on the one hand, as opposed to images that need to be treated as items of content in their own right, e.g. carefully selected and edited photographs vs "quick & dirty" upload of trip snapshots. Obviously there will be gray areas, but one example of a rule of thumb might be, if an image is significant enough so that you want to show a larger version when the thumbnail is clicked, then you might want to consider treating it as a node.
Another factor is whether or not an image could be re-used in different parts of the site, as opposed to ones that only pertain to a single node. If the latter applies to most of your sites' images, then the re-usability issue becomes less important.
There are good arguments for just using one image-handling method on a site. It makes things simpler for the site designer and administrator, e.g. you can easily display different content types in teaser/list displays.
As mentioned above, it is possible to standardize a given site's image-handling on any of the various modules, and still choose your "image as nodes" philosophy as you feel appropriate for your site's needs.
