[wp-trac] [WordPress Trac] #47839: Extended file management in Media Library

WordPress Trac noreply at wordpress.org
Tue May 7 00:48:39 UTC 2024


#47839: Extended file management in Media Library
-------------------------+------------------------------
 Reporter:  mimoho       |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Media        |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by patrick_here):

 Replying to [comment:2 ricjcs]:
 >...Organization by folders (or categories) would be much better.
 >...risk of losing the work of having organized thousands of images. The
 best plugins of this type are also paid for the full version, with the
 free version being very limited.
 > ...It wouldn't make sense for an operating system with just one folder
 to organize thousands of files, and you need to pay for a plugin to
 organize them. Basically what happens with WordPress is this.
 > ...the implementation of this feature has been a utopia for many
 years...

 Well said; I agree 100%. The typical WordPress site today has far more
 images or photos in its Media Library, possibly hundreds of them, than it
 would have had back in 2012.  Some considerations:

 **The Folders-vs-Categories Design Decision:**
 My preference would be for (virtual) **Folders**.  This means that one
 image can be dragged-and-dropped to one folder only which is desirable in
 most cases.  The **Categories** approach allows the user to assign more
 than one category to a single image - an advantage for some but for most
 users this would only add confusion.

 **The Virtual-vs-OnDisk Design Decision**
 And yes, it's true that most of the existing "folder" plugins really
 implement the feature by providing a "virtual folder structure using
 hierarchical taxonomies" rather than tampering with the location of files
 on hard drive.  I think that paradigm should be maintained.  The whole
 question of where the image files live on hard drive (ie: a single custom-
 named folder or year/date folders) currently is complex enough as-is and
 could be treated as a separate enhancement if there is a desire to support
 multiple user-named folders on disk.

 **Adding images elsewhere**
 All of this implies that when the user goes to add an image to a post, the
 folder hierarchy that has been created should be visible and accessible
 somehow in the "Add Image" interface so that finding the image is not a
 needle-in-haystack proposition. Note also that when creating a (WP native)
 gallery on a post, if the user had the option of simply getting all the
 images from a single user-created (virtual) folder, it would be a huge
 step forward.

 **Time is of the essence**
 This re-design is long overdue and the longer it is delayed, the greater
 the potential for it to become more painful when it is finally implemented
 due to backward compatibility issues, etc. Right now, the backward
 compatibility issues are manageable, in my opinion.  (But the code is
 Backbone.js code. Does it make sense in 2024 to code an enhancement like
 this in Backbone.js?  If not, perhaps the solution is to tear it out and
 re-do it with something more up-to-date while maintaining the current
 interface wherever appropriate.)

 -Patrick

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47839#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list