This is a recap from the the Media Component kickoff meeting last Friday, August 26. The main goal of this meeting was to discuss potential focus areas for 4.7. Read the conversation log in #core-images on Slack. Our next meeting is Friday, September 2 at 19:00 UTC. The agenda will be to continue discussion on priority projects and review media focused tickets on Trac.
Media library organization improvements
Defining scope for this project is important in order to make meaningful progress. Here is an outline of the plan that was discussed:
- Start simple by addressing #22744
- Begin discussing a default taxonomy structure for media in Core
- Research existing plugins that address media organization and review approaches to taxonomy/data structure and UX/UI (@paaljoachim volunteered to put together an initial list in this Google Doc)
- Research non-WP apps for UX/UI inspiration
We may only do bits of this in 4.7, but the research should result in an initial proposal/road map for the media library including any recommendations about data structure, API, or UI changes that may be required.
PDF thumbnails (#31050)
@markoheijnen is leading this effort. People can get involved with testing and knocking out the final bugs/edge cases. Assistance from people with existing PDF/ImageMagick experience would be grand.
Core could benefit from a standard way of modeling attachment data, including methods for generating/retrieving pieces of that data without redundant calls to lower level functionality. However, as @johnbillion pointed out, this should start with a well defined set of use cases which demonstrates the problems we would be addressing by adding new classes.
This is probably a lower priority for this release unless there is increased interest.
Better full size image optimization (#37840)
Many authors upload and embed unoptimized full size images in their content. We may be able increase front end performance by optimizing full size uploads. Some initial suggestions to this end include:
- Look into creating an official ‘full’ or ‘master’ size which would replace uncompressed uploads on the front end and could potentially be used to speed up additional edit operations.
- It’s important that the original upload be stored as is and not affected at all so we always retain a “gold standard” backup.
- We would need to account for times where users are optimizing their images before uploading, i.e., this new method shouldn’t add page weight.
- If adding a new size is required for this, it will likely require optimizing the time and memory it takes to resize to avoid the dreaded “HTTP Error” (#37853)
- Additionally, could we be smarter about creating intermediate sizes and only do so when an intermediate size would reduce file size and not just dimensions?
- We may want to define maximum dimensions for the “full” size.
Core media widget (#32417)
A lot of progress has already been made on this feature, but it seems to have gotten stuck in a complexity/decision rut. The media component team may be able to help shepherd this project in 4.7 by supporting those already working on it.
@designsimply suggests simplifying the approach to only support images for a V1 may help move things forward. Either way, decisions need to be made about what should be supported in an MVP and a plugin should probably created for testing.
We fixed many HTTPS bugs in 4.4 and 4.5, but there are still many remaining issues.
@johnbillion is planning on leading a working group to pick this effort back up fo 4.7, with a focus on:
- Fixing HTTPS bugs, and
- Aiding users switching from HTTP to HTTPS, in whatever form that takes.
Copy/paste images directly into the editor (#27970)
This request gained some interest in the wishlist post. @azaozz and @iseulde have looked into this in the past and it seems the concerns outlined in the original ticket remain, so this is probably still a wontfix for now.