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.

Comments

toamit’s picture

toamit CreditAttribution: toamit commented
Issue summary: View changes
toamit’s picture

toamit CreditAttribution: toamit commented
Issue summary: View changes
toamit’s picture

toamit CreditAttribution: toamit commented
Issue summary: View changes
toamit’s picture

toamit CreditAttribution: toamit commented
Issue summary: View changes
jhedstrom’s picture

jhedstrom
Primary language English
Location Portland, OR
CreditAttribution: jhedstrom at Phase2 commented
Version: 8.0.x-dev » 8.1.x-dev

Feature request => 8.1.x.

toamit’s picture

toamit CreditAttribution: toamit commented
Issue summary: View changes

Updated to include discussion from https://www.drupal.org/node/2128055#comment-9938253

Crell’s picture

Crell CreditAttribution: Crell at Palantir.net commented

This looks like an effective duplicate of #2128055: Files should be uploaded to per year/month directories by default, which already has buy-in and a very simple implementation. I suggest we mark it won't fix.

toamit’s picture

toamit CreditAttribution: toamit commented

File organization aspect is duplicate of #2128055.

Should Managed file and permission proposal concept be spun of as separate issue?

Crell’s picture

Crell CreditAttribution: Crell at Palantir.net commented

Or repurpose this issue for it, although I'm unclear what the ask is. (And it's likely too late for 8.0, and most people aren't talking 8.1 yet.)

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

jigarius’s picture

jigarius
Location Montréal
CreditAttribution: jigarius as a volunteer and at Symetris commented

Since the other file organization issue is closed and it seems related to 7.x I'll post a mini-suggestion here.

Currently, Drupal stores files to public://YYYY-MM directories by default.
I'd like to suggest storing them to public://YYYY/MM directories by default.

Alternatively, there are systems that organize files into multiple levels of directories based on their MD5 hashes.