WordPress.org

Make WordPress Core

Tagged: media Toggle Comment Threads | Keyboard Shortcuts

  • Joe McGill 9:20 pm on November 22, 2016 Permalink |
    Tags: , , media   

    Media Changes in 4.7 

    This post provides an overview of the changes to the Media component in WordPress 4.7. See a list of all the 4.7 media tickets.

    Two notable changes, enhanced PDF support in the media library and changes to the default fallbacks for alt attributes, are explained in separate posts.

    Enhanced PDF Support in WordPress 4.7

    Improving accessibility of image alternative text in 4.7

    Make media library searchable by file name (#22744)

    Before 4.7, if you uploaded a file to the media library and changed the title, it wasn’t possible to find that file again by searching for the file name. Now, attachment search queries will also include matches to the _wp_attached_file post meta value.

    Other enhancements and bug fixes

    • Added a $wp_error parameter to wp_insert_attachment() (#37813)
    • Fix Drag/Drop Ordering of Media in Chrome on touch enabled devices (#31652)
    • Avoid undefined offset notice in wp_prepare_attachment_for_js() when image_downsize filter in used in (#34437).
    • Improve docs for image_send_to_editor filter (#34823).
    • Use wp_get_attachment_metadata() instead of get_post_meta() where appropriate (#36246).
    • Ensure wp_get_attachment_link() output text for non-images (#37343).
    • Avoid undefined index notices when pathinfo() is used (#37608).
    • Improve alignment of inputs and button heights in media edit screens (#37806).
    • Set focus when closing the media modal (#38142).
     
  • Mike Schroder 6:12 pm on November 15, 2016 Permalink |
    Tags: , , media   

    Enhanced PDF Support in WordPress 4.7 

    WordPress 4.7 makes it easier to preview PDFs in the media library by generating image representations of the first page, which are now used throughout the media library and media attachment screens.

    If a WP_Image_Editor is available that supports PDF, the following sizes are generated:

    • Full size representation, rendered at 128dpi.
    • Thumbnail (without cropping)
    • Medium
    • Large

    The sizes generated can be modified, or the feature disabled entirely via the new fallback_intermediate_image_sizes filter, and are all stored in the sizes array in attachment meta.

    The preview images generated are used within the Media screen, Gallery, Attachment Details, and on the Attachment page for PDFs.

    Core support is provided through WP_Image_Editor_Imagick and requires Imagick, ImageMagick, and Ghostscript support. When not supported, or if the generation fails, WordPress falls back to previous behavior and saves the attachment without adding image previews to meta.

    For more context, see #31050 for the primary ticket and #38594 for the filter.

    Updated:

    Since this change requires having Imagick load only the first page of a PDF for performance reasons, this means that if you rely on core loading the entire PDF for your extension of WP_Image_Editor_Imagick, this will no longer function as expected (See: #38832).

    As a result, in [39303], the PDF setup code was moved to WP_Image_Editor_Imagick->pdf_setup(), which can be overridden to restore the previous behavior if needed.

     
    • yanai101 9:09 pm on November 15, 2016 Permalink | Log in to Reply

      WOW !!!

    • FolioVision 5:56 am on November 16, 2016 Permalink | Log in to Reply

      This is exactly the small but deft improvements WordPress.org core should be making to what is mature software now. Thank you very much Mike!

    • Julien 6:48 am on November 16, 2016 Permalink | Log in to Reply

      This is great news :))

    • Sergey Mochalov 1:27 pm on November 16, 2016 Permalink | Log in to Reply

      I waited this for the long time. thank you guys.

    • Tom Ryan 4:39 pm on November 16, 2016 Permalink | Log in to Reply

      Cool! Can the preview be used on a front end page too? Would love to have full (all pages) PDF preview and download capability.which can be inserted into posts.

      • Joe McGill 6:18 pm on November 16, 2016 Permalink | Log in to Reply

        They sure can, Tom. To do so, you would retrieve them just like you would an image asset, passing the ID and image size you want to generate to wp_get_attachment_image().

    • tristanfaganguimond 9:18 am on November 23, 2016 Permalink | Log in to Reply

      Excellent

    • Bjarne 5:04 pm on November 25, 2016 Permalink | Log in to Reply

      That’s a great improvement! Two questions?
      1) Is it possible to generate thumbs of existing PDF’s or is this for new uploads only?
      2) Is it possible to use the thumbnails when inserting media into a post, or via a gallery? In my tests, its still a text only link to the attachment page (which then shows the thumbnail). Without further coding that is… I’m testing on the Twenty Seventeen theme…

      /Bjarne

    • leemon 11:10 am on November 27, 2016 Permalink | Log in to Reply

      I don’t know if this has to do with this new PDF feature, but since upgrading to 4.7RC when I upload an image smaller than the smallest size set in the media settings, no thumbnail is shown in the media library/media uploader, the plain document icon is shown instead.

    • Knut Sparhell 4:56 pm on November 27, 2016 Permalink | Log in to Reply

      I always get the medium sized preview on the attachment page. Expected?

      What is the purpose of selecting size before inserting to the post, when only a text link appears in the post?

  • Joe McGill 5:40 pm on November 11, 2016 Permalink |
    Tags: , , , media   

    Improving accessibility of image alternative text in 4.7 

    WordPress 4.7 includes a change to the way image alt attribute values are generated. Formerly, any time WordPress created the markup for an image with an empty alt value, it would attempt to use either the caption text or the image title—in that order—as a fallback value.

    In 4.7, we have removed this fallback behavior.

    To ensure your images having meaningful alternative text, you should make sure to set a value for alt text in your media library.

    How removing fallbacks improves accessibility

    The intent of the fallbacks were to ensure each image included alternative text. In practice however, this fallback behavior often resulted in poor user experiences for people using screen readers. As counterintuitive as that may seem, let’s take a look at some common examples.

    Consider a situation where we’ve uploaded an image named “edbc4ef7.jpg” without changing any additional information. WordPress will generate the image title from the file name as shown in the following screenshot of the insert media modal.

    Attachment details for an image shown in the insert media modal.

    Formerly, inserting this image in a post would result in HTML similar to this (simplified slightly for clarity):

    <img src="https://example.wordpress.org/wp-content/uploads/2016/11/edbc4ef7-1024x683.jpg" alt="edbc4ef7" width="700" height="467" />
    

    A person using a screenreader on this page would end up hearing the file name read to them, which is not the most helpful experience, and can be quite frustrating when the file name is lengthy.

    For another example, setting a caption value but no alternative text would result in markup that looks something like this:

    <figure id="attachment_1741" style="width: 660px" class="wp-caption alignright">
        <img src="https://example.wordpress.org/wp-content/uploads/2016/11/edbc4ef7-1024x683.jpeg" alt="This is a caption." width="660" height="440">
        <figcaption class="wp-caption-text">This is a caption.</figcaption>
    </figure>
    

    Notice that the alt value and the figcaption text are redundant? WebAIM describes two ways of presenting alternative text:

    • Within the alt attribute of the img element.
    • Within the context or surroundings of the image itself.

    The same article goes on to explain that an alt attribute value may be omitted when an identical figcaption is present, to avoid redundancy; but best practice when using a figcaption is to provide a separate and different alt attribute to describe that image to users of screen readers.

    In each case, omitting the alt attribute entirely may result in screen readers reading the file name from the src attribute, so WordPress includes an alt attribute with an empty value, i.e. alt="", whenever the alternative text hasn’t been explicitly set—a technique that is common when an image is decorative.

    This change will not affect content already published, but will be the expected behavior for any new content published after upgrading to 4.7. For more background on this issue, see ticket #34635.

     
    • Carrie Dils 9:52 pm on November 11, 2016 Permalink | Log in to Reply

      +1

    • bahia0019 7:48 am on November 12, 2016 Permalink | Log in to Reply

      One thing to bear in mind is that while WebAIM will take either figcaption or alt, search engines haven’t declared the figcaption as a identifier in image search, whereas the alt tag is still in play with Google, et al.

      So, the alt should definitely not be pulled from image file name, but if a caption is filled out, it may be redundant for WebAIM, but it’s not redundant everywhere.

      • Joe McGill 2:51 am on November 13, 2016 Permalink | Log in to Reply

        Thanks for bringing that up @bahia0019. According to Google’s image publishing guidelines, they take several factors into account, including the file name and context around the image, including captions and titles. So it would appear that captions are indeed read by Google.

        Also, to be clear, if you define an alt attribute along with a caption for your images, WordPress will still display both. What has changed is that formerly, including a caption and omitting an alt value would result in the alt attribute duplicating the text that was in your caption.

    • FolioVision 7:21 pm on November 15, 2016 Permalink | Log in to Reply

      Hi Joe,

      Bahia’s quite right in making a difference between what Google says and what Google does.

      One shouldn’t take Google’s guidelines to heart. We coded lots of schema.org into a recipe plugin following Google’s guidelines, passing Google’s structured data tests. That markup was ignored for years, while an older form of microdata actually worked.

      For SEO, we should still be duplicating caption data to alt. It would be even more helpful to include an option to include file names at alt (for those who do use explicit file names), with the option turned off by default as most publishers these days are too lazy and amateur to name their media accurately.

      • Joe McGill 11:07 pm on November 15, 2016 Permalink | Log in to Reply

        Hi @FolioVision,

        Thanks for sharing your experience. I agree that anticipating how Google will actually parse markup in their algorithms is fairly opaque.

        In this case, the changes we have made do nothing to inhibit people from crafting `alt` attributes in ways that optimize how Google ranks their content, if they so choose. At the same time, we are making the experience better for actual users in the process.

        I think the benefits outweigh the downsides for publishers who aren’t taking the time to include good `alt` values with their images.

    • Aaron Jorbin 10:06 pm on November 15, 2016 Permalink | Log in to Reply

      WordPress should always choose the experience that humans have when interacting with a site over an attempt at better search rankings.

      This is a great change. Thanks to all the people who helped make it happen.

    • Chuck Reynolds 9:23 pm on November 16, 2016 Permalink | Log in to Reply

      👍

    • blepharisma 8:55 pm on November 21, 2016 Permalink | Log in to Reply

      I think this is just Step #1 — Step #2 would be to prompt the user to enter ALT text when the field is left blank.

      I know that the regulations differ in different countries, but in many is is becoming law that public and private business meet certain accessibility standards. Having the ALT text present is in the first level, and a prompt would go a long way to training content creators to automatically include this very important information.

      In similar implementations, a check box is present if the image is decorative.

  • Joe McGill 9:36 pm on October 19, 2016 Permalink |
    Tags: , media   

    Media Weekly Update (Oct 14) 

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

    Summary from last week

    The last meeting was Friday, October 14 at 17:00 UTC. You can read the entire chat log in the #core-media channel on Slack.

    Attendees: @mikeschroder, @karmatosed@adamsilverstein@paaljoachim, @mapk, @flixos90, and @azaozz.

    • Media organization improvements:
      • Last week, we chatted about starting up design for Media organization improvements. @paaljoachim and @flixos90 started sketching flows in GitHub.
      • @karmatosed mentioned focussing on documenting the current flows this week.
    • Add new core media widget (#32417) – No progress was made this week and it’s now too late for 4.7, but work should continue so it’s ready for a future release.
    • Rotate Full Size Images on Upload (#14459) – @mikeschroder planned to do additional profiling re: complete resize+rotate times for upload vs editing.
    • Better PDF Upload Management (#31050) – @mikeschroder is putting more attention on trying to get this in this release after chatting with @helen.
    • Drag/Drop Ordering of Media Does Not Work in Chrome on touch enabled devices (#31652) – @adamsilverstein noted that the patch to enable sortable on touch devices was ready to commit, which was handled in [38793] this week. Additional discussion about reducing reliance on `wp_is_mobile()` is happening on #33704.
    • Accents in attachment filenames should be sanitized (#22363) – @gitlost has been working on updates for this ticket, which is now closely related to fixing #24661 (`remove_accents()` is not removing combining accents”).
    • Usage of `image_size_names_choose` breaks JS attachment model attributes (#34981)@azaozz suggests using srcset in the media library to make sure full size images aren’t used if a smaller image is available (as described in the ticket description).
    • Responsive images (srcset) can include images larger than the full size (#36477) – The latest patch, which utilized `Imagick::getImageColors` adds a significant performance concerns. @mikeschroder punted this out of the current milestone for now.

    Agenda for the next meeting

    This week, discussion will continue on 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-media channel.

     
  • Mike Schroder 6:26 am on October 12, 2016 Permalink |
    Tags: , , media   

    Media Weekly Update (Oct 7) 

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

    Summary from last week

    The last meeting was Friday, October 7 at 17:00 UTC. You can read the entire chat log in the #core-images channel on Slack.

    Attendees: @karmatosed, @joemcgill, @mikeschroder, @swissspidy, @flixos90, @desrosj, @azaozz, @paaljoachim, @markoheijnen, @adamsilverstein, @jorbin, @designsimply

    • Media organization improvements:
      • @joemcgill opened up conversation about a feature project to start work on this, explaining that we have the chance to take a UI/UX first approach.
      • @karmatosed is going to head up the UI/UX side of things.
      • @joemcgill thinks the likely first step is exploration of base taxonomy support, and a review on how it is currently broken with media.
      • @karmatosed asked all those interested in working on this to create sketches of their ideal media categorization flow for review by next week.
    • Add new core media widget (#32417)@joemcgill noted that the runway for 4.7 is ending, but work can continue for a future release. @designsimply to refresh the current patch on the ticket by Monday (October 10), and may target images specifically as a first step (this is still missing a refreshed patch).
    • Rotate Full Size Images on Upload (#14459)@mikeschroder profiled this and found that while the clock time for checking and setting orientation is minimal, it took ~230ms for an iPhone 7-sized image to be rotated (total 5.6s resize time) on a shared test server. He thinks total resize time should be reduced before this is added, and that #37140 is a better step for 4.7. After discussion with @markoheijnen and @azaozz, consensus seems to be that benchmarking of upload vs manual rotation should be done to prove the UX case for #37140 over #14459.
    • Accents in attachment filenames should be sanitized (#22363)@joemcgill pointed out the new patch here from @gitlost, which looks promising. @swissspidy to take a look over the weekend (feedback is on ticket now, but could use more eyes).
    • Better PDF Upload Management (#31050) – Everyone likes this, but time running out for 4.6. @markoheijnen to target next patch by Wednesday (Oct 12) (this was moved out of the milestone, as it’s currently missing a refreshed patch).
    • Responsive images (srcset) can include images larger than the full size (#36477)@mikeschroder didn’t have time to performance test the patch. To do so shortly and post feedback on the ticket (feedback is on ticket now).

    Agenda for the next meeting

    This week, discussion will continue on 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.

    Edit: Updated post per status on Wednesday, Oct 12.

     
  • Mike Schroder 10:51 pm on October 3, 2016 Permalink |
    Tags: , , media   

    Media Weekly Update (Sept 30) 

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

    Summary from last week

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

    Attendees: @joemcgill, @mikeschroder, @swissspidy, @flixos90, @azaozz

    • Unexpected change to media title behavior in WP 4.6.1 (#37989)@joemcgill noted that @sergey found a fix for the remaining UTF-8 issues and it has been committed to trunk, but needs to be backported still. @joemcgill working on getting this done. Test please!
    • Downscale to only smaller images with srcset (#36477) – It looks like a true fix is not likely to land in 4.7, since this would have likely been part of changing the way WordPress handles full size images. @mikeschroder and @joemcgill to test the current patch for performance and SSIM.
    • Better PDF thumbnails (#31050)@markoheijnen was not able to attend, but previously noted that he is continuing work on this for a week or two to try to make 4.7.
    • WordPress image’s title is not alt (#34635)@joemcgill chatted with the Accessibility team about this, and the suggestion is that WordPress should no longer guess at an appropriate alt if the user hasn’t explicitly added one. He notes that this shouldn’t be that difficult to patch, but the change will need to be well communicated.
    • image_send_to_editor filter is not fired when an Image is edited or replaced in TinyMCE (#34823) – Based on @adamsilverstein‘s feedback, it looks like the ticket should be closed, as there’s a different filter intended for this purpose.
    • Usage of image_size_names_choose breaks JS attachment model attributes (#34981) – Chatted about a bit of background. @azaozz took a look and posted a new patch for review.
    • Sanitize accents in attachment filenames (#22363) – From @gitlost’s comments, it looks like there are fixes in remove_accents() necessary that should happen first, and would likely fix the base bug here. His work on it is mostly in #24661. @mikeschroder to dig into the progress of Safari’s support of these filenames. Feedback from those who have strong knowledge in UTF/character encodings would be appreciated.
    • Rotate Full Size Images on Upload (#14459 and #37140) – Would rather not destroy EXIF/IPTC in full size images (with GD), so may be better to fix this in Imagick first. Needs performance testing. Comment left on ticket.
    • Add new core media widget (#32417) – No updates here. May not be 4.7 at this point, but @joemcgill reaching out to @designsimply for status.
    • Media organization improvements:
      • Make media library searchable by filename (#22744) – @joemcgill added a patch to fix a JOIN issue found by @flixos90. Please continue testing this, especially with large media libraries.
      • @flixos90 opened a GitHub repo to work on media taxonomies/UI, and is organizing a feature project around it. @joemcgill suggests an initial meeting with @karmatosed for high level direction, followed by changes in the plugin, or core directly where appropriate.

    Agenda for the next meeting

    This week, discussion will continue on 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.

     
    • simonrcodrington 10:44 am on October 4, 2016 Permalink | Log in to Reply

      Hey there Mike. Thanks for the update.

      I usually can’t make it to the slack meetings (they end up being really early where I am), but I’ve been meaning to push forward my ticket for inclusion into core: https://core.trac.wordpress.org/ticket/37535

      Basically, when you register a post type you can include the `description`. That description is never used anywhere by default. My idea was to output it right at the top of the post type listing admin page (where all your posts are displayed). The usefulness would be the description would be displayed in a practical place, with very few changes required.

      I’d be pretty keen to discuss this / put forward a pull request with how it would all work.

      Thanks.

  • 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.

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