WordPress.org

Make WordPress Core

Tagged: 4.4 Toggle Comment Threads | Keyboard Shortcuts

  • Ryan McCue 9:23 pm on April 6, 2016 Permalink
    Tags: 4.4, ,   

    REST API: Slashed Data in WordPress 4.4 and 4.5 

    Hi everyone. The REST API team recently discovered a bug with parameter parsing in the API infrastructure, part of WordPress 4.4. For those of you using the API infrastructure, you need to be aware of a bug fix we’re making with the API.

    The Problem

    The REST API has several types of parameters that it mixes together. These come from several sources including the request body as either JSON or URL-encoded form data ($_POST), query parameters ($_GET), the API route, and internally-set defaults. Unfortunately, due to an oversight on our behalf, these parameters can be inconsistently formatted.

    In WordPress, the superglobal request variables ($_POST and $_GET) are “slashed”; effectively, turning magic quotes on for everyone. This was originally built into PHP as a feature to help guard against SQL injection, but was later removed. Due to compatibility concerns, WP cannot change this behaviour for the superglobals. This only applies to the PHP superglobals, not to other sources of input like a JSON body or parameters in the URL. It additionally does not apply to form data on PUT or DELETE requests.

    Internally, some low-level WordPress functions expect slashed data. These functions internally call wp_unslash() on the data you pass in. This means input data from the superglobals can be passed in directly, but other data needs to be wrapped with a call to wp_slash().

    When the REST API gathers the data sources, it accidentally mixes slashed and unslashed sources. This results in inconsistent behaviour of parameters based on their source. For example, data passed as a JSON body is unslashed, whereas data passed via form data in the body is slashed (for POST requests).

    For example, the following two pieces of data are equivalent in the REST API:

    
    // JSON body:
    {"title": "Foo"}
    
    // Form-data ($_POST)
    title=Foo
    
    // Both result in:
    $request->get_param('title') === 'Foo';
    

    However, if the data contains slashes itself, this will be inconsistently passed to the callback:

    
    // JSON body:
    {"title": "Foo\Bar"}
    
    // Results in:
    $request->get_param('title') === 'Foo\Bar';
    
    // Form-data ($_POST) (%3D = "\")
    title=Foo%3DBar
    
    // Results in:
    $request->get_param('title') === 'Foo\\Bar';
    

    This means that callbacks need to understand where parameters come from in order to consistently handle them internally. Specifically:

    • Data passed in the query string ($_GET, $request->get_query_params()) is slashed
    • Data passed in the body as form-encoded ($_POST, $request->get_body_params()) is slashed for POST requests, and unslashed for PUT and DELETE requests.
    • Data passed in the body as JSON-encoded ($request->get_json_params()) is unslashed.
    • Data passed in the URL ($request->get_url_params()) is unslashed.
    • Data passed as a default ($request->get_default_params()) is unslashed.

    In addition, parameters set internally via $request->set_param() are unslashed. Unit and integration tests for API endpoints typically use these directly, so the majority of tested code (such as the WP REST API plugin) assumes parameters are unslashed.

    See the related Trac Ticket #36419 for more information.

    The Solution for WordPress 4.4 and 4.5

    We are regarding inconsistently-slashed data as a major bug, and are changing the API infrastructure to ensure unslashed data. This will ensure that data is consistent regardless of the source. Callbacks will now receive unslashed data only, and can rely on this regardless of the original data source or request method.

    If you are using functions that expect slashed data in your callback, you will need to slash your data before passing into these functions. Commonly used functions that expect slashed data are wp_insert_post, wp_update_post, update_post_meta, wp_insert_term, wp_insert_user, along with others. Before passing data into these functions, you must call wp_slash() on your data.

    The fix for this issue, will be included in the WordPress 4.5 release candidates and final release. Due to the severity of the bug, we are also backporting the fix to the next minor WordPress 4.4 update. This also ensures you can update your plugins can act consistently across all versions of the REST API.

    We understand that this may inadvertently break some plugins that are expecting slashed data. Right now, it’s not possible to consistently ensure that callbacks receive slashed data, so it is likely that these plugins will already break in some conditions.

    tl;dr: if you’re using wp_insert_* or *_post_meta in your REST API callback, you need to ensure you are calling wp_slash() on data you are passing in, regardless of source.

    We apologize for this bug existing in the first place. Slashed data is a problem that has plagued WordPress for a long time, and we’re not immune to getting caught by the issue ourselves.

     
    • Mike Schinkel 7:16 am on April 7, 2016 Permalink | Log in to Reply

      We apologize for this bug existing in the first place. Slashed data is a problem that has plagued WordPress for a long time, and we’re not immune to getting caught by the issue ourselves.

      Given that this issue created such a major bug, wouldn’t it be a good time to take backward compatible action to slowing start eliminating this as an issue?

      • Mike Schinkel 7:35 am on April 7, 2016 Permalink | Log in to Reply

        In case of interest in addressing this moving forward:

      • Ryan McCue 3:40 am on April 8, 2016 Permalink | Log in to Reply

        As it happens, this is part of my Secret Master Plan for Unslashing, and part of why I wanted to ensure we fixed this right now.

        My Secret Master Plan:

        • Take the generic parts of WP_REST_Request and make a new WP_HTTP_Request object
        • Ensure the Request object has unslashed data
        • Pass the Request around liberally to replace the superglobals (discussed somewhat in #36292)
        • Finally introduce internals that take unslashed data, and turn the existing functions into wrapper functions.
    • NateWr 7:54 am on April 7, 2016 Permalink | Log in to Reply

      Is this change in the latest WP 4.5 RC or do we need to get the latest commits to test our apps?

      • Marius (Clorith) 12:56 pm on April 7, 2016 Permalink | Log in to Reply

        It is not available in RC-1, that’s out at this time, as it was pushed in last evening/earlier today (depending on your time zones), the goal is to get RC-2 out some time this week, and it will include this change.

        If you are running trunk you’ll have access to it at this time, alternatively you can manually apply the patch to your own install if you wish to start testing it right away (the patch from #36419)

  • Samuel Sidler 3:25 pm on February 1, 2016 Permalink
    Tags: 4.4, 4.4.2, ,   

    4.4.2 Release Candidate 

    A Release Candidate for WordPress 4.4.2 is now available. This maintenance release is scheduled for tomorrow, Tuesday, February 2, but first it needs your testing. This release fixes 17 issues reported against 4.4 and 4.4.1.

    WordPress 4.4 has thus far been downloaded over 20 million times since it’s release on December 8. Please test this release candidate to ensure 4.4.2 fixes the reported issues and doesn’t introduce any new ones.

    Contributors

    Thank you to the following 11 contributors to 4.4.2:

    afercia, berengerzyla, boonebgorges, chandrapatel, chriscct7, dd32, firebird75, ivankristianto, jmdodd, ocean90, salvoaranzulla

    Fixes

    A total of 17 fixes are included in this RC (trac log). Notable fixes include:

    • #35344 – Strange pagination issue on front page after 4.4.1 update.This was a very visible issue for certain users with specific settings. While remnants of this issue still exist (see #35689), the bulk of it has been fixed and is ready for testing.
    • Comments – A total of 6 issues were fixed within the Comments component.
      • #35419 – Incorrect comment pagination when comment threading is turned off
      • #35402 – per_page parameter no longer works in wp_list_comments
      • #35378 – Incorrect comment ordering when comment threading is turned off
      • #35192 – Comments_clauses filter (issue)
      • #35478 – 4.4 Regression on Querying for Comments by Multiple Post Fields
      • #35356 – wp_list_comments ignores $comments parameter

    Download & Test

    We need your help to ensure there are no issues with the fixes in 4.4.2. Please download the RC and test!

     
    • Ryan Boren 5:20 pm on February 1, 2016 Permalink | Log in to Reply

      Use the beta tester plugin to reduce testing the RC to a few clicks. Rollback from the beta track to the latest production release is also a click. Details: https://make.wordpress.org/core/handbook/testing/beta/

      • Ryan Boren 5:22 pm on February 1, 2016 Permalink | Log in to Reply

        I have several sites that follow trunk nightlies using the beta tester plugin. To test the 4.4.2 RC, I tried switching those sites from bleeding edge trunk nightlies to point release nightlies using the beta tester plugin. After changing the setting in Tools > Beta Testing and doing an upgrade, I’m still on trunk. Smoothing this would be a nice improvement to beta testing flow.

  • Aaron Jorbin 12:17 am on January 5, 2016 Permalink
    Tags: 4.4, 4.4.1, ,   

    4.4.1 Release Candidate 

    A Release Candidate for WordPress 4.4.1 is now available. This maintenance release is scheduled for Wednesday, January 6, but first it needs your testing. This release fixes 52 issues reported against 4.4.

    WordPress 4.4 has thus far been downloaded over 7 million times since it’s release on December 8. Please test this release candidate to ensure 4.4.1 fixes the reported issues and doesn’t introduce any new ones.

    Contributors

    A total of 36 contributors have contributed to 4.4.1:

    Compute, DvanKooten, JPr, KrissieV, SergeyBiryukov, ShinichiN, aaroncampbell, afercia, azaozz, boonebgorges, dd32, dossy, eherman24, gblsm, hnle, igmoweb, jadpm, jeff@pyebrook.com, joemcgill, johnbillion, jorbin, meitar, nacin, netweb, obenland, ocean90, pento, peterwilsoncc, redsweater, rmccue, rogerhub, salcode, smerriman, scottbrownconsulting, stephenharris, swissspidy, tharsheblows, tyxla, voldemortensen, webaware, wonderboymusic, wp-architect

    Notable Bug Fixes

    Two severe bugs have been fixed. In some cases, users with an out of date version of OpenSSL being used by PHP were unable to use the HTTP API to communicate with to communicate with some https sites. Additionally, posts that reused a slug (or a part of a slug) would be redirected.
    The polyfill for emoji support has been updated to support Unicode 8.0. This means that diversity emoji, and other new emoji like 🌮 and 🏒 are fully supported. 

    All Changes

    Most components have received at least one change. This is a list of all tickets closed, sorted by component.
    (More …)

     
  • Mike Schroder 5:42 am on December 11, 2015 Permalink
    Tags: 4.4, , ,   

    December 10 Meeting Summary and 4.5 Call for Volunteers 

    We gathered together after the marvelous release of 4.4. Many congrats to @wonderboymusic, his deputies @sergeybiryukov and @ocean90, and all contributors who helped out! See the full transcript for the entire chat.

    On 4.4

    What’s Next?
    @helen is building a product design team that is kicking off shortly. I’m excited about this — it’s an opportunity to really step up our game in the UX space. She’ll be building out a few projects and calling for volunteers on make/design, so watch there if you’re interested in getting involved.

    Officially, 4.5 doesn’t kick off until early January, but I’d like to start off with a ready-to-go set of teams. The time between now and then is also great for preparing feature plugins that you’re interested in seeing merged.

    4.5 Call for Volunteers
    Currently looking for those interested in:

    • Being a Release Backup/Deputy
    • Contributing to Week in Core Summary Posts
    • Working on a particular development focus or feature

    If you’re interested in contributing in any of these areas/roles, please leave a comment! Feel free to ping me in the Make WordPress Slack (@mike) if you have any questions on these roles.

     
    • WP Sites - Brad Dalton 5:56 am on December 11, 2015 Permalink | Log in to Reply

      I’d like to be a volunteer & contribute however according to my competitiors, i don’t know what i’m doing, my code doesn’t work and i don’t know anything about WordPress!

    • yehudah 7:03 am on December 11, 2015 Permalink | Log in to Reply

      I would like to help, I don’t care in which area.

    • Nick Halsey 7:38 am on December 11, 2015 Permalink | Log in to Reply

      Count me in for working with @westonruter and others on the Customizer. Most of my availability will be in the next month, so I’m planning on trying to get moving on several UI and UX-related items (including possible new features). As I mentioned in the meeting, a possible theme of eliminating dead-ends to improve user flow is emerging and I’ll expand on that once it’s more fleshed out.

      Also, I just realized that the work to re-imagine the toolbar that was done during 4.3 was never completed – #32678. I think that should be doable for 4.5, and would help improve flow between the frontend and admin.

    • Varun Sridharan 9:17 am on December 11, 2015 Permalink | Log in to Reply

      I would like to volunteer and contribute my time to WordPress 🙂
      i am basically strong in development. so i can do development or being a release backup/Deputy

    • Justin Greer 11:19 am on December 11, 2015 Permalink | Log in to Reply

      Throw me in somewhere needed! Just let me know where! 🙂

    • Ahmad Awais 2:50 pm on December 11, 2015 Permalink | Log in to Reply

      Would love to contribute again. @westonruter‘s idea on the Customizer SPA looks pretty good to me.

    • Rami Yushuvaev 1:50 am on December 12, 2015 Permalink | Log in to Reply

      I will defiantly continue contributing to core!

    • Morgan Estes 2:32 am on December 12, 2015 Permalink | Log in to Reply

      I’m interested in working on inline JS docs, and giving the Toolbar some love. Oh, and Week in Core. 🙂

    • Joe McGill 4:44 am on December 12, 2015 Permalink | Log in to Reply

      I’d like to see if we can push forward the improved imagick compression settings from the RICG plugin project and explore the possibility of streamlining some of our media internals, maybe something like #23424.

    • Najum Rahim 4:21 pm on December 12, 2015 Permalink | Log in to Reply

      I would to contribute efforts and time to WordPress.

    • Scott Kingsley Clark 4:21 pm on December 12, 2015 Permalink | Log in to Reply

      I’ll be focusing on Fields API, not sure if it’ll be ready in time for the 4.5 merge window but I’ll be hopeful!

    • Mostafa 8:36 am on December 31, 2015 Permalink | Log in to Reply

      I really want to contribute on WordPress Core…..but how?
      Can i contribute on core just by fix a bug and make a patch for it?

    • vinorodrigues 12:49 am on January 1, 2016 Permalink | Log in to Reply

      I can help.

    • ucheng 6:05 pm on January 4, 2016 Permalink | Log in to Reply

      I have no experience on contributing to WordPress core, but I really want to make it in 2016. Since I have made a plugin for Layers WP, I want to focus on Customizer and make it better!

    • SlimBob 2:11 pm on January 5, 2016 Permalink | Log in to Reply

      I’m interested in working on a particular development focus or feature.

  • Weston Ruter 11:29 pm on December 2, 2015 Permalink
    Tags: 4.4, ,   

    Customizer improvements in 4.4 

    Now an update for the hottest most buzz-worthy JavaScript-driven single page application (SPA) in WordPress: Calypso the Customizer. Earlier in the release cycle there was a proposed roadmap for the Customizer and I wanted to share an update for what improvements have made it into the 4.4 release. I won’t include everything, but I’ll highlight some items that you may notice or want to make note of.

    Performance

    As noted on the roadmap, the focus for the Customizer in 4.4 has been to improve performance, and there are some drastic improvements in this release. Note that selective refresh (#27355, neé partial refresh) did not make it in, however the feature plugin now has a pull request for review.

    Multidimensional Customizer settings (options & theme mods) are not scalable (#32103)

    In 4.3 the time to load/refresh the Customizer preview increases exponentially as the number of settings/controls grows. If you have 200 settings it can take 15 seconds for the preview to update. If you have 300 settings, it can take 36 seconds to load/refresh the Customizer preview. And the time to reload the preview continues to grow exponentially as the number increases:

    With the fixes in place for 4.4, the time to refresh the preview grows linearly very slowly (basically flatlined) as opposed to exponentially. I would share a graph, but it would be a very boring flat horizontal line.

    See also aggregated multidimensional settings below.

    Reduce Customizer peak memory usage by JSON-encoding settings and controls separately (#33898)

    In addition to the slow preview load/refresh time, when there are a lot of Customizer settings/controls registered, the process for exporting the data from PHP to JavaScript used a lot of server memory when it serializes the JSON data in 4.3. In 4.4, each setting and control now gets serialized individually in a loop to avoid the memory spike, and this helps avoid any white screen of death due to the allowed memory size being exhausted in PHP.

    Defer embedding Customizer widget controls to improve DOM performance (#33901)

    The previous performance improvements were for the server and reduced the amount of time it takes to get a response (TTFB). Nevertheless, for sites that have a lot of widgets, the Customizer would still load very slowly, not due to WordPress being slow on the server, but due to the JavaScript running in the browser. In 4.3 given 100 widgets (with a lot of inputs), the Customizer could take 40 seconds to finish building the page due to all of the widget controls being embedded into the DOM. So in 4.4 we defer the embedding of widget controls until the contained widget area section is expanded, that is until the widget control is actually shown to the user. This results in the Customizer loading over 10× faster: what did take 40 seconds now takes 3 seconds in WordPress 4.4.

    Widgets section in customize late to show up (#33052)

    The widgets panel now will now always be shown even if there are no widget areas currently displayed in the preview. This ensures that the widgets panel doesn’t slide down after the preview finishes loading. This is another browser-based improvement that doesn’t actually improve actual performance but it does improve perceived performance, or at least the user experience.

    Aggregated Multidimensional Settings

    The problem with the scalability of multidimensional settings for options or theme mods (#32103) is that the number of filters added to preview changes grows exponentially (see above). The fix for this is to ensure that only one filter gets added for a multidimensional settings that share a common ID base. The entire root value for the option or theme mod gets stored in a variable, and any previewed setting’s value gets applied to that variable once, and this root value then gets returned by the filter. This construct is referred to in the source as a “aggregated multidimensional setting”. Note that this has only been implemented for options and theme mods: custom multidimensional setting types that subclass WP_Customize_Setting should also be able to make use of the functionality, although this has not been specifically tested.

    Two new actions have been introduced:

    • customize_post_value_set
    • customize_post_value_set_{$setting_id}

    These are triggered whenever WP_Customize_Manager::set_post_value() is called, and they allow for WP_Customize_Setting::preview() to update the value being previewed. You can now, for instance, call preview() on a setting up-front and then set the post value later, and the new value will be applied for previewing as expected. This can be called a “deferred preview” or “just in time” previewing.

    Facilitate plugins to override Customizer features (#33552)

    Sometimes widgets or menus are not applicable for a given site. Ticket #33552 introduces a new filter customize_loaded_components which allows nav menus or widgets to be skipped from initialization. For example, to prevent the nav menu functionality from being loaded the following plugin code can be used:

    add_filter( 'customize_loaded_components', function ( $components ) {
        return array_filter( $components, function ( $component ) {
            return 'nav_menus' !== $component;
        } );
    } );
    

    JS Inline Docs

    The Customizer is a JavaScript-heavy application, and in #33503 #33639 the inline docs for JS have been improved to help developers understand how it works. See [33709] [33911] [33841].

    Non-autoloaded Option Settings (#33499)

    When settings are registered for options that don’t already exist in the DB, an update for these settings in the Customizer would result in update_option() called with the default $autoload parameter and thus them being saved as autoloaded. In 4.4 you can now register option settings to explicitly not get added with autoloading, for example:

    $wp_customize->add_setting( 'foo[first]', array(
        'type' => 'option',
        'autoload' => false,
    ) );
    

    Other Improvements

    • #21389 Retina theme custom headers
    • #31540 Dropdown pages Customizer description option
    • #32637 Customizer should default to returning to the front page, not the themes page
    • #32812 Customizer Menus: Escaping inconsistencies — You can now use limited markup in nav menu item titles in the Customizer.
    • #33319 Customizer header image crop uses static URL when refreshing UI after crop.
    • #33665 Menu Customizer: Implement indicators for invalid menu items
    • #34432 Customizer subclasses can be broken out and remain BC — All Customizer PHP classes now reside in a separate files.
    • #34607 Customizer: Wrapped labels should align to start of label, not checkbox or radio button
    • New methods:
      • WP_Customize_Manager::get_preview_url()
      • WP_Customize_Manager::set_preview_url()
      • WP_Customize_Manager::get_return_url()
      • WP_Customize_Manager::set_return_url()
      • WP_Customize_Manager::set_autofocus()
      • WP_Customize_Manager::get_autofocus()
      • WP_Customize_Manager::customize_pane_settings()

    Several accessibility fixes were also made.

    See also the full list of tickets that were closed during the 4.4 release for the customize component.

     
  • Aaron Jorbin 4:18 pm on November 11, 2015 Permalink
    Tags: 4.4, ,   

    WordPress 4.4: Field Guide 

    WordPress 4.4 is the next major release of WordPress and is shaping up to be an amazing release. While you have likely discovered many of the changes from testing your plugins, themes, and sites (you have been testing, right?), this post highlights some of the exciting 🎉changes developers can look forward to. 💥

    Externally Embeddable

    New Embeds Feature in WordPress 4.4

    Using a handful of filters, you can customize how your site looks when it’s embedded elsewhere. As a part of the work around embeds, there are also a couple of new functions for retrieving and displaying embeddable content. The post above also links to a plugin which will remove the ability to embed your site elsewhere.

    REST API Infrastructure Introduction

    The infrastructure to create a REST API has landed in WordPress core.  Adding your own endpoints (or using the latest version of the REST API plugin) is now even easier.  The new embed feature mentioned above uses this new infrastructure.
    Note: If you are using v1 of the API plugin, it is incompatible with 4.4, however an update is planned before 4.4 ships. The update will not use the new REST API infrastructure, so you’ll want to update your REST API usage eventually. If you are using v2 of the API plugin, be sure you’re on beta 5 or later; previous versions do not support WordPress 4.4.

    Responsive Image Insertion

    Through the use of a display filter, image tags in WordPress now include srcset and sizes.  These two attributes to the <img> tag allow browsers to choose the most appropriate image size and download it, ignoring the others. This can save bandwidth and speed up page load times. There are new functions, filters, and an additional default image size available to help with the creation of responsive images.

    wp_title Deprecation Decision

    Since WordPress 4.1, add_theme_support( 'title-tag' ); has been the recommended way of outputing a title tag for themes.  Now, a year later the wp_title function has been officially deprecated. Take a look at this post if you want to see all the great new filters you can use to modify title tags.

    UPDATE 12 November – wp_title has been reinstated for the time being. It is a zombie function.  add_theme_support( 'title-tag' ); remains the recommended way to insert a title tag into your theme, however there were use cases for wp_title that were not accounted for in the original deprecation decison

    Term Taxonomy Tranquility

    WordPress 4.4 is the latest in a string of releases to feature major updates to the taxonomy system. This release introduces of term meta, a new WP_Term class, and a host of other under the hood changes.

    Comment Component Cultivation

    Comment Object and Query Features in 4.4

    Changes to fields output by comment_form in WordPress 4.4

    Comments received love both on the front end of sites and on the backend. On the front-end, the comment field will always appear first, before the name and email fields. This fixes a longstanding bug where the behavior was different for logged in and logged out users.

    Under the hood, comments are now represented by a WP_Comment class and comment queries are now considerably more powerful.

    Multisite Momentum

    Like taxonomy and comments, the multisite features gains a new class, WP_Network. Additionally, there are now *_network_option functions which make it easier to use multiple networks. The linked post also highlights new hooks, some notable bug fixes, and two newly-deprecated functions. If you use WordPress in a multisite environment, this is a must-read.

    Heading Hierarchy Happiness

    Headings on the admin screens are now more semantic. Be sure to update your custom admin screens to follow the proper heading structure. These changes help users of assistive technologies, such as screen readers.

    Twenty Sixteen

    Each year, WordPress releases a new default theme and this year is no exception. Twenty Sixteen is a brand new theme, bundled with WordPress 4.4. Default themes are incredibly popular; be sure to test your plugins to ensure they function well with Twenty Sixteen.

    Other Notes

    So far, this release has had over two thousand commits. There are many additional changes not outlined above including: the removal of support for my-hacks.php(Update Nov 20th: My Hacks support was added back), giving add_rewrite_rule support for an easier-to-read syntax, support for single-{post_type}-{post_name} in the template hierarchy, pretty permalinks for unattached media, and stronger enforcement of the show_ui argument in custom post types. As with every major update, it is very important to test every feature in your plugins and themes to ensure there are no regressions in their behavior.

    Closing

    If you haven’t been testing your themes, plugins, and sites with WordPress 4.4, now is a great time to start. You can grab a copy from svn (or git), download the nightly builds, or install it using the Beta Tester Plugin.

    WordPress 4.4 is not recommended for use on production servers until the final release has been announced on the WordPress News blog. The release is currently targeted for December 8, 2015. Get testing today!

     
    • Xavier Borderie 9:13 am on November 12, 2015 Permalink | Log in to Reply

      Very useful, thanks a lot Aaron!

    • Shah Alom 2:29 pm on November 12, 2015 Permalink | Log in to Reply

      Very helpful on the first look … Thanks!

    • Ahmad Awais 6:50 pm on November 12, 2015 Permalink | Log in to Reply

      Thanks for enlisting everything, Aaron! I’ve been fortunate enough to contribute to the REST API, Headings Hierarchy and Twenty Sixteen theme. Looking forward to WP 4.4 in December.

    • Nisha 12:55 pm on November 13, 2015 Permalink | Log in to Reply

      Thanks for the update Aaron. Looking forward to new features in WP 4.4.

    • jomarlipon 12:10 am on November 19, 2015 Permalink | Log in to Reply

      Looking forward to this update. 🙂

    • dawesi 4:54 am on November 20, 2015 Permalink | Log in to Reply

      So great seeing major breaking changes in a dot release. So glad you’re using professional standards and only releasing breaking changes in major versions… oh wait..

      Too many breaking changes, my clients want out of wordpress. It’s your reputation, 4.3 was the WORST software release of any company in the world in 2015, 4.4 better be PERFECT or you’ll be winning more shonkey awards.

      Our clients want OUT if 4.4 breaks ANYTHING out of the box. (2400 wordpress sites GONE overnight)

      Some great features here that should be in 5.0… goes to show this product is off the rails.

      • Samuel Sidler 3:18 pm on November 20, 2015 Permalink | Log in to Reply

        Hello,

        WordPress 4.4 is considered a major release, just as WordPress 4.3 was considered a major release. WordPress 5.0 will be another major release and no different than WordPress 4.9 or 5.1. More information about our versioning is available in the handbook.

        Regarding quality, note that 4.3 was one of the most solid WordPress releases we’ve had in years, only requiring minor fixes after its release and being adopted at a faster rate than any previous release in recent memory. What issues affected you?

      • demixpress 3:57 pm on November 27, 2015 Permalink | Log in to Reply

        The version numbering of WordPress is great, or it may be another Android in CMS.

    • wpsupporthq 4:06 am on November 29, 2015 Permalink | Log in to Reply

      Thanks Aaron! This is a great rundown of the upcoming changes.

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

    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:

    <?php
    $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.

      example

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

        Joe

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

            Cheers

            • 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

              Mark,

              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.

              Thanks,
              Joe

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

        Joe

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

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

      Alec

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

        Joe

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

          Joe,

          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:
      https://shellcreeper.com/responsive-image-in-wordpress-4-4/

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

        Thanks,
        Joe

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

      Thanks!

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

      Example:

      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.

        Thanks,
        Joe

        • 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

      Hi,

      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.

      cheers

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

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

      Example:
      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.

      Thanks!

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

  • Andrea Fercia 8:14 pm on October 28, 2015 Permalink
    Tags: 4.4, , , example-flow, user-anecdote, visual-comparison   

    Headings hierarchy changes in the admin screens 

    For a number of years, the headings hierarchy in the admin screens have been setup without careful thought. WordPress 4.4 aims to fix this. This work is mainly focused on helping those users of assistive technologies such as screen readers, and is a continuation of the work started in 4.3 on restoring the H1 (heading level 1) to the admin screens.

    If you’re a plugin or theme author and you’re providing custom admin screens for settings, etc., there are a few things you should check and update.

    Why it matters

    Headings provide document structure, which can directly aid keyboard navigation. Users of assistive technologies use headings as the predominant mechanism for finding page information. When heading levels are skipped, it’s more likely for these users to be confused or experience difficulty navigating pages.

    Putting it simply, one of the first things screen reader users do in a web page to find relevant content is to press the 1 key on their keyboard to jump to the first <h1> heading and then they will try the key 2 to find the <h2> headings and so on. Thus, it’s extremely important for WordPress to provide a correct headings hierarchy, ensuring no headings levels are skipped.

    How to fix your Plugin or Theme

    Restructure the document headings hierarchy to ensure that heading levels are not skipped. The main heading should be a <h1> and any subsequent headings should (likely) be bumped one level up. There should be no skipped levels. Check your headings in the Admin, for example in settings pages, list tables, screen options, (dashboard) widgets, and meta boxes.

    See for example the screenshot below, the first heading (Sharing Settings) should be a <h1> followed by a <h2> for Sharing Buttons.

    main h1 heading example

    Your plugin screens should start with a H1!

    List Table headings

    List tables (such as on wp-admin/edit.php ) have now additional headings added, though you won’t see them. These headings are hidden with the .screen-reader-text CSS class and are intended to allow users to jump to the relevant sections in these screens.

    Note: For more in-depth information on using the core .screen-reader-text class, the Accessibility team has a great write-up on it.

    The screenshot below illustrates the new headings in the Posts and Categories screens.

    In the screen wp-admin/edit.php the heading structure is now:

    • H1: Posts
    • H2: Filter posts list (visually hidden)
    • H2: Posts list navigation (visually hidden)
    • H2: Posts list (visually hidden)

    In the screen wp-admin/edit-tags.php?taxonomy=category the heading structure is now:

    • H1: Categories
    • H2: Categories list navigation (visually hidden)
    • H2: Categories list (visually hidden)
    • H2: Add new category
    hidden headings for default posts and taxonomies lists

    The hidden headings in the default posts and taxonomies lists.

    If your plugin or theme provides custom post types or custom taxonomies, these new headings will use their default values “Post” and Category”:

    hidden headings for custom posts and taxonomies lists

    The hidden headings in the custom posts and taxonomies lists.

    New post type and taxonomy labels in 4.4

    In order to provide for better heading text, some new labels have been added for use with register_post_type() and register_taxonomy().

    For register_post_type():

    'filter_items_list'     => __( 'Filter your-cpt-name list', 'your-plugin-text-domain' ),
    'items_list_navigation' => __( 'Your-cpt-name list navigation', 'your-plugin-text-domain' ),
    'items_list'            => __( 'Your-cpt-name list', 'your-plugin-text-domain' ),
    

    For register_taxonomy():

    'items_list_navigation' => __( 'Your-tax-name list navigation', 'your-plugin-text-domain' ),
    'items_list'            => __( 'Your-tax-name list', 'your-plugin-text-domain' ),
    

    Here’s an example for a custom post type:

    custom posts list with proper headings

    Using the new labels to provide proper headings for a custom post.

    Screen Options tab changes

    Some plugins add custom options in the Screen Options tab. Previously, a h5 heading was used for the options “title”. In WordPress 4.4, the Screen Options tab has been revamped and together with other changes, it has been decided to remove the h5 heading which didn’t allow for a good headings hierarchy.

    Each group of options is now within its own form fieldset and uses a legend element as “title”. You’re strongly encouraged to change the HTML you use for your plugin options and use the new markup.

    the new Screen Options tab

    The new Screen Options tab: each option is in a separate fieldset.

    Dashboard widgets and meta boxes changes

    All Dashboard widgets and meta boxes headings changed from an H3 to an H2.

    <h2 class="hndle ui-sortable-handle">
    	<span>your-widget-title</span>
    </h2>
    

    If you are a theme or plugin developer: please check the heading structure in the content of your widgets and meta boxes, use an H3 and lower in the right order and context.

    Get ahead of 4.4 and update now!

    Now is a great time to update your plugins and themes! The power of the Web is in its universality. Help us to make the Web a place designed to work for all people. Any feedback and thoughts are more than welcome, please let us know in the comments below.

     
    • Marcel Pol 9:22 pm on October 28, 2015 Permalink | Log in to Reply

      Just to be of help, you can easily check your headings as developer with the WP-Tota11y plugin:
      https://wordpress.org/plugins/wp-tota11y/

    • Rami Yushuvaev 12:00 am on October 29, 2015 Permalink | Log in to Reply

      Meta Box Question:

      When creating meta boxes, we use the add_meta_box() function. The second parameter sets the meta box title. As a plugin developer I don’t create h2/h3 titles, It’s done by WordPress. What do I need to update?

      Dashboard Widget Question:

      Same thing. When I register new dashboard widgets I use the wp_add_dashboard_widget() function. The second parameter is used to set the widget title. The function added HTML tags around the title, not the plugin developer. What do I need to change in 4.4?

      • Jeffrey de Wit 12:35 am on October 29, 2015 Permalink | Log in to Reply

        Hey Rami,

        The main thing to look out for is when you use additional headings inside of your actual meta boxes/widgets. If you don’t do this, then you’re all set and good to go without having to change anything.

      • Ahmad Awais 12:39 am on October 29, 2015 Permalink | Log in to Reply

        Hey, Rami!
        If you yourself are not creating headings and relying on WordPress to create them for you, then there is nothing to worry about. I myself changed these headings for the widget part, not sure about the Metabox.

        You can download the bleeding edge version and check your metabox generator code. I am pretty sure, you won’t run into any issue.

    • Amanda Rush 8:46 am on November 1, 2015 Permalink | Log in to Reply

      This is excellent news! Yet another accessibility win for WordPress.

      • FolioVision 1:40 am on November 2, 2015 Permalink | Log in to Reply

        I agree whole heartedly Amanda. This is exactly the kind of low friction but usability improvement which doesn’t break anything and makes WordPress better.

        Very nice instructions Andrea!

    • pepe 11:06 am on November 2, 2015 Permalink | Log in to Reply

      So is this only for installations running 4.4 or should we change the heading hierarchy regardless of the user’s WP version?

      • Andrea Fercia 10:22 pm on November 2, 2015 Permalink | Log in to Reply

        WordPress 4.4 has some CSS back compatibility for plugins or themes screens that still use H2 as main heading, basically keeping the old selectors in the style sheet(s). There may be edge cases though which would require some minor CSS adjustments. So, if you prefer to don’t update your headings, you’re not immediately forced to do that. You’re strongly encouraged to update them though 🙂
        About previous WordPress versions, plugins and themes can provide their own CSS for the headings in their screens or accept some minor visual glitches in exchange for greatly improved semantics and accessibility. Probably another good reason to update WP 🙂

      • Ipstenu (Mika Epstein) 12:12 am on November 3, 2015 Permalink | Log in to Reply

        If you tag your next release as “Requires at least: 4.4” then no one below 4.4 will get the update so they won’t get the new headings.

        In general, we recommend people stop supporting older versions of WP to help encourage people to upgrade.

    • Ryan Boren 4:33 pm on November 11, 2015 Permalink | Log in to Reply

      Great post. I tagged it #visual-comparison, #user-anecdote, and #example-flow. The example flow in “Why it matters” provides important perspective and context that most of us don’t have. We need more anecdotes and more step-by-step bulleted flow, especially for accessibility.

    • Cor van Noorloos 7:43 pm on November 14, 2015 Permalink | Log in to Reply

      Great job. Not exactly keyboard related, but have you thought on adding anchor links on (sub)headings as well?

    • revaxarts 8:28 am on November 25, 2015 Permalink | Log in to Reply

      Should we so a feature check or a version check to output H2 on WP = 4.4? Is there a new function available to check?

    • Andrea Fercia 1:12 pm on November 25, 2015 Permalink | Log in to Reply

      You don’t need anything special to output a H2, but you’re strongly encouraged to use a H1.

  • Jeremy Felt 7:18 pm on October 28, 2015 Permalink
    Tags: 4.4, ,   

    Multisite Focused Changes in 4.4 

    WordPress 4.4 has been a very productive release for multisite. In addition to some exciting new enhancements, we were able to resolve some long standing bugs. Check out the full list of multisite focused changes on Trac if you want even more wonderful reading material. 💖

    Introduce WP_Network

    The $current_site global has been maintaining a stdClass object representing an assumed description of a network since the original merge of WordPress MU with WordPress. With the introduction of WP_Network, we give a network a bit more definition and open up possibilities for working with a network (or networks) in a more sane way.

    Take a look at ms-settings.php if you are using a custom sunrise.php to populate the $current_blog or $current_site globals. We now create a WP_Network object from the existing $current_site if it has been populated elsewhere. This is a backward compatible change, though should be tested wherever your code interacts with $current_site, especially if anything has been done to extend its structure.

    See #31985 for more discussion while this was built.

    Introduce *_network_option functions

    During the introduction of WP_Network, we needed a way to populate network options (stored in wp_sitemeta) for a network other than the current.

    add_network_option(), update_network_option(), get_network_option(), and delete_network_option() are all new functions in 4.4. Each takes the network ID as its first argument, matching the structure of the *_blog_option() functions.

    *_site_option() functions remain as the proper way for working with a current network’s options. These now wrap the new *_network_option() functions and pass the current network’s $wpdb->site_id.

    In a future release, likely 4.5, we can look at the introduction of network 0 as a way to store global options.

    See #28290 for more discussion.

    New actions and filters

    • before_signup_header fires before the signup header in wp-signup.php. #17630
    • ms_network_not_found fires when the $current_site global has not been filled and ms_not_installed() is about to fire. #31702
    • invite_user fires immediately after a user is invited to join a site, but before the notification is sent. #33008

    Other enhancements of note:

    • WordPress has always enforced a /blog prefix for the main site’s permalink structure to avoid collisions with other sites in a subdirectory configuration. This was always changeable in the network admin, though the permalinks UI in the site admin never reflected the change and could cause confusion. Now, thanks to #12002, WordPress forgets that /blog was ever assigned if it is changed in the network admin to anything else. When changing this value, choose something that won’t conflict.
    • manage_network_users is now used to determine edit_users caps rather than is_super_admin. In preparation for 4.4, take a look at how you’re using the manage_network_users capability in your code to be sure access is set as intended. #16860
    • Network activated plugins are now visible as “network activated” in an individual site admin if the user can manage network plugins. These are not shown to site administrators. #20104
    • Recently active plugins are now displayed as such in the network admin. #20468
    • Language selection is now available when adding a new site through the network admin. 🌍 #33528
    • Language selection is also now available when signing up for a new site through wp-signup.php. 🌏 #33844
    • Network user searching has been improved by wrapping search terms in asterisk for looser matching. #32913

    Bugs of note fixed:

    • It was previously impossible to set the upload limit for an individual site to 0 as it would then fallback to the default of 100MB. In 4.4, 0 is a respected number. #34037
    • When a site’s home, siteurl, or page_on_front option was updated in the network admin, rewrite rules were previously flushed incorrectly, causing rewrite rules for the main site on the network to take the place of the rewrite rules for the site being changed. #33816
    • Subdirectory sites created on an HTTPS network are now set to HTTPS rather than the incorrect HTTP. 🔒 #33620
    • A site’s title can now be longer than 50 characters! #33973

    Deprecated functions:

    Both get_admin_users_for_domain() #34122 and create_empty_blog() #34120 have never been used by WordPress core and are now deprecated. 🍻

     
    • webaware 11:17 pm on October 28, 2015 Permalink | Log in to Reply

      *_network_option functions FTW!

    • Remkus de Vries 12:12 pm on October 29, 2015 Permalink | Log in to Reply

      Thanks for the update Jeremy, and good to see so many small but wonderful updates happening in 4.4 for Multisite!

    • Ian Dunn 11:15 pm on October 30, 2015 Permalink | Log in to Reply

      Kudos to Jeremy and everyone else who contributed 🙂

    • lernerconsulting 6:25 am on November 15, 2015 Permalink | Log in to Reply

      What is happening with domain mapping in WordPress core? Or do we keep using wordpress-mu-domain-mapping plugin?

    • chrisv2 3:22 pm on December 14, 2015 Permalink | Log in to Reply

      I’m really struggling with this as well – there are so many conflicting pieces of information out there. Can anyone confirm (or dis-affirm) that WordPress 4.4 now has domain mapping functionality included in core? I think the WordPress “mu-domain-mapping” plugin is genius – but reading through the code, the idea of being dependent on it scares me.

      I’m lost right now trying to figure out the best and most robust way to enable domain mapping.

    • chrisv2 8:54 pm on December 14, 2015 Permalink | Log in to Reply

      Thanks, Mika. So then what’s the all the hoopla about “WordPress may include this function in the core someday” (which I have read about for domain mapping in more than one article)? One more line of code to handle the cookie setting?

      Your article is very helpful – but when I read the very last paragraph I got nervous again. Is this whole topic of domain mapping so fragile that it can (and will) break, so we should just expect there to be problems?

      • Ipstenu (Mika Epstein) 12:16 am on December 15, 2015 Permalink | Log in to Reply

        Well there’s no allowance for cookies, the GUI is lacking, you can’t have the backend at one domain and the front end at another (something companies like), and so on.

        So it’s not so much adding to core but making it way better in core 🙂

  • Scott Taylor 4:24 pm on October 28, 2015 Permalink
    Tags: 4.4,   

    Today’s 4.4 Dev Chat: Oct 28 

    Dev chat is still at 20:00 UTC this week, even though Europe lost an hour, but it will change next week to 21:00 UTC after the US changes.

    TODAY’S DEV CHAT: Wednesday, October 28, 2015 16:00 UTC-4:

    Agenda:

    • Beta 2
    • Open floor for components
    • Dev post roundup

    Fin.

     
    • Pascal Birchler 5:19 pm on October 28, 2015 Permalink | Log in to Reply

      I probably won’t be around for the chat. The open tickets regarding embeds are the ones mentioned in my last post. #34207 is ready for commit, @rmccue said it looks good to him.

      Working on getting the other bug fixes in as soon as possible.

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