WordPress.org

Make WordPress Core

Tagged: media Toggle Comment Threads | Keyboard Shortcuts

  • Joe McGill 1:40 am on September 23, 2016 Permalink |
    Tags: , media   

    Media Weekly Update (Sept 22) 

    This post serves to jump-start discussion before our weekly check in, which takes place in #core-images on Slack. Our next meeting is Friday, September 23 at 17:00 UTC and the agenda for these meetings include moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on Trac.

    Summary from last week

    Our last meeting was Friday, September 16 at 19:00 UTC. You can read the entire chat log in the #core-images channel on Slack.

    Attendees: @joemcgill, @paaljoachim, @markoheijnen, @helen, @flixos90, @afercia

    • Unexpected change to media title behavior in WP 4.6.1 (#37989) – This is a regression, which has been partially fixed.
    • Sanitize accents in attachment filenames (#22363)@mike and @markoheijnen were planning to work on #22363 in person this past week and will decide on next steps.
    • Better PDF thumbnails (#31050)@markoheijnen tested out plugins that claim to handle this and found that all suffer from the same “corrupted image” issues that have blocked this ticket. The strategy is to see if we can detect which PDFs will fail and fall back to a default PDF icon when that is the case.
    • Media organization improvements:
      • Make media library searchable by filename (#22744) – This was fixed in [38625].
      • We had a lengthy discussion about the potential for adding a default taxonomy to attachments, including identifying some related tickets that would need to be addressed (e.g., #22938)
      • @paaljoachim shared the results of some research into how non-WP image applications handle media organization in the form of this Google doc.

    Agenda for our next meeting

    This week, we will continue discussion on our priority projects for the 4.7 release. If you have specific tickets that you want to have discussed, feel free to leave a comment on this post or reach out on Slack in the #core-images channel.

    Priority Tickets:

    HTTPS Update: @johnbillion recently posted a call for an HTTPS Working Group on the make/core blog. Meetings will be on Fridays (time TBA).

     
    • djsteveb 6:33 am on September 23, 2016 Permalink | Log in to Reply

      Glad to see people improving WP’s image things.

      Hope we can get an easy option to set a default limit of how many media appear on the main /media uploads/ or whatever pages. Hope we can also choose to set a default ‘only user XXXX” at first, and perhaps view by user role in the future.

      Currently the browser window will freeze up with some WP installs I run with buddypress – as the default admin screen loads up with all the user’s images and thumbnails, taking a ton of time and memory.

      I mentioned this here:https://make.wordpress.org/core/2016/09/08/media-weekly-update/#comment-31163 but think I got the comment out there too late for anyone to see it.
      Maybe there is a better place to mention these things for future consideration in improvements with wp images ?

      Steve

      • Joe McGill 2:05 pm on September 23, 2016 Permalink | Log in to Reply

        Hi djsteveb,

        Thanks for the feedback. The best way to bring up enhancement requests or bugs is by filing an ticket on Trac (if one doesn’t already exist addressing the issue you’re experiencing). In this case, it sounds like you may be experiencing the same issue described in ticket #30401. If you could provide feedback on that ticket, that would be helpful.

        Cheers!

  • Mike Schroder 1:53 pm on September 15, 2016 Permalink |
    Tags: , media,   

    Media Weekly Update (September 9) 

    This post summarizes the most recent media meeting, which takes places weekly in #core-images on Slack.

    Our next meeting is Friday, September 16 at 19:00 UTC and the agenda for these meetings include moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on Trac.

    It was brought up that the current meeting time is not great for @swissspidy or @flixos90, and they’d prefer to meet earlier, which we would start next week at Friday, September 23 at 17:00 UTC or alternatively on Thursday, September 22 at 17:00 UTC. Please sound off in the comments as to whether you’d be able to make either of the above to help decide on whether the meeting time will change.

    Agenda for the next meeting

    This week, we will check in on the priority projects for the 4.7 release. If you have specific tickets that you’d like to have discussed, please leave a comment on this post or reach out on Slack in the #core-images channel.

    Recap of the last meeting

    Our last meeting was Friday, September 9. You can read the conversation log in #core-images on Slack.

    Attendees: @mikeschroder, @markoheijnen, @flixos90, @adamsilverstein, @swissspidy, @paaljoachim, and @achbed.

    Media library organization improvements

    • @joemcgill and @swissspidy are working on adding the ability to search the media library by filename (#22744).
    • Following the meeting, @joemcgill posted some great notes on his thoughts regarding process for forming a roadmap for these improvements. You can read them on Slack.
    • Separately, we would like to engage members of the design team in initial conversations about what UI/UX improvements can be made to the media library to make it easier for people to organize and find their media. It’s likely that any UI changes in 4.7 would be relatively light, but we want to begin planning now and focus work during this release on getting as much infrastructure in place as we can.

    Improved full size image optimizations (#37840)

    Good conversation around ways to solve or work around the issue of increased CPU time/HTTP failures for image resizing.

    • Proposed closing #36534, and creating tickets from the issues found. It was great for gathering information, but has become a dropbox for all HTTP Error related tickets.
    • This is related closely to the full size image task because we want to avoid making the timeout issue worse when adding another resize.
    • In addition to running additional profiling to find what’s now taking the most time, one thing @joemcgill and @mikeschroder discussed in particular is a “try again” or “continue” button as a first jump into making it easier to recover when these failures happen. At the moment, this isn’t a thing because WP only saves meta after creating all sizes is completed successfully, and also because the code doesn’t support creating “the sizes that are left” (related: #15311).
    • @mikeschroder would also like to see investigation into making the HTTP Error more specific, but this could be part of the above project or solved without users needing to know the details, when WP can recover by itself.

    Core Media Widget (#32417)

    No Update. Reached out to @designsimply and @fab1en.

    HTTPS fixes

    No Update. Reached out to @johnbillion to see what plans are for 4.7.

    PDF Thumbnails (#31050)

    No time last week due to travel. @markoheijnen to send update this week.

    Accents in attachment filenames should be sanitized (#22363)

    @gitlost provided great feedback on the ticket (thanks!), but it looks like it’s going to need additional work before an initial commit.
    @mikeschroder looking into this with @markoheijnen at WC Tokyo this week.

     
  • Joe McGill 4:11 pm on September 8, 2016 Permalink |
    Tags: , media   

    Media Weekly Update 

    This post serves to jump-start discussion before our weekly check in, which takes place weekly in #core-images on Slack. Our next meeting is Friday, September 9 at 19:00 UTC and the agenda for these meetings include moving priority tasks forward, providing feedback on issues of interest and reviewing media focused tickets on Trac.

    Agenda for our next meeting

    This week, we will continue discussion on our priority projects for the 4.7 release. If you have specific tickets that you want to have discussed, feel free to leave a comment on this post or reach out on Slack in the #core-images channel.

    Recap of our last meeting

    Our last meeting was Friday, September 2. You can read the conversation log in #core-images on Slack.

    Attendees: @joemcgill, @mike, @kkoppenhaver, @lukecavanagh,@paaljoachim, @markoheijnen, @swissspidy, and @azaozz.

    Media library organization improvements

    • @joemcgill and @swissspidy are working on adding the ability to search the media library by filename (#22744).
    • @paaljoachim compiled a lists of WordPress plugins that exist to extend/improve media management and a document comparing features of these plugins.
    • Next step will be to compare the list of current plugins and decide on an initial approach for adding a default taxonomy structure for attachments.
    • Separately, we would like to engage members of the design team in initial conversations about what UI/UX improvements can be made to the media library to make it easier for people to organize and find their media. It’s likely that any UI changes in 4.7 would be relatively light, but we want to begin planning now and focus work during this release on getting as much infrastructure in place as we can.

    Improved full size image optimizations (#37840)

    No real update this week, should pick up once filename search is finished.

    Core Media Widget (#32417)

    @designsimply was traveling. We’ll plan on an update at the next meeting.

    HTTPS fixes

    @johnbillion is planning a make/core post outlining the plan for this release. In the mean time, the list of HTTPS related issues can be found in this report.

    PDF Thumbnails (#31050)

    @markoheijnen is reviewing the issue and looking into how plugins have addressed some of the remaining bugs.

    Accents in attachment filenames should be sanitized (#22363)

    @mike is reviewing feedback on this issue, but is planning on committing an initial fix soon.

    Rotate full size images on upload (#14459 and related #33051)

    @markoheijnen is looking at this issue for 4.7.

     
    • djsteveb 10:16 pm on September 14, 2016 Permalink | Log in to Reply

      No idea where best place to post about these issues.. let me know and I’ll add details.

      Attachments / media view crashes a lot for some of my wp sites when there is a lot of media.. think pages of images and video thumbnails loading when click on media -> library or whatever. Wish I could show you how painful it is to do this with a buddypress install, and a few users who upload – especially with rtmedia plugin making it easy to add media. sometimes the page takes forver to load, sometimes it fails.

      We need a way to limit how many media gets displayed by default, how much browser memory gets used when sucking in the thumbnails and such on these views.. and the tabs could be used to choose only to show media by certain users, etc.

      It’s also a major pain point in that in many cases users are able to see other user’s uploads when using buddypress. I used one setting with ‘press permit core’ plugin to fix this – but that’s overkill – and many don’t know about this and freak out when it comes to light.

      PASSWORD work around

      Recently discovered that having a secret image added to a page that is set as not public / passwrod required.. these are easily found when clicking next / next via themes’ image / media view.. certainly something should be done that says “if image is attached to page or post that is not public” – require password or admin account to view or something?

  • Joe McGill 4:01 am on September 2, 2016 Permalink |
    Tags: , media   

    Media kickoff meeting recap (August 26) 

    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.

    Attendees: @joemcgill, @bravokeyl, @mike, @azaozz, @nonproftechie, @designsimply, @johnbillion, @iseulde, and @paaljoachim.

    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.

    Add WP_Image and/or WP_Attachment (#23424)

    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.

    HTTPS issues

    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:

    1. Fixing HTTPS bugs, and
    2. 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.

     
    • FolioVision 12:34 pm on September 2, 2016 Permalink | Log in to Reply

      Thanks for this very comprehensive summary Joe.

      You wrote:

      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.

      I really like the idea of a standard master size maximum (with potential for special case override even if it has to be done in wp-config.php).

      I disagree strongly about not touching the original upload. WordPress is not a raw file image archiving system and should not be used as such. It’s not fair to webhosts (remember WordPress is supposed to play well in shared hosting) or in the end to users as it leaves users with absurdly large media folders.

      What could help is if we build in best practice image optimisation so that these masters are stored properly but without excess weight.

      Those who do want to build an image archiving system with WordPress should be able to override these defaults to store the original image but not easily. This would benefit 90%+ of the people running WordPress to run smoother faster sites which are more easily migrated. I don’t see a good reason for the 10% usage case to slow sites all over the world and create crazy storage issues for hosts.

      Perhaps I’m missing something here. I’m making one side of the case, but from experience. We host clients with very image intensive and high traffic sites. We also deal with neophyte clients who upload large quantities huge images with zero need to store originals on their server. Setting up each site to behave in a sane way is a big time drain. I can’t imagine the nightmare for hosts who run normal shared hosting businesses.

  • Joe McGill 3:15 pm on August 26, 2016 Permalink |
    Tags: , media   

    Media Kickoff Meeting for 4.7 

    We’re planning to have weekly meetings in the #core-images Slack channel throughout the 4.7 release cycle. The kickoff meeting is set for today, August 26, at 19:00 UTC. We will use these meetings to keep projects moving forward and to discuss any priority tickets that require discussion.

    Meeting Agenda

    The main purpose of the kickoff meeting is to identify the priority projects for 4.7 and to determine who is available to work on those projects. We will also review the current meeting schedule to see if a different time would be better for those wanting to be involved.

    Potential Focus Areas for 4.7

    • Improve media library management (#22744, explore default taxonomy structure, UX issues)
    • Better PDF management (#31050)
    • Create a standard WP_Image or WP_Attachment class (#23424)
    • Better optimization of full size images (#37840).
    • Core media widget (#32417)
    • Address HTTPS issues with media (#34109, #25449, #35182, etc.)
    • Improve responsive image defaults.
    • Support responsive images in WP_Customize_Media_Control (#36191)
    • Support responsive images in the editor.

    Wishlist Tickets

    Additional issues that were mentioned in the comments of the 4.7 wishlist post include:

    • Return option for media_sideload_image()  (#19629)
    • Add hook in wp_ajax_save_attachment() for additional attachment fields (#23148)
    • Updating link URL on image within admin with gallery (#13429)
    • Accents in attachment filenames should be sanitized (#22363)
    • Reconsider SVG inclusion to get_allowed_mime_types (#24251)
    • Dynamic image sizes in the editor (#35094)
    • Paste images into content area (#27970)
    • Add a drop zone to the the featured image meta box.
    • Revisit the Image Flow project.
    • Improve documentation/instruction for the WP media modal.
    • Address inconsistencies in the media library UI (see comment).

     

     
  • Andrew Ozz 2:00 am on July 29, 2016 Permalink |
    Tags: , , , media,   

    Editor changes in 4.6 

    In WordPress 4.6 TinyMCE is upgraded from version 4.3.10 to 4.4.1. There are numerous bug fixes and several new features, most notably a new inline theme (changelog).

    The wpview editor plugin (that is responsible for showing gallery, video, audio, and oEmbed previews) was updated to use the TinyMCE API for non-editable elements. This brought some small changes and improvements in the UI, for example “views” are draggable now. On the back-end the wp-mce-view-unbind event was removed as it doesn’t exist in the API. It was intended for cleanup/unloading but was never very reliable. If a plugin needs to unload instance dependent scripts, it can use mutation observer to monitor when the view node is deleted. See #36434 for more information.

    wpview remains an experimental API, though with each iteration it is getting closer to being finalized. As an experimental API, breaking changes are expected. As always, please test your plugin now if it modifies or depends on the editor, especially if you use experimental features like wpview.

     
    • elliotcondon 4:08 am on August 29, 2016 Permalink | Log in to Reply

      Hi guys,

      Elliot here – ACF developer.

      I’ve just noticed an odd bug (maybe) in this version of tinymce. The tinymce JS object contains a function called ‘add’ which “Adds an editor instance to the editor collection”. This is run each time a tinymce editor is initiated.

      This function contains an odd line of code copied below which seems to ‘double’ up the ‘collection’:
      `
      editors[editor.id] = editor;
      editors.push(editor);
      `
      Note that the editor is added using the id (as expected), and then also ‘pushed’ (added again using a numeric key).

      if you check the console lo, you can see the collection using “tinymce.editors”. You can see each editor is added twice.

      Please also be aware that this function also changes the ‘activeEditor’ to the last added instance which is different to the WP JS that sets the wpActiveEditor value (to the first editor id).

      I hope this info has been useful. I’ve just updated the ACF PRO plugin with a fix to avoid some JS errors introduced by this (I think…)

      Cheers
      E

    • Arno Kools 9:29 am on September 1, 2016 Permalink | Log in to Reply

      TinyMCE was NOT upgraded when upgrading WordPress to version 4.6.

      Version 4.3.10 was still used and it broke completely.
      I had to manually replace it with the latest version from the TinyMCE website.

  • Joe McGill 5:07 pm on May 26, 2016 Permalink
    Tags: , media   

    Media Weekly Meeting Recap (May 20, 2016) 

    The weekly Media meeting happens each Friday at 19:00 UTC in #core-images. The agenda for these meetings include reviewing priority tickets for the Media Component, open discussion on tickets desiring review, and scrubbing through open tickets.

    Participants this week: @joemcgill, @mikeschroder, @azaozz, @adamsilverstein, @ocean90

    Tickets Reviewed

    We focused on the open Media tickets on the 4.5.3 milestone, several of which prompted lengthy discussion.

    • #36533: Doesn’t work browse media libary on Frontend
    • #36534: Media Upload Issue Since 4.5 Upgrade
    • #36861: The Insert into post button in the Edit Image window doesn’t work
    • #36587: PHPUnit Tests fail with PHP7 and Imagick 3.4.x

    Read the full archive of this discussion and join us tomorrow, Friday at 19:00 UTC to get involved.

     
  • Joe McGill 7:14 pm on May 9, 2016 Permalink
    Tags: , media   

    Media bug scrub summary, May 6, 2016 

    Last week, we held a media component bug scrub in #core-images. You can read the archive of the discussion here: https://wordpress.slack.com/archives/core-images/p1462561213000210

    Participants included: @joemcgill, @kkoppenhaver, @ocean90, @markoheijnen

    We reviewed all of the Media component tickets currently slated for the 4.6 release (6 in all), and began working through issues on the Awaiting Review milestone.

    Tickets reviewed

    • #36531 Default image size medium_large is not generated
    • #36316 Image editor: improve form validation errors handling
    • #36587 PHPUnit Tests fail with PHP7 and Imagick 3.4.x
    • #14244 Upload file types should be checked BEFORE uploading.
    • #17262 wp_get_attachment_thumb_file should check new ‘thumbnail’ image size
    • #34384 No way of preventing image_get_intermediate_size from returning cropped image
    • #36777 Grid view not working after upgrading to WordPress v4.5.1
    • #36735 Add media, insert from URL and alt attribute (marked as good first bug)
    • #36684 Image crunched does not render in Microsoft Edge/IE/Windows Photos

    We’ll pick this back up next week at the same time, Friday, May 13 at 19:00 UTC.

     
  • Joe McGill 6:48 pm on May 5, 2016 Permalink
    Tags: , media   

    Media Component: Call for volunteers 

    The media component is a very large and highly-used component in WordPress—including sub-components like media uploading, the media editor, galleries, embeds, media template functions, etc. Maintaining such a large part of the codebase is a formidable task, and frankly, one that could use some extra love.

    As of this writing, there are 268 open tickets attributed to the media component, many of which haven’t received much attention. A release focused on bug-fixes is a perfect opportunity to reverse this trend.

    Get involved

    The team around the media component has gotten a bit light over the past few releases. If you’re interested in assisting with this effort, leave a comment on this post or reach out in the #core-images channel on Slack.

    We could use help on everything from reproducing bugs and verifying patches, to writing patches and unit tests. If you’re looking for a way to get involved in core development, this is a great place to get started.

    Weekly bug scrubs

    During the 4.6 release cycle, we’re going to experiment with using our weekly meeting times to do bug scrubs on the component in order to get the number of open bugs down to a reasonable number. The next meeting will be May 6 at 19:00 UTC in the #core-images channel on Slack.

     
  • iseulde 8:24 pm on April 14, 2016 Permalink
    Tags: , , , media,   

    Media Chat 

    In the regular #core-images chat this Friday, 15 April, 19:00 UTC we are planning to discuss enhancements for 4.6. So far there are four items on the agenda:

    • We are planning to add responsive images to the editor and discuss different implementation methods, e.g. saving srcset and sizes attributes to the database versus generating them on the front end. See #36475.
    • The makers of TinyMCE recently released JavaScript image tools for editing images in the browser which could replace the current server based image editor. The new editor would be quite faster, allowing you to edit and resize images before uploading them, and it would be easier to include in other scripts. This may well be a feature project over a few releases.
    • PDF preview images. See #31050.
    • Continue to improve mixed content issues on HTTPS sites. See #34945.

    If you have more ideas or tickets to discuss regarding media, please join us or leave a comment here. 🙂

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar