WordPress.org

Make WordPress Core

Welcome to the official blog of the core development team for the WordPress open source project.

Here, we make WordPress core. Follow our progress with general updates, status reports, and the occasional code debate.

We’d love for you to help out.

Looking to file a bug?

It’s easy to create a ticket on our bug tracker.

Want to contribute?

Get started quickly. We have some tickets marked as good first bugs for new contributors. There’s more on our reports page, like patches needing testing.

We also have a detailed handbook for contributors, complete with tutorials.

Weekly meetings

We use Slack for real-time communication. As contributors live all over the world, there are discussions happening at all hours of the day.

We have a project meeting every Wednesday at 20:00 UTC in the #core channel on Slack. (Find out more about Slack.)

You can find meeting agendas on this blog. You’re welcome to join us or listen in.

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Daniel Bachhuber 12:37 am on November 19, 2015 Permalink |
    Tags: , ,   

    WP REST API: Version 2.0 Beta 7 

    Hot out of the version controls, we have a new REST API for you: 2.0 Beta 7 “Tastes Like Burning”. Download it from the plugin repository or from GitHub.

    Here’s the changelog:

    • Sync infrastructure from WordPress core as of r35691.
      • Remove register_api_field() because it’s conceptually tied to WP_REST_Controller #34730
      • Update the REST API header links to use api.w.org #34303
      • Require the $namespace argument in register_rest_route() #34416
      • Include enum and description in help data #34543
      • Save preg_match iterations in WP_REST_Server #34488
      • Don’t return route URL in WP_REST_Request:get_params() #34647
    • Restore register_api_field() within the plugin. (#1748)
    • Require admin functions for use of wp_handle_upload(), fixing fatal. (#1746)
    • Properly handle requesting terms where parent=0 and 0 is a string. (#1739)
    • Prevent PHP error notice when &filter isn’t an array. (#1734)
    • Change link relations to use api.w.org. (#1726)

    Check out the full set of changes if you’re interested.

     
    • Samuel Wood (Otto) 1:07 am on November 19, 2015 Permalink | Log in to Reply

      Nice Simpsons reference.

      “That’s where I saw the leprechaun. … He told me to burn things.”

    • chatmandesign 2:28 pm on November 19, 2015 Permalink | Log in to Reply

      api.w.org is not a valid domain. Was that supposed to be an abbreviation for api.wordpress.org?

      • Daniel Bachhuber 2:28 pm on November 19, 2015 Permalink | Log in to Reply

        api.w.org is not a valid domain. Was that supposed to be an abbreviation for api.wordpress.org?

        It will shortly become a valid domain.

      • Ryan McCue 12:35 am on November 20, 2015 Permalink | Log in to Reply

        It’s only a namespace, so it doesn’t need to resolve to anything in particular. :) In the future though, it’ll probably redirect to the documentation.

  • Ryan McCue 1:27 am on November 18, 2015 Permalink |
    Tags:   

    WordPress Importer Redux 

    Hi, I’m Ryan McCue. You may remember me from such projects as the REST API.

    I’m here today to talk about something a bit different: the WordPress Importer. The WordPress Importer is key to a tonne of different workflows, and is one of the most used plugins on the repo.

    Unfortunately, the Importer is also a bit unloved. After getting immensely frustrated at the Importer, I figured it was probably time we throw some attention at it. I’ve been working on fixing this with a new and improved Importer!

    If you’re interested in checking out this new version of the Importer, grab it from GitHub. It’s still some way from release, but the vast majority of functionality is already in place. The plan is to eventually replace the existing Importer with this new version.

    The key to these Importer improvements is rewriting the core processing, taking experience with the current Importer and building to fix those specific problems. This means fixing and improving a whole raft of problems:

    • Way less memory usage: Testing shows memory usage to import a 41MB WXR file is down from 132MB to 19MB (less than half the actual file size!). This means no more splitting files just to get them to import!
    • Faster parser: By using a streaming XML parser, we process data as we go, which is much more scalable than the current approach. Content can begin being imported as soon as the file is read, rather than waiting for pre-processing.
    • Resumable parsing: By storing more in the database instead of variables, we can quit and resume imports on-the-go.
    • Partial imports: Rethinking the deduplication approach allows better partial imports, such as when you’re updating a production site from staging.
    • Better CLI: Treating the CLI as a first-class citizen means a better experience for those doing imports on a daily basis, and better code quality and reusability.

    Curious as to how all of this is done? Read on!

    (More …)

     
    • pavot 1:36 am on November 18, 2015 Permalink | Log in to Reply

      I can’t express how happy I am about this progress!
      Thank you very much.

    • Jon Brown 1:54 am on November 18, 2015 Permalink | Log in to Reply

      Ditto. This is awesome. Having spent a lot of hours last weekend trying to debug a massive wp.com WXR/XML export (split in over 20 parts and failing on files 14-16)… this is so timely. Looking forward to testing it.

      Curious if the pull parser works with a folder full of xml files the way the WP importer did? Since as I said above, what .com dumped was a couple dozen xml files and I don’t have a convenient way to glue them back together.

      Huge thank you for attending to a long neglected corner of WordPress!

      • Ryan McCue 1:56 am on November 18, 2015 Permalink | Log in to Reply

        Curious if the pull parser works with a folder full of xml files the way the WP importer did?

        You should be able to work with split files by just importing them one after another. (You should also be able to import them in any order, theoretically.) This is something I haven’t put a lot of testing into yet though, so give it a shot and let me know!

        In the future, hopefully we’ll never need to split files again. :)

      • Brent Toderash 6:05 am on November 19, 2015 Permalink | Log in to Reply

        If you’re up for an adventure, on the command line you could do something like

        cat $(ls *.xml -t) > complete.xml

        to stitch the files back together in date order, then try importing the whole thing at once :-)

    • Sakin Shrestha 2:12 am on November 18, 2015 Permalink | Log in to Reply

      Wow this is awesome… Thanks a lot :)

    • nicholas_io 2:13 am on November 18, 2015 Permalink | Log in to Reply

      This is Awesome! The WordPress importer as it currently stands is far from being good. I’ll be happy testing it out

    • Mike 2:20 am on November 18, 2015 Permalink | Log in to Reply

      Great stuff Ryan. Really nice performance improvements. I’ve often ran into memory limits during import.

      As an aside, has there been discussion around offline import, most specifically around media items? Such a possibility would allow for sites to be exported wholly together with all of their content items and either kept for archive or imported more easily. Such a site could have been mocked up on an unreachable development server.

      • Ryan McCue 2:24 am on November 18, 2015 Permalink | Log in to Reply

        Thanks Mike!

        We have an issue filed for that one. Deferring the actual images getting imported will get a few gains: offline imports, parallel downloads, or static content imports (i.e. image files in a zip).

        You can pass 'fetch_attachments' => false (also the default internally, but not in the CLI) into the importer class in __construct for this already. :)

    • Ryan Markel 2:25 am on November 18, 2015 Permalink | Log in to Reply

      Hey, Ryan.

      This is other Ryan. :) We’ve been dealing with super-large imports on WordPress.com VIP for some time now and I’ve been dealing with them for a year-plus. I’d love to chat with you at some point about the kinds of things we have run into in these large imports and in other things that are edgier-case like site merges and other things that the import currently can struggle with.

      Some of what we are doing on WordPress.com is almost certainly not practical for movement to core, but we can probably provide some valuable insight on larger imports and problems that are encountered there.

      • Ryan McCue 2:49 am on November 18, 2015 Permalink | Log in to Reply

        Hey other Ryan! Let’s chat; one of the big use cases that lead to me rewriting this was huge VIP-level imports, so it’s definitely something I’m conscious of. I’d love to have your and VIP’s feedback :)

    • Ipstenu (Mika Epstein) 2:43 am on November 18, 2015 Permalink | Log in to Reply

      This will be a game changer for the many people who want to export from wordpress.com and import to self-hosted where they either can’t afford or aren’t able to use the migration package.

      You, sir, deserve all the pizza bites.

    • Matthew Eppelsheimer 3:15 am on November 18, 2015 Permalink | Log in to Reply

      This is so, so, great Ryan!

      Looking forward to testing this and seeing if our pet bugs in the 0.6 importer to fix “someday” still exist. I’ll bet not…

    • JakePT 3:38 am on November 18, 2015 Permalink | Log in to Reply

      My biggest frustration is the inability to import Posts only and import images at the same time. Images only come across if the entire site is exported. This is very annoying when trying to transfer a client’s blog between sites without bringing across menus and random plugin post types. I can understand the challenge since they’re only img tags and not necessarily attached to the post, but it’s definitely my biggest hangup with the importer.

    • bishless 4:59 am on November 18, 2015 Permalink | Log in to Reply

      This is great news! Thanks for your work, Ryan!

    • jeffmcneill 5:43 am on November 18, 2015 Permalink | Log in to Reply

      I’ve run into a ton of problems with importing, usually a memory or parsing issue. I’ve had to eject a lot of content from several site migrations because of this. That you are working on this critical tool for WordPress means you should be applauded, and lauded. Thank you!

    • DeBAAT 6:26 am on November 18, 2015 Permalink | Log in to Reply

      Reading the responses, you’ve definitely hit a soft spot!
      Thanks already for picking this challenge.

      I myself did have some issues with the importer lately as I was migrating some content from dev to prod.
      And this actually had to do with the GUID, so please take real good care to using this.
      I mean, a post developed on site x.dev typically has x.dev in the guid. When I try to import it into x.com, I would like to have an option whether or not to ‘translate’ the GUID from x.dev to x.com.

      The same goes for the GUID of an image. In some cases, the image may have been uploaded already in the x.com site before. So how do you discriminate between the two images?
      Hope you’ll get it working nicely.

      Reading your article, I thought you mentioned something about changing the exporter as well. I’m not sure however, so are there any plans to work on the exporter as well?

      • Ryan McCue 6:47 am on November 18, 2015 Permalink | Log in to Reply

        The main thing with the GUID is that it shouldn’t ever change. The new importer actually uses it more, so if you change the GUIDs, later imports will reimport the same data again. That said, @westonruter‘s pull request would let you write complex logic to map this back and forth, and I do know it’s a common use case. Happy to discuss further on a GH issue :)

        Specifically on images, there’s a flag in the options in the new importer called update_attachment_guids – the old importer always changes the GUID to the new filename, but this rewrite avoids that by default, as it makes deduplication on future imports impossible. (The reason the old importer did this is because originally the GUID contained the filename, so that’s occasionally used by older code to find the image URL.)

        There’s no real plans to change the exporter right now, but if it turns out we can improve import efficiency by changing data in exports (i.e. avoid post-processing by being careful about the element order), we’ll likely do that.

        Thanks for the feedback!

    • Ahmad Awais 6:38 am on November 18, 2015 Permalink | Log in to Reply

      I’ve had my fair share of WTF Moments™ with WordPress importer. So, believe me when I say this, I am glad someone is finally working on improving that. It’s a great news. Going to test it this weekend.

    • Sam Hotchkiss 6:51 am on November 18, 2015 Permalink | Log in to Reply

      You’re amazing, Ryan, well done.

    • Per Soderlind 6:53 am on November 18, 2015 Permalink | Log in to Reply

      Excellent Ryan, can’t wait to test it :)

    • Dreb Bits 7:30 am on November 18, 2015 Permalink | Log in to Reply

      Truly amazing! Will find time this weekend to test this baby! And thanks a lot initiating the movement to improve the WordPress importer :)

    • Ajay 7:52 am on November 18, 2015 Permalink | Log in to Reply

      This is awesome news. It’s been a long time coming. Are you planning to update the Exporter as well?

      • Ryan McCue 7:54 am on November 18, 2015 Permalink | Log in to Reply

        No major plans there yet, but if there’s improvements to be made there, I’ll be sure to take a look. :)

    • Morten Rand-Hendriksen 8:00 am on November 18, 2015 Permalink | Log in to Reply

      Thank you Ryan. This is a sorely needed upgrade.

    • connectr 8:22 am on November 18, 2015 Permalink | Log in to Reply

      Ooh, goodie! It always baffled me why such an important tool received so little love. The GSoC project looked hopeful, but then not much came from it. Super duper happy it’s back on the radar :)

    • Mario Peshev 8:37 am on November 18, 2015 Permalink | Log in to Reply

      Thanks for the great work Ryan – given the state of the original Importer for years now, that’s incredible news.

    • Omaar Osmaan 8:38 am on November 18, 2015 Permalink | Log in to Reply

      So excited about this- 😀

    • dimitris33 9:42 am on November 18, 2015 Permalink | Log in to Reply

      Great news Thanks!

    • capuderg 10:10 am on November 18, 2015 Permalink | Log in to Reply

      Great!!! So excited! Thanks Ryan for working on this!

    • Tran Ngoc Tuan Anh 10:36 am on November 18, 2015 Permalink | Log in to Reply

      This is a great news.

      I’m wondering about media import. Some themes use licenced images and don’t want to import, they usually are replaced by dummy image as a placeholder. Can we do that (maybe with a filter) with this new importer?

      Also, would it help in importing theme mods?

      • Ryan McCue 10:39 am on November 18, 2015 Permalink | Log in to Reply

        You can filter `wxr_importer.pre_process.post`, which gets passed the full post data, and go ahead and change anything in there. :)

        I’m not sure what the current state of theme mods is in the export data, so I can’t speak to that, but file an issue and I can take a look. :)

    • Primoz Cigler 10:42 am on November 18, 2015 Permalink | Log in to Reply

      Wow, incredible! Just awesome Ryan. It is clear from responses here that this was a huge pain for many people.

      Something came to my mind when I was reading this, I am not sure if it will be relevant, but still worth mentioning: would it be possible to utilize the REST API and switch to JSON instead? I believe it would make for much cleaner approach, as I was always struggling with any XML files, while JSON is so human-readable? I believe the import/export would be possible without the XML file at all, only import WP calling the export WP over the JSON calls.

      I would love to hear the feedback on my thinking and if that is something that should be considered in the future when migrating content over the web, as it sounds much leaner approach :)

      • Ryan McCue 10:48 am on November 18, 2015 Permalink | Log in to Reply

        As the lead developer of the API, I’m conscious of this. 😉

        There’s a number of reasons it’s better to stick with WXR/XML right now:

        • PHP has a streaming XML parser built-in, but it doesn’t have a streaming JSON parser out of the box. This means any streaming parsing would need to take place in userland (i.e. a library), which I suspect would cause performance to be worse.
        • WXR is compatible with RSS, which means the export format can be imported by a lot of other tools, not just WP. Switching to our own format might have benefits to us, but it would likely harm the wider ecosystem.
        • XML isn’t really a problem most of the time. It’s not the greatest format ever invented, but it’s reasonably readable, and there’s tonnes of tooling around it.

        With that said, if somebody wanted to try it, it’d be interesting to see at the least. :) The XML parsing in this new version of the importer is contained in a few small methods, so you could probably swap that out for JSON reasonably easily.

        • Primoz Cigler 10:52 am on November 18, 2015 Permalink | Log in to Reply

          Gotcha, thank you for your swift reply!

          I don’t promise anything, but I might actually try to implement the REST API way. I will give you heads-up if I do.

    • sonjanyc 11:23 am on November 18, 2015 Permalink | Log in to Reply

      This is amazing, Ryan!! You will make so many people so very happy with this, me included!! :)

    • Alvaro Gois dos Santos 11:28 am on November 18, 2015 Permalink | Log in to Reply

      Wow. Awesome @rmccue, thanks!

      Let’s try that importer…

    • Damian 12:55 pm on November 18, 2015 Permalink | Log in to Reply

      Thanks Ryan, this is problem we all faced at some point. My concern is the exporter now. It will be also updated ? Currently how the exporter work is primitive. Eg: You can’t export featured images if you just export posts, you need to export the whole content.

      Or if you want to export just taxonomies becuase you have lots of them and you want to duplicate them in a new site.

      Thanks again!

      • Ryan McCue 1:35 pm on November 18, 2015 Permalink | Log in to Reply

        Right now, I don’t have any plans to work on the exporter (unless there’s performance gains to be had for the importer there), however there’s a few tickets already on that: #27048 and #17379 are the two most relevant here I think.

        At the end of the day, these things just need someone to sit down and spend some time on them. :)

    • Rich Tabor 1:32 pm on November 18, 2015 Permalink | Log in to Reply

      Really glad this is happening!

    • Josh Eaton 2:57 pm on November 18, 2015 Permalink | Log in to Reply

      Wait, so you’re saying I no longer need 8GB of RAM in my local VM just to import a WXR file? 🎉

    • Steven Gliebe 3:21 pm on November 18, 2015 Permalink | Log in to Reply

      This is music to my hears. Thank you for working on this!

    • Ben Doherty (Oomph, Inc) 5:33 pm on November 18, 2015 Permalink | Log in to Reply

      This is great, I’m very excited to see this development. I wonder if parallelization is also something that’s been considered, as PHP is just SLOW when walking through large files, and I found that parallelization can greatly improve overall import times, especially when munging XML files. My quick elevator pitch is that the importer spins off M processes, 1..N, each of which imports every M+Nth post from the file in parallel, and then the post-cleanup operation (translating URLs, IDs, etc) runs when all of the processes have completed.

      • Ryan McCue 11:55 am on November 19, 2015 Permalink | Log in to Reply

        Parallelisation is definitely something in my mind, but given the complex way that the object cache and database interact in concurrent requests (i.e. concurrent saves break basically everything in WP), not something I’ve put a huge amount of time into. :)

        I’d love to see someone have a go at it though! The new importer should let you build this as a plugin on top reasonably easily, so if you want to try it… 😉

    • pathartl 6:12 pm on November 18, 2015 Permalink | Log in to Reply

      A much needed update. I opened up #30887 a while ago when I first noticed the GUID issue, in case you wanted another ticket to close :). Great work as always.

    • Shmoo 2:26 am on November 19, 2015 Permalink | Log in to Reply

      Ryan should get a WordPress company sports car for doing this! 🚗 💨 vroom vroom..

      Can’t wait to test this.. Did you the WP Importer yesterday -10MB file #drama

    • lepardman 9:00 am on November 19, 2015 Permalink | Log in to Reply

      Awesome! Just a thought: it would be nice to have the ability to remap post types (maybe even taxonomies?) on import.

      Example: yesterday I was trying to import posts from an old site to a new one I’m working on. The site was so old that the developers used posts as a way to store the clients products and their actual news posts were just added as text to a huge list in the editor on a page. Some years after, a new developer added a new post type called news since post were “taken”. So I figured that I at least could do an export of the lastest news and the products. Then import them and switch post types, news as post and the products (old post type post) into a new post type called products. But that wasn’t possible, I just got and error that the post type news didn’t exist and the import failed.

      TL;DR: I couldn’t remap posts on import to other (nowadays more correct) post types. A nice way would be to be able to assign them to post type(s) just as you can change author (I guess a bulk option would be needed). I’m unsure if this would be possible but I’m throwing out the idea and then let’s hear what you guys say.

      (I guess I could do a search and replace in the xml files or create the correspondent post type temporarily, import and then do a search and replace in db but it would be so much nicer to have this built in)

      Thank you!

    • chzumbrunnen 3:14 pm on November 19, 2015 Permalink | Log in to Reply

      Wow, Ryan, that sounds great. When I understand you right my biggest question is already somehow fixed.
      Normally for an import the old site hast to be still reachable to get the images. Now with the new importer it should be possible to import images manually. But I’d like to go one step further and be able to enter the path to the images folder from where the images should be imported.

      • Ryan McCue 12:36 am on November 20, 2015 Permalink | Log in to Reply

        The tooling around this stuff will need some time to develop and mature, but I’d also love to have that eventually :) Right now, should be technically possible, but just a pain to do so.

    • DoodleDogCody 3:56 pm on November 19, 2015 Permalink | Log in to Reply

      In regards to Media. I have noticed that with the current importer media items are not imported unless we select export all from the exporter. This seems a little odd to me. Media items should be imported if they exists in a post, page, or whatever post type that we export as media items are not thought of as a seperate psot type to most people. I know that’s how they are stored in the database but If I am building a new site for a client and need to export and import only their posts on the current site. I want to click export post and choose the date range of all. Then when I import I expect the images to import as well.

    • Ella Iseulde Van Dorpe 5:23 pm on November 19, 2015 Permalink | Log in to Reply

      ❤️

    • Samuel Wood (Otto) 12:33 am on November 20, 2015 Permalink | Log in to Reply

      Awesome. I’m gonna steal your XML code. :)

    • Michael Ecklund 8:02 pm on November 20, 2015 Permalink | Log in to Reply

      Thank you for taking the time to update the importer. It’s been begging for attention for quite some time.

  • Daniel Bachhuber 9:54 pm on November 12, 2015 Permalink |
    Tags: , ,   

    WP REST API: Versions 1.2.4 (Compatibility Release) and 2.0 Beta 6 

    First and foremost: version 1.2.4 of the REST API is now available for compatibility with the upcoming WordPress 4.4. Version 1.2.4 overrides REST API infrastructure in WordPress 4.4 core, leaving your endpoints working as you expect them to. Download it from the plugin repository or from GitHub.

    Version 2.0 Beta 6

    Alongside the compatibility release for version 1.2, we’re also releasing the latest beta for version 2.0: 2.0 Beta 6 “Bluella The Whale”. Download it from the plugin repository or from GitHub.

    Here are some highlights:

    • Removes global inclusion of wp-admin/includes/admin.php. For a long time, the REST API loaded wp-admin/includes/admin.php to make use of specific admin utilities. Now, it only loads those admin utilities when it needs them. If your custom endpoints make use of admin utilities, you’ll need to make sure to load wp-admin/includes/admin.php before you use them.
    • Easier access to the featured image. Posts link directly to the featured image, and attachments include media_details attribute in the embed context. For image attachments, media_details includes a sizes array of image sizes, which is useful for templating.
    • Documentation clarifications throughout, including new hook docs.

    As always, we have a detailed changelog as well as the full set of changes if you’re interested.

     
    • Rouven Hurling 10:03 pm on November 12, 2015 Permalink | Log in to Reply

      Okay, so to get the featured image one would have to use “?_embed” and then grab it like this item[‘_embedded’][‘http://v2.wp-api.org/attachment’][0]?
      And it will either be an empty object if no featured image is set or the featured image object?

    • Daniel Bachhuber 10:09 pm on November 12, 2015 Permalink | Log in to Reply

      to get the featured image one would have to use “?_embed”

      Assuming the initial request is for the Post, then ?_embed will give you embedded versions of related resources.

      grab it like this item[‘_embedded’][‘http://v2.wp-api.org/attachment’][0]?

      It’s actually directly linked as item[‘_embedded’][‘http://v2.wp-api.org/featuredmedia’]

      And it will either be an empty object if no featured image is set or the featured image object?

      The link won’t exist if there’s no featured image set.

      • Rouven Hurling 10:15 pm on November 12, 2015 Permalink | Log in to Reply

        Ah, okay.
        I was using http://demo.wp-api.org/ as reference, which isn’t updated yet.
        After updating my local version it makes more sense.

        Any plans for something like `/wp/v2/posts?_embed=featuredimage`, to only embed needed data?

        • Daniel Bachhuber 10:17 pm on November 12, 2015 Permalink | Log in to Reply

          Any plans for something like `/wp/v2/posts?_embed=featuredimage`, to only embed needed data?

          No confirmed plans, but modifying the contents of the response (fields included, embeds added, etc.) is something we’ve been discussing all along.

        • Joe Hoyle 10:25 pm on November 12, 2015 Permalink | Log in to Reply

          I actually wrote a small plugin to do exactly this: https://gist.github.com/joehoyle/12e37c293adf2bb0ea1b

          • Rouven Hurling 8:46 am on November 13, 2015 Permalink | Log in to Reply

            But your version doesn’t seem to work for Collections.
            I modified (mostly copied) it and added a second function to do the same thing for Collections.
            https://gist.github.com/rhurling/e91ddb7b25ccc297508b

            If I understand it correctly it now does basically the same thing, only earlier and for every item, disregarding whether it’s in a Collection or a single Post.

            • Daniel Bachhuber 12:32 pm on November 13, 2015 Permalink

              But your version doesn’t seem to work for Collections.

              This comment thread isn’t an appropriate venue for support. You’re welcome to join us in the #core-restapi channel in the Making WordPress Slack, or continue the conversation with Joe elsewhere.

    • Ahmad Awais 9:41 am on November 13, 2015 Permalink | Log in to Reply

      For how long will you guys support 1.** version of REST API? I have built a few fun projects with it, will update them to REST API 2.0 if the deadline of deprecating v1 is known or something.

      • Daniel Bachhuber 12:29 pm on November 13, 2015 Permalink | Log in to Reply

        For how long will you guys support 1.** version of REST API?

        We’ll be supporting 1.x for security indefinitely. There’s no new development going into the 1.x branch, however.

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

    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: , , ,   

    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!

  • Ella Iseulde Van Dorpe 6:42 pm on November 3, 2015 Permalink |
    Tags:   

    Weekly editor chat resumed 

    After some quiet time in #core-editor, we’d like to resume the weekly editor chats. The next one will be before the weekly developer meeting on Wednesday, 4 November 2015, 18:00 UTC. It will be used to discuss new features, answer questions, and do component bug scrub if there is time. See you Wednesday!

     
  • Daniel Bachhuber 9:30 pm on November 2, 2015 Permalink |
    Tags: , , , , ,   

    Shortcake (Shortcode UI) chat summary – November 2nd, 2015 

    Present: @danielbachhuber, @goldenapples, @matth_eu

    Logs: https://wordpress.slack.com/archives/feature-shortcode/p1446494424000273

    • We released Shortcake v0.6.0. Read through the full release notes.
    • Weekly meetings are on hold until January. Between now and then, we’ll be thinking about what we need to do to put forth a core proposal. @matth_eu might put together sketches.
    • We missed the boat on getting a Shortcake representative to the community summit, and are researching ways to helicopter @goldenapples to said community summit boat.

    Next chat: sometime in January 2016

     
  • Andrea Fercia 8:14 pm on October 28, 2015 Permalink |
    Tags: , , , 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: , ,   

    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: ,   

    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