Make WordPress Core

Tagged: media Toggle Comment Threads | Keyboard Shortcuts

  • 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;
      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…)


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

  • Ella Iseulde Van Dorpe 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. 🙂

  • Joe McGill 3:46 pm on March 12, 2016 Permalink
    Tags: , , , media, ,   

    Performance improvements for images in WordPress 4.5 

    WordPress 4.5 includes a few performance enhancements for images.

    Increased image compression for custom sizes

    WordPress 4.5 increases the amount of compression applied to intermediate sizes by changing the default quality in WP_Image_Editor from 90 to 82. As noted in the proposal for this change, this results in a noticeable reduction in file sizes with little change in visual quality. Developers can override the default image quality value using the wp_editor_set_quality filter.

    Improved resizing settings for ImageMagick

    For sites making use of ImageMagick, we’ve reduced file sizes further by resizing images  more efficiently in WP_Image_Editor_Imagick and by stripping extraneous metadata using the new WP_Image_Editor_Imagick::strip_image() method.

    For now, ‘icc’ and ‘icm’ color profiles are retained, along with ‘exif’, ‘xmp’, and ‘iptc’ profiles, which can contain copyright and orientation data. Those who want to retain additional metadata can disable profile stripping by adding a callback function to the image_strip_meta hook that returns false.

    Note that the original full sized images uploaded to WordPress are unaffected by these changes.

    Introduction of wp_get_upload_dir()

    As Jeremy Felt mentioned in his post on Multisite changes, wp_upload_dir() received a major performance overhaul in this release. Those changes were pared with the addition of a new function, wp_get_upload_dir(), which can be used as a more performant way to display information about the uploads directory on the front end. This is particularly useful when building URLs for images in templates. (See #34359)

    • petermolnar 5:56 pm on March 12, 2016 Permalink | Log in to Reply

      I don’t welcome the default EXIF stripping. It’s not optimization, it’s removing information from a picture.

      • Joe McGill 6:43 pm on March 12, 2016 Permalink | Log in to Reply

        Hi Peter,

        Thanks for your comment. To be clear, Exif data is not being stripped by default at this time. Please reread the section about metadata stripping, which lists all the profiles that are retained. Sorry if that was unclear.

    • petermolnar 5:58 pm on March 12, 2016 Permalink | Log in to Reply

      • Destac 6:07 am on March 13, 2016 Permalink | Log in to Reply

        You should again reread that link the images are not having the data stripped but the resizing doesn’t carry the exif data over.

        WordPress strips EXIF data from the auto-resized versions of the images as a side effect. What it’s actually doing is creating new images from the original, and not copying that data.

        However, the original image is saved as-is, with all EXIF information included. The original image is not modified in any way.

        • Marko Heijnen 3:10 pm on March 14, 2016 Permalink | Log in to Reply

          That’s copy/pasting from the topic. I’m sure Peter can read. His first statement is still correct since WordPress by default with Imagick will strip information from a picture. Not the EXIF information but other related information.

          For GD I have played a bit to see what options we have and the only workable option is storing EXIF data as IPTC.

          • Destac 1:06 pm on March 15, 2016 Permalink | Log in to Reply

            Not true. His original statement says.

            I don’t welcome the default EXIF stripping. It’s not optimization, it’s removing information from a picture.

            So my statement as was Joe’s were still correct.

            On this separate matter i don’t see the value of this information vs stripping it which is recommended for

        • petermolnar 11:21 am on March 31, 2016 Permalink | Log in to Reply

          resizing does carry EXIF over. GD used to strip it, imagick does not.

    • Kochhase 2:10 pm on March 15, 2016 Permalink | Log in to Reply

      hello, “along with ‘exif’, ‘xmp’, and ‘iptc’ profiles, which can contain copyright and orientation data”. in germany the there is a § for that. http://dejure.org/gesetze/UrhG/95c.html. so wordpress does not authorized to remove this information.

    • FolioVision 10:34 pm on March 28, 2016 Permalink | Log in to Reply

      This is great work Joe. Wonderful to have better core support of ImageMagick (IM really does make a huge difference in quality). Any chance we could get a Setting screen in the backend to handle the Media Library and these settings. Making them command line only seems pretty user unfriendly. Even if one has to flick a switch to make them available (i.e. add Advanced Media Settings checkbox somewhere visible by default).

      Alec Kinnear

      • Joe McGill 11:59 am on March 31, 2016 Permalink | Log in to Reply

        Thanks Alec,

        While we aren’t planning to add a screen to control specific ImageMagick settings in core, I think it would be a wonderful plugin for those who are interesting in controlling the fine details.


    • Bayu Angora 11:40 pm on April 13, 2016 Permalink | Log in to Reply

      So, we don’t need image compress plugin anymore?

      • Joe McGill 1:19 am on April 14, 2016 Permalink | Log in to Reply

        It’s likely that you still might get some benefit out of some compression plugins, but it shouldn’t be nearly as dramatic as it was before. Best thing to do is to evaluate the difference you’re seeing in quality and performance between WordPress defaults and what your compression plugin gives you and decide if it’s worth continuing to use a compression plugin in your particular use case.

    • ninjaunmatched 5:09 pm on April 15, 2016 Permalink | Log in to Reply

      Will the new compression be applied to existing images or only new uploads?

    • nekroido 8:28 pm on April 20, 2016 Permalink | Log in to Reply

      Are you planning on enhancing the resizer with focal points support? The feature is quite vital for custom themes and support for mobile apps.

    • Simon Pollard 3:39 pm on May 11, 2016 Permalink | Log in to Reply

      Apologies if this is a silly question – if a user uploads an image that is 1024 x 768 and I have a custom thumbnail size that is 1024 x 768 that I use in my code and request that version of the thumbnail. Will the image I get back be the original uncompressed image, or will I get an optimised one? If it is the original do I need to ask my user to upload images 1025 x 768 to enforce a compression? Hope that makes sense.

      • Simon Pollard 8:07 am on May 12, 2016 Permalink | Log in to Reply

        So it appears if the size of an image matches the size of a specified image size by add_image_size() it does not get created and thus not optimised. If I make the image 1px larger it will then create an optimised version. Is there any way to enforce optimisation on all images or enforce the creation of an optimised image size version?

    • Mikel King 3:48 pm on May 18, 2016 Permalink | Log in to Reply

      Is there a guide somewhere that explains how this works from the content creation to hydration process?

  • Mike Schroder 10:22 am on February 24, 2016 Permalink
    Tags: , , media   

    Theme Logo Support 

    Note: This proposal was merged to core in [36698]. Download the latest nightly build and give it a try!

    It’s been proposed that we add Theme Logo Support to core for 4.5. This would allow themes to declare support for a logo, which would be customizable via … the customizer! Let’s walk through some background, and how this would work.


    Theme Logo Support was kindly ported over to core from Jetpack’s “Site Logo” feature by sir @obenland on #33755, with much assistance from others in getting it core-ready ( :D ).

    In core, it’d be a theme mod enabled via add_theme_support( 'site-logo', size ), rather than storing the logo persistently across themes. This is for a few reasons:

    • Customizer controls should only be visible when a feature is supported by the theme.
    • Prevent plugins from using a “global” logo when the Customizer controls may not be visible
    • Prevent poor display of logos that looked good on one theme, but whose size is not appropriate for another theme’s declared size.

    The plan would be to ship a new version of Twenty Sixteen (thanks @karmatosed, @iamtakashi!) that supports this feature along with 4.5, as an example to other themes for implementation.

    This would allow a common theme feature, logos, to have a common implementation provided by core and available in a consistent location for users.

    There were user tests performed by @karmatosed, on make/flow, which showed confusion with customizer discoverability, but were generally positive in users being able to tell the difference between the Logo feature and a Site Icon.

    @boren also has a running set of flow screenshots that you can look through, with the newest ones on iPhone, and the screenshot above reflecting the most recent patch.

    To test this, apply the most recent patch on #33755, and install the Twenty Sixteen theme found in the site-logo branch.

    Let me know what you think!

    • dantewaters 10:38 am on February 24, 2016 Permalink | Log in to Reply

      This is a great implementation I 2nd this!

    • jameskoster 10:52 am on February 24, 2016 Permalink | Log in to Reply

      Yes please 🙂

    • HoaSi 11:19 am on February 24, 2016 Permalink | Log in to Reply

      Great move.

    • David Gwyer 11:59 am on February 24, 2016 Permalink | Log in to Reply

      Great idea!

      In my themes I provide logo support (via the customizer) for the site logo AND the login screen as it’s a popular request to be able to display a separate logo for the login screen.

      Would this additional feature be worth considering whilst implementation is still at an early stage?

    • sinan isler 12:40 pm on February 24, 2016 Permalink | Log in to Reply

      yes good idea

    • Chip Bennett 12:40 pm on February 24, 2016 Permalink | Log in to Reply

      Emphatically: yes! Much needed. This will end the need for the understandable, but unfortunate, use of the custom header image as a “logo”.

    • wpgaijin 1:34 pm on February 24, 2016 Permalink | Log in to Reply

      How would this handle SVG with retina and non-retina fallbacks? It’s a noble idea, but I don’t think this would work with modern web design patterns unless you provide SVG/fallback support.

    • Mark Howells-Mead 2:17 pm on February 24, 2016 Permalink | Log in to Reply


    • leemon 3:48 pm on February 24, 2016 Permalink | Log in to Reply

      At last!

    • Pauthake015 5:06 pm on February 24, 2016 Permalink | Log in to Reply

      +1. Love it ! Can’t wait!

    • Emil Uzelac 7:14 pm on February 24, 2016 Permalink | Log in to Reply

      Heck yeah!

    • Brad Griffin 7:20 pm on February 24, 2016 Permalink | Log in to Reply

      Well done @obenland :dang it wheres the hand clap emoji:

      Bravo Zulu to the 4.5 team! https://en.wikipedia.org/wiki/Bravo_Zulu

    • Helen Hou-Sandi 7:50 pm on February 24, 2016 Permalink | Log in to Reply

      To start, I think this is a valuable feature to have and am more than happy to support work on it, whether it makes 4.5 or not. Here are questions that occur to me:

      • Is there a defined intent for how this is used by themes? Is this intent permanent(-ish) or first-run?
      • With the premise that this is worth bringing into core because it is an exceedingly common task for users (particularly of the sort that use the customizer) and its existing widespread usage in themes, are we just moving the goalposts for theme standardization? That is, what kinds of things are themes still going to roll themselves? For instance, Twenty Fifteen’s most likely logo space is very different between two column/desktop and one column/mobile view. Is this going to default to poor default results for people? Are we just going to end up with a proliferation of ever-more-creative custom controls?
      • Bigger picture question (decision making does not hinge on this): does it feel like the “Site Identity” section holistically makes sense? If a list was made today of what would go in there without consideration for what exists, do we have too much, are we missing things, or are we doing well?
    • Morten Rand-Hendriksen 8:02 pm on February 24, 2016 Permalink | Log in to Reply

      I second all of Helen’s questions above, and would like to add these comments:

      • For this to be added to the Customizer UI, great emphasis must be put on differentiation between Site Icon and Site Logo to ensure end-users understand what they are and how they work.
      • Site Logo sizes and proportions would ideally need to be pre-defined (ie. “must be square” or similar) to provide a consistent experience across themes, especially when a site owner changes themes. Otherwise this feature could become a pain point for users.
    • Ahmad Awais 10:13 pm on February 24, 2016 Permalink | Log in to Reply

      I think it would be a great feature. I second what Helen and Morten asked above except for the pre-defined part of logo dimensions. I think the site logo feature must allow the theme authors to define an image size which is for the Site Logo size only (in an ideal world it would automatically be prompted inside the customizer to the user i.e. Add 250px x 150px logo to the theme) but pre-defining its dimension or even proportion could be a very bad idea. I say this as someone who has been designing logos and themes for last 8 years or so.

      — Some themes make use of the same logo in several places E.g. in the header (of course) in the footer (which in most cases is the smaller/larger version of the same logo) how do you think we can help theme authors with this?

      — Some themes make use of the same logo’s light and dark versions, what about that? (Just a random concern)

      That said, I support this one and am willing to contribute where I can.

      • Hardeep Asrani 2:19 pm on February 26, 2016 Permalink | Log in to Reply

        Regarding dark & light versions, it’s more of what a theme author wants to do. Giving a logo is more of a general feature. But yes, the size point is something that I’m also concerned about. 🙂

    • Tran Ngoc Tuan Anh 6:57 am on February 25, 2016 Permalink | Log in to Reply

      Love this feature. I have a question: will theme are able to define logo sizes?

    • David Gwyer 6:13 pm on February 26, 2016 Permalink | Log in to Reply

      Will it be possible to filter the URL the logo links to, or even control if it links to anything at all? I’ve had requests before to link the logo to a URL other than the homepage.

    • pansotdev 9:23 pm on February 26, 2016 Permalink | Log in to Reply

      Love it! Great work!

    • sidati 5:45 pm on March 4, 2016 Permalink | Log in to Reply

      @mikeschroder, Dont forgot to mention these related functions :


      and thank you for this great implementation 🙂

    • Zach Stepek 3:34 pm on March 7, 2016 Permalink | Log in to Reply

      To ease some of the confusion between Site Logo and Site Icon, would it make sense to add some simple descriptive text to each field? Site Logo: Displays a custom logo on your website. Site Icon: Displays a custom favicon or home screen icon. (cross-posting to the user testing post)

    • Caleb Evans 8:28 pm on April 10, 2016 Permalink | Log in to Reply

      @mikeschroder: I understand how Theme Logos differ from Site Icons; to me, that distinction is intuitive and quite clear. However, I do not understand how a Theme Logo is any different from a Header Image. Do they serve different purposes? How do you draw the distinction? And what will become of header images with the addition of theme logos? This glaring ambiguity is my only major gripe about WP 4.5, so I’d greatly appreciate any insight you can offer. 🙂


    • dtbaker 2:49 am on April 13, 2016 Permalink | Log in to Reply

      Hey guys, codex says it’s `custom-logo` https://codex.wordpress.org/Theme_Logo but this page and a bunch of other blog posts say it is `site-logo`

      Something change?

    • Karl Lettenström 12:07 pm on April 20, 2016 Permalink | Log in to Reply

      custom-logo it is, just FYI. 🙂

  • Joe McGill 12:51 pm on February 22, 2016 Permalink
    Tags: , , media,   

    Proposal: Increase the default image compression in WordPress 

    Note: This proposal was merged to core in [36615]. Download the latest nightly build and give it a try!

    In order to improve page load performance, I propose that the default image compression setting be changed from 90 to 82 in WordPress. Let’s get into why.


    The default quality setting for resized images in WordPress has been 90 since the image_resize() function was shipped in version 2.5. This setting creates images with much larger file sizes than recommended by modern web best practices.

    Over the past several years, the importance of performance has been highlighted as users access the web globally on slower connections, and performance has even started being used by search engines to influence search results.

    Tools like Google PageSpeed Insights and WebPagetest will warn site owners if images aren’t sufficiently compressed. For example, the glossary at the bottom of the WebPagetest performance optimization page states:

    Within 10% of a photoshop quality 50 will pass, up to 50% larger will warn and anything larger than that will fail. The overall score is the percentage of image bytes that can be saved by re-compressing the images.


    With this in mind, web developer and performance advocate Dave Newton published recommendations for ImageMagick compression settings based on his research comparing various ImageMagick settings against Photoshop’s ‘high quality’ (60) setting for JPEGs. He found that an Imagick compression setting of 82 was closest to this using an objective measurement named DSSIM to compare the visual similarity between two images.

    We experimented with Dave’s settings in the RICG Responsive Images plugin during the 4.3 cycle and found that not all Dave’s suggestions can be easily applied by default in WordPress due to the memory required to process large images on shared hosts. However, changing the default image quality setting is a relatively small change that makes a big impact on file size without sacrificing much in the way of perceived image quality.

    In research released in 2014, compressed images with a DSSIM score of 0.015 were deemed acceptable to most people. In tests of several different images, I found that changing the default compression setting in WP_Image_Editor from 90 to 82 reduced image sizes by an average of ~25% with DSSIM scores ranging from 0.0014 to 0.0019 for ImageMagick and 0.0019 to 0.0023 for GD — both of which are drastically under the 0.015 threshold cited above.


    Given these results, I suggest making the change to 82 for the default image compression setting. You can follow the discussion on the related ticket (33642) and give feedback in the comments or in the #core-images channel on Slack.

    As a reminder, this setting only applies to the intermediate sizes that WordPress creates, and not the original files uploaded by users. For any users who need to maintain a higher image quality for intermediate sizes, the default quality can still be changed with the wp_editor_set_quality filter.

    • leehodson 1:26 pm on February 22, 2016 Permalink | Log in to Reply

      How about setting the default to 82 and providing an easy way for site admins to adjust the setting from within the upload screen at the time of upload and for site admins to set a default compression value in Settings > Media.

      Many site admins, editors and authors are unaware that images are compressed on upload and so few (even among developers) are aware of the wp_editor_set_quality filter; makes sense to provide a user friendly way for the quality setting to be adjusted both at time of upload and from within the media settings screen. I’d even go as far as to let those with media upload permission to rebuild their uploaded images from within the media library.

      What’s the general feeling toward this idea?

      • Eric Andrew Lewis 2:14 pm on February 22, 2016 Permalink | Log in to Reply

        I don’t think the typical end-user needs to worry about image compression levels.

        • leehodson 2:32 pm on February 22, 2016 Permalink | Log in to Reply

          They do when they can’t figure out why their beautiful high quality images of special events look fuzzy on their iPads when viewed within their websites.

          Really isn’t for us as web developers to tell people what they do and don’t need to worry about; it is for us to make it easy for people to control their websites. One extra slider in the media uploader won’t be huge distraction to authors but will make life easier for them and for site admins.

          • Samuel Wood (Otto) 4:18 pm on February 22, 2016 Permalink | Log in to Reply

            Really isn’t for us as web developers to tell people what they do and don’t need to worry about

            Actually, it is. That’s exactly your job. You don’t tell your mechanic the best way to fix your car, you don’t tell your plumber the best way to plumb. And you don’t tell your web developer the best way to develop for the web.

            “It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.” – https://wordpress.org/about/philosophy/

            • Jon Brown 4:56 pm on February 22, 2016 Permalink

              I don’t think anyone would suggest exposing the technical details to users.

              Images and image quality are deeply personal things for many bloggers and site owners though and ignoring those desires isn’t serving our users.

              IMHO, we should have always had an option for image quality vs speed, something like

              Image quality settings could be:
              [ ] High (Minimal compression/large file size, 90 old default)
              [ ] Medium (Optimized Compression/small file size, 82 new default)

              • Neither setting affects your originally uploaded image. Changing the setting will only affect newly generated thumbnails.

              Photographers could set things to “high”, everyone else would stop generating poorly compressed thumbnails.

              I find users are very strongly bipolar on this. Either they’re photo focus and want “100% quality JPEGs” or they’re speed focused and want “A’s on all the speed test suites”. Of course the first group actually wants both, but one can explain, or at least try, to explain why those are mutually exclusive options.

            • Ihor Vorotnov 5:14 pm on February 22, 2016 Permalink

              I totally agree that it’s our job develop properly. But WordPress is used by many non-devs, without dev assistance/hiring. It this case, a UI for setting this option would make sense. IMHO, it should be:

              • default option value is 82
              • a user can change this options in Settings – Media (simple input with instructional text would be sufficient)
              • a developer can override this value via `wp_editor_set_quality` filter
            • chrishoward 5:43 pm on February 22, 2016 Permalink

              There’s so many things in WP where we allow the user to make their own choice.

              The breadth of WP users goes well beyond those reliant on other developers. Many, many, many, many WP sites are one person shops, so the user is also the admin.

              They have to set things like permalinks, home page type (blog/static), use the theme customizer, post format types, widgets, menus, categories, tags, etc.

              People have had quality setting on their digital cameras for 20 years. Likewise photo editing software.

              Poor user is sitting their trying to decide if his post is an “Aside” or a “Quote” or a “Status”… so seeing an image quality option would be like seeing old friend!

              An image quality setting is not going to scare anyone – esp if you put it in words. i.e. Max, high, medium, low.

              Adding an option for image quality is hardly “a weight of technical choices”.

              “It’s our duty as developers to not treat users as idiots – even if they are.”

              The only I’d do different to Lee is I’d only have a control for it in the Media Settings.

            • Jeremy Clarke 6:01 pm on February 22, 2016 Permalink

              FWIW you guys should focus on accepting the fact that there will not be an option for this, and definitely don’t allow yourselves to waste cycles on feeling bad about it. Decisions v. Options is an ancient debate in WP and this particular setting will NOT be the one that breaks the trend.

              Opine on what you think the default should be and accept that changing it will involve either 4 lines of code or installing a tiny plugin.

            • leehodson 6:24 pm on February 22, 2016 Permalink

              The web developer’s duty is to build the site and make it as easy as possible for the site owner or his/her designated admins to use it to create and publish contenet. Control of the site belongs to the site’s owner, not me; I’m the experienced developer, not the inexperienced site owner: make it easy to use the site.

              To use the plumber example, I’d tell the plumber what I want done and give instruction on how I’d like the end product to look e.g. fit the new sink in the corner but please make sure there is enough room for me to move my elbows without hitting the wall and try to hide the pipes as best you can without leaving any pipes sticking out for me to trip over. I’m the householder, not the plumber, but I know what I want and what I don’t want: what I want is the plumber to do the work and leave me with a way to turn on the taps without need to call in a plumber each time I need to wash my hands.

              In any case, this belongs in a different discussion.

            • leehodson 6:26 pm on February 22, 2016 Permalink

              Jeremy, who says this feature isn’t up for discussion? It obviously is up for discussion. We’re looking at changing the way WordPress handles media files and we, as end users and developers, are making a reasonable suggestion. The discussion is still open.

            • Jeremy Clarke 6:37 pm on February 22, 2016 Permalink

              leehodson: What’s up for discussion is changing the default compression level. That’s what the OP was about and that’s what this conversation could potentially change.

              Nowhere in the OP did anyone ask whether there should be a setting and the reason is there won’t be. I say this as a fellow traveler who has wasted too much energy fighting for my own pet settings, and as someone with no influence over core WP and nothing to gain other than reducing the overall community drama.

            • leehodson 6:51 pm on February 22, 2016 Permalink

              Thinking about it, there is another solution: could be added to Jetpack as part of the gallery or carousel module.

              The problem with not providing a visible override setting in core is that those with image rich sites who are unknowingly accustomed to an image compression value of 90 may suddenly find their displayed images look low-res when compressed at 82. That will catch many users unaware and I can already see the headlines slating WordPress for making the change without providing a visible method to manually adjust the setting that doesn’t require a plugin (which so many equate with the mantra ‘too many plugins are bad’) or that doesn’t require a single line of code (which many users don’t expect to be forced to use).

              Really wouldn’t like to see some developers charging WP users high fees for adjusting the compression setting. We all know some will.

              The idea of changing the default compression value to 82 or between 82 and 90 is good and is one I like but without an easy way to adjust the setting I can’t see the idea being welcomed by regular end users.

        • Mike Schroder 10:32 pm on February 22, 2016 Permalink | Log in to Reply

          Completely agree. This is one of the areas where “Decisions, not Options” is pretty clear. It’s up to us to do the research (as @dnewton, @joemcgill, and more have) and make a decision that’s good for the majority of sites. Plugins can (and do) modify this value or present a UI as they would like.

      • Jon Brown 4:40 pm on February 22, 2016 Permalink | Log in to Reply

        +1 on this proposal and +10 on Lee’s additional suggestions.

        The current setting is awful for users and we should make this better all around.

        Witness the plethora of cloud based images compression services and plugins that have sprung up to do little more than fix this fundamental design flaw in WP media management. Setting up SmushIt, Krakken, EWWW, etc should be completely unnecessary and it’s become de rigeur.

        Over the years I can’t begin to count the number of users frustrated by WP’s handling on images. Granted a huge number of those don’t understand compression, image size or color space, but the frustration stems from poor defaults without transparency (ie. making it clear what compression is happening, what sizes are being created and used) and zero control over any of it.

        • Jeremy Clarke 6:07 pm on February 22, 2016 Permalink | Log in to Reply

          Adding a setting for image compression will solve pretty much none of those problems, which IMHO are related to featured images and custom sizes (which have never been well-expressed in the UI despite being critically important to authoring workflows). Compression doesn’t confused people, it’s just something people want once they learn the benefits. Turning it on by default is the solution. Once WP has aggressive compression by default a lot of those plugins will fade away as users see the diminishing returns offered by them.

          Unlike custom image sizes, which are editorially relevant (like most of the other decisions highlighted by people in these comments as examples of settings) compression levels are not relevant to how you publish posts. No one NEEDS a different compression level no matter how much they might believe they do, whereas having a custom image size that works properly as a thumbnail in X part of your theme is mandatory.

          • leehodson 6:16 pm on February 22, 2016 Permalink | Log in to Reply

            I need it. Countless others say they need it. Where do you get the idea that no one needs it? Evidence suggests otherwise.

            • Jeremy Clarke 6:25 pm on February 22, 2016 Permalink

              I don’t think you can prove you “need” it. You want it and that’s fine, lots of people feel they want it, but your site will continue to function and display correctly without it (unlike a site with messed up Custom Image Sizes).

              Also for those who “need” it 4 lines of code or a tiny plugin is not an unreasonable step. If you really need it you can install a plugin, that’s how WP works.

              It would be so boring to make a list of options in WP that people actually need but aren’t supported by core (about as interesting as the lists above of settings that ARE in core). For now I’ll leave you with this: Despite WP having a powerful and elaborate capability/role system which can be customized infinitely, there are no options to control it anywhere in core. You can’t add roles or modify the capabilities of roles at all without a plugin. You are stuck with 4 crappy roles that barely cover common use-cases of multi-author sites. Pretty much any site with more than a dozen users will need a plugin like Members or Capability Manager. This is not a bug, it’s a decision made by core to protect users from the extra complexity.

            • leehodson 6:31 pm on February 22, 2016 Permalink

              Role management is a reasonable point. WordPress core presently allows admins to perform tasks that editors, authors and subscribers can’t perform. Is there a reason that same method can’t be employed to control access to a compression value setting in Media Settings or within the media uploader? I can’t think of one.

            • Jeremy Clarke 6:40 pm on February 22, 2016 Permalink

              >Is there a reason that same method can’t be employed to control access to a compression value setting in Media Settings or within the media uploader? I can’t think of one.

              Sorry you missed my point. I wasn’t saying that role/capability management somehow complicates the question of a setting for image compress, I was just pointing out that even role/capability management has no option visibility in core, despite being a huge, complex feature set in place under the hood.

              If such an important (security/workflow/community) feature doesn’t get admin options, you can see why options like image compression are left as “plugin territory” too.

            • leehodson 6:55 pm on February 22, 2016 Permalink

              I read it a bit fast, maybe. Thanks for clearing that up. I do see what you mean though I don’t see it the same way. Might do after an internal debate with myself.

    • chrishoward 1:37 pm on February 22, 2016 Permalink | Log in to Reply

      What Lee said!

      Some sites want minimum compression, wanting their images to look their best.

      Most folks though can’t even tell.

      Looking at that owl, I reckon you can set the default much lower, and then like Lee said, provide an override in the Media settings.

    • Mark-k 1:49 pm on February 22, 2016 Permalink | Log in to Reply

      This doesn’t sound like a real research. I am not objecting but to actually test the usefulness of this change you will need actually web page to test against.

      For small images 25% reduction will not be felt by the user as the bigger factor is the latency.. Big images are many time used as the original image so there will be no change there.

      As for saving money argument, lets call it BS. I get 10GB/mo for 8$ which I can’t even get close to utilizing. I know that israel in this regard is an outliner, but still the price for byte/mo on desktop is virtually 0 and mobile is rapidly getting there all over the world.

      Again, no objection if people can not see the difference, but not sure that a surprise reduction in quality will be welcomed by site owners that will be able to notice it. If implemented this feature should be active only on new installs.

      • Ihor Vorotnov 5:27 pm on February 22, 2016 Permalink | Log in to Reply

        > and mobile is rapidly getting there all over the world

        If you’re talking about mobile traffic cost, you’re soooo wrong. I live in Ukraine, Turkey and Montenegro. All mentioned countries aren’t technical outsiders. In fact, regular internet in Ukraine is much, much, much better then in US. I have unlimited 100Mbps cable for $5/m. However, we just got 3G in 2015, it’s available only in large cities and it’s expensive. Same applies to Russia and Belarus. In Turkey, regular networks are bad and slow, but they have great 3G even in mountain villages. But still, it’s pretty expensive. In Montenegro, regular network is fine (not that good as in Ukraine, but pretty good), 3G is fine but not cheap too. Same applies to many other european countries. So, mobile bandwidth isn’t even close to being cheap. And I’m not even talking about less developed countries. Check India, for example, or Thailand, other asian countries (except China, that’s a different beast). I don’t know how things are going in Latin America, but somehow I’m sure it’s not better. All mentioned countries/regions combined are at least half of the world. So, yes, your Israeli experience is rather an exception.

        • Jeremy Clarke 6:12 pm on February 22, 2016 Permalink | Log in to Reply

          +1 What we know for sure is that decreasing bandwidth requirements has a meaningful impact in all contexts and on mobile the impact is very important for MANY users all over the place for all kinds of reasons.

        • Mark-k 11:51 am on February 23, 2016 Permalink | Log in to Reply

          You don’t design features for today, you should design features for tomorrow when they will actually be used. Changing the default in 4.5 will have no impact on images generated before that and it will take a long time for this feature to generate more then half of wordpress hoisted images on the web. So if you think that anyone around the world will be able to save any money from the introduction of the feature then I think you are very wrong.

      • Drivingralle 3:33 am on February 23, 2016 Permalink | Log in to Reply

        @Mark-k: Happy for you that you can get cheap mobile data. But even in Germany 1GB/mo can cost you around € 10,-. The networks are quite good there but still no reason to send big images.

        Right now I’m in Asia and bandwidth is a big concern here. Volume is cheap, but a lot of sites take ages to load.

        The combination of srcset and an increased compression for intermediate sizes would be a win for both cases/locations.
        In general the weight of most websites is way to high. Images are the biggest part of it. Working on that is a a really important thing.

        • Mark-k 12:01 pm on February 23, 2016 Permalink | Log in to Reply

          srcset **increases** the sizes of the images being send, it is the opposite of this feature in terms of bandwidth performance. srcset increases the size by a factor of 4 for retina displays. shaving 25% off it will end you in an increase of a factor of 3. Maybe a faster and better way to improve image bandwidth performance is to have an option to disable srcset in core so people in “developing world” (whatever that is) can out of the box help their users save bandwidth.

    • dsthedev 2:26 pm on February 22, 2016 Permalink | Log in to Reply

      This is a great idea. I think some people are missing the point here. A mere 8% reduction in quality level can yield ~25% smaller image sizes across the board (minus original) with almost no visual difference? That sounds like it would be good for everyone. Especially since adding an option in media settings would be easy enough and allow for a little more customization.

      I think it makes even more sense if you combine it with the responsive images feature recently added. Improving performance with practically no downsides?

    • Benjamin Pick 3:11 pm on February 22, 2016 Permalink | Log in to Reply

      While I support this proposal, we need to make sure that site editors/admins (!) can find out why their images become blurry. That’s why I like the idea of a media setting – this makes it clear that there is some subjective judgement involved.

      (For example, we had a client that complained that the PNGs become blurry already at the 90%-Level. This was because the typical image was technical drawings or product images with text on it, so it feels blurry much earlier than with photos. I also think of the PDF thumbnails that might get merged into core – please test if 82% would be appropriate there as well.)

      • Jeremy Clarke 6:17 pm on February 22, 2016 Permalink | Log in to Reply

        Benjamin you’re our only hope! Can you go find those images and see how they perform at 90 v. 82?

        I suspect the difference will be invisible as in the test above, and that if they get “blurred” (certainly not a description of the test above) then 90 v. 82 won’t be the reason.

        Either way, at this point it’s up to whoever thinks 82 is to low to show examples.

        • Mark-k 12:09 pm on February 23, 2016 Permalink | Log in to Reply

          Why? it is always the people that want to change things that need to justify it. 90% kinda works and maybe the difference between 90% and 82% is not big, but is it too much difference between the original and 82%? Wherever you have text it will become harder to identify, so maybe the nice owl in the example should be replace with an image of text and the difference should be tested on this kind of images.

          Then you will say that most images do not contain text, and I will agree but before a proper measurement and additional research is done you can not just say that the “difference is invisble” to everyone.

          • Helen Hou-Sandi 3:33 pm on February 23, 2016 Permalink | Log in to Reply

            The post very clearly lays out DSSIM as a proper objective measurement, existing outside research on a precise threshold, and a lot of work done by this team to quantify various outcomes as documented in a spreadsheet. The image set includes images with text, both JPG and PNG. If that is not “proper measurement and additional research”, I have a hard time believing you’re actually open to discussion.

    • jeffmcneill 3:23 pm on February 22, 2016 Permalink | Log in to Reply

      I strongly endorse this proposal. File size, besides number of files, is one of the biggest factors in a slow user experience. Yes indeed, “the biggest factor is latency” but it is latency for requests and responses, that is what is being requested is slow making it to the device, because it is big. Also, the idea that everyone has cheap bandwidth/throughput everywhere, all the time, is simply mistaken. We need ways of making WordPress more mobile-friendly (not to mention developing-country friendly), and this is an excellent proposal to do just that.

    • Aaron D. Campbell 3:46 pm on February 22, 2016 Permalink | Log in to Reply

      I’m all for this change. An average of 25% reduction in file size seems like an obvious win, especially since the visual difference between 90 and 82 is almost none.

      However, we do not need, and should not add, a setting for this. The vast majority of users not only won’t need the setting, but won’t understand it (What does an image quality of 90 vs 82 vs 60 vs 100 actually mean?). The filter (wp_editor_set_quality) is already in place for those that really want it, and a plugin could easily be created to add this setting for any users that want it.

      • dsthedev 4:26 pm on February 22, 2016 Permalink | Log in to Reply

        I don’t know, I feel like it would be pretty easy to write a simple 1 – 2 sentence description of what the setting does. Benjamin Pick provided a perfect example of somebody uploading technical drawing or images with text on them. If a user doesn’t understand the setting they will probably skip it entirely. I also don’t think we need yet another plugin for something that could be a very simple option in core. A great example of that is needing to download the “Disable Google Fonts” plugin on every site I create because wp-core forces Open Sans on everybody without providing a very simple checkbox option to not use it.

        • Aaron D. Campbell 6:06 pm on February 22, 2016 Permalink | Log in to Reply

          The problem here is two fold:

          1) If the majority of users will never use an option, then it shouldn’t be in core. We generally refer to this as the 80-20 rule of thumb. We want core to be what 80% of the people need, and plugins to cover the needs of the other 20%. I don’t even think 20% of users will need this option, much less 80%.

          2) Option overload is a real thing. Users freeze up when there are too many options, because they feel overwhelmed. Every option that goes into the WordPress admin needs to be carefully examined and an EXTREMELY good case needs to be made for it’s necessity. A single new option, then another int he next release, and another after that, and soon our options screens are overfilled and scary to an average user. “It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.” – https://wordpress.org/about/philosophy/

    • Stephane Daury (stephdau) 4:01 pm on February 22, 2016 Permalink | Log in to Reply

      Thanks for the time you put into this. I’m also in favor of looking deeper into this. Those not browsing on broadband, or those with bandwidth limits, will surely appreciate such savings, especially when thinking web scale, and WP as “25% of it”.

    • pix365 4:25 pm on February 22, 2016 Permalink | Log in to Reply

      LIke Aaron, I too am in favour of the change, Mobile data packages in Europe is quite expensive, so reducing the volume of data downloaded can only be a good move, I vote for a Option (& i am assuming it will be dropped to 82) inside the Media admin section to allow folks to override the new default with the Legacy setting (90)
      AND OR if you gave folks the ability to enter a custom value, i think most will use it responsibly, but you can bet some users will use 100%. for that reason alone a custom value field setting is probably not a good one, unless max setting was 90.

    • Aaron Jorbin 5:57 pm on February 22, 2016 Permalink | Log in to Reply

      Thanks for writing thus up.

      The proposal looks great. Let’s do it!

    • Helen Hou-Sandi 6:05 pm on February 22, 2016 Permalink | Log in to Reply

      I’m for this. Really great to see the numbers from objective measurements (DSSIM) included in this, always appreciate the thoroughness and thoughtfulness. Also really cool that this came from responsive images work, which while related, is not inherently coupled to this. Having API improvements come from feature work tends to work well for us.

      Regarding the comments here, no core UI settings for this, please. We don’t have one now and this change is, per the numbers, incredibly unlikely to be visually noticeable in the end results, so I don’t see why it requires further changes in the admin.

      Just so I’m clear on this point – this only applies to JPGs, yes? Are PNGs resized to PNGs or are they resized to JPGs? (There’s also a comment above with concerns about PNG quality loss.)

      • Joe McGill 6:37 pm on February 22, 2016 Permalink | Log in to Reply

        Good questions Helen.

        The quality setting affects both JPG and PNG files. PNGs will remain PNGs but compression in Imagick affects PNGs differently than JPGs so the file size differences aren’t as noticeable. There are a few tickets floating around track about better compression for PNGs specifically, which would be another nice addition to tackle.

    • Primoz Cigler 6:55 pm on February 22, 2016 Permalink | Log in to Reply

      Yes, do it. And no, no extra settings are needed. I even think you could set it to lower than 82, but I guess some other people here will kill me with fire 😀

      Are metadata and exif stripped also? I think it is a good idea they should be stripped by default as well. So called lossless compression.

    • Dave 7:10 pm on February 22, 2016 Permalink | Log in to Reply

      I’m all for this change, and appreciate Joe’s time in writing it up, and providing data to explain why.

      I agree with the last few comments about no UI settings in core (for all the same reasons that were already mentioned).

    • jteague 7:13 pm on February 22, 2016 Permalink | Log in to Reply

      +1 on this proposal. Our own recent tests came out at 84% optimal, but either compression percentage is fine.

    • Ansel Taft 7:53 pm on February 22, 2016 Permalink | Log in to Reply

      A great write-up, well reasoned, and an excellent tweak to WordPress. [/makeitso]

    • Gary Pendergast 11:20 pm on February 22, 2016 Permalink | Log in to Reply

      +1 on this change, nice writeup, Joe. 🙂

      -∞ on adding UI for an option, the existing filter is sufficient.

    • jtleathers 1:15 am on February 23, 2016 Permalink | Log in to Reply

      I’m all in favor of this change. It always bugs me when the current default creates smaller resolution images with larger file sizes than the original image. This change should definitely help.

    • M Asif Rahman 2:14 am on February 23, 2016 Permalink | Log in to Reply

      Agreed. Let’s do this.

      And for changing the value, we have a hook already.
      add_filter( 'jpeg_quality', create_function( '', 'return 80;' ) );

      Read more at – https://developer.wordpress.org/reference/hooks/jpeg_quality/

    • Drivingralle 3:45 am on February 23, 2016 Permalink | Log in to Reply

      +1 for this.

      I created a ticket in trac about giving developers a way to control image compression for costume image sizes per size to save even more file size. I think somehow related.

    • Mark Howells-Mead 8:42 am on February 23, 2016 Permalink | Log in to Reply

      +1 from me. When I make the effort to optimize content photos as precisely as possible before uploading them, WordPress’ processing always creates copies from them which are larger in file size than the originals.

      I doubt many editors or admins will take the time to pay attention to a setting in wp-admin: I think that a customization of the default setting should continue to be handled by the experienced developer, via a hook.

    • AllenAyres 8:02 pm on February 23, 2016 Permalink | Log in to Reply

      I understand I’m not a developer, but speaking for the thousands (millions?) of photographers using WP for their business-front end, it would be appreciated to give them a heads-up on the change and the way to undo it if they prefer.

      *You* may not care for image-quality vs download speed, but those who rely on the display of their work to be seen at its best do. Our life’s work is image quality, what may not be obvious to some is glaring to others.

      For those who are on slower/metered access, I’m ok if they bypass my site, it’s generally not for them in the first place.

      • Ipstenu (Mika Epstein) 12:45 am on February 24, 2016 Permalink | Log in to Reply

        I’m curious… Do you have people looking at the downsized images or the full sized? Because as I understand it, we’re only going to be changing compressions for the resized images.

        • Ryan Hellyer 8:25 am on February 24, 2016 Permalink | Log in to Reply

          I suspect it’s both. Even the “full sized” images shown on photography websites tend to be scaled down to a more reasonable number for display. And photographers tend to be very particular about their thumbnails in my experience too. I actually think the thumbnails can be even more important, as they tend to show up JPG compression more, due to their small size and people staring close at them.

          • Ipstenu (Mika Epstein) 7:55 pm on February 24, 2016 Permalink | Log in to Reply

            But isn’t the fullsized not scaled down by WP? If I upload a 3000×2000 image, it doesn’t get processed, it just gets copied.

            Thumbnails, yeah, I totally agree there. Not sure how to get the word out really.

      • Joe McGill 4:20 pm on February 24, 2016 Permalink | Log in to Reply

        Hi Allen,

        While the visual differences will be slight, I agree that we’ll want to let users with strong opinions about this sort of thing know. In fact, that’s the main reason for publicly publishing this proposal in the first place. Besides publishing information on this blog, I’d be curious to know where else you suggest we publicize this information?

        • AllenAyres 4:57 pm on February 24, 2016 Permalink | Log in to Reply

          Thank you Joe.

          To me, it would need to be published in the release notes so that those many photographers (and the developers a good percentage of the photographers pay to develop their site) would know before they update. On some hosts that update automatically it would be good to know what happened to their image quality.

          Again, what may appear slight to some is a huge change to others, and as Ryan mentioned, the resized images would be affected more (I spend a lot of time getting each image looking perfect, all the while optimizing for download speed, upload a 900×600 image, the theme resizes it to something a bit smaller to fit and then generates 1-2 thumbnails to display varying sizes throughout the site – the smaller the image the more compression affects perceived quality).

          Please don’t strip exif data either, our IP is carried in there via copyright notices, etc. I already strip out as much as possible but have seen many photographers track down theft of copyrighted images through the searches of the info they place within the exif.

          For professionals, we work/invest tremendously already to have the image display at its best, balancing that with download speed too, at least allow us a way to undo the changes made.

    • davidshq 2:02 am on February 26, 2016 Permalink | Log in to Reply

      I’m not a huge fan of this idea. I see too much deterioration in image quality. The owl looks great, but I see way too much degradation in numerous images I’ve utilized on sites in the past…

      What I would like to see is something akin to jpegMini’s technology, which reduces file size but maintains perceived image quality.

    • Todd Lahman 2:15 am on March 1, 2016 Permalink | Log in to Reply

      Not sure if this was mentioned, but this should also be applied to the jpeg_quality filter.

    • Mark Howells-Mead 8:42 am on March 31, 2016 Permalink | Log in to Reply

  • Joe McGill 2:56 am on November 10, 2015 Permalink
    Tags: , , media,   

    Responsive Images in WordPress 4.4 

    WordPress 4.4 will add native responsive image support by including srcset and sizes attributes to the image markup it generates. For background on this feature, read the merge proposal.

    How it works

    WordPress automatically creates several sizes of each image uploaded to the media library. By including the available sizes of an image into a srcset attribute, browsers can now choose to download the most appropriate size and ignore the others—potentially saving bandwidth and speeding up page load times in the process.

    To help browsers select the best image from the source set list, we also include a default sizes attribute that is equivalent to (max-width: {{image-width}}px) 100vw, {{image-width}}px. While this default will work out of the box for a majority of sites, themes should customize the default sizes attribute as needed using the wp_calculate_image_sizes filter.

    Note that for compatibility with existing markup, neither srcset nor sizes are added or modified if they already exist in content HTML.

    For a full overview of how srcset and sizes works, I suggest reading Responsive Images in Practice, by Eric Portis over at A List Apart.

    New functions and hooks

    To implement this feature, we’ve added the following new functions to WordPress:

    • wp_get_attachment_image_srcset() – Retrieves the value for an image attachment’s srcset attribute.
    • wp_calculate_image_srcset() – A helper function to calculate the image sources to include in a srcset attribute.
    • wp_get_attachment_image_sizes() – Creates a sizes attribute value for an image.
    • wp_calculate_image_sizes() – A helper function to create the sizes attribute for an image.
    • wp_make_content_images_responsive() – Filters img elements in post content to add srcset and sizes attributes. For more information about the use of a display filter, read this post.
    • wp_image_add_srcset_and_sizes() – Adds srcset and sizes attributes to an existing img element. Used by wp_make_content_images_responsive().

    As a safeguard against adding very large images to srcset attributes, we’ve included a max_srcset_image_width filter, which allows themes to set a maximum image width for images include in source set lists. The default value is 1600px.

    A new default image size

    A new default intermediate size, medium_large, has been added to better take advantage of responsive image support. The new size is 768px wide by default, with no height limit, and can be used like any other size available in WordPress. As it is a standard size, it will only be generated when new images are uploaded or sizes are regenerated with third party plugins.

    The medium_large size is not included in the UI when selecting an image to insert in posts, nor are we including UI to change the image size from the media settings page. However, developers can modify the width of this new size using the update_option() function, similar to any other default image size.

    Customizing responsive image markup

    To modify the default srcset and sizes attributes,  you should use the wp_calculate_image_srcset and wp_calculate_image_sizes filters, respectively.

    Overriding the srcset or sizes attributes for images not embedded in post content (e.g. post thumbnails, galleries, etc.), can be accomplished using the wp_get_attachment_image_attributes filter, similar to how other image attributes are modified.

    Additionally, you can create your own custom markup patterns by using wp_get_attachment_image_srcset() directly in your templates. Here is an example of how you could use this function to build an <img> element with a custom sizes attribute:

    $img_src = wp_get_attachment_image_url( $attachment_id, 'medium' );
    $img_srcset = wp_get_attachment_image_srcset( $attachment_id, 'medium' );
    <img src="<?php echo esc_url( $img_src ); ?>"
         srcset="<?php echo esc_attr( $img_srcset ); ?>"
         sizes="(max-width: 50em) 87vw, 680px" alt="A rad wolf">

    Final notes

    Users of the RICG Responsive Images Plugin should upgrade to version 3.0.0 now in order to be compatible with the functionality that included in WordPress 4.4.

    • Tomas Mackevicius 3:33 am on November 10, 2015 Permalink | Log in to Reply

      Can we say that from now on users will be encouraged to always include full sized image instead of one that fits the regular content width the best, like size Large?

      Another question is if this improvement will affect images in older posts that are already inserted with certain predefined width parameters.

      Thank you!

      • Joe McGill 4:38 am on November 10, 2015 Permalink | Log in to Reply

        Hi Tomas,

        Site authors will be able to include whichever size they feel is most appropriate, but now site visitors will get the benefit of downloading the best image source available to fit their needs, which could be larger or smaller, depending on their device capabilities.

        • Tom Belknap 4:10 pm on December 15, 2015 Permalink | Log in to Reply

          I’m not sure that this is entirely true: while in full-size view I can see the proportional size, in practice WP is putting the thumbnail in on small screens.

          Another question: if we override the default image placement (say, to use

          instead of captions), we’ll need to perform the above snippet of code to make it work, is this correct?
    • David Chandra Purnama 4:10 am on November 10, 2015 Permalink | Log in to Reply

      in wp we have “hard-crop” (such as thumbnail size), or soft-crop (like medium large sizes) or my fav is using fixes width, and very tall height to keep the image as is (resize, no crop)

      so how do WP check this images? what images WP uses?

      I don’t want to display my image content as thumbnail, when it shouldn’t be cropped (?)
      thank you.

      • Joe McGill 4:39 am on November 10, 2015 Permalink | Log in to Reply

        Hi David,

        WordPress will only include images that match the same aspect ratio as the image in the ‘src’ attribute.

    • Monika 8:06 am on November 10, 2015 Permalink | Log in to Reply

      I’m using WP 4.4 and twenty sixteen on my testsite.
      *only developer plugins are active

      *for “responsive image tests” I ‘m using always the same image and upload it again.

      *my last test was this morning.

      If I insert an image with 300×199 in a post,

      I can find all large sizes in source => this doesn’t make sense too me.


      <img src="xx/media/2015/11/IMGP9685-300×199.jpg" alt="IMGP9685"
      width="300" height="199" class="aligncenter size-medium wp-image-750"
      srcset="xx/media/2015/11/IMGP9685-250×166.jpg 250w,
      xx/media/2015/11/IMGP9685-300×199.jpg 300w,
      xx/media/2015/11/IMGP9685-768×511.jpg 768w,
      xx/media/2015/11/IMGP9685-1024×681.jpg 1024w,
      xx/media/2015/11/IMGP9685.jpg 1029w" sizes="(max-width: 300px) 85vw, 300px"

      How can I avoid this?

      • Joe McGill 1:13 pm on November 10, 2015 Permalink | Log in to Reply

        Hi Monika,

        The larger sizes are included in the srcset attribute in order to account for screens with high density displays and only the most appropriate size will be used for any device, so this is the expected behavior. However, if you want to keep out all the large sized images from being included in your srcset attributes, you can filter the max_srcset_image_width, like this:

        function filter_max_srcset( $max_width, $size_array ) {
        if ( $size_array[0] === 300 ) {
        $max_width = 768;

        return $max_width;
        add_filter( 'max_srcset_image_width', 'filter_max_srcset', 10, 2 );

    • Mark-k 1:36 pm on November 10, 2015 Permalink | Log in to Reply

      To add to monica above, it seems like there is a missing option, a non responsive image. Lets say the image is a company logo and it should be displayed at exactly one size no matter what images WP generates for it an if it doesn’t stretch well on the screen.

      • Joe McGill 3:54 pm on November 10, 2015 Permalink | Log in to Reply

        Hi Mark,

        The responsive image markup should not change the display size of your image. Instead, it’s used to let the browser know which image source to use. For example, if you have a company logo that should be displayed at 300px wide, and you have a 300px version of the logo and a 600px version of the logo, you can identify both image sources in the `srcset` attribute and retina displays could use the 600px version so the logo looks crisp on all devices.


        • Mark-k 5:54 pm on November 10, 2015 Permalink | Log in to Reply

          The point is that for whatever reason I don’t want to use anything except for the full size image, what should I do then. Possible (but maybe invalid) scenario is the ability to save the full size image on my local pc. If I give the browser the option to select whatever image is being displayed, what would be the image saved?

          Another related question that came into my mind is by what criteria the images are added to srcset? Are those all the images for which there is an add_image_size or is there some selectivity?

        • Mark-k 6:08 pm on November 10, 2015 Permalink | Log in to Reply

          Maybe I have a better real life question. Once images are compressed into about a file size of 30k it is hard to get any real reduction in size just by using lower dimension without terminally reducing the quality of the details of the image. Therefor I do not want to suggest to the browser to get any image smaller then 30k even if it fits better because the price I pay in bandwidth is not worth the quality reduction, and I would prefer to avoid another hit on the server just because the resolution was changed when flipping the device without making enough display space for a much better image.

          • Joe McGill 10:35 pm on November 10, 2015 Permalink | Log in to Reply

            Hi Mark,

            There may be valid scenarios where you would not want this functionality, and if so, you are free to use the included filters to modify/remove the default behavior. That said, I would suggest spending a bit of time getting familiar with the benefits of responsive images and how they work before making that decision, because generally, the benefits to your users (and your bandwidth) should be worth it. For a primer on responsive images, check out this blog series: http://blog.cloudfour.com/responsive-images-101-definitions/


            • Mark-k 7:43 am on November 11, 2015 Permalink

              1. It is really annoying to get from core developers the attitude of “we know better then you so trust us”. In this case since I am following the whatwg mailing list I am quiet sure I am aware of this feature history and how it is intended to be used and what were the objections to it that created the picture element in the end as much as you.

              2. Unlike oEmbed and REST API this is not a new functionality developed on empty slate and it has an impact on the behavior of all existing sites, therefor you can’t just say “it is easy to do with a filter” which might be very true but joe shmo that will upgrade from 4.3 to 4.4 doesn’t know that he is supposed to write a filter to keep his site functioning exactly as before.

              3. So this is my suggestion
              a. have an option to control whether this feature is inactive
              b. on upgrade from 4.3 set the option to true

              This follows what was done for link management so I am sure there is some efficient pattern to use here.

              People that want to opt in can use a simple plugin that should be run only once to do that.

            • Joe McGill 1:08 pm on November 11, 2015 Permalink


              Thanks for the feedback. Comments are not generally the best forum for long explanations and I was attempting to acknowledge that you may have valid reasons for turning these off without a long technical explanation. I can see how it would have come across as condescending, which was not my goal.

              I’ll add that we did ask for community feedback regarding whether this feature should be turned on by default or if we should toggle it on via a site option and the majority of people thought we should turn it on by default.


    • Travis Northcutt 8:51 pm on November 10, 2015 Permalink | Log in to Reply

      First off, awesome! Thanks, RICG team, for making this happen.

      > The medium_large size is not included in the UI when selecting an image to insert in posts, nor are we including UI to change the image size from the media settings page. However, developers can modify the width of this new size using the update_option() function, similar to any other default image size.

      One thought on this: does this mean that if the width of medium_large is changed, there won’t be any indication of that change (save, of course, for the actual images being generated at a different size)? If so, I wonder if that might make debugging a tad difficult, since it could lead to inconsistent behavior (old images at 768px, new ones at ____px) without a clear reason as to why, without looking directly at the database (something many/most people won’t/can’t do).

      That’s certainly not an argument in favor of a UI to change this, and is admittedly an edge case, but I wanted to at least mention it in case it bears further discussion.

      • Joe McGill 10:27 pm on November 10, 2015 Permalink | Log in to Reply

        Hey Travis,

        Good thought. For that size to change, a developer would have to intentionally run `update_option()`. I think it would be rare when that happens unintentionally, or that a future developer couldn’t check the size through a `get_option()` call in order to debug the issue. However, if we find out that leaving the option out of the admin UI causes a large amount of issues, we can certainly add it later.

        • Joe
    • Morten Rand-Hendriksen 10:04 pm on November 10, 2015 Permalink | Log in to Reply

      Probably a dumb question:

      Is `wp_make_content_images_responsive()` applied to posts by default ensuring that existing posts will receive responsive images? Or am I just misunderstanding the function of this function?

      • Joe McGill 10:29 pm on November 10, 2015 Permalink | Log in to Reply

        Hi Morten,

        Sorry that the post wasn’t clear. The `wp_make_content_images_responsive()` function is automatically hooked to the `the_content` filter and will automatically apply responsive image markup to all posts by default, regardless of when they were originally published.


        • Morten Rand-Hendriksen 10:40 pm on November 10, 2015 Permalink | Log in to Reply

          OK. That’s what I suspected. So the purpose of the wp_make_content_images_responsive() function comes into play any time you want to apply the RICG markup to content that is not filtered through the_content then.

          • lamnt 8:19 am on November 11, 2015 Permalink | Log in to Reply

            I did installed RICG 3.0 on wordpress 4.3 but i don’t see it works. Is this compatible with these? I also check attributes in “the_content”, i don’t see the srcset, data-size or something like that of RICG.
            It seems doesn’t work filter and automatically apply responsive image.

    • Paal Joachim Romdahl 10:21 pm on November 10, 2015 Permalink | Log in to Reply

      Ehhh hmm not sure what to say here….
      How would this benefit the regular beginner user and designers?
      I am trying to grasp what your saying.
      If you could “dumb down” the language a bit that would help.

    • programmin 4:10 am on November 11, 2015 Permalink | Log in to Reply

      This is exciting news! I wonder if there are any good developer tools for testing through these, as the Firefox Inspector doesn’t seem to give any special preview to the srcset or sizes attributes, just shows a very long attribute text.
      Thanks for the good work 🙂

    • FolioVision 4:43 am on November 11, 2015 Permalink | Log in to Reply

      HI Joe,

      This is wonderful! How does the srcset and sizes for responsive images fit in with Retina? Should we expect full retina support any time soon?


      • Joe McGill 12:58 pm on November 11, 2015 Permalink | Log in to Reply

        Hi Alec,

        Browsers that support the `srcset` and `sizes` take into account the screen density when selecting an appropriate source, so this will provide full retina support as long as the original uploaded image was large enough to have the appropriate sizes created by WordPress.


        • Jesse Heap 10:00 pm on December 9, 2015 Permalink | Log in to Reply


          Doesn’t that assume though that your theme is appropriately setup with image sizes that are 2x the size of the image?

          If I’m understanding correctly I think it still may make sense to use plugins like WP Retina 2x as that plugin will automatically create a retina image that is twice the resolution regardless of whether you have the appropriate image sizes setup in your theme.

          If I’m understanding correctly, using a plugin like Wp Retina 2x is potentially a better solution especially if you have varying image sizes as WP Retina 2x will dynamically create the 2x image based on the original image dimensions….

          Am I correct?

    • Dwain Maralack 1:04 am on November 12, 2015 Permalink | Log in to Reply

      Well done for getting the feature wrapped up Team!

    • David Chandra Purnama 1:26 pm on November 13, 2015 Permalink | Log in to Reply

      thank you for the explanation.
      is there possible performance and compatibility issue for filtering content with this complex parser? (vs the benefit for default content filter)
      here’s my full thoughts for this feature to help explain my question:

      • Joe McGill 3:05 pm on November 14, 2015 Permalink | Log in to Reply

        Hi David,

        Great write up about your experience testing the feature. Thanks for sharing.

        From a performance point of view, filtering the content to add responsive image support adds a bit of overhead, but many times, I expect users to benefit by downloading smaller images than they would have normally—making the small overhead worthwhile.

        On the compatibility side, I’m sure there will be some issues to work out. For example, the Jetpack team is working right now to make sure that Photon is compatible with this feature. As issues come up during the next few weeks, we’ll work to address what we can.


    • klihelp 10:27 pm on November 20, 2015 Permalink | Log in to Reply


    • joost de keijzer 10:35 am on November 26, 2015 Permalink | Log in to Reply

      Hi, great feature!

      De srcset attribute doesn’t seem to be added by default to images in a gallery. Is this on purpose?

    • tornography 10:09 am on December 9, 2015 Permalink | Log in to Reply

      Please include the original size into srcset aswell. Otherwise the largest srcset is loaded, even if the original image is larger.


      src = original.jpg // 1920*1200
      srcset = small-300.jpg 300w, …, large-1024.jpg 1024w
      sizes = (max-width: 1920px) 100vw, 1920px

      Window/Browser is 2084px wide, but large-1024.jpg is laoded. If srcset is extended by the original size:

      srcset = …, original.jpg 1920x

      the original sized Image is laoded.

    • jmy1138 3:01 pm on December 9, 2015 Permalink | Log in to Reply

      For those of us that are already using the RICG Responsive Images Plugin, is there any advantages to dropping this plugin and using the native responsive image feature?

      • Joe McGill 3:12 pm on December 9, 2015 Permalink | Log in to Reply

        Hi Jon,

        The plugin still includes a few features that are not found in core. Namely, advanced image compression, the Picturefill polyfill to enable responsive image support on older browsers, and some backward compatibility shims for people who were using early versions of the plugin that wrote `srcset` and `sizes` information directly to the markup saved in posts. If none of those issues are important to you then you can safely remove the plugin.


        • jmy1138 5:07 pm on December 9, 2015 Permalink | Log in to Reply

          Thanks for the feedback Joe. I can seeing compressing images before uploading to WP, enqueuing the Picturefill script, and making sure syntax is up to date would negate the need for the plugin.

    • Angristan 3:52 pm on December 9, 2015 Permalink | Log in to Reply

      Some images are loaded with the srcset attribute in HTTP and not HTTPS, so most browsers are blocking them on my website…

    • Eric Mathison 6:36 am on December 10, 2015 Permalink | Log in to Reply

      How will this behave with custom image sizes added with add_image_size? We’ve long adapted to not using the builtin WordPress Image sizes and create our own, which are easier to reference when adding into a post.

    • zjk 8:40 am on December 10, 2015 Permalink | Log in to Reply


      In my wordpress image are done with a structure of a div wrapper with classes like “preload” triggering the js process deferred after dom ready, also “loader” for getring a nice loading font awesome icon animation nicely centered in the container while the ressource is non obstruvisly loading. This allow me to get the best response time of default interface. Img src are are given in a data-src attribute of this div, and used by the js loading process. I just have in a noscript with default img src in case we have no js support. Please allow us to have your fonctionnality disabled by default as my manner of processing img is far better in term of support and frontend perfomance.


    • stemie 3:13 pm on December 10, 2015 Permalink | Log in to Reply

      I have https enabled on my backend and since the WordPress 4.4 update my featured images in the backend display blank images. When I remove srcset image (with chrome developer tools) the featured image appears. The srcset image causing the problem is http while all my other images are https (or at least they begin with //). Any ideas how to get the featured image to show or enable https on the srcset?

    • thisisbbc 6:32 pm on December 10, 2015 Permalink | Log in to Reply

      Hi there,
      We’re struggling to get our product images to display the right size. They keep getting cropped for an unknown reason. Is there any known problems with WooCommerce?
      Thank you

    • christoffer.alm 6:22 pm on December 11, 2015 Permalink | Log in to Reply

      Is there any way to implement this on background images, aka with image-set?

      background: -webkit-image-set( url(‘path/to/image’) 1x, url(‘path/to/high-res-image’) 2x );

    • Tim Berneman 7:40 pm on December 11, 2015 Permalink | Log in to Reply

      What’s the code to remove the srcset tags from my images? I have some custom code and WP4.4 is cause my images not to display. Here is my current code:

      global $post;
      if ( has_post_thumbnail( $post->ID ) )
        echo get_the_post_thumbnail( $post->ID, array( 180, 180 ) );

      I tried the_post_thumbnail() and that didn’t work either.

      I just want to disable the new “srcset” tag in my code to get my images to display again!

      • Joe McGill 8:53 pm on December 11, 2015 Permalink | Log in to Reply

        Hi Tim, the easiest way to disable responsive images on your site is to add this code snippet to your functions.php or better yet through a separate plugin file.

        function disable_srcset( $sources ) {
        return false;
        add_filter( 'wp_calculate_image_srcset', 'disable_srcset' );

        However, if your images aren’t displaying because of HTTPS mixed content issues, than you may want to keep an eye on this thread.

    • Bielousov 8:42 pm on December 11, 2015 Permalink | Log in to Reply

      I actually hope this doesn’t work, for I had to create a front-end analog to dynamically add srcset with respect to retina display, not just screen size and really really hope it won’t break with this new update.
      Nice try though WordPress, I was looking for this some time ago, but too late.

    • SnixyKitchen 3:08 am on December 14, 2015 Permalink | Log in to Reply

      I’m super excited about this update because I’ve been inserting images that are 2x the display width to optimize for retina, which is surely slowing down my site on other non-retina screens. One issue I’ve noticed though is that on iphone retina screens, it’s choosing a really low resolution image from the srcset making all the images SUPER blurry! Does anyone know why this is happening? Or is there a way to set a min size to include in srcset so it doesn’t have this one as an optin??

      • Joe McGill 1:11 pm on January 20, 2016 Permalink | Log in to Reply

        Hi SnixyKitchen,

        iPhones still on iOS8 suffer from a Safari bug that always chooses the first source in the `srcset` attribute. My advice would be do add the Picturefill polyfill for responsive images in order to fix this issue.

    • greenzilla 6:42 pm on December 17, 2015 Permalink | Log in to Reply

      I came across an issue where I would want to limit the srcset max width based on the images placement. IE: I don’t want a 100px w image placement to be able to grab a 300px w image. I would want to limit the srcset to a 200px w image. My phone (Droid Turbo 2) is pulling the 300px w image while the iphone 6 is pulling the 200px w image and desktop is grabbing the 100px image. My reasons to limit to 200px w is it looks ‘good enough’ and to save on bandwidth and decrease load times. This is where the invaluable ‘max_srcset_image_width’ filter comes into play. I can take the $size_array parameter and calculate ‘max_srcset_image_width’ for the desired image placement. Hopefully others will find this useful.

    • rcgordon 1:34 am on December 19, 2015 Permalink | Log in to Reply

      The responsive images break some posts on the iPad on http://www.theshelterblog.com. I lauded the Disable Responsive Images plug-in to stop it. One specific post that was showing a thumbnail image on iPad (either portrait or landscape) is http://www.theshelterblog.com/18-year-old-builds-debt-free-tiny-house-as-school-project/.

      The impacted image was only obtainable in a medium size (662×424).

    • donaldG2 4:01 pm on December 21, 2015 Permalink | Log in to Reply

      I for one am so incredibly stoked to have this as part of core! I do have a quick question: will the polyfill script ever be included in core? I can see how you’d want to leave that up to the different users depending on their needs instead of including one.more.script, ha. I was a bit confused until finding this thread, thinking that picturefill.js had been included but glad to have discovered the thread. Many thanks!

      • Joe McGill 1:15 pm on January 20, 2016 Permalink | Log in to Reply

        Hi Donald,

        We’re not planning to include the polyfill in core since many people prefer to be in control of their own front-end javascript dependencies. However, if your not able to add it to your theme yourself, you can install the RICG Responsive Images plugin, which still includes the polyfill.

    • chatmandesign 8:19 pm on December 23, 2015 Permalink | Log in to Reply

      Is there a filter to change the src attribute? I want to support retina, but I don’t want to fallback to an image that big for browsers that don’t support responsive images, so I’d like to override the src to a more middle-size image (say, targeted at 1366w).

    • thinkwired 12:23 am on December 29, 2015 Permalink | Log in to Reply

      I am seeing posts where some images have the additional srcset markup but other images do not (on the same post/page). These images were uploaded at the same time and all of them have various sizes in the upload folder. What would cause some images to display the responsive markup but, others not? I’m trying to diagnose the issue to no avail.

    • vovkasolovev 8:43 pm on January 19, 2016 Permalink | Log in to Reply

      Oh… I got two problems with this update. I already implement responsive images in my theme myself with default Large size. My Large size width 975px, and I don’t need Medium_large. Also, after update checking for original image size is broken now.

      In UI Large image set to 975 and 0. Uploading image.jpg with 975px width and 731px height:
      Before 4.4 update: WordPress upload it as image.jpg (without additional Large image size).
      After 4.4 update: WordPress upload it as image.jpg, create Large image-975×731.jpg and Medium_large image-768×576.jpg. So I got 2 similar files and one almost similar in Uploads.

      How to change default medium_large size to 975px in functions.php?
      How to prevent WordPress to generate image with exact similar image size?
      Please, help, there no examples in docs right now.

      • Joe McGill 1:09 pm on January 20, 2016 Permalink | Log in to Reply

        Hi vovkasolvev,

        Sounds like you’re suffering from a known bug with image sizes (see: #32437). Here’s a good example of how to enforce image default image sizes from your functions file.

        • vovkasolovev 3:02 am on January 21, 2016 Permalink | Log in to Reply

          Thank you! You right, this is exactly that bug.
          I will try method you suggest.

        • papijo 10:41 am on January 26, 2016 Permalink | Log in to Reply

          Hi Joe,

          I also suffer from that problem. Most of the images I upload to my wp site are 1024px wide. Upon uploading, my original images are “re-sized” to 1024px wide, thus creating useless duplicates.
          1.- Workaround: in Settings->Media->Large size replace the default 1024×1024 with 1025×1025.
          2.- It works, but a side effect is that now the newly introduced medium_large size (768px wide) is no longer generated upon uploading images.
          3.- And even if I revert Settings->Media->Large size to the default 1024×1024, still no medium_large size is generated! Is there a way to reset the Media settings?

          4.- It should be relatively easy and very useful to fix this bug as reported in https://core.trac.wordpress.org/ticket/32437. I will post to that ticket soon.

          • papijo 10:30 am on January 30, 2016 Permalink | Log in to Reply

            Further to my previous post, can anyone confirm my findings about the Settings>Media behaviour? If one changes ANY of the size settings, this will remove the generation of the new “medium_large” size files when uploading image files. And there seems to be no way to reset this!

    • Kerrie Redgate 1:38 am on January 23, 2016 Permalink | Log in to Reply

      This is terrible! I don’t have time for this, with 5 sites to maintain. Some of my major images are fuzzy now on retina screens. When I remove the dimensions that I had carefully planned to work well on all devices, the image is too large on normal screens and shrinks to a third of its size into a corner on retina screens. Why has WordPress done this? This is a major headache!

    • richarduk 1:19 pm on January 31, 2016 Permalink | Log in to Reply

      Although I’m getting srcset for images in posts, the header image uploaded through the media uploader and output using header_image () has no srcset. Is there a likely reason for this?

    • Martin999 3:21 pm on January 31, 2016 Permalink | Log in to Reply

      Hi Joe,
      at the moment I still use WP 4.3.2 for my site. It has a lot of relatively small images between 100 and 250 px width. They are perfect for non-mobile devices and become responsive by CSS (max-width: 100%; height: auto;) without any visible loss of quality. EACH IMAGE ONLY EXISTS ONCE, IN ONE SIZE.

      When installing WP I disabled cropping in media settings and also set all sizes there to “0”. Therefore WP didn’t generate additional images for different sizes when uploading an image. When uploading an image I choosed “link image: none” and “size: full size”

      I have two questions:
      1. Will the new responsive image feature “take” my images and give them srcset and size attributes, though there are no different image sizes in media library, due to my upload and media settings?

      2. What is the official recommended code for my functions.php to disable the new responsive feature of WP? Searching the web I find several codes, partly different ones. I’m mot a coder, just a webmaster.


      • Joe McGill 4:11 am on February 3, 2016 Permalink | Log in to Reply

        Hi Martin,

        1. The responsive image functionality relies on the existence of the different image sizes created when your image is uploaded. If no extra sizes are created, `srcset` attributes won’t be added.

        2. The easiest way to disable the feature if you absolutely need to is to install this plugin: https://wordpress.org/plugins/disable-responsive-images/.

        • Martin999 4:30 pm on February 3, 2016 Permalink | Log in to Reply

          Hi Joe,
          thanks for your fast answer.

          I guess the plugin uses the same code you mentioned here (sorry, overlooked it).

          Btw, searching the web I found several dissenting comments about the new responsive feature taking also action on already existing images (with different sizes in media library).

          Could you please explain, what “already existing image” exactly means? Will images become responsive which were inserted in a post/page before WP-Update to 4.4? If not, what happens when editing the post/page (with image in it) and saving? Will it then become responsive, providing that the media library has several image sizes?

    • adijeff 5:14 pm on February 2, 2016 Permalink | Log in to Reply

      Having upgraded to WP 4.4 I have disabled the PB Responsive Images plugin I was using, but I’ve got a problem with many images in my posts that are missing a wp-image-XXX class. This class appears to be what makes the images responsive. Is there a way to fix these images without me having to go through hundreds of images? Thanks

      • Joe McGill 4:16 am on February 3, 2016 Permalink | Log in to Reply

        Hi adijef,

        Unfortunately, there’s not an easy solution that lets you add the ID class back to the image markup in your plugin. You could probably come up with a way to do a reverse lookup on each image URL to get the image ID and add the markup back to your posts, but that’ll take a bit of scripting.

    • g-niloo 2:10 pm on February 4, 2016 Permalink | Log in to Reply

      Actually I don’t really like the idea of 768px default width. All my high resolution images are saved with that width and have a terrible quality, unless they’re opened in another tab. What should I do to show the original image quality and save the original image from posts like before? I always add images with their original size and then for high resolution ones I resize them to 565px width and had no problem saving them with original quality!

    • TraciBunkers 7:45 pm on February 10, 2016 Permalink | Log in to Reply

      I just updated my wordpress, and now my images that are on Amazon S3 that are served through cloudfront don’t work. It’s not an issue of http/https for me. I had to add the code to my theme’s functions.php file to disable the srcset that I got from here: http://wordpress.stackexchange.com/questions/211375/how-do-i-disable-responsive-images-in-wp-4-4/211376#211376

    • graphicsxp 10:05 am on February 17, 2016 Permalink | Log in to Reply

      I have a problem with this feature on my blog. The images show as thumbnail when the size of the screen is equivalent to an iPad portrait ( 768 x 1024). See it here http://www.pretty-story.com/blog/mariage-original-au-luxembourg/

      What should I do to fix this ?

    • stemlund 5:55 pm on February 27, 2016 Permalink | Log in to Reply

      This may have been addressed – but I’m not finding it. There seems to be additional tweaks needed for a basic issue I’m finding. Previously in the post/page editor, when an image is added, and let’s say it’s a large image (larger than the parent div), the webpage would only make that image as wide as the parent div. This was done by simply having max-width: 100% on img in CSS. Now, when adding images that are wider than the parent div, just keeps that image full-width and not constrained by the parent div.

      I know there are best-practice issues here – but when you have clients adding images, there needs to be some compromises sometimes, and the max-width 100% provided that compromise.

      Is there something I’m missing where these super large images shouldn’t be breaking out of their parent div? It seems the issue is the sizes parameter includes a max-width equal to the image width – instead of 100%.

      How should this be handled? Is there a global change I can make on a site so all images added are max-width=100% and not max-width=image width?

      This issue seems like it would affect many existing websites and possibly break many layouts.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar