Have you taken the WordPress 2015 Survey yet?

WordPress.org

Make WordPress Core

Tagged: 4.4 Toggle Comment Threads | Keyboard Shortcuts

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

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

    • 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

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

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

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

     

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

  • Pascal Birchler 10:37 am on October 28, 2015 Permalink |
    Tags: 4.4, , ,   

    New Embeds Feature in WordPress 4.4 

    WordPress has been operating as an oEmbed consumer for quite some time now, allowing users to easily embed content from other sites. Starting with version 4.4, WordPress becomes an oEmbed provider as well, allowing any oEmbed consumer to embed posts from WordPress sites.

    Here’s how that looks like:

    In order to achieve this, WordPress’ oEmbed consumer code has been enhanced to work with any site that provides oEmbed data (as long as it matches some strict security rules). For security, embeds appear within a sandboxed iframe – the iframe content is a template that can be styled or replaced entirely by the theme on the provider site.

    Related ticket: #32522

    What That Means for Developers

    First of all, this new feature means that any post (or basically any public post type) will now be embeddable. If you’re using pretty permalinks, the embeddable content will be available at example.com/your-post/embed/.

    If you’re a developer, make sure you do not add an embed rewrite endpoint yourself!

    Functions and Hooks

    Here are the four most useful functions related to embeds:

    • get_post_embed_url() — Retrieves the URL to embed a specific post in an iframe, e.g. https://make.wordpress.org/core/2015/10/28/new-embeds-feature-in-wordpress-4-4/embed/
    • get_post_embed_html() — Retrieves the full embed code for a specific post.
    • get_oembed_endpoint_url() — Retrieves the oEmbed endpoint URL for a given permalink, e.g. https://make.wordpress.org/core/?oembed=true&url=<url>. This is used to add the oEmbed discovery links to the HTML <head> for single posts.
    • get_oembed_response_data() — Retrieves the oEmbed response data for a given post, according to the oEmbed specification.

    Of course the return values of these functions are all filterable, making it easy for you to customize this new feature.

    Customizing The Output

    The embed template mentioned earlier can be customized similarly to any theme template file. Use embed_head and embed_footer to add custom code in the beginning and the end of the template.

    Note that an X-WP-embed:true header will be sent when that template is used, so you can easily target embedded posts in your application.

    Further Improvements

    We’re currently tweaking the embeds functionality to sort out the last few bugs. Here’s a short list of tickets that are being worked on and their purposes:

    • #34204 — Improved support for IE7+. This will also introduce a enqueue_embed_scripts hook that can be used to enqueue JavaScript and CSS.
    • #34451 — Improved support for embedding posts on non-WordPress sites
    • #34278 — Add support for embeds in the theme template hierarchy, allowing you to override the template easily in your theme.
    • #34207 — Leverage the REST API structure for the oEmbed endpoint.
    • #34462 — Add a <blockquote> fallback for the iframe.

    Disabling The Feature

    Don’t like these enhanced embeds in WordPress 4.4? You can easily disable the feature using the Disable Embeds plugin if you really want to.

     

    • th23 10:51 am on October 28, 2015 Permalink | Log in to Reply

      Shouldn’t this feature have a switch in the “Options” to be disabled, rather than requiring another plugin to be installed?

      • Martin Stehle 12:16 pm on October 28, 2015 Permalink | Log in to Reply

        I wish that as an option, not as a plugin, too.

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

        Such a feature shouldn’t get an option to disable it because only few people should ever feel they need to do that.

        The new embed functionality has been developed with the majority of users in mind. It just needs to grow. Imagine that you can paste a URL for a WordPress site, and know that it will be embedded in your editor.

        • maximeschoeni 6:29 pm on October 28, 2015 Permalink | Log in to Reply

          A few people – those who use wordpress as a custom CMS – still represent tens of thousands… Is it really the right way to have them to add one more remove-something plugin at every wp updates?

        • th23 10:36 am on October 30, 2015 Permalink | Log in to Reply

          Sorry, but a feature – that either loads content from an external site or allows embedding of own content in a foreign site SHOULD have an option to disable in my opinion!

          Just few reasons for it I can think of:
          1) It might slow down page loads
          2) It might be a gate for any cross-site vulnerability
          3) The owner of a site should be the one who controls what happens with his content

          If an option to disable is too much, than maybe the feature itself should be/ remain a plugin to add?

      • Aaron Jorbin 9:45 pm on October 28, 2015 Permalink | Log in to Reply

        Options aren’t free. As the WordPress Philosophies section on Decisions not Options states:

        Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration. As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.

        The vast majority of users benefit from having their content embeddable. The smart decision is to make content embeddable and to not burden users with the weight of an option.

        • maximeschoeni 3:14 pm on October 29, 2015 Permalink | Log in to Reply

          So why not add an hidden option, only editable from wp-admin/options.php, where most users will never go?

        • FolioVision 2:29 am on November 3, 2015 Permalink | Log in to Reply

          That’s what Advanced Options pages are for, along with intelligent defaults. Just tell the users at the top that normally they do not need to change this.

          While I think the feature itself is a fantastic idea for those who want, it does seem that oEmbed should ship turned off. People should have a choice about how they run their websites. oEmbed is not essential functionality, hence should ship turned off.

          • George Notaras 3:24 am on November 22, 2015 Permalink | Log in to Reply

            I second that. +1 for adding an option, +1 for shipping 4.4 with this feature turned-off by default.

            I assume lots of people will be frustrated when they find out that their posts will suddenly (after an upgrade) be allowed to be embedded in 3rd party web sites without their consent. Moreover, there is the possibility of the unnecessary extra server load .

            An obvious switch in the settings for a feature like this should be considered a natural expectation.

            My 2 cents.

            • George Notaras 3:47 am on November 22, 2015 Permalink

              Just noticed that only an excerpt is displayed in the embed instead of the whole content. In this case, shipping 4.4 with this feature turned on might make sense, but, IMO, an option is still necessary.

    • Martin Stehle 12:13 pm on October 28, 2015 Permalink | Log in to Reply

      Great work! Thank you! During playing with the embed functions in WP 4.4-beta1 I realize that the arguments and the comments for the functions get_post_embed_html() and get_oembed_response_data() as found in /wp-includes/embed-functions.php are strange:

      • get_post_embed_html(): the function catches arguments (parameters). The first one is optional, the next ones are not. So you can not omit the first argument, so it is not optional. Same for the function get_oembed_response_data().
      • The comment (lines 454 and 514) says the default value of the $post variable would be the global variable $post. But in the parameters list the function’s variable $post is set to null by default. So you have to get the post object or its ID before calling the function and pass it as the first param to the function. It is neither optional nor set to the global variable $post by default, in contradiction to the comment.
      • The other params are $width and $height. In get_oembed_response_data() there is a filter for them setting width to 200 and height to 600 by default. That values should be written in the param list of the function, too. So that params can be optional. Or they are not necessary because there is a filter hook.
      • get_oembed_response_data() sets $height automatically to 16/9 of $width. get_post_embed_html() does not calculate a height; that function needs width and height as params. For me that seems inconsistent.

      I would be happy if there are some revisions. I would wish:

      • all arguments of both functions are optional
      • width and height are filterable in both functions.

      Thank you!

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

        Thanks for the feedback! Now that you mention it, it wouldn’t hurt improving that function. Would you mind creating a ticket for that? Some notes:

        > The comment (lines 454 and 514) says the default value of the $post variable would be the global variable $post.

        If you pass null to get_post_embed_html(), get_post( $post = null ) will return the global post. You can’t set the global post as the default in the function signature.

        > get_post_embed_html() does not calculate a height; that function needs width and height as params. For me that seems inconsistent.

        The function is meant to only return the embed code, nothing more. When the height is already calculated, why calculate it again further down the stack, duplicating logic?

      • Pascal Birchler 11:24 am on October 31, 2015 Permalink | Log in to Reply

    • WP Sites - Brad Dalton 2:25 pm on October 28, 2015 Permalink | Log in to Reply

      Cool function but based on my testing locally it really slows down page loading times when using external URL’s.

    • chrishoward 9:28 pm on October 28, 2015 Permalink | Log in to Reply

      This is awesome! Currently doing this with RSS. Can it grab the latest post?

      • Pascal Birchler 7:27 am on November 2, 2015 Permalink | Log in to Reply

        It’s not something automated. You paste the URL of the post and it gets embedded. If you want to automatically embed the latest post, you’d need to build that manually.

    • mrjarbenne 10:58 pm on October 28, 2015 Permalink | Log in to Reply

      Am I correct in assuming this will now eliminate the need to white-list additional oembed providers as per: https://codex.wordpress.org/Function_Reference/wp_oembed_add_provider

    • Gary Jones 11:33 am on October 29, 2015 Permalink | Log in to Reply

      One more ticket created:

      #34481 – oEmbed “Read more” accessibility.

    • pradeepdotco 3:14 pm on October 29, 2015 Permalink | Log in to Reply

      Awesome work Pascal!

      Will this also work with Shortlinks? Instead of using the full URL, can someone just embed WordPress posts with the Shortlink for that post?

      And what if someone is using custom URL for Shortlinks?
      (For example, I use a custom URL http://WPi.sm for Shortlinks for my website https://WPism.com/ ) Will this still work?

    • Matt Barrett (corradomatt) 5:32 pm on October 30, 2015 Permalink | Log in to Reply

      While I think that this is a cool feature, I do agree with those voicing concerns about adding a plugin to remove such a feature.

      The biggest negative issue I see with this feature is that the vast majority of site owners will not realize that anyone can embed posts or content across the interwebs. Without any sort of control over who and where these embeds occur, it could have a great impact in terms of site owner bandwidth usage. For that reason alone I think it worth while to add the ability to turn off the feature through something like a constant flag in wp-config.php … or better yet, to require that site owners specifically turn this feature on in wp-config.php.

    • Phil C 10:50 pm on November 1, 2015 Permalink | Log in to Reply

      Nice feature, but it should really be something which can be disabled via a constant in wp-config.php, surely?

    • Julio Potier 12:33 am on November 2, 2015 Permalink | Log in to Reply

      Hello,

      1) i can’t read anywhere that the embed post will display the excerpt, so if you’re using a template (like a contact.php custom template) it will still display the post_content you wrote in the backend like “DONT DELETE THIS PAGE”, logical but not for everyone you know.

      2) Also, why 600 px and not $content_width?

      3) Did you test the performance difference? Because if i understand the behavior, now, for each URL in my content, a wp_safe_remote_get() will be done on it everyday, yes for each ULR in each post, each day of year. wow.

      Thank you

      • Pascal Birchler 7:33 am on November 2, 2015 Permalink | Log in to Reply

        Also, why 600 px and not $content_width?

        Because $content_width is only relevant for your site, but other sites will embed your site with a different $content_width. Note that 600px is only the default and WordPress will pass the ideal width for a site ($content_width if set) to an oEmbed endpoint.

        Because if i understand the behavior, now, for each URL in my content, a wp_safe_remote_get() will be done on it everyday, yes for each URL in each post, each day of year. wow.

        No, that’s not how it works. There’s 1 HTTP request when pasting the URL to get the iframe embed code. After that, the iframe is of course loaded when a user visits the post. Since that happens on the client side, it won’t affect your server.

    • Rene Hermenau 12:33 pm on November 12, 2015 Permalink | Log in to Reply

      It´s a nifty feature which is able to bring extra traffic to everyone of us very easily. I welcome that Pascal took care of making it completely deactivatable so i can not say anything against this feature.

      I am using wordpress as a CMS and i am aware that there is a whole bunch of plugins and extra function i have to install first before WP is doing what i want.

      It’s a hard decision to determine what features should be core and what not.

      Devs just want to have a small code base where they are able to enable only the features they want, regular user are preferring the all including feature monster.

      Personally i would also prefer a smaller and stripped wordpress framework with fewer functions and improvements in other directions but wp development and market grow goes on and that’s the most important part for me.

      However, a (developer only) section that would able to enable/disable complete features is something which would be extremely helpful for everyone of us who is using WP for more than the average user and who is worrying about speed, scalability and the hunger for system resources.

      This section could be available only for devs when they define a constant in wp-config so there would be no interfering with the principal of https://wordpress.org/about/philosophy/#decisions

    • ramthas 9:18 am on November 20, 2015 Permalink | Log in to Reply

      Very interesting,
      if the source performs an update the recipient can detect it or once incorporated the content remains the same?
      Sorry horrible English translated with google

  • Ryan McCue 6:30 am on October 28, 2015 Permalink |
    Tags: 4.4, , ,   

    REST API: Welcome the Infrastructure to Core 

    Hi from the REST API team! We’re extremely excited to announce the API infrastructure has now been merged into core as of r34928 (plus a couple of fix up commits we won’t mention). Huzzah!

    Sincere thanks to every single one of the contributors, we wouldn’t be where we are today without you. It takes time and effort to produce great things, and it’s impossible to make things great without everyone helping. This has been a truly collaborative effort, and I wish I could do more than just give you props.

    (Important note: if you have a 2.0 beta already installed, you must upgrade to beta 5.)

    What’s included in 4.4?

    As mentioned in the merge proposal, the API comes in two parts: infrastructure and endpoints. In 4.4, the infrastructure is now available as part of core, while the endpoints continue to only be available in the plugin.

    You can think of the infrastructure as an “API construction kit”. WordPress 4.4 will make it possible for everyone to build RESTful APIs in a much easier fashion, which will benefit people building custom APIs for their site. The infrastructure handles the routing, argument handling, JSON serialisation/deserialisation, status codes, and all that other lovely REST stuff.

    For client authors, this doesn’t help you much right now. Hold tight, the team is working as fast as we can on the endpoints to get them ready for a future release. In the meantime, you can make sure sites you want to work with have the plugin installed, which isn’t a change from the current state.

    For plugin and theme authors, you can start building new APIs immediately using the infrastructure now in core. This can start replacing your existing custom admin-ajax endpoints or other bespoke code you already have.

    To authenticate with the API, only built-in cookie authentication is available out of the box right now. The OAuth 1 plugin will continue to work with WP 4.4 and the API plugin, as will the Basic Auth plugin for local development.

    It’s super easy to get started, and there’s even a guide available to kick-off. (Note: the WP_REST_Controller class is not included in WordPress 4.4.) This documentation will be migrated across to developer.wordpress.org soon.

    If you want to access any of the built-in data in WordPress without building it out yourself, you’ll need the endpoints as well. These will continue to be packaged in plugin form, and version 2.0 final will be released to accompany 4.4 before the end of this cycle.

    What if I’m using the API already?

    If you’re on version 2 of the API, you’ll need to update the API to beta 5 or later before updating to the latest version of core. This new version will use the new infrastructure in core if available, or fallback to a compatibility library otherwise.

    Important note: Earlier 2.0 betas (1 through 4) are incompatible with WP 4.4. Your site will fatal error if you don’t upgrade to beta 5 or later. You must upgrade to the latest API to run trunk and to run WP 4.4 when it’s released.

    If you’re on version 1 of the API, you won’t hit any fatal errors straight away, but endpoints will stop working with 4.4. We’re still planning on releasing a final version 1 release for compatibility, but now would be a great time to consider migrating forward to version 2. Apart from security releases, version 1 has ceased being actively maintained.

    Looking forward for the API

    Now that the API is past this first hurdle, it’s important to keep looking forward. Our immediate next step is to improve and polish the endpoints for phase two of our merge. There’s a lot of work still to be done here, so we’d love you to join us on GitHub.

    The infrastructure of the API will now be maintained via Trac, so new issues and patches should be sent there instead under the “REST API” component. Issues with endpoints should still be filed on GitHub. Don’t worry if you’re not sure; you can file issues on either Trac or GitHub, and they’ll be triaged into the correct place as needed. (It’s more important to make sure the issue is filed in the first place!)

    The team wants to keep pressing forward with the API and keep up our rate of progress, if not improve it even further, and we’d love your help. We still need help from content writers on our documentation, designers and developers on our authentication plugins, and developers on the endpoints. If you want to help, we can always use a hand, and we’d love to help get you started. We’re available in the #core-restapi room on Slack, and we’d love to see you at the weekly meeting at Monday 23:00 UTC 2015.

    We look forward to continuing to work on the API and getting these endpoints happening. Thanks again to everyone who got us here.

    (Then again, maybe a REST API is more of a Shelbyville idea…)

     

    • Ahmad Awais 9:20 am on October 28, 2015 Permalink | Log in to Reply

      It’s a new day :) Looking forward to how REST API transforms WordPress as a platform and in turn the WWW.

    • Ahmad Awais 9:33 am on October 28, 2015 Permalink | Log in to Reply

      It’s a new day! Excited to see how REST API helps WordPress grow as an ultimate go-to platform for all the web development needs.

    • Manny Fleurmond 11:36 am on October 28, 2015 Permalink | Log in to Reply

      Are the models/collections/etc part of this or do those come later?

    • Stephane Daury (stephdau) 2:44 pm on October 28, 2015 Permalink | Log in to Reply

      Congrats on a monumental effort by the whole team.

    • Justin Sternberg 3:56 pm on October 28, 2015 Permalink | Log in to Reply

      🎉👏🍺

    • Mahesh Waghmare 3:57 pm on October 28, 2015 Permalink | Log in to Reply

      Great….!

    • karlazz 8:33 pm on October 28, 2015 Permalink | Log in to Reply

      Congratulations!

    • Jon Brown 11:25 pm on October 28, 2015 Permalink | Log in to Reply

      A whole new world awaits… thank you to the tireless devs working on this the last couple years!

    • Scott Bolinger 4:59 pm on October 29, 2015 Permalink | Log in to Reply

      Congrats guys! Is the wp-api 1.x plugin compatible with WordPress 4.4?

      • Aaron Jorbin 6:32 pm on October 29, 2015 Permalink | Log in to Reply

        As noted in the post:

        If you’re on version 1 of the API, you won’t hit any fatal errors straight away, but endpoints will stop working with 4.4. We’re still planning on releasing a final version 1 release for compatibility, but now would be a great time to consider migrating forward to version 2. Apart from security releases, version 1 has ceased being actively maintained.

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

      We’re still planning on releasing a final version 1 release for compatibility, but now would be a great time to consider migrating forward to version 2

      I’m still not clear on the upgrade path for sites running the 1.x plugin in production. I don’t really want to start running v2 on production until it’s stable, and I also don’t want to spend a lot of time upgrading my customizations until v2 is stable, in case anything changes.

      So, if I upgrade to 4.4 and the final 1.x plugin at the same time, will everything continue working? Or, do I need to wait until v2 is stable, then upgrade my customizations to work with it, and then install 4.4?

      • Joe Hoyle 1:22 am on November 14, 2015 Permalink | Log in to Reply

        The latest version of the 1.x plugin will continue to work with 4.4 – just make sure you update the plugin when you upgrade to 4.4.

        Right now, the 1.x plugin essentially overwrites the v2 infrastructure that is in core, so that does mean that you won’t be able to take advantage of the REST API infrastructure bundled in core if you are using v1. This will be resolved in a future update however.

  • Rachel Baker 2:45 am on October 28, 2015 Permalink |
    Tags: 4.4, ,   

    Comment Object and Query Features in 4.4 

    Without comments, a website is as effective at creating a community as the Chicago Cubs are at winning World Series titles. WordPress 4.4 is a rebuilding release and the comments system is much improved under the hood.

    This release lays the groundwork for future features and improvements.

    A New Classy and Strong Comment Object

    The new WP_Comment class provides a single organized comment object that models its row in $wpdb->comments. You may be familiar with this approach from WP_Post, which inspired the caching implementation used in WP_Comment.

    This was a prerequisite to many of the other comment-related bug fixes and features added in 4.4. The WP_Comment class is marked final to retain flexibility while it is young.

    See #32619.

    Comment Queries for the Whole Family

    WP_Comment_Query has new query parameters for traversing your comments family tree.

    • parent__in takes an array of comment parent IDs to return all matching children.
    • parent__not_in takes an array of comment parent IDs and does not return any matching children.
    • hierarchical can be set to either threaded, flat, or false.
      • threaded returns a tree for matched comments, with the children for each comment included in its children property.
      • flat returns a flat array of matched comments plus their children.
      • false does not include descendants for matched comments. This is the default behavior.
    • orderby has a new option comment__in, useful when querying by comment__in the matched results will return in the same order.

    See #8071 and #33882.

     

    • Piet Bos 2:52 am on October 28, 2015 Permalink | Log in to Reply

      To be honest, none of the site I develop and have developed this year actually have comments. The first mu-plugin I install is remove comments absolute.
      I think in your analogue you can replace “site” with “traditional blog” :)

      • Pippin Williamson 2:54 am on October 28, 2015 Permalink | Log in to Reply

        I’ve used comments extensively in numerous sites / projects, just rarely for their standard and intended use 😀

        Love these improvements!

      • Aaron Jorbin 3:31 am on October 28, 2015 Permalink | Log in to Reply

        It all depends on what you are after on your sites. Sure, you can look The New York Times, WIRED, and the Washington Post as “tradional blogs”, but I tend to think of them more as the mainstream media. Sites come in all shapes and sizes. Plenty of the smaller sites I’ve worked had no need for comments, while others live and breath based on the user interaction that comments provide. At the same time, not having comments can be a solid editorial decision as well. It all depends on the goal of the site. The important thing is that efforts like the one that Rachel announced here are making WordPress better. It is important to respect that work, even when it’s on a feature you don’t use.

    • Ahmad Awais 3:16 am on October 28, 2015 Permalink | Log in to Reply

      WordPress 4.4 is going to be the most feature-rich release ever. `WP_Comment` class is a worthy improvement.

    • Ansel Taft 7:33 pm on October 28, 2015 Permalink | Log in to Reply

      Let’s be fair, there are teams who have never won a world series, AKA the San Diego Padres. While the Cubs slam was topical, let me tell you about the infinite tears stemming from my hometown team.

      Our nation’s former past time aside, I like what I’m reading about the new comment class. Kudos!

      • Ipstenu (Mika Epstein) 11:33 pm on October 28, 2015 Permalink | Log in to Reply

        Ansel, Rachel’s from Chicago :) As someone who has been a part of both fan franchises, the Cubs win for the OMG are you SERIOUS? (The Padres have seen the World Series twice in living memory. Same cannot be said of the cursed cubs.)

  • Tammie 6:14 pm on October 23, 2015 Permalink |
    Tags: 4.4,   

    Under the hood of Twenty Sixteen 

    Twenty Sixteen is the new default theme for WordPress 4.4. This year the process has been done differently, with an exciting exploration of how default themes are created. The theme has been developed on GitHub and you can follow along here. The theme has also been synced every night with the WordPress.org theme repository. This has meant more people have been able to use them theme earlier than previous default themes.

    As Beta 1 is now out, it’s a great time to explore a little more about what Twenty Sixteen contains and how the contributions have shaped this default theme so far.

    Features of Twenty Sixteen

    This theme is designed to be a fresh take on the traditional blogging format. It includes:

    • Multiple menu positions and a social menu.
    • Optional sidebar.
    • Custom color options and beautiful default color schemes.
    • Harmonious fluid grid using mobile-first approach.
    • Custom background and header.
    • Overflow displaying large images.
    • Ability to add intro to post using custom excerpt.

    Contributions to Twenty Sixteen

    During development, there have been some amazing contributions along the way. These include:

    • Lots of accessibility improvements. The Accessibility team have done amazing work reviewing and ensuring Twenty Sixteen is better than any other default theme for accessibility.
    • Improved js handling and tidying in files. Thanks to contributions, the theme js and that of other default themes has been reviewed and optimised.
    • Numerous design enhancements including sub menus.
    • Travis testing integrated with the repo.
    • Device and browser testing. Everyone really helped put this theme through it’s paces.
    • The addition of singular.php.
    • Responsive image support (on the way).
    • Prefixing cleaning up to focus on browsers using.
    • Sanitisation and escaping.
    • Adding of core comments navigation.
    • Hyphenated post titles for better language support.
    • Numerous bug fixes, code tidying and countless tiny improvements.

    A big thank you to everyone that has helped make Twenty Sixteen the theme it is. It’s been incredible to see everyone so engaged and active over on GitHub.

    With Twenty Sixteen on GitHub, if you have a bug you’d like to report you can do so using GitHub right here.

     

  • Boone Gorges 2:27 pm on October 23, 2015 Permalink |
    Tags: 4.4, ,   

    4.4 Taxonomy Roundup 

    We’ve made lots of improvements to the Taxonomy component for WordPress 4.4. Let’s round ’em up, pardner!🐴

    Term Meta

    The most significant improvement is the introduction of term meta #10142. Use the new term meta API – add_term_meta(), update_term_meta(), delete_term_meta(), and get_term_meta() – to store arbitrary data about taxonomy terms, in the same way you would for posts, users, or comments. The term query functions get_terms() and wp_get_object_terms() now support a ‘meta_query’ parameter, with syntax identical to the corresponding argument for WP_Query, etc.

    Term meta was built with performance in mind. When fetching terms using get_terms() or wp_get_object_terms(), metadata for located terms is loaded into the cache with a single database query; disable this by passing 'update_term_meta_cache' => false in your query parameters. When querying for posts using WP_Query, we have another trick up our sleeves: term meta for terms belonging to matched posts is lazy-loaded, so that all relevant term meta is only fetched the first time you call get_term_meta() in the loop.

    Developers who have previously implemented term meta in their own plugins or client sites should prepare their customizations for WordPress 4.4, to ensure that nothing’s broken in the transition.

    WP_Term and unique term IDs

    For the last few releases, we’ve been working hard on the taxonomy roadmap. A major achievement was the complete splitting of shared taxonomy terms in 4.3, which ensures that terms can be uniquely identified by their term_id. In 4.4, we begin taking advantage of this uniqueness: the $taxonomy parameter is now optional in get_term() and get_term_field(), functions that previously required both $term_id and $taxonomy.

    Under the hood, we’ve introduced WP_Term, a new class that properly models a term object #14162. Everywhere where terms can be retrieved – one at a time, as in get_term() or get_term_by(), or in bulk, as in get_terms() and wp_get_object_terms()– you should expect WP_Term objects to be returned, rather than stdClass. For 4.4, this change doesn’t affect much, aside from making our term-caching internals somewhat more sane. But in the future, WP_Term will allow for more extensive caching throughout the Taxonomy component, as well as the potential for method chaining and other developer conveniences.

    Other goodies

    We’ve made lots of smaller improvements to Taxonomy as well. Some highlights:

    • Registering a taxonomy with 'public => false' now prevents the taxonomy from being queried publicly. (Imagine that!) #21949
    • The $taxonomy parameter for get_term_by() is optional (and ignored) when fetching by term_taxonomy_id. #30620
    • Argument arrays are now filtered in get_terms(), register_taxonomy(), and in the Categories post edit metabox. #33026 #33369
    • Accented characters in term names are no longer ignored when checking for duplicates, allowing for, eg, tags ‘foo’ and ‘fóó’ to coexist. #33864
    • Term relationships caches are properly busted during wp_remove_object_terms(). #34338
     

← Older posts

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