Make WordPress Core

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Eric Binnion 2:39 pm on May 18, 2016 Permalink |
    Tags: ,   

    Week In Core, May 11 – May 18 2016 

    Welcome back the latest issue of Week in Core, covering changes [37417-37457]. Here are the highlights:

    • 40 commits
    • 31 contributors
    • 74 tickets created
    • 12 tickets reopened
    • 78 tickets closed

    Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.


    • Make the tab order match the visual order in the Edit terms screens. [37439] #35664


    • System font: The stack does not work with the font shorthand property. [37442] #36753
    • Credits: Add a missing closing tag. [37434] #35911
    • Admin font: Remove a redundant sans-serif declaration. [37419] #36753


    Build/Test Tools


    • Add $data parameter to include the comment data in the edit_comment action. [37423] #36427


    • Change attachment condition in the site icon control to prevent errors. [37456] #36749
    • Include shortcut button in Custom Menu widget to edit the selected menu in the Customizer. [37437] #32683
    • Remove use of reserved word default in Underscore template which breaks IE8. Fixes #36793. [37450] [37417] #36793
    • Handle filtering sidebars_widgets when the underlying option is non-existent. Merge of [37352] to the 4.5 branch. Fixes #36660. [37453] #36389, #36660
    • Clean up media control CSS. Removes unnecessary wrapper elements and refactors class names to eliminate duplication of rule selectors. [37426] #30618


    • TinyMCE: prevent showing the placeholder URL when adding a link and clicking more than once on the Insert Link button. Merge of [37301] to the 4.5 branch. [37454] #36637
    • Editor: Merge two strings. [37441] #27756


    Filesystem API

    • Don’t add '.' to the list of directories which need to be checked/created when extracting a file. [37421] #36570


    • Docs: Standardize on ‘backward compatibility/compatible’ nomenclature in core inline docs. [37431] #36835


    • Use prepared JSON data correctly. This was modifying a variable that was never used. Oops. [37444] #36358
    • Pass array-like object to http_api_debug. This was mistakingly passing the Requests_Response object, which caused fatal errors with debugging tools. [37436] #33055
    • Fix compatibility with cURL < 7.22. [37430] #33055
    • Add browser compatibility hook for 3xx redirects. [37428] used the wrong method of adding this hook, now corrected. [37429] #33055
    • Replace internals with Requests library. [37428] #33055


    • In get_translations_for_domain() check if the global $l10n was set by _load_textdomain_just_in_time() before accessing it. [37440] #34114


    Networks and Sites

    • Tests: Set public to 1 in the default blog factory. [37418] #36566
    • Tests: Use factory method to generate fixtures for wp_unique_post_slug() tests. [37443] #20419

    Posts, Post Types

    • Fire a post_action_{$action} action for a custom post action request. [37424] #27056



    • Add changelog entries for when the classes were moved to its own file. [37432] #36618


    • List Tables: Pass the $which parameter to restrict_manage_posts and restrict_manage_users. [37422] #35307


    • Create WP_Widget_Mock as a mock of WP_Widget which can be used for widget tests. You cannot instantiate an abstract class. Not even in WordPress world. [37427] #35981
    • Make WP_Widget a real abstract class. [37425] #35981

    Thanks to @adamsilverstein, @afercia, @boonebgorges, @brianvan, @celloexpressions, @danielhuesken, @DrewAPicture, @dshanske, @helen, @iseulde, @jeremyfelt, @jfarthing84, @joemcgill, @johnbillion, @jorbin, @jrf, @martin.krcho, @mintindeed, @Mte90, @neverything, @ocean90, @pavelevap, @rachelbaker, @ramiy, @rmccue, @samantha-miller, @SergeyBiryukov, @sudar, @swissspidy, @tfrommen, and @westonruter for their contributions!

  • Boone Gorges 2:07 pm on May 18, 2016 Permalink |
    Tags: ,   

    Query component bug scrub – May 24 

    A 90-minute bug scrub for the Query component will be held at Tuesday 24 May 2016, 18:00 UTC in the #core channel on Slack. We’ll spend some time looking through the Awaiting Review milestone, and we’ll have a glance at any specific tickets that attendees might interested in talking about.

  • Konstantin Obenland 7:50 pm on May 17, 2016 Permalink |
    Tags: ,   

    Shiny Updates Chat Summary 5/17/16 

    This is a summary of the shiny updates chat from May 17. (Slack log)

    Attendees: @ocean90, @swissspidy, @j-falk, @mapk, @ethitter, @obenland


    • Accomplished work since last week
      • Review requests were posted to the Accessibility, Flow, Polyglots, and Design teams.
      • The feature project landing page was written and published.
      • @swissspidy merged update-core.php into master.
      • Lots of bug fixes and smaller enhancements went in.
    • Activate after install
      We discussed what the best way would be to provide users with the ability to activate a plugin after it was installed. @swissspidy offered to work on a way that would switch the install button to an activation link after the install queue emptied, so it can be user tested for a more informed decision.
    • Update core
      @swissspidy‘s update-core work was merged into master, where it will remain to receive a broader test coverage than it would in a branch. All updates (except for ‘update all’ button) work via ajax.
    • Open floor
      We decided on a new meeting time, 20:00 UTC, that is one hour later than before.

    Next meeting is therefore on Tuesday May 24, 20:00 UTC.

  • Helen Hou-Sandi 6:45 pm on May 17, 2016 Permalink |  

    May 17 feature projects chat and prompt 

    Today’s feature projects chat will be held at May 18 01:00 UTC. We should cover what each project needs to do next, any other stuck points, and new proposals or ones that need some workshopping. If you cannot make this meeting, leave a comment below with new proposals or questions, and the next meeting will be at May 31 17:00 UTC.

    As a reminder, each feature project needs to develop a clear statement of purpose. This may be an answer to the oft-asked “what problem does this solve?”, but may also be more exploratory in nature. The important thing to keep in mind is to stay away from the “how” or implementation details in the statement itseflf, and focus instead on the what, why, and for whom.

    • Pascal Birchler 8:55 pm on May 17, 2016 Permalink | Log in to Reply

      Emerging out of #28197, I’d like to propose a new Preferred Languages feature project. Currently, users can select the site language in the settings, but it has become clear that this has some limitations, especially for different locales (de_CH, de_DE, formal/informal for example) and missing translations.

      There was quite a long discussion about how this could be fixed implementation-wise, but we really should explore this from a feature project side of things.

      The Preferred Languages project should improve the experience for users which speak different languages. Currently, if your site is configured to be served in de_CH, but a plugin is only translated into de_DE, English strings will be shown, which definitely unexpected.

      For this, I’d like to first explore how other software accomplishes this UI-wise and proceed from there.

      So far @Kau-Boy has shown interest in this too.

    • bonger 12:43 am on May 18, 2016 Permalink | Log in to Reply

      This is a repost of https://make.wordpress.org/core/2016/04/19/new-time-for-feature-projects-chat-on-tuesday-april-19/#comment-30126

      A possible featured project has arisen from #30130 “Normalize characters with combining marks to precomposed characters”.

      The goal of the proposed project (UTF-8 Normalization and Audit) would be to have a consistent, unsurprising experience for users on all systems when dealing with UTF-8 data from any source. This to be achieved by exploring if and when UTF-8 should be normalized, and by auditing existing manipulations of UTF-8.

      Currently no normalization of UTF-8 occurs in WP, which can cause issues for users particularly when they copy and paste from non-normalized sources, or refer to non-normalized file names (eg on Mac OS X systems).

      The code basis of the project would be the existing normalization plugin by @zodiac1978 at https://wordpress.org/plugins/normalizer/ and its exploratory fork at https://github.com/gitlost/tl-normalizer

    • Pascal Casier 8:37 am on May 18, 2016 Permalink | Log in to Reply

      Yes, yes and yes please 🙂
      This discussion about language fallback has been running around for long now among the #polyglots and we all agree this would be extremely useful. The project could evaluate the feasibility of putting it into core, have the choice on website level or (even better) at user level.

  • Adam Silverstein 2:01 am on May 17, 2016 Permalink |
    Tags: 4.5.3,   

    Bug Scrub for 4.5.3 

    We will be meeting Tuesday 17 May , 20:00 UTC (at the usual core dev chat time) in #core to scrub bugs milestoned for 4.5.3.

    There are currently 11 tickets assigned to the milestone.  Most of these have solid patches (or are already fixed and reopened for the branch) and are tagged has-patch or commit , except #36748 which is tagged needs-patch needs-unit-tests.

    Please join us to help work thru these bugs and get some patches committed!

  • voldemortensen 3:30 pm on May 16, 2016 Permalink |
    Tags: ,   

    This Week in 4.6: May 16 – May 22 

    This is the jump-start post for the fourth week of the WordPress 4.6 release cycle.

    Tickets seeking feedback:

    Meetings this week:

    Bug Scrubs

    4.6 Feature Chats

    Weekly Chats

    Notable updates from last week:

  • Andrea Fercia 1:03 pm on May 16, 2016 Permalink |
    Tags: , ,   

    Categories and Tags screens changes 

    In WordPress 4.6 the Categories and Tags screens (and all the custom terms screens that use the same edit-tags.php page) will change in order to make the visual order of the main elements match the tab order. This change is focused on helping people who use the keyboard to navigate the content or use assistive technologies such as screen readers.

    If you’re a plugin or theme author and you’re providing custom functionalities in these screens, there are a few things you should check.

    Why it matters

    For accessibility, the visual order should always match the tab order. The main functionality in a page should just be the first thing in the source markup and other parts of the user interface should never be “skipped”.

    The screenshot below illustrates the current Tags screen. The main content is split in two columns. The first element in the source is the right column with the table to list the terms followed by the tag cloud for the popular tags and the form to add new tags.

    Tags screen visual order and tab order

    The current order of the main content elements in the Tags screen.

    On page load, the initial focus is set on the first focusable field in the form which is the third and last block of content in the page.

    When using the keyboard or a screen reader, content navigation is a linearised process. Starting from the form to add new terms makes sense since this is the main task on these screens. But then users will move forward and they will find just the footer of the page. When relevant parts of content are skipped, it’s more likely for screen reader users to be confused or experience difficulty navigating pages. They just don’t have a clue there is something “before” their navigation starting point. Keyboard users will have to tab backwards to get to the previous content.

    What is going to change

    The two columns in these screens will be swapped. The first one in the source will be the left column, followed by the right column. Also, in the Tags screen, the tag cloud will be moved after the form. Visually, this change will make these two screens more consistent. From an accessibility point of view, the content structure and organization will be easier to understand and navigate.

    The new categories screen

    The new Categories screen.

    The new tag screen

    The new tag screen.

    Things you should check

    • if you’re using CSS or jQuery selectors for your added functionalities, you should consider the order of the elements in the markup has changed
    • there are a number of action hooks and filters in these screens but basically just one will have a different order, see the related ticket for more details

    Note: For more in-depth information see the related Trac ticket: Edit term screens: tab order should match visual order.

    Get ahead of 4.6 and update now!

    If you’re a theme or plugin developer: now is a great time to check your code! 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.

  • Ryan McCue 7:10 am on May 16, 2016 Permalink |

    Rewrites Next Generation: Next Meeting 

    There was a bit of confusion with the last Rewrites meeting, so we never really got to kick off the conversation. Let’s give it another shot this week. The revised kick-off meeting for the Rewrites Next Generation project will hence be on May 18th 23:00 UTC.

    The agenda for this meeting is to discuss problems you see with the rewrites system, any particular use-cases you think should be considered, as well as agreeing on a broad approach for how we want to tackle the problems.

    (In case you missed it, you may want to read the introductory post for the project.)

    Hope to see you all there!

  • Joe Hoyle 1:38 am on May 16, 2016 Permalink |

    WP REST API: Introducing the Authentication Broker 

    As an astute follower of the REST API project may have noticed, authentication with the API has been difficult and incomplete. While cookie authentication solves the issue for JavaScript code running on the site, external sites have a much harder time.

    In particular, connecting a client to multiple sites is near-impossible, as the distributed nature of WordPress would require registering on every site.

    To solve the decentralised registration problem, the REST API team (lead by myself and Ryan) is introducing the Authentication Broker system. Our initial default broker is at https://apps.wp-api.org/ and we’ve published the specification for the system.

    Authentication Challenges

    There are primarily two challenges when it comes to authentication: the protocol and application discovery. The protocol we have broadly settled on is OAuth 1, as the simpler OAuth 2 requires HTTPS. OAuth 1 builds in a cryptographic signing process to avoid replay attacks, while OAuth 2 relies on the security provided by SSL/TLS instead. As there are client libraries available for OAuth 1 in virtually every language, the additional cryptography is simple enough to not worry about too much.

    The second challenge is application discovery. OAuth requires pre-registration of the application on the site, which then issues you a key and secret. This concept should be familiar to anyone who has registered a Facebook or Twitter application. The basic principle here is that you register your application with Facebook, which means the two parties (your app and Facebook) both have the “shared” secret. This is then used for the cryptographic signing. (Technically, Facebook uses OAuth 2, but the difference is not particularly relevant here.)

    Because all WordPresses are their own sites, they are essentially each their own copy of Facebook in the above OAuth flow. This means as an app developer, you need to register an application on a WordPress site (using the OAuth 1 plugin) and copy the key and secret into your app. This is OK for people developing an app for their specific install of WordPress, but it’s no good for developers creating apps that can connect to anyone’s WordPress site. For distributable apps, this would require users to register your application manually on their site, then go through the usual OAuth process. This is the process that open source plugins typically have to do for Facebook and Twitter authentication, and it’s generally a terrible experience.

    Solving Distributed Application Registration

    To solve this issue, we have created a new project dubbed the REST API Authentication Broker. The broker is a separate registry of applications that WordPress installs can use as the authority on what applications can connect to it. This means a developer can create their application with the broker (similar to how they would on Facebook) and then they can use their key and secret to connect to all WordPress installs that delegate to the broker.

    This also allows the broker to revoke bad acting applications from the registry, which will cause the rogue application to be disabled on all WordPress sites using it.

    The WordPress ecosystem is very decentralized, allowing site owners to control who and what has access to their data. The broker adopts this philosophy by allowing anyone to run a broker service which WordPresses can delegate to. Brokers need only to be mutually recognised by the application and site to be used; our initial primary broker is simply a default broker built into the connection plugin. For example, a large organization that has several hundred WordPress installs could run their own broker server to act as the centralized point of authority on what apps they allow to connect to their sites.

    It’s important to note that the broker is never able to access your site or user data directly. It’s just used as a registry of allowed applications that can use the normal OAuth process whereby a user on your site delegates permission on their behalf.

    The Default Broker

    Rather than explaining all this in the abstract, we decided to put our code where our mouth is and build the broker system with the intent for it to be adopted to solve this problem. We’ve been working on this for the last few months, and we’re finally ready to release it.

    The “default” broker is currently hosted on https://apps.wp-api.org/ where you can sign up as a developer to create your app. You’ll be presented with a key and secret that you can use in your app to communicate with the broker and connect to any site using the broker plugin. The goal is to merge the broker plugin into the OAuth plugin, and eventually into core. This is the path we see to being able to authenticate with any WordPress site on the web!

    We’re currently looking for feedback and testing of the new broker system. You can install the broker plugin on your site (which requires the OAuth 1 plugin) from GitHub.

    Much more information about this can be found at https://apps.wp-api.org/ and you can even read the Specification for Brokered Authentication if you wish. The broker server, example client and the theme are all open source on GitHub too.

    Thanks to everyone who helped in the development process and contributed their feedback.

    • Lester Chan 2:33 am on May 16, 2016 Permalink | Log in to Reply

      Getting a 404 after registering and clicking on the activation link in the email.

    • George Stephanis 8:58 am on May 16, 2016 Permalink | Log in to Reply

      So, I assume this operates in a sort of “just in time” fashion, where .org sites pull down and cache the secrets for applications? Or does it query the apps.wp-api server for each request?

      If caching, whats the ttl? Is there active app invalidation, where the broker pings all sites that a secret has been invalidated? Or does it just reject on the next ttl verification request sent by the .org site?

      Cc: @pento as hed been involved in prior discussion on this.

      • Ryan McCue 10:07 am on May 16, 2016 Permalink | Log in to Reply

        When a client wants to connect to a site it hasn’t connected to previously, it asks the broker to help out. The broker then asks the site to create the key and secret, the site passes that back to the client via the broker, then the broker is no longer involved. The key and secret are created by the site as if they’d been manually created by an admin via the UI. The app exists until someone deletes it from the site, or until the broker tells the sites to revoke it.

        The details of the revocation protocol haven’t been sorted yet, but they’ll be based on a similar system to how Certificate Revocation Lists work in browsers (OCSP-style is also a potential solution, but doesn’t work as well for us as it does for browsers). The basic way it works is that sites will check for revocations every X hours.

    • Ross Wintle 10:07 am on May 16, 2016 Permalink | Log in to Reply

      Who OWNS this? Automattic? WordPress Foundation? Human Made? Who are we trusting for availability, confidentiality, and integrity of this service?

      Given that this involves security, this would seem like a REALLY important question that has not been addressed in this post or on the apps.wp-api.org site.

      • Joe Hoyle 10:40 am on May 16, 2016 Permalink | Log in to Reply

        Great question, the project it’s self is owned by the community, it’s all on the “wp-api” GitHub organization. Everything you see on `apps.wp-api.org` is literally 100% open source.

        As for the hosting it’s self, the “default” broker apps.wp-api.org is currently run on some Human Made servers, however this is not the longer term goal. I’d like for this to be hosted on the .org infrastructure, I’m saying that with zero authority over the matter whatsoever – I just think if this model for auth works very well, that would make a lot of sense.

        It’s probably worth reiterating that while this primarily about security / auth, the broker is only vouching for an application registry (so you don’t need to personally pre-add all applications to your WordPress install), it’s never provided access to your site – all that authentication is still handled between the application and your site directly.

      • Ryan McCue 10:48 am on May 16, 2016 Permalink | Log in to Reply

        I think you’re totally right to question this, as the entire system is built on trust. The domain (wp-api.org) is owned by myself, the server the broker is running on is a Human Made server running on AWS. The eventual plan is to transfer this to running on WordPress.org itself, at which point it would be running on Foundation infrastructure.

        The broker protocol doesn’t allow the broker to access data. At worst, it can access the client credentials for the site, but this does not allow any access to the site itself. You still need to authorise the application to connect to your user. At a worst case scenario, the broker can re-use the client credentials and attempt to run a phishing attack to get you to authorise it.

        Fundamentally speaking, your site needs to give some trust to the broker, which in turn requires trusting myself (and partially, Human Made). You’re already trusting me in some sense, as I’m both a core committer and a lead on the API project itself. The broker source could potentially be compromised, as it’s not possible to prove that we’re running the code that’s available. If you’re concerned, you can opt out of the broker system instead.

      • Dan 4:21 pm on May 16, 2016 Permalink | Log in to Reply

        Great question, I’m also wondering who will be handling the monitoring of the system for naughty apps?

        • Ryan McCue 2:02 am on May 17, 2016 Permalink | Log in to Reply

          Currently, me and Joe via the normal API team security processes, but the plan would be to have a volunteer-moderated directory, similar to the plugins/themes repo.

    • Aaron Douglas 2:27 pm on May 16, 2016 Permalink | Log in to Reply

      Is there a way to determine if a site is participating in the authentication broker? I’m thinking more towards the mobile apps so that we can discover the right method of authenticating based upon some simple discovery calls. If someone puts in their username/password we will have to go through a polling process to see if the REST API is enabled, then the broker, then failing back to XML-RPC.

      If a site is pulled from the broker are all of the authentication tokens revoked? Would the users be expected to reauth then?

      Lastly how are applications determined to be “bad acting”? Will there be a formal review process for any blacklisting? Is there a list of criteria/guidelines that app devs can follow? One of my concerns comes from hosting providers that use super strange rulesets to weed out attack traffic from real traffic – its pretty common for the XML-RPC calls from the mobile apps to be tagged as bad (even though its not). Would a hosting provider be able to get an entire app pulled from the broker? Just want to make that the arbitration process is considered alongside the technical process.

      • Ryan McCue 2:12 am on May 17, 2016 Permalink | Log in to Reply

        Is there a way to determine if a site is participating in the authentication broker?

        You can just assume that sites are, and the broker will let you know if it can connect to it or not. Alternatively, the API index on sites with the broker enabled have a `broker` key/value under the `authentication` property, which lets you check if the plugin is active.

        If a site is pulled from the broker are all of the authentication tokens revoked? Would the users be expected to reauth then?

        I’m not sure what you mean by “pulled from the broker”; the broker is a setup-only step really, plus revocation checking. If you disable a broker by disabling the plugin or filtering it out, then the application will basically just continue acting as a manually registered application on the site. Revocation will need to be done by the site manually then.

        Lastly how are applications determined to be “bad acting”? Will there be a formal review process for any blacklisting?

        Currently, it’s very early days, so we’ve not sorted the processes here yet, more just solving the technical issues. As the tech is finalised, we’ll start working on formal process developers can rely on, but for now: applications will be revoked if their credentials are compromised. This could come from an application developer requesting us to revoke the application, or another source informing us that the application is compromised.

        We may have other issues where we need to move fast to stop the bleeding, and we reserve the right to use our judgement to revoke applications, but ideally we’ll never need to do this. We’ll always try our best to act in good faith. 🙂

        (I know this isn’t the best guarantee to try building things on, but it’s early days and we’re not sorted out yet. I promise this will get better in the future.)

        • Jorge Bernal 7:36 am on May 17, 2016 Permalink | Log in to Reply

          applications will be revoked if their credentials are compromised

          Thinking about the apps, the credentials will be “compromised” by default, as they need to be shipped along with the software. Has this scenario been considered?

    • Gary Jones 4:45 pm on May 16, 2016 Permalink | Log in to Reply

      This may be covered by the OAuth spec, but what’s to stop someone taking the credentials from Client A (approved for all sites), and using them within Evil Client B, to pretend to be Client A?

      • Ryan McCue 3:50 am on May 17, 2016 Permalink | Log in to Reply

        If you get the credentials for another client, you can definitely try to act as a different client. There are a few things that make this harder:

        • You don’t have the user token, so you’d still need to convince the user to connect the application to your app.
        • The app has a callback that the site redirects to. It’s possible for installed applications to potentially hijack this, but much harder for web applications to do so.
        • The broker could revoke the app from every site once the credentials have been exposed.

        It’s definitely possible though, which is why you should keep the credentials secret. 🙂

    • Mike Nelson 5:36 pm on May 16, 2016 Permalink | Log in to Reply

      Right on! Thanks wp api team!

    • Chuck Reynolds 1:51 am on May 17, 2016 Permalink | Log in to Reply

      nice this is good. thx guys

  • Helen Hou-Sandi 8:35 pm on May 15, 2016 Permalink |

    New committers for 4.6! 

    Each cycle, the lead developers review guest and potential committers. We’ve been taking the time to assign each new committer a dedicated mentor and ensure we’re getting feedback from and giving it to existing committers, so it took us a little longer to put it all together this time around. Without further ado, we’ve got two new guest committers and two new permanent committers!

    First up, we have Joe McGill (@joemcgill), whose work on responsive images both as a plugin and post-merge has proven invaluable over the last few releases. He has also been serving as a component maintainer for the extensive media component. I look forward to his continued work in this area, as well as other features and parts of core.

    Next, Peter Wilson (@peterwilsoncc) will be joining our Australian contingent of committers. Peter has shown solid judgment and admirable tenacity in chasing down tricky issues across a number of areas, especially as we’re approaching the finish line. The trickiest things always get left for last, and help in those areas is always appreciated.

    Finally, I’m happy to announce that Ella Van Dorpe (@iseulde) and Weston Ruter (@westonruter) are now permanent committers. Their continuous stewardship of the editor and customizer respectively have been exemplary, and we have all been enjoying the great strides that have been made in these areas thanks in large part to them.

    Please join me in congratulating everyone!

    Update: Additionally, all current guest committers have had their commit renewed for the cycle.

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