Improving Media

[apeatling]

I'm looking to break down work that can be done to improve media handling in the editor, as well as improve the media library in general in WordPress.

There's a good list of items on this Make post https://make.wordpress.org/core/2023/07/07/media-library/

Here are some other items I've found on comments and Github issues. Please add any more you find in the comments.

• Add folder support
• Better EXIF support by auto tagging, categorizing, attributing media.
• Look for alternatives to the "Load More" functionality that works for both usability and accessibility.
• Adjust inserted media URLs so they use the relative not full path, to help with site URL moves.
• Dominant color background for images.

Thanks!

[annezazu]

Noting this that I just stumbled upon today: #12753

[piermario]

Besides folder support, in a dreamy dream world it would be cool to add the ability to rename media files.

[joemcgill]

Hi @apeatling, happy to see some of these ideas being collected. Many of the ones you have listed are already being tracked in the Media Component in Trac. I'd suggest reviewing tickets related to these topics and reaching out to the active component maintainers there.

For example

• The history for adding folder support can be found here (and related tickets)
• Using relative rather than absolute paths is a project design decision documented here.

Additionally, the Performance Team already has a dominant color implementation available as part of the Performance Lab plugin.

[apeatling]

Thanks!

[paaljoachim]

A bunch a years ago I took a greater part in the media area of WordPress and made these documents in relation to various discussions at the time. (There is some overlap in the documents.)
There might be some information there that can create some additional inspiration.

Thank you for starting this discussion!

Media Management Software overview
https://docs.google.com/document/d/1Y4Okna5nMZ40gqOgUjdOzJv5u9ZskofxnOvD5KZjNMw/edit#heading=h.zgsvj0qgc6l9

Media management feature plugin
https://docs.google.com/document/d/1Wx1M_mCFJRvcMD9xhvIySpkGRFmocpqPEf3ShryzgYU/edit#heading=h.7ydj168fc9rd

Comparing media feature for tags, categories and folder plugins.
https://docs.google.com/document/d/1Xgt8Cjv8rNcPwEwpECp3FgCOA5v1ehSkaA0uEFdQX6c/edit

[apeatling]

Thanks for these links, much appreciated!

[Ren2049]

Support for graphic embeds (oembed) across all graphic/image related blocks and a way to commit the final designs to the media library would make the workflow for people who want or need to prototype within WordPress a lot smoother.

It would help hobby designers using tools like Canva which supports embedding graphics on other sites. It's much smoother if you can adjust and update your linked graphics alongside the styles and layouts within the block editor without getting annoyed by manual export/import and image replace procedures.

I wouldn't consider myself a WP developer yet but I did some previous research into functions for a potential paid plugin. But I came to the conclusion that it should be free and core functionality because it would affect millions of users and accelerate the adoption of modern WordPress.

[paaljoachim]

Adding another comment here...
Once again I discovered that a client had uploaded multi MB images and I had to install the plugin Imsanity. Having a settings inside the Media Library to define the max size of uploaded images would be helpful.

This can also mean being able to sort the media library by media size. Being able to manually resize one or bulk resize multiple images at once.

Another aspect is to easily rename the title of media.

[JPBarringer]

This might be part of the "folder support" item above, but a huge pain point has been separating original media from generated thumbnails, especially on older sites, after the fact. Putting them in separate folders would be great for site management, and would make it a lot easier to make manual backups, run batch optimizations, and to perform server migrations.

Personally, I would prefer keeping generated images in a "cache" or "temp" folder that was clearly deletable and outside of wp-content (allowing a person to copy all of wp-content and the DB dump to backup or move a site, without a ton of overhead). ...But I imagine this is a much more contentious take than just "hey, can we be allowed to keep originals and generated thumbnails in separate folders?".

(...although, I do like the cache folder. Other CMSes use this approach, and it could be used for other generated items beyond image thumbnails.)

[JPBarringer]

I don't know if S3, R2, or even something crazy like Git LFS are worth mentioning here, but most of the object stores offer an S3-compatible API at this point.

Being able to use those services would cost-effectively solve a major disk-usage issue for people on smaller sites, would provide an avenue for hosting providers to move to more modern system architectures, and could bypass a lot of painful experiences for non-technical users.

[bahia0019]

Hey @apeatling,
I've been trying to find everyone working on this. There's quite a few people it turns out that have started tickets.
I'm trying to get everyone on the same page so we can consolidate the features, and any work that people have already done.
We've got a ticket over here #53788.
Hoping to get all planning handled in one spot.

We've also got a couple threads going on the Core Media channel on Slack. Wouldn't be a bad idea to get everyone involved over there for the occasional convo as well.

[apeatling]

Thanks for posting here! I was also part of the work on the prototype PR. I think the best place to bring everything together would be the new tracking issue that @ramonjd put together.

[lgladdy]

Just checking in here on behalf of ACF! We're happy to engage when it comes to making this extensible for third party plugins devs. Adding additional meta to media is important, so has backwards compatibility implications - or at a minimum, requires new hooks to allow that to continue into the site editor.

[MadtownLems]

Another media request: The ability to Replace a media item, much like https://wordpress.org/plugins/enable-media-replace/ adds.

Basically, it lets users swap in a new file for an existing media item. This lets them not worry about breaking any links to the original file, and given that most sites use the /year/month/ folder structure for media items, is one of the only ways to preserve the original file's URLs.

We've found this functionality absolutely vital for our environment, and believe it warrants consideration for core support.

[oslogrolls]

Enable media replace is so 2010 😃. WP ideally should…

• watch source-folders for new files (e.g. a folder outside the WP-installation)
• detect updates in source files (time stamp, file size, metadata changes)
• re-import the updated asset (retain all links)
• trigger CDN cache refresh

The whole assumption, that asset upload, file association to content pieces and updates of files all have to get performed manually, is a painful limitation in a professional media pipeline. Thinking of e.g. a WooCommerce scenario, where there's always a featured image and likely a few gallery images, it should be perfectly possible to remote-control populating new products from the Desktop machine: Even including later colour-corrections in product images.

[oslogrolls]

Many people wish for media folders, categories or tagging – any sort of clustering. All suggestions I read think of the current Media Library as an unordered file repository. Uploaded files are usually considered dumb (=they don't contain any sort of flag).  

As soon as WordPress made folders or tagging a core feature, once could finally start cleaning up. One would start creating from scratch with a metadata system that only lives in the WordPress database.

---

What I miss in the discussion is using metadata that already lives in files. Likely, the vast majority of media files used by publishing houses around the world use keyword- and other metadata in open standards that is permanently attached to files. These keywords could easily get read by WordPress (some plugins do this already) and would allow users to create clusters with arbitrarily many dimensions (folders, categories, tags). 

Existing and newly uploaded files, could automatically sort themselves to the correct collections. Editors would see the same structure, they use in their offline image tools or DAM software, and would instantly feel at home. Of course, editors, also inside WordPress, could create new metadata which gets written to the database and to the files.

No need to worry about metadata bloating media file size: One may strip this data before delivery –most CDNs do this by default, anyway.

TL/DR: Open metadata standards, such as xmp would make all types of logical grouping possible. Professional users would end up with a logical extension of their pipeline and would save a lot of time. Users who never used metadata experience no drawbacks. In contrast to any WordPress exclusive clustering there was no lock in – keyword data travels with the files and is readily available after a site-migration. Even after migration to another CMS.

[annezazu]

Wanted to cross share this recently created issue around Media workflows around patterns as I imagine it'll interest folks who have already chimed in here: #58172