Here is an enhancement request to Drupal's native file handling. Both file and image fields provide an optional setting to store the files in a well defined location. This is nice but not quite sufficient for large amount of content.
For example, if we have several nodes with several images and files attached to it. Currently, they are stored in a flat layout in respective file and image directories if they were set, else they go in default files dir.
Drupal can optionally provide a another way to store this type of content, i.e. by offering to store files and images associated with each node in a separate directory.
A simple and very effective enhancement could be made by adding an option to store files associated with an entity say node in a separate directory in a well defined location within its content type.
These additional fields are optional and can be added as a check box to store files/images separately for each node with nid as the unique identified.
Current Implementation Files: all files stored here
Currently Optional per field type Files > User-defined-file-dir
Proposed option for file and image fields Files > User-defined-dir > PRE-defined-pattern > NID-DIR : In this implementation all content associated with a node/entity is stored in a well designed location.
Inherit storage from parent Files > User-defined-parent-dir >PRE-defined-pattern > NID-DIR > USER-defined-child-dir > CHILD-nid-dir : A greatly useful extension of above proposition will be allow inheritance of storage location when content types are nested in each other.
The benefits of this layout are as follows
- Well organized and well distributed file system
- Scalable as filesystems don't get bogged down with too many files in one dir
- Streamline WYSIWIG editors to browse existing files as well as upload them to correct location. Currently, there is no way to browse content associated with a node, and the ones that offer this expose everything and disregard Drupals' partitioning.
Managed file refinement
Another option is to add an option for a managed file to used only once. I suspect this is mostly the case, very few files are referenced more than once. Many people go with unmanaged files due to the performance penalty for managed files. This will be a middle ground option that reduces complexity and improves performance. Of course it must be implemented as an optional field for those who benefit in this use case.
These suggestions will be nice extension to make in Drupal core. Importantly they don't require changes in design, except for Managed file refine which can jettison extra complexity of keeping references. Finally, these enhancement should not affect or interfere with current way of doing things.