Make WordPress Core

Updates from October, 2016 Toggle Comment Threads | Keyboard Shortcuts

  • K.Adam White 11:15 pm on October 13, 2016 Permalink |
    Tags: ,   

    Merge Proposal Discussion: REST API Content Endpoints 

    There are discussion meetings and office hours in #core-restapi at 2016-10-14 14:00UTC and 2016-10-14 19:00UTC on Friday the 14th. Our next team meeting is on 2016-10-17 14:00UTC. Please attend some of all of these, because

    We are meeting at 2016-10-18 01:00 UTC to make a decision on this merge proposal!

    To that end, the below discussion points will be updated regularly, please leave comments on this post or join the conversation in #core-restapi.

    Yesterday at the dev chat the API Team proposed the Content API Endpoints for merge in WordPress 4.7. There was popular support for this feature but as @jorbin and @helen noted that the lack of dissent suggested additional review is needed, so the API Team is continuing to seek thorough review & constructive criticism of the content endpoints, including the open questions previously shared on the week 7 and week 8 API team updates.

    The merge proposal also engendered follow-up discussion in the #core-restapi channel about the benefit content endpoints bring to core, whether having such endpoints built in is quantifiably more beneficial than having them as a plugin, whether moving development from a plugin to core would slow development, and whether the endpoints as-proposed have been sufficiently reviewed for security and performance. We attempt to capture those questions & concerns (and the perspectives on them) below.


    Have the content API endpoints been thoroughly reviewed for security?

    • The REST API plugin has been on HackerOne for over a year with paid bounties for bugs
    • @barry has begun a security review


    How does the API measure up against alternatives? Are there concerns about how the API could impact the servers to which it is deployed?

    • DeliciousBrains did a performance comparison with Admin AJAX and found the REST API to have a performance improvement (These tests have not yet been independently verified)
    • @mikeschroder notes in the comments that using the REST API in place of Admin-Ajax will also bring speed benefits by permitting many previously-uncacheable requests to be cached.

    User Feedback

    Are the content endpoints sufficiently well-tested & vetted by the community?

    • @matt questions whether feedback is coming too late in development for concerns to be acted upon
      • @rmccue notes that the v2 endpoints were created based on user feedback; REST API endpoints are being deployed by plugins and running on VIP, and the content endpoints have been in wide use across a variety of sites, leading to 90+ code contributors and far more developers’ support & feedback on the endpoints
    • @rmccue has also reached out to Phil Sturgeon for feedback and will follow up

    Do Content Endpoints Benefit Core Development?

    Will having these endpoints in core improve future core development, or solve any immediate problems?

    • @bradyvercher suggested that the content API endpoints would remove the need to write a variety of one-off ajax callbacks when developing future WordPress Core AJAX functionality
    • @westonruter notes that the customizer could dynamically create settings for posts and other kinds of content without having to wire up new admin-ajax handlers

    Will Merging Negatively Impact API Development?

    Will having to work through trac instead of GitHub cause development to atrophy?

    • @jjj argues that merging will slow development, because GitHub-hosted plugins are not bound to WordPress release cycles and have less overhead for features to be developed and deployed for testing. @jjj requested a plan for how the REST API will be developed going forward after the merge of these endpoints that would account for the added friction.
    • @krogsgard countered that core increases the visibility of a project like the content endpoints
      • The number of new contributors in this Slack discussion suggests that this merge proposal is bringing in new voices; whether this supports Brian’s point or not, the team is grateful for the breadth of perspectives being shared -Ed.
    • @rachelbaker suggested that the API endpoints are sufficiently inter-dependent with core WordPress code that maintaining the plugin separately amounts to maintaining a fork, and that such separated development is untenable long-term.
    • @matt hopes that a merge of these endpoints would slow release speed, but not development speed; @rmccue feels that development speed will stay the same or increase, and that tying releases to WordPress Core increases the stability and predictability of the API endpoints.
    • The versioning of the API endpoints supports forward compatibility

    Do Content Endpoints Belong on Every WordPress Site?

    What are the pros and cons to having every WordPress site have content API endpoints?

    • @rmccue suggests the API has network effects that can only be realized with a large install base. @krogsgard draws a comparison to RSS, the widespread availability of which enables everything from podcasting from WP to the use of apps like Feedly.
    • @matt suggests that the Atom API is a better analogue than RSS, which is an independent and pre-existing standard, and that network effects could be tested through inclusion in Jetpack
    • @joostdevalk notes that many plugins, like Yoast, have data tied to existing content such as posts and pages; either they expose the content through their own endpoints, or core does. If Core exposes content types through the API then plugins may build on top of that shared foundation, not independently reinvent the wheel. “if this doesn’t end up in core, we’ll start rolling our own API for stuff. Others will too. Interoperability won’t be there, for even the most basic stuff. I think this isn’t like RSS, I think this is much more like all of us using the same table space in MySQL.”
      • @shelob9 and @masonjames agree that merging the endpoints would create a consistent and reliable open “standard” that WordPress developers can use instead of continually reinventing how to read and edit post data over HTTP.
      • In response to the question “what prevents you from building on the endpoints in their plugin form,” @joostdevalk went on to note that plugin dependencies would make that a viable option, but that burden currently lies on the user. Plugin installation is not frictionless.
    • Can these endpoints be bundled? short takeaway: no
      • Woo bundled the API infrastructure before it was merged; doing so for content endpoints would require bundling prohibitively large amounts of endpoint code.
      • @nerrad worries that if plugins bundle different versions of the endpoints plugin, then those plugins may conflict if all bundled copies are not kept in sync.
        • @nerrad clarifies in the comments below that these worries also encompass the additional risk of conflicts when plugin authors each build their own versions of these content endpoints, instead of leveraging a shared standard: if two plugins each expose their own REST collection for posts, a developer working on a site with multiple such endpoints will need to decide which to extend, and will then have their extension tied to that specific plugin rather than to a core API.
    • @schrapel and @jorbin discussed that these content endpoints make it much easier to crawl a site, which also brings some potential performance concerns: no new content is exposed, but the process of aggregating it is easier and more easily automated.
    • In the  comments below @foliovision believes that merging the endpoints will be the best way to assert the level of back-compatibility that mid-size agencies need in order to confidently utilize the endpoints.

    Please leave thoughts, questions, concerns, comments & experience in the comments below. Thank you!

    Edited 2016-10-16 to include the below comments into the body of the post

    • FolioVision 11:27 pm on October 13, 2016 Permalink | Log in to Reply

      Great discussion summary Adam. As the leader of a mid-size development agency, the sooner these endpoints are in core, the sooner we can start to use the REST API. For smaller to medium size clients, trying to play pin the tail on a donkey on a moving train (i.e. different versions of the REST API plugin, different versions of core) is simply not economically or technologically viable.

      As long as the REST API team can commit to retaining some backward compatibility if the API endpoints must change significantly in a couple of major releases, I can’t see any benefit to keeping REST API separate from core. So much great work has gone into creating the additional REST potential, it would be a shame to see it remain bottled up and a niche product only for huge agencies and hosts like VIP.wordpress.com or WordPress.com.

    • Josh Pollock 11:39 pm on October 13, 2016 Permalink | Log in to Reply

      One thing I wanted to add to this is that the REST API adds standards. I and many others have written tons of custom systems for alternative ways to read and edit post data using admin-ajax, or using custom rewrite rules.

      The constant reinventing of the wheal is counter to the spirit of open-source. By agreeing to a standard, with tons of eyes on it, we can all do better with greater efficiency and security. This after all is why we use WordPress and other open-source tools, instead of making our own CMSes.

      • masonjames 12:53 pm on October 14, 2016 Permalink | Log in to Reply

        I want to affirm this point as well. Our agency looks to WordPress (core) to provide an opinion. We value the decisions and respect them (even when we disagree).

        Web development is an incredibly competitive space with pressures in open source and otherwise. Having content end points in core ensures consistency and reliability across the WP community.

    • rag-guay 7:00 am on October 14, 2016 Permalink | Log in to Reply

      I would like to be able to edit widgets from the desktop app. So slow over the net from Thailand!

      • K.Adam White 12:58 pm on October 14, 2016 Permalink | Log in to Reply

        That’s a good point and I agree we need a solution for it. On behalf of the API Team, support for editing widgets is on the roadmap but is not part of what’s being proposed for merge this cycle. It is definitely a common request, and is one of our priorities for 4.8 as we expand the site management capabilities of the API!

        You can see some early experiments from earlier this year towards this usage here: https://github.com/WP-API/wp-api-menus-widgets-endpoints

    • Darren Ethier (nerrad) 10:46 am on October 14, 2016 Permalink | Log in to Reply

      Great summary! A lot of great back and forth in that discussion thread that isn’t always easy to capture 🙂

      Just wanted to clarify that the comments I made were not only in regards to the possibility of conflicts if plugin authors bundled the plugin version of the REST API with their own plugins, but also, with the presence of the infrastructure already in WordPress core, there is the possibility of conflicts should plugin authors roll their own different versions of the content endpoints to support what they are doing.

      Imagine plugin author A has used to api infrastructure in WP core to build custom endpoints for his plugin and his users are asking if he can add some endpoints for their posts, pages and users as well, so he goes ahead and does that. In the meantime, plugin author B has users asking her to build custom endpoints for users that support her needs as well so she adds them. Then along comes User Sally who installs and activates both plugins. She contracts mobile app developer Jimmy to build an app for her that interacts with both plugins and her website. Jimmy starts running into conflicts between what “user” endpoint to use but he manages to get it working. Then Sally tells Jimmy that she wants to distribute this app for anybody using plugin A or plugin B and Jimmy starts thinking about building a custom user endpoint in a plugin that site owners will need to install to use the app to save having to worry in the mobile app about what user endpoint to utilize.

      There are definitely different technical solutions to the above example story, but the reality is, things would be MUCH simpler for all the actors in the story above if there was an accepted standard in WordPress core for the content endpoints. It prevents a lot of problems from occurring.

    • K.Adam White 1:00 pm on October 14, 2016 Permalink | Log in to Reply

      If I may make a request of the developer community: Share this with your colleagues and friends outside of WordPress. See what they like, and what they find rough; let us know what they think! We’ve been gathering outside input on this but for more is always better.

    • Mike Schroder 6:03 pm on October 14, 2016 Permalink | Log in to Reply

      I noted this in the #core chat this week, but from my perspective at a host, we’re excited that landing the REST API will have performance benefits — in particular, because it will mean that we can cache requests that could only go through `admin-ajax` previously (and were thus forced to be dynamic).

      This will help with scaling even if it’s found that performance for the actual time in PHP/MySQL is exactly the same.

      Gradually moving those requests (whether they be core related, or added with plugins) out of `admin-ajax` will also help SysEng/Support more easily spot which requests are problematic.

      • Matt Mullenweg 1:15 am on October 18, 2016 Permalink | Log in to Reply

        It probably won’t have any real-world performance benefit — the admin-ajax benchmark was kind of flawed, and you won’t be able to do HTTP-level caching unless you also support some quite-fancy invalidation.

    • Luke Cavanagh 9:49 pm on October 14, 2016 Permalink | Log in to Reply

      I only see this as positive thing to be in WP core.

    • Brian Richards 2:21 pm on October 17, 2016 Permalink | Log in to Reply

      I’m late to the party but I want to officially register my voice in favor of merging the content endpoints into core.

      As @joostdevalk mentioned in Slack (and others have discussed elsewhere), there are a lot of opportunities to include API-based interactions within a plugin that are stifled presently because of the dependency on the REST API as a plugin. While it does seem like a small thing to inform end-users “This plugin requires the WP REST API plugin” it’s still a burden they needn’t bear. Further, by relegating the REST API to a plugin it stifles the ability for API-based interactions across many sites. For instance, a plugin that creates a widget that shows the most recent comments across a number of sites that you don’t control (e.g. getting the latest comments from a variety make/core inside a personal dashboard … and having the ability to bookmark certain comments or posts into a “read later” list for later consumption).

      As @getsource mentions above there are some fantastic wins by moving these interactions that currently depend on admin-ajax.php into standard, cacheable API calls.

      The most convincing dissenting opinion that gave me reason to pause was @JJJ‘s post that merging would hinder development. I do believe that is true. However, I also believe @rachelbaker is correct in that maintaining parity within the plugin as a long-term stand-alone is implausible. Given the choice between a REST API that can adapt and change quickly at the expense of dying slowly from a thousand cuts and a REST API that changes slowly but maintains perfect core parity I will pick the latter, every time.

      TL;DR: I really want to see the REST API land in core because I want to build some fantastic utilities (for myself and others) that can communicate with many sites without necessarily requiring administrative access (the ability to install the REST API plugin) within those sites.

    • K.Adam White 2:30 pm on October 17, 2016 Permalink | Log in to Reply

      I don’t think we’ve noted yet that the endpoints here don’t just encompass the built-in types, but also the endpoints that extend them — `WP_REST_Controller` provides a strong base for implementing new endpoints, and a custom post type with `show_in_rest => true` will automatically pick up behavior extending that class without any further action from the developer than a single line in `register_post_type`.

      Aside from the benefits of augmenting a shared resource like the posts collection @joostdevalk mentions above, having a sharable code foundation for new custom classes has the potential to reduce a lot of endpoint class duplication and fragmentation across the plugin ecosystem.

  • Ryan McCue 4:05 am on October 8, 2016 Permalink |
    Tags: , , merge-proposals,   

    REST API Merge Proposal, Part 2: Content API 

    Hi everyone, it’s your friendly REST API team here with our second merge proposal for WordPress core. (WordPress 4.4 included the REST API Infrastructure, if you’d like to check out our previous merge proposal.) Even if you’re familiar with the REST API right now, we’ve made some changes to how the project is organised, so it’s worth reading everything here.

    (If you haven’t done so already, now would be a great time to install the REST API and OAuth plugins from WordPress.org.)

    A brief history of the REST API

    The REST API was created as a proof-of-concept by Ryan McCue (hey, that’s me!) at the WordPress Contributor Summit in 2012, but the project kicked off during the 2013 Google Summer of Code. The end result was Version 1.0, which grew into a community supported initiative that saw adoption and provided for a solid learning platform. The team used Version 1 to test out the fundamental ideas behind the API, and then iterated with Version 2, which made some major breaking changes, including explicit versioning, the introduction of namespacing for forwards compatibility, and a restructure of the internals. Version 2 also led to the infrastructure of the REST API being committed to WordPress core in 4.4.

    This infrastructure is the core of the REST API, and provides the external interface to send and receive RESTful HTTP requests. Since shipping in 4.4, the infrastructure is now used by WordPress Core for oEmbed responses, and by plugins like WooCommerce and Jetpack, enabling anyone to create their own REST API endpoints.

    The team has also been hard at work on the API endpoints. This has included core changes to WordPress to support the API, including deeper changes to both settings and meta.

    Today the REST API team is proposing the inclusion of a collection of endpoints that we term the “Content API” into WordPress Core.

    Proposals for Merge

    Content Endpoints

    For WordPress 4.7 the API team proposes to merge API endpoints for WordPress content types. These endpoints provide machine-readable external access to your WordPress site with a clear, standards-driven interface, allowing new and innovative apps for interacting with your site. These endpoints support all of the following:

    • Content:
      • Posts: Read and write access to all post data, for all types of post-based data, including pages and media.
      • Comments: Read and write access to all comment data. This includes pingbacks and trackbacks.
      • Terms: Read and write access to all term data.
      • Users: Read and write access to all user data. This includes public access to some data for post authors.
      • Meta: Read and write access to metadata for posts, comments, terms, and users, on an opt-in basis from plugins.
    • Management:
      • Settings: Read and write access to settings, on an opt-in basis from plugins and core. This enables API management of key site content values that are technically stored in options, such as site title and byline.

    This merge proposal represents a complete and functional Content API, providing the necessary endpoints for mobile apps and frontends, and lays the groundwork for future releases focused on providing a Management API interface for full site administration.

    Content API endpoints support both public and authenticated access. Authenticated access allows both read and write access to anything your user has access to, including post meta and settings. Public access is available for any already-public data, such as posts, terms, and limited user data for published post authors. To avoid potential privacy issues we’ve taken pains to ensure that everything we’re exposing is already public, and the API uses WordPress’ capability system extensively to ensure that all data is properly secured.

    Just like the rest of WordPress, the Content API is fully extensible, supporting custom post meta, as well as allowing more complex data to be added via register_rest_field. The API is built around standard parts of WordPress, including the capability system and filters, so extending the API in plugins should feel as familiar to developers as extending any other part of WordPress.

    This Content API is targeted at a few primary use cases, including enhancing themes with interactivity, creating powerful plugin interfaces, building mobile and desktop applications, and providing alternative authoring experiences. We’ve been working on first-party examples of these, including a mobile app using React Native and a liveblogging web app, as well as getting feedback from others, including WIRED, the New York Times, and The Times of London. Based on experience building on the API, we’ve polished the endpoints and expanded to support settings endpoints, which are included as the first part of the Management API.


    The API Infrastructure already in WordPress core includes support for regular cookie-based authentication. This is useful for plugins and themes that want to use the API, but requires access to cookies and nonces, and is hence only useful for internal usage.

    To complement the Content Endpoints, for WordPress 4.7 the API team also proposes merging the REST API OAuth 1 server plugin into WordPress Core. This plugin provides remote authentication via the OAuth 1 protocol, allowing remote servers and applications to interact securely with the WordPress API.

    OAuth is a standardised system for delegated authorisation. With OAuth, rather than providing your password to a third-party app, you can authorise it to operate on your behalf. Apps are also required to be registered with the site beforehand, which gives site administrators control over third-party access. Access to these apps can be revoked by the user if they are no longer using the app, or by a site administrator. This also allows apps with known vulnerabilities to have compromised credentials revoked to protect users.

    We’ve chosen OAuth 1 over the newer OAuth 2 protocol because OAuth 1 includes a complex system for request signing to ensure credentials remain secure even over unsecured HTTP, while OAuth 2 requires HTTPS with a modern version of TLS. While it is strongly encouraged for sites to use HTTPS whenever possible (Let’s Encrypt makes it easier than ever to do so), WordPress itself does not require HTTPS and we do not believe WordPress should make HTTPS a requirement for using the API. The additional complexity that OAuth 1 adds can be easily supported by a library, and many such libraries already exist in most programming languages. OAuth 1 remains supported around the web, including for the Twitter API, and we also provide extensive documentation on using it.

    Authentication Beyond 4.7

    One issue with OAuth over direct username and password authentication is that it requires applications to be registered on the site. For centralized OAuth servers this wouldn’t be a problem, but the distributed nature of WordPress installations makes this tough to handle: your application must be independently registered with every WordPress site it connects to. If you’ve ever had to create a Twitter or Facebook app just to use an existing plugin on your site, you’ll know this can be a less-than-optimal experience for users.

    To solve this distribution problem, we’ve created a solution called brokered authentication. This allows a centralised server (called the “broker”) to handle app registration and to vouch for these apps to individual sites. It simplifies app registration by allowing app developers to register once for all sites, and improves security by allowing the broker to vet applications and revoke them across the entire network. The system is designed to allow multiple brokers; while the main broker is run at apps.wp-api.org, organisations can run their own broker for internal usage, and developers can run a broker locally for testing.

    While the broker system has been running live at apps.wp-api.org for months, we want to stay conservative in our approach to the API, especially where security is concerned. We are therefore proposing brokered authentication for WordPress 4.8 to ensure we have further time to continue testing and refining the broker system. In addition, this will require an installation of the broker on a centralised server to act as the canonical broker for out-of-the-box WordPress. While apps.wp-api.org is currently acting in this role, this is currently hosted by a third-party (Human Made) on behalf of the API team. For long-term usage the broker should instead be hosted on WordPress.org, alongside the existing plugin and theme repositories. This migration will take time but we remain committed to continuing to develop and support the broker.

    After Merge

    After merging the REST API, the team plans to continue developing the API as before. We expect that integrating the REST API into WordPress core will bring additional feedback, and we plan on incorporating this feedback through the rest of the 4.7 cycle.

    During the remaining parts of this release cycle and through into the 4.8 cycle, additional work will go into other parts of the API. This includes further work and refinement on the broker authentication system, including work on WordPress.org infrastructure. Additionally, we plan to continue working on the Management API endpoints, including theme and appearance endpoints to support the Customiser team. Both of these components will be maintained as separate feature projects on GitHub until they’re ready for merge into core.

    The team remains committed to supporting the API in core, and the Content API will switch from GitHub to Trac for project management and contributions. This same process occurred for the API Infrastructure in WordPress 4.4.

    Reviews and Feedback

    With this merge proposal, we’re looking for feedback and review of the project. In particular, we’re focussing on feedback on the security of the API and OAuth projects, and are also reaching out to specific people for reviews. (We take the security of the API seriously, and bug reports are welcomed on HackerOne at any time.) Design and accessibility reviews for the OAuth authorisation UI are also welcomed to ensure we maintain the high standards of WordPress core.

    Both the REST API plugin and the OAuth plugin are available on WordPress.org, and issues can be reported to the GitHub tracker for the API and the OAuth plugin respectively. We have released a final beta (Beta 15 “International Drainage Commission”) which includes the meta and settings endpoints.

    With Love from Us

    As always, this is a merge proposal, and is not final until 4.7 is released. We’re eager to hear your thoughts and feedback; the comments below are a perfect place for that, or you can pop along to one of our regular meetings. We’re also always available in the #core-restapi room on Slack.

    We’d like to thank every single one of our contributors, including 88 contributors to the main repository and 23 contributors to the OAuth repository. Particular thanks goes to my (@rmccue) wonderful co-lead Rachel Baker (@rachelbaker), our 2.0 release leads Daniel Bachhuber (@danielbachuber) and Joe Hoyle (@joehoyle), and our key contributors for the 4.7 cycle: Adam Silverstein (@adamsilverstein), Brian Krogsgard (@krogsgard), David Remer (@websupporter), Edwin Cromley (@chopinbach), and K. Adam White (@kadamwhite). Thanks also to the core committers helping us out through the 4.7 cycle, including Aaron D. Campbell (@aaroncampbell) and Aaron Jorbin (@aaronjorbin), and to the fantastic release lead, Helen Hou-Sandí (@helen).

    Thanks also to everyone who has used the REST API, and to you for reading this. We built the REST API for you, and we hope you like it.

    With love, The REST API Team

    • George Stephanis 12:17 pm on October 8, 2016 Permalink | Log in to Reply

      Regarding Authentication, as nice as OAuth 1.0a may be in some respects, I feel that we’re missing some rather obvious problems here.

      We’re expressing such concern about securing the REST API endpoints to work on HTTP — that we’re missing the fact that for sites that don’t support HTTP, normal wp-login requests or cookies could just as easily be sniffed.

      It just feels to me like we’re spending a lot of time reinforcing the back door against attackers, when the front door isn’t even locked.

      The concept of a third-party broker feels very antithetical to WordPress Core. To have to ping the third-party server for every login to check for invalidations of their applications, let alone the initial confirmation of an application … for me, it doesn’t pass the gut check.

      I’d much rather see something akin to the Application Password system we’ve devised. It has unique per-application passwords, with 142 bits of entropy, usage logging (date and ip last used), and trivial invalidation, as well as a proposed simple flow for applications to request passwords and get the generated passwords passed back.. And, as an added bonus, it works with the legacy XML-RPC API.

      Compared to that, making someone hoping to do something for API access to a single site register for a cloud broker, and then reauth with the individual site .. the UX doesn’t pass muster for me. :\

      Authentication is probably the most important key to getting the REST API correct, and it’s necessary (imho) to ship. We need to get it right.

      • marsjaninzmarsa 7:25 am on October 9, 2016 Permalink | Log in to Reply

        To have to ping the third-party server for every login to check for invalidations of their applications, let alone the initial confirmation of an application … for me, it doesn’t pass the gut check.

        Nope, you’re missing the point, third party will be pinged only on first use of new app on particular site, and next every few hours or so for invalidation (same as with checking for security updates).

      • Dion Hulse 10:40 am on October 9, 2016 Permalink | Log in to Reply

        Core. To have to ping the third-party server for every login to check for invalidations of their applications, let alone the initial confirmation of an application … for me, it doesn’t pass the gut check.

        I tend to agree here.

        I’d much rather see something akin to the Application Password system we’ve devised

        However, I feel that Application Passwords are actually a far worse solution to the problem than the various oAuth options out there, to the point that I think Application Passwords are an anti-pattern which core should never directly support. The user experience of Application Passwords are not user friendly at all, they’re a hacky solution to avoid using a proper modern application authentication mechanism.

        I could ramble for quite some time on the UX of these, but at the end of the day moving towards oAuth is going to provide a far better developer and user experience for API clients.
        Unfortunately though with all options here there’s the downside that Applications need to be registered/known/considered safe and also be able to invalidate their credentials in the event the applications key store is leaked (For example, Plugin X which relies upon a service has it’s keystore hacked, the application would have no way of informing those sites to distrust it’s previous authenticated sessions).

        In an ideal world, a central provider wouldn’t be needed, but we don’t have a decentralised platform for WordPress yet, so there’s no other mechanism for WordPresses out there to be told the sort of information they need to know.

      • Ryan McCue 8:40 pm on October 9, 2016 Permalink | Log in to Reply

        At its core, OAuth is just a standardised system for issuing app tokens. The primary things that it builds on top of this are specifically for security over HTTP, so I would be extremely reluctant to move backwards from those to a more simple token-based system.

        Regular WordPress logins are protected by two main factors: nonces and session tokens. While it is possible to sniff a raw username/password over the initial login, subsequent requests are protected, which means automated attacks are much harder. The nature of an external API means neither WP nonces nor session tokens (which are both intentionally server-only secrets) can be used to protect authentication, so we need a replacement system.

        OAuth incorporates a combination of nonce and timestamp to replace these in a similar manner, which are then combined with the secret, which we need since it’s no longer server-only. (WP nonces and session tokens have an internal secret with NONCE_SALT, the only difference is that we share them with the client for OAuth.)

        The broker system exists specifically because dynamic registration (either with OAuth or your plugin) has a number of key problems, primarily that it makes revocation useless. If the app is revoked, it can simply register again, which subverts both the site admin and W.org team if it were intentionally revoked. We looked at dynamic registration and rejected it specifically because of the issues with it.

        While the system might seem conceptually complex, it’s pretty simple to actually implement, because the broker is just regular OAuth under the hood. The entirety of the flow can be written in 200 lines of JavaScript. From the app’s perspective, it primarily Just Works, with most of the complexity hidden inside the broker implementation instead.

        The OAuth 1.0a specification is rigorously tested by security researchers and in production on huge web apps. The broker system builds on top of this, but avoids reimplementing the wheel, and instead just uses OAuth for some of the heavy lifting. Application Passwords is at its core HTTP Basic Authentication, which in its own specification 17 years ago recommended against actually using it.

        OAuth 1 isn’t perfect, but every thing in it is there for a reason. Is it perfect? No. But it provides a lot of benefit over Basic Auth for a relatively low cost.

    • Jon Brown 1:09 pm on October 8, 2016 Permalink | Log in to Reply

      Much love back at you all. This looks fabulously well thought out and complete.

    • Josh Pollock 2:42 pm on October 8, 2016 Permalink | Log in to Reply

      5 Stars!

    • fgilio 3:09 pm on October 8, 2016 Permalink | Log in to Reply

      Thanks to all of you!

    • Ahmad Awais 4:07 pm on October 8, 2016 Permalink | Log in to Reply

      I’m all in. Let’s do it this time. BTW great read Ryan.

    • Omaar Osmaan 5:55 pm on October 8, 2016 Permalink | Log in to Reply

      Thanks so much for all the hard work from the team- eager to see it get merged on core!

    • Noel Tock 7:56 pm on October 8, 2016 Permalink | Log in to Reply


    • Sergio Santos 1:45 pm on October 9, 2016 Permalink | Log in to Reply

      Thanks to all the team behind this outstanding work!

    • Matthew Eppelsheimer 9:43 pm on October 9, 2016 Permalink | Log in to Reply

      Thumbs up!

    • Weston Ruter 12:12 am on October 10, 2016 Permalink | Log in to Reply

      Additionally, we plan to continue working on the Management API endpoints, including theme and appearance endpoints to support the Customiser team. Both of these components will be maintained as separate feature projects on GitHub until they’re ready for merge into core.

      I’d like to note that customizer changesets (#30937, formerly “transactions”) allows for REST API responses to have customizations applied when the request includes a customize_changeset_uuid query param which identifies a customize_changeset post. This allows the customizer to be used with headless sites and mobile apps.

      A feature plugin needs to be started shortly that allows for these changeset posts to be CRUD’ed via the REST API as well, allowing for new customizer administrative applications to be built on top of the REST API without any need to go to customize.php.

    • Tammie Lister 8:08 pm on October 10, 2016 Permalink | Log in to Reply

      As requested in the design Slack channel, here is a design review. I took the OAuth plugin for a spin today and only focused on the design elements.

      I first of all had discoverability issues, but that was mainly due to not using this. I sort of imagine if someone is going to use this they will be doing so knowing more than I did – so that’s ok.

      The first screen is minimal but as expected when empty. It seemed to all fit the existing WP patterns. Thanks for taking the time and doing that. Should there be select all boxes though – I don’t see any actions for all.

      On the ‘add’ screen, I tried adding nothing in the fields. I was surprised when got a green message. I would expect this should be red over the success green.


      The term ‘Add Application’ but then the action button being ‘Save Consumer’, this threw me. Perhaps this is my lack of knowledge over terminology, but shouldn’t they both be the same?

      The page gets cluttered fast, I sort of want a break here visually, just a simple line would do:


      Regenerating the secret success message I felt should be by the secret. It was odd as the message appeared above my eye view. I click to regenerate lower and then this message pops up the top, feels like it should be close to add context.


      This may be a bug but when I searched for applications it tried to search users and I got the following:


    • Matt Mullenweg 8:26 pm on October 10, 2016 Permalink | Log in to Reply

      1. Given the hurdles of authentication I don’t think that bringing this into core provides benefits for WP beyond what the community gets from the plugin. I don’t believe in its current state the benefit outweighs the cost, and we should err on the side of simplicity.

      2. I am not interested in hosting the centralized brokered authentication server on WordPress.org in the 4.8 timeframe, and hesitant about the implications it has for WP more broadly. I do appreciate the thought that has been put into solving this tricky problem.

      • K.Adam White 9:39 pm on October 11, 2016 Permalink | Log in to Reply

        @matt, thanks for the comment. Can you clarify whether with (1) you mean the authentication solution, or the merge proposal for the content endpoints more broadly? There was discussion today in slack where we weren’t sure which way to interpret this point.

    • Dominik Schilling (ocean90) 10:01 pm on October 10, 2016 Permalink | Log in to Reply

      I gave the OAuth 1 plugin a try and here’s some feedback:

      • https://github.com/WP-API/OAuth1/issues/161 makes me wonder how we can integrate something with may not work on “a lot of sites”.
      • Adding Applications as a sub menu of Users doesn’t feel right to me. I just can’t imagine that 80% of our users really need this there. Twitter and Facebook have it both in the settings.
      • The UI: https://cloudup.com/c1emHXcHP4g Reusing existing elements is fine, but that looks a bit to simple and not fully developed. I’m sure that this can made better and doesn’t require a table. See Twitter/Facebook.
      • The plugin is using closures so it’s not compatible with the minimum requirements of WordPress.
      • I got a “500 Internal Server Error” error when the callback URL was invalid.
      • A few DocBlocks don’t follow the documentation standards.

      For some reasons I can’t get a successful `oauth1/access` request, I’ll try this again tomorrow…

    • Aaron D. Campbell 7:30 pm on October 11, 2016 Permalink | Log in to Reply

      The API endpoints themselves seem to be in a really good place, but I’m not sure the oAuth plugin is. Would it be reasonable to separate these into different proposals?

    • Mark Howells-Mead 2:32 pm on October 12, 2016 Permalink | Log in to Reply

      Issues aside, I’m strongly in favour of the REST API becoming a core feature as soon as it is stable.

    • Chris Smith 3:13 pm on October 12, 2016 Permalink | Log in to Reply

      +1 here as well and thanks to the team for their hard and thoughtful work.

      Based on the comments here, it does seem like it would make sense to split the proposal into the Content API and oAuth pieces for 4.7 so they can be dealt with/commented on independently as needed.

      @kadamwhite, what were the team’s thoughts on that in yesterday’s discussion?

    • Nilambar Sharma 5:32 pm on October 12, 2016 Permalink | Log in to Reply

      Really waiting for this. Lets make WordPress more awesome. It would be a great step merging new endpoints to core.

    • brad989 5:33 pm on October 12, 2016 Permalink | Log in to Reply

      Been looking forward to this for a long time. The content endpoints are an essential addition to WordPress core.

    • Chuck Reynolds 6:52 am on October 14, 2016 Permalink | Log in to Reply

      full api integration into core needs to happen eventually… API endpoints are at/near a good place. re: oath tho… meh..
      needs full support of CPT’s, which theoretically it would but… lots to test there.

    • forbze 7:16 am on October 14, 2016 Permalink | Log in to Reply

      I really want this! I’ve had to use hacky solutions in the past to repurpose content for mobile apps (I didn’t want to use web views / Mobile ui plugins).

      WordPress’s admin interface would make it really simple for me to give clients content control for their app content – rather than me having to build a custom editor UI on top of Parse / Firebase.

      I think oauth is the right solution for auth.

    • pwaring 9:23 am on October 14, 2016 Permalink | Log in to Reply

      I’m only in favour of this if the API can be disabled (ideally by default). I don’t need or want this functionality and it sounds like another remote attack vector.

      “we do not believe WordPress should make HTTPS a requirement for using the API”

      I *strongly* disagree with this. TLS uptake is increasing all the time and some browsers (e.g. Chrome) are starting to show stronger warnings for plain HTTP. Plus, if a popular application like WordPress requires HTTPS for its API, that will act as a significant nudge to hosting providers to provide HTTPS by default (a bit like moving from PHP 4 to 5).

      • Ryan McCue 9:18 pm on October 14, 2016 Permalink | Log in to Reply

        It’s super easy to disable the REST API via the `rest_enabled` filter (just return false), and there’s already a plugin for it. 🙂

        • pwaring 8:10 am on October 15, 2016 Permalink | Log in to Reply

          Whilst I’m capable of changing the code to add a filter, I don’t think that counts as ‘super easy’. It really should be a tick box somewhere in the admin settings.

          Installing a plugin to disable optional behaviour in core also seems unnecessarily complicated, plus it introduces another dependency and there’s no guarantee that the plugin author will keep it up to date.

          • Dave McHale 1:59 pm on October 18, 2016 Permalink | Log in to Reply

            I understand your concern, pwaring, but we already don’t have the ability to disable XML-RPC in core (ever since they enabled it by default in 3.5) – and since the REST API is “the same but different” I believe that’s why the new feature is following the same model. “Decisions, not options” and all that 🙂

            It’s also why I’m the author of the plugin Ryan linked to above. I think the REST API is great, and can’t wait to start using it myself *and* also see what other people build with it. But it’s not going to be for everyone, and I thought that people may want the easy ability to turn it off if they had a reason to.

            Since the plugin uses the root-level filters provided by the REST API there should very, VERY little need for actual plugin updates moving forward into the future (though I do keep an eye on the project, in case an update is needed). The only time I’ve needed to make a real functional change was when the filters themselves changed from version 1.x to 2.x of the API, before it was even merged into core. New features like the content endpoints won’t change the use of the plugin, because the REST API is still entirely disabled if you’re using the filters.

  • Grant Palin 6:13 am on October 7, 2016 Permalink |  

    Week in Core, September 28 – Oct 5, 2016 

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

    • 62 commits
    • 48 contributors
    • 57 tickets created
    • 9 tickets reopened
    • 77 tickets closed

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

    Code Changes


    • Remove target=_blank from the help tab links on several admin screens. [38725] #38145, #23432
    • Remove target=_blank from the Users and Widgets screens help tabs links. [38723] #38217, #23432
    • Remove target=_blank from the Plugins, Themes, Media, Update, and Tools screens help tabs links. [38722] #38215, #23432
    • Remove target=_blank from the Network screens help tabs links. [38721] #38159, #23432
    • Remove target=_blank from the Settings screens help tabs links. [38720] #38143, #23432
    • Remove target=_blank from the old custom background/header help tabs links. [38719] #38141, #23432
    • Remove target=_blank from the comment/edit-comments help tabs links. [38718] #38140, #23432
    • Editor, Publish meta box: remove a stray label and redundant CSS. [38700] #28411

    Admin Bar

    • Remove unused ID ab-awaiting-mod from comment count. [38683] #37901








    • Improve description for term_exists() $term param. [38716] #37224
    • Correct default value for next_text in paginate_links(). [38701] #38212
    • Correct ‘Since’ version number for Cloudup in oembed_providers filter description. [38675] #38188



    • Simplify wp_parse_url() to ensure consistent results. [38726] #36356
    • Add a $component parameter to wp_parse_url() to give it parity with PHP’s parse_url() function. [38694] #36356



    • Fix plugin activation link after installing an importer on multisite. [38704] #37943




    • Improve ID casting when getting, updating or deleting meta data. [38699] #37746




    • Display ‘Less Than 10’ active installs of a plugin rather than ‘0+’ active installs. [38729] #37509
    • Fix odd typo introduced in [38703]. [38706] #37973
    • Fix checkbox selection when searching for installed plugins. [38703] #37973



    • Add filters to allow creating REST API middleware plugins. [38689] #35590


    • Add more complete capability and role assertions to existing user capability tests. Also reuses one more user account fixtures. [38732] #38236, #38235
    • Reuse some user account fixtures in the user capability tests. [38731] #38235
    • Introduce tests that assert the primitive and meta capability tests test the correct capabilities. [38697] #38191
    • Correct some meta capabilities that were incorrectly listed as primitive capabilities in the role and capability tests. [38696] #38191
    • Add explicit cases to map_meta_cap() for various meta capabilities that are used in core. This will allow more complete meta and primitive capability unit tests in #38191. [38695] #38191, #38201



    • Remove the popular tag cloud from edit-tags.php. [38735] #36964
    • Introduce more fine grained capabilities for managing taxonomy terms. [38698] #35614
    • Use WP_Term_Query in get_term_by(). [38677] #21760



    • Account for uppercase chars when managing themes. [38710] #37924


    • Be more strict about adding a ‘View Posts’ link to the toolbar. [38708] #34113

    Unit Tests

    • Remove unused variable in Tests_oEmbed::dataShouldNotMatchOembedRegex(). [38714] #38187


    • Pass the current element to process() to properly register event handlers. [38711] #38174
    • Add ‘urn’ to the list of URI protocols whitelisted by default. [38686] #37300
    • Add test for each whitelisted URI protocol in wp_allowed_protocols(). Move test from [25301] to the new file. [38685] #38198


    Thanks to @adamsilverstein, @afercia, @boonebgorges, @chrisjean, @dd32, @dlh, @DrewAPicture, @dshanske, @earnjam, @feedback, @flixos90, @for, @frankiet, @geekysoft, @gma992, @helen, @ipm-frommen, @iseulde, @jeremyfelt, @jnylen0, @joehoyle, @joelcj91, @joemcgill, @johnbillion, @johnjamesjacoby, @jorbin, @jrf, @Kenshino, @melchoyce, @mrahmadawais, @obenland, @ocean90, @ovann86, @pento, @peterwilsoncc, @Presskopp, @rachelbaker, @ramiy, @rianrietveld, @rmccue, @ryankienstra, @ryanplas, @SergeyBiryukov, @spacedmonkey, @sudar, @swissspidy, @truongwp, and @westonruter for their contributions!

  • K.Adam White 9:31 pm on September 30, 2016 Permalink |
    Tags: ,   

    REST API Meeting Agenda for Oct 3 2016 

    REST API: Meeting Agenda for Oct 3, 2016

    The weekly meeting for the API team will be on Monday at 2016-10-03 14:00 UTC in #core-restapi. On the agenda:

    • Update on Settings from @joehoyle
    • Update on Meta from @rmccue
    • 4.7 Merge Plan TODOs

      • Decision on supported authentication methods
      • Progress on outside review
      • Timeboxed open floor
    • Review open PRs
    • Find owner for open tickets, e.g. some OAuth/Cookie conflicts
  • Jeff Paul 8:37 pm on September 29, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: September 28 (4.7 week 6) 

    This post summarizes the dev chat meeting from September 21st (agenda, Slack archive).


    • Schedule: We are 3 weeks from the final chance to merge in major features. This includes Twenty Seventeen.
    • Tickets: There are currently 196 tickets in the 4.7 milestone. This is 14 more than last week. In just 6 short weeks, this needs to be zero. For any tickets you’ve moved into the milestone, please make sure these are active tickets, with some kind of activity in the last 10 days.
    • Bug Scrubs: We’re looking for people to help run a bug scrub, please reach out to @jorbin if you have interest (details here). Bug scrubs this week plus one on Monday and one on Wednesday next week at yet to be scheduled times.

    Components & Features

    • Twenty Seventeen (@davidakennedy, @melchoyce)
      • Latest update
      • Add multi-panel feature to pages through add_theme_support (#37974) & Enable Video Headers in Custom Headers (#38172) need eyes and help the most
      • Additional i18n eyes on Better support for non-latin font fallbacks especially designers who use non-latin alphabets natively to hear suggestions for non-latin font stacks that would look good in the theme
      • Next meeting Friday at 18:00UTC (theme-focused), Tuesday (feature-focused)
    • Media (@mikeschroder, @joemcgill)
      • Latest update
      • Unexpected change to media title behavior in WP 4.6.1 (#37989) – Looks like @sergey added a patch that fixes the remaining issues with some UTF-8 characters. Should be committed soon.
      • Media search doesn’t include file name (#22744) – The current implementation is trampling any preexisting JOINs. Should have a patch a new patch ready to test soon.
      • Also looking at pursuing additional media organization improvements through a feature plugin, details still need discussion, @karmatosed on board to help with design
      • Next meeting Friday at 17:00 UTC
    • Customize (@westonruter, @celloexpressions)
      • Latest update
      • Primary commit for Harden panel/section UI code by removing contents from being logically nested (read: goodbye margin-top hacks) (#34391) is in, and a dev note is scheduled to be published after today’s dev chat
        • Some major changes here, so we need plugin and theme authors to test
      • Received design feedback on A New Experience for Discovering, Installing, and Previewing Themes in the Customizer (#37661) and working on making those revisions by the end of this week and planning to publish a feature proposal on Friday
        • Need to discuss themes again during tomorrow’s #design meeting for final approval before the changes are made
      • Need attention on Provide a better gateway for code-based theme customizations with the Customizer (#35395)
        • Discussion of whether this direction is appropriate lead to tentative consensus that this is likely appropriate for core
        • Next steps will be to loop @folletto in to improve the design and polish up the patch
        • Big other block discussed: sanitizing and validating the CSS & most appropriate corresponding capability
          • Currently rudimentary validation in the patch for balanced braces and comments. Need improvement if relying on it heavily, but it provides instant user feedback
          • Capability solution needs to work for multisite if at all possible, since that’s a primary use case
          • Discussion to continue on the Trac ticket and/or #core-customize
    • i18n (@swissspidy)
      • Feedback/help on Introduce a locale-switching function (#26511) would be appreciated
        • The problem is that labels of custom post types and taxonomies are only evaluated once, so switching locales wouldn’t properly translate those.
        • There’s a proposed fix for built-in types and taxonomies, but we prefer a better solution that works for all of these.
    • Editor (@azaozz, @iseulde)
      • Would like to help with a survey (scratchpad/draft). Need to start gathering user usage stats, should be opt-in, start with a plugin first, and release the aggregated data
      • Weekly data tracking (back-end) meeting Wednesday at 1900 UTC
    • HTTPS (@johnbillion)
    • REST API (@krogsgard, @kadamwhite )
      • Latest update
      • Whether the API should follow core behavior and save a revision every time a post is updated
        • Right now every update to a post creates a revision and can be a bit painful for some clients, so: 1) should that always happen? 2) should we have the ability to turn it off?
        • Decided on: 1) Yes.  2) The ability to use auto-drafts like in core makes sense, but doesn’t need to block merge.
      • How to handle image permissions, specifically for the case where an image is attached (uploaded) to a private post and then featured in a public post
        • Specifically, if I upload an attachment to a private post, its visibility is governed by that post, so it too is private but, in wp-admin I can add it as featured media to another public post. When that public post is queried: what happens!?
        • @joemcgill summary: I happen to think it’s an oversight in WordPress that we allow an image attached to a private post to be set as the featured image of another post (and by an author without permission to view the private parent post). We should probably either close this loophole or detach the attachment from the private post whenever it’s set as a featured image on another post.
        • @kadamwhite to document decision, @rmccue @joemcgill @helen et al will identify core tickets that should be opened.
      • Whether (and how) to expose edit locks through the API
        • Main thing here is whether this is a blocker? Decision: edit locks are great, but doesn’t need to block merge.
      • Next bug scrub is Thursday 1400 UTC; next team meeting is 1400 UTC on Monday, October 3rd
  • Andrew Rockwell 11:14 am on September 22, 2016 Permalink |  

    Week in Core, September 7 – 20, 2016 

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

    • 66 commits
    • 61 contributors
    • 171 tickets created
    • 15 tickets reopened
    • 106 tickets closed

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

    Code Changes



    • Docs: Use a third-person singular verb for wp_doing_ajax filter added in [38334]. [38607] #25669
    • Bootstrap: Use dirname() when loading class-wp-hook.php from plugin.php. [38589] #37707


    • Database: Fall back to utf8 when utf8mb4 isn’t supported. [38580] #37982


    • Add wp-util as a dependency for customize-controls. [38628] #38107
    • Remove IE8 access to customizer to discontinue support. [38627] #38021
    • Let static_front_page section be contextually active based on whether there are any published pages. [38624] #34923, #38013
    • Ensure nav menu items lacking a label use the title from the original object. [38618] #38015
    • CBetter hover/focus state for section titles and available widgets. [38602] #29158
    • Implement previewing of form submissions which use the GET method. [38587] #20714
    • Prevent widget previewing logic from building invalid jQuery selectors when sidebars are registered without a class name in before_widget. [38577] #37993


    • Normalise index names in dbDelta(). [38591] #34874
    • Increase the size of wp_posts.post_password to 255 characters. [38590] #881


    • Docs: Use a third-person singular verb for smilies filter added in [38504]. [38608] #35905
    • Update autop() to match wpautop(). [38594] #4857, #4857
    • Docs: Fix an outdated comment. [38593] #4857
    • Add an extra line break before block elements in wpautop(). [38592] #4857
    • Don’t send an HTTP status code in wp_send_json() by default. This avoids clobbering an HTTP status code that may have been set prior to calling this function. [38576] #35666



    • Correct context for Next/Previous strings in get_the_posts_pagination(). [38611] #37952



    Networks and Sites

    • Multisite: Show always domain and path when deleting a site. [38633] #37309
    • Multisite: Use get_networks() in get_main_network_id(). [38632] #37218
    • Multisite: Provide $join as a possible SQL clause to the sites_clauses filter. [38631] #37922
    • Multisite: Add annotations for extended WP_Site properties. [38630] #37932
    • Docs: Synchronize docblocks for WP_Site_Query::__construct() and get_sites() after the changes in [37735], [38008], [38103], and [38336]. [38596] #38039
    • Docs: Correct description for domain and path arguments in WP_Network_Query::__construct(). [38595] #32504

    Options, Meta APIs

    • Options: Build out register_setting like register_meta. [38635] #37885


    • Ensure Pending Review Posts permalink posts link to the draft [38572] #37423


    • Style the primary action link in the non-js “Installing Plugin” page. [38617] #36430
    • Tests: Use add_filter() when it’s available. [38582] #17817
    • Docs: Fix minor formatting for inline docs in WP_Hook following its introduction in [38571]. [38573] #17817
    • Hooks: Add the new class WP_Hook, and modify hook handling to make use of it. [38571] #17817

    Posts, Post Types




    • Docs: Correct the description of {$taxonomy}_term_new_form_tag hook, making it more consistent with other *_form_tag hooks. [38629] #38104
    • Pass taxonomy name to actions in term-relationship CRUD functions. [38621] #38006
    • Query: Eliminate unnecessary wp_list_filter() call in get_queried_object(). [38586] #37962
    • Query: Avoid PHP notice in get_queried_object() when query contains NOT EXISTS tax query. [38585] #37962


    • Docs: Correct two references to plugins in the $args parameter description for themes_api(). [38623] #37939
    • Docs: Use a third-person singular verb for {$type}_template_hierarchy filter added in [38385]. [38609] #14310
    • Docs: Use a third-person singular verb in the DocBlock summary for get_theme_file_uri(), get_parent_theme_file_uri(), get_theme_file_path(), and get_parent_theme_file_path(), introduced in [38578]. [38606] #18302
    • Docs: Use a third-person singular verb for theme_file_uri, parent_theme_file_uri, theme_file_path, and parent_theme_file_path filters added in [38578]. [38605] #18302
    • Add the non-encoded form of the queried item slug to the template hierarchy when the slug contains non-ASCII characters. [38583] #37655
    • Taxonomy: Revert accidental changes introduced in [38578]. [38579] #18302
    • Improve child theme file inheritance by introducing functions for locating and fetching the URL or path to files within child and parent themes. [38578] #18302


    • Add a ‘View Posts’ link to the toolbar when on the post listing screen. [38634] #34113


    • Docs: Correct a comment and @return entry in WP_Upgrader::create_lock(). [38622] #38089
    • Automatically log users in after installation. [38619] #34084


    • Avoid a PHP notice in ::pingback_ping() if page title was not found. [38620] #36727
    • Check the minimum number of arguments in ::wp_getUsersBlogs() and ::blogger_getUsersBlogs(). [38600] #29750

    Thanks to @aaroncampbell, @adamsilverstein, @afercia, @akibjorklund, @DMing, @BjornW, @boonebgorges, @celloexpressions, @curdin, @danielpietrasik, @dd32, @DrewAPicture, @eliorivero, @enshrined, @ericlewis, @FlorianBrinkmann, @folletto, @georgestephanis, @gma992, @helen, @hideokamoto, @hugobaeta, @ian.edington, @iandunn, @jbrinley, @jeremyfelt, @joehoyle, @joemcgill, @johnbillion, @johnjamesjacoby, @jorbin, @karmatosed, @kitchin, @knutsp, @markshep, @MaximeCulea, @melchoyce, @monikarao, @nacin, @nazgul, @obenland, @ocean90, @paulwilde, @pento, @peterwilsoncc, @RedSand, @rmccue, @rnoakes3rd, @rommelxcastro, @ryankienstra, @ryanplas, @SergeyBiryukov, @skippy, @spacedmonkey, @swissspidy, @Takahashi_Fumiki, @websupporter, @welcher, @westonrute, @westonruter, and @wonderboymusic for their contributions!

  • Aaron Jorbin 2:40 pm on September 15, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: September 14 (4.7 week 4) 

    This post summarizes the dev chat meeting from September 14th (agenda, Slack archive).


    As of this meeting, we are 5 weeks from the final deadline to merge major features.
    There are a lot of tickets in the milestone and owners / people who milestoned them need to make sure they are active and moving, or else punt. You can use this report see tickets in the milestone grouped by who moved it there:https://core.trac.wordpress.org/report/61.

    Components and features

    Twenty Seventeen (@davidakennedy, @melchoyce)

    Make sure to checkout both the Announcement post and the latest update. There is no formal meeting this week. Development has started on GitHub. Like many feature projects, it will live on GitHub until it is ready to come into SVN (within the next 5 weeks).

    REST API (@krogsgard, @kadamwhite, @joehoyle, @rmccue)

    Core patches, documentation, and reducing the issue backlog have been the primary focuses. There is a settings registry up (https://github.com/WP-API/wp-api-site-endpoints/pull/13) with a corresponding core patch (https://core.trac.wordpress.org/ticket/37885).

    Feedback is needed on #37885.  Please take a look.

    #38056 is needed for password posts. (update: it has landed).

    The next dev chat is Monday September 19 1400 UTC.

    Media (@mikeschroder, @joemcgill)

    • Still looking for feedback/testing on #22744, but planning to commit soon.
      • If you have a large media library, your help in testing would be particularly helpful.
    • @paaljoachim continued researching UI flows in other platforms and posted a bunch of screenshots in #core-images.
    • Joe shared an outline of what we’re trying to accomplish longer term here in#core-images and would like to talk more about it design side of things during the #design meeting tomorrow, if possible.
    • Still waiting to hear back from folks who were involved in starting up the Core Media Widget #32417 work, but travel has been an issue. Hopefully we’ll have a better update there next week.

    Customize (@westonruter, @celloexpressions)

    • @boone is thinking about/investigating ⁠⁠⁠⁠term_status⁠⁠⁠⁠ for #38015. We have some time to think about it, and could potentially use shadow/draft taxonomies as a workaround for #38014 in 4.7 if needed.
    • tracking the ability to add page stubs or create pages directly from the static front page controls along with this project to facilitate creating pages for initial site setup within the customizer. @westonruter is leading the way on #38013.
    • #34391 is a significant refactoring of code that themes and plugins are encouraged to extend. A corresponding make/core post will follow soon after.
      • Already working with some plugin, theme, and framework authors to minimize breakage.
    • We need some feedback now on #35395 – Custom CSS – @johnregan3 is making great progress.  Please check out the ticket.

    i18n (@swissspidy)

    • #29783 (User Admin Language): in good shape, but not much testing happening so far. We could do much more when #26511 is in core though…
    • #26511 (switch_to_locale()): needs some much needed performance testing. If anyone runs a large WordPress site, I could use your help!
      Also since there are some similarities with switch_to_blog(), I’ll open a new ticket to suggest adding a WP_State interface for such switching functions. Think WP_Site_State, WP_Locale_State, WP_Post_State (see #19572), etc. Not a blocker, but worth keeping in mind for future compatibility.
    • #20491 (JS i18n): I documented the current state in the tasks with responsibilities etc. As of tomorrow I’ll have more time to work on it (mainly on the GlotPress side of things). Also have been thinking about a switch_to_locale() function in JS via Ajax…

    Editor (@azaozz, @iseulde)

    • Post your wishlist items for the editor.

    HTTPS (@johnbillion)

    • Plan of attack for HTTPS work will be published on Make/Core.

    Open floor for tickets and any lingering 4.7 ideas.

    Please review and comment on these tickets:

  • Brian Krogsgard 9:25 pm on September 8, 2016 Permalink |
    Tags: ,   

    WordPress REST API update 


    There’s a renewed push going on right now to try and get what is being termed “content endpoints” into WordPress core with the 4.7 release.

    In the first core development meeting of the 4.7 cycle, @helen identified a series of tasks that would need to be analyzed and acted upon to be able to make a new proposal for core inclusion, including identifying existing blockers. There is a team of people actively working on these items, and your participation is wanted!

    New meeting times

    Regular meetings have been changed to take place at 14:00 UTC Mondays, with bug scrubs at 14:00 UTC Thursdays — all in #core-restapi. So the next meeting is Monday, September 12th, 14:00 UTC.

    Fuller story and action items

    If you are not caught up on the state of the WordPress REST API, the infrastructure for the API went into WordPress 4.4. Since that time, several prominent plugins are using the infrastructure to create their own REST APIs.And now the feature project (not in core) consists of core endpoints and authentication mechanisms. The four primary types of resources that have been developed are for: posts (and other post types), users, comments, and terms. There is also a Google spreadsheet where you can list sites you know of running V2 of the REST API plugin in production.

    The proposal, if the various criteria are met, would request core inclusion for what we’re calling “content endpoints”, and “management endpoints” would be part of a subsequent release cycle. With the content endpoints, website developers would have tools at their disposal to build websites in whatever programming language they choose, using data from WordPress. Additionally, certain types of applications would also be able to create experiences for managing WordPress content — though not complete WordPress site management the way you can from the WordPress admin.

    The primary focus areas for core inclusion of the WordPress REST API — as initially defined by Helen, and then expanded on in the core dev chat meeting — are as follows:

    1. Rigorously test 4.6 and trunk compatibility and resolve any issues that may be found.
      1. Includes reviews by current component maintainers for existing endpoints.
      2. For example: WP_Post_Types and other new objects, need compatibility.
    2. Identify and resolve some of the final “quirky” issues (e.g. password-protected posts).
    3. Create support for meta.
      1. By “meta support” in the API, we refer to meta values that have been registered by a developer. Ideally via register_meta( ...., array( 'show_in_rest' ) ). For clarity, this excludes arbitrary meta storing (i.e. a client arbitrarily using the WordPress database)
    4. Create support for options – this is not “content” per say, but imagine an app where you can’t change your site title and tagline.
      1. Needs significant clarification, definition of what should be achieved
      2. Repo for site endpoints: https://github.com/WP-API/wp-api-site-endpoints
        1. Discuss architecture for how this would work (like, site endpoints w/ object of settings) https://github.com/WP-API/WP-API/issues/816
    5. Establish a forward compatibility plan, particularly around how to avoid/minimize plugin and theme conflicts. IE: namespacing and documentation / protected stuff. Relate to current general WP best practices (IE: custom field named “likes” – possible vs good idea). Need document to outline our views.
    6. Dedicated reviews from developers with deep experience in security and REST APIs, ideally including some of the non-WP PHP community.
      1. Identify and request reviews by specific developers & subjects.
        1. Security
        2. Core compatibility
        3. Integration
        4. Consumption
        5. Non-WP developers / fresh eyes
    7. Identify current authentication options, and their viability for inclusion in 4.7. Document flows of implementing and using each.
      1. Cookie auth
      2. Basic auth
      3. oAuth 1
      4. oAuth 2
    8. Establish and document data with performance comparisons – speed, bandwidth, etc – against admin-ajax, XML-RPC, etc. (Might just require education, as really all these are pretty similar). Identify and address performance related issues on project GitHub repo.
    9. Recruit and assign new / excited contributors
    10. Align existing docs with primary project. Outline documentation needs, and create them.
      1. Get volunteers to take on specific tasks
      2. Decide where these docs go, both now and in the future

    Specific initiatives

    There are several more specific initiatives to work on, many of which we’ve tasked out and assigned, but plenty that could use more input.

    Docs Initiatives

    • Inline docs will eventually be merged into core inline docs, so any prep there should be roadmapped along with the rest of the 4.7 planning
    • User docs on consuming the API (e.g. doing things with the routes it provides from external systems, like uploading media) are needed and should live in the docs-v2 repo for now. See issues list for current user-facing documentation needs.
    • User docs on extending within the context of the API plugin (how to add routes, how to lock down access to auth’d users) are needed and should live in the docs-v2 repo for now
    • Docs on making endpoints with the infrastructure currently in core should live within the developer handbook

    Task Assignments

    • Ping component maintainers to see what testing they’ve done w/ API (@krogsgard)
    • Password game plan: relies on #16483: Blank content, rendered string, title however it is done in core now, 401 for individual posts, content to include protected:truein return object, and (maybe) give users that can edit posts access to content in response, consider Authorization header options. (@rmccue)
    • A pass at registered settings. @joehoyle has tackled this with a first draft, along with #37885.
    • Document feature detection as it works today (http://v2.wp-api.org/guide/discovery/). Establish best practice for extending with new endpoints. Establish best practice for modifying existing objects.
    • Documentation needed: compare register_rest_field() vs register_meta() and document best practice for when register_rest_field() may still be preferable. But generally encourage usage of register_meta()
    • Consideration: With register_rest_field, maybe force a namespace a la register_rest_route
    • Contact implementors from @joehoyle‘s API-in-use list to get feedback on their experience with the API (@krogsgard)
    • Document that name, description, url and home are the options already available in index as read-only. Consider change of this with global options endpoint.
    • Develop personas for user groups that interact with the API (@jorbin)
    • Interface testing for cookie and oauth1 implementations. Recruit UI/Design help. (@krogsgard and @kadamwhite)
    • Determine auth_callback (needs different name, has a conflict right now) necessity within register_meta(), as someone may want meta exposed, but only for authenticated users, and there is no cap system for read_meta.>
    • Review https://github.com/WP-API/WP-API/issues/2558 for performance gain.
    • Review https://github.com/WP-API/WP-API/issues/1625 for awkward data handling w/ client-js

    Bug scrubs

    The first bug scrub of this cycle took place today, and we were able to go through all open issues on GitHub that do not have a label, and label them, plus add at least some level of context. Our priority for future meetings will be to ensure that we have assigned bugs to appropriate people, and go back through and ensure we have milestones assigned to various tickets. We’ll have an open floor period during each regular meeting to discuss particular issues.

    Get involved

    If you have any interest in the API, your help and insights are wanted! You can join Chat.WordPress.org in the #core-restapi room to sit in and watch, or jump in to various discussions. Also, if you just want to play with the plugin and report back your experience, that’d also be super helpful.

    One group of core contributors we really need feedback from are component maintainers. The team working on the REST API would like your input on how well the API currently interacts with your component, how it can improve, and to identify trouble areas that would need to be addressed both for initial core inclusion of the API, and down the road.

    Thanks for listening!

  • Andrew Rockwell 3:14 pm on July 20, 2016 Permalink |
    Tags: ,   

    Week In Core, July 12 – July 19 2016 

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

    • 71 commits
    • 40 contributors
    • 82 tickets created
    • 7 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.

    Code Changes


    • Improve keyboard navigation on the themes browser modal window [38084] #37383

    Bundled Themes



    • Use wp_strip_all_tags() to strip HTML tags [38092] #37208
    • Include comment_content with html and without in blacklist_keys comparison [38048] #37208
    • Strip html tags from comment content before blacklist_keys comparison [38047] #37208


    • Add unit test to test that a column type change for a table name with a hyphen is working after [38044] #31679


    • Use the three-digit, x.x.x-style version in the DocBlock for the nested lowercase_octets() function. [38107] #32246
    • Add a missing DocBlock for the lowercase_octets() function, which is nested within redirect_canonical() [38106] #32246
    • Clarify the fields argument description in WP_Network_Query::__construct(). [38104] #32504
    • Clarify the fields argument description in WP_Site_Query::__construct(). [38103] #35791
    • Correct comment_max_links_url filter and $url param descriptions to communicate values are found links [38098] #37319
    • Correct type of WP_Post_Type::$cap from array to object. [38097] #36217
    • Correct $post parameter name and description for wp_attachment_is() and wp_attachment_is_image(). [38068] #37377
    • Update a cross-reference in the DocBlock for wp_register_plugin_realpath() from plugin_basename() to wp_normalize_path(). [38061] #37357
    • Add an initial since version to wp-includes/feed.php [38056] #32246, #36295
    • Update the default value for the optional $args parameter in get_networks() following [38055] #32504
    • Add and clarify changelog entries for elements that can now accept, use, or return WP_Post_Type objects [38051] #36217


    • Enqueue the wp-embed script to fix embed previews inside the media modal. [38062] #37334


    External Libraries

    Filesystem API


    • Pass proxy settings to Requests [38054] #33055, #37107
    • Update Requests. Fixes an issue where you couldn’t set a Requests_Proxy_HTTP object as a proxy setting. [38053] #37107, #33055
    • Remove duplicate documentation for the http_api_debug hook. [38043] #37081


    • Remove non-translatable link attributes from translatable strings in wp_plugin_update_row(), wp_theme_update_row(), and get_theme_update_available() [38082] #36048
    • Combine duplicate “Menu Locations” and “Menu Options” strings. [38080] #18218
    • Combine two duplicate “Invalid post type” strings. [38076] #18218
    • Change unnecessary uppercased words in WP_Upgrader::generic_strings() to lower case. [38074] #18218
    • Combine two duplicate “Unable to locate WordPress Theme directory” strings. [38073] #18218
    • After [38057], consistently use a context for other instances of Activate %s,Network Activate %s, and Delete %s strings [38071] #37290
    • Remove a stray translator comment added in [38070] #37290





    • Ensure $wp_meta_keys is an array in get_registered_meta_keys(). [38108] #37415, #35658
    • Remove object subtype handling from register_meta() [38095] #35658
    • Ensure filters are backwards compatible for pre-4.6 style meta registration [38041] #35658


    • Correct default value for orderby in WP_Network_Query::__construct() [38102] #32504
    • Correct default values for orderby and order in WP_Site_Query::__construct() [38085] #35791
    • Set default $args to an empty array in get_networks() [38042] #32504


    • In wp_install_maybe_enable_pretty_permalinks() [38109] #36628
    • Rename $usingpi to $using_index_permalinks for clarity. [38067] #37380
    • After [37747], make sure $usingpi, $writable, and $update_required are defined before checking them on permalinks update.


    • Use the correct admin screen when searching for plugins via Ajax [38091] #37373


    • Link to the Plugin Developer Handbook on DevHub as the primary resource for information on extending WordPress [38105] #37399


    • Introduce capability tests for non-logged-in users. [38096] #37405

    Script Loader

    • Limit resource hinting to enqueued assets [38100] #37385
    • Increase priority of wp_resource_hints() so hints get printed before scripts and styles [38046] #37317


    • Improve back compat of values passed to ‘terms_clauses’ filter [38099] #37378
    • Correct WP_Error usage in WP_Tax_Query::clean_query() and WP_Tax_Query::transform_query(). [38079] #37389
    • On term.php, use $taxnow when fetching currently edited term. #37205. [38069] #37205

    Text Changes

    • Change Network deactivate %s to upper case, for consistency with Network Activate %s. [38081] #37290
    • Add a full stop to “Invalid taxonomy” and “Invalid term ID” strings, for consistency with similar post-related messages. [38077] #18218, #32329
    • After [37297], replace two more instances of “WordPress.org Plugin Directory” with “WordPress Plugin Directory”.


    • Replace the editor iframe title on MacOS to fix the help shortcut. [38110] #36863

    Twenty Thirteen

    • Fix selective refresh of Masonry-laid out widgets by deferring initialization until DOM ready [38083] #37390

    Unit Tests


    • Give context to some install/update strings to allow for differentiation between theme and plugin translations. [38057] #37290


    • Update help text for user-new.php to remove reference to sending passwords via email. [38064] #36763

    WP Mail


    Thanks to @ramiy, @afercia, @alleynoah, @ambrosey, @anneschmidt, @azaozz, @boonebgorges, @bpetty, @celloexpressions, @cfinke, @Clorith, @dabnpits, @davidakennedy, @dlh, @DrewAPicture, @flixos, @flixos90, @iandunn, @jeremyfelt, @joemcgill, @johnbillion, @karmatosed, @morganestes, @ocean90, @pbearne, @pento, @peterwilsoncc, @rachelbaker, @ramiy, @rmccue, @ruudjoyo, @SergeyBiryukov, @stephenharris, @swissspidy, @szepeviktor, @underdude, @vishalkakadiya, @westonruter, and @zuige for their contributions!

  • Grant Palin 6:45 pm on July 13, 2016 Permalink |
    Tags: ,   

    Week In Core, July 6 – July 12 2016 

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

    • 59 commits
    • 39 contributors
    • 61 tickets created
    • 3 tickets reopened
    • 20 tickets closed

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

    Code Changes


    • Add aria-button-if-js class to links in the media list table that behave like buttons when JavaScript is on. [38031] #26504, #36555




    • Fix panel indentation in Firefox. [37984] #34622
    • Ensure that WP_Customize_Setting::value() can return a previewed value for aggregated multidimensionals. [37982] #37294
    • Ensure that WP_Customize_Nav_Menu_Section is able to represent a placeholder nav menu. [37981] #37293


    • The $labels property in WP_Post_Type is of type object as returned from get_post_type_labels(), not an array. [38030] #36217
    • Standardize references to “meta box” or “meta boxes” as two distinct words throughout core documentation per the core spelling guide. [38029] #32246
    • Standardize capitalization of Ajax throughout core documentation per the core spelling guide. [38028] #32246
    • Link the 4.6 changelog entry in the DocBlock for register_meta() to its corresponding dev note on make/core. [38027] #35658, #37318
    • Fix a typo in the DocBlock for themes_api(), themes_api, plugins_api(), and plugins_api. [38025] #32246
    • Fix minor formatting and syntax for wp-admin/* elements introduced in 4.6. [38024] #37318
    • Cross-reference parent classes in DocBlocks for upgrader classes moved to their own files in 4.6 [38023] #36618, #37318
    • Improve usefulness of DocBlocks for ajax-actions.php functions introduced in 4.6. [38022] #37318
    • Fix a typo in the hook doc description for the enable_loading_advanced_cache_dropin run-time filter. [38021] #34936, #37318
    • Fix a typo in an inline hook reference in the DocBlock for comment_form(). [38018] #32246
    • Fix typo in a comment in Core_Upgrader::upgrade(). [38014] #37314
    • Correct the description of the $network_id in WP_Site_Query. [38008] #35791
    • Fix an incorrect @since comment. [37994] #36495
    • Use 3-digit, x.x.x-style semantic versioning for _doing_it_wrong(), _deprecated_function(), _deprecated_argument(), and _deprecated_file() throughout core. [37985] #36495


    • Include locale stylesheets after default styles. [38010] #36839
    • Don’t print the HTML for a featured image if a post has no featured image. [37988] #37288



    • I18N: Introduce an on/off switch for locales where comment number needs to be declined. [37987] #13651


    • Don’t use ‘full’ as array key in wp_calculate_image_srcset(). [37986] #36345


    • Add a missing @since param for wp_object_type_exists(). [38038] #35658
    • Don’t pass an empty $meta_key to get_metadata(). [37996] #35658
    • Introduce an initial set of tests for register_meta(). [37995] #35658
    • Make registration error conditions return consistently. [37991] #
    • Ensure $object_subtype is available before use in register_meta(). [37990] #35658


    • Use hash_equals() when comparing hashes to mitigate timing attacks. [38032] #37324
    • Correct logic used to display an Edit User link after adding a user. [38007] #37223
    • Add a nonce to the “Cancel” URL when changing a site’s admin email. [38006] #36954
    • Don’t store max_num_pages in WP_Network_Query query cache. [38003] #32504
    • Don’t store max_num_pages in WP_Site_Query query cache. [38002] #35791


    • Improve Ajax search of installed plugins. [38033] #37230
    • In plugin_basename() sort plugin paths before resolving symlinks. [37983] #28441

    Resource Hints

    • Remove schemes from dns-prefetch resource hint outputs. [38036] #37240



    • Remove an unnecessary double assignment in WP_Term_Query::get_terms(). [38020] #37254


    • Don’t change the memory_limit setting during tests. See #32075. [38016] #32075
    • Ensure that test for invalid user ID actually uses an invalid user ID. [38005] #37308
    • Add description for data_get_comments_number_text_declension(). [37997] #13651

    Text Changes


    • PHP 7 compatibility issues fixed in Twenty Thirteen and Twenty Fourteen [38026] #37227



    • Allow 0 as a value for the tabindex property of a menu item. [38035] #32495


    • Do not remove event handlers when trying to update a theme. [38019] #37285


    • After [37972], ensure that $box['args'] is an array before trying to access __widget_basename. [38004] #35021


    Thanks to @A5hleyRich, @adamsilverstein, @afercia, @azaozz, @birgire, @boonebgorges, @DrewAPicture, @elrae, @ericlewis, @Faison, @helen, @iseulde, @jaspermdegroot, @jdgrimes, @jeremyfelt, @joedolson, @joemcgill, @johnbillion, @jrf, @karmatosed, @metodiew, @niallkennedy, @ocean90, @pento, @peterwilsoncc, @rachelbaker, @ramiy, @rmccue, @sc0ttkclark, @scottbasgaard, @SergeyBiryukov, @spacedmonkey, @stubgo, @swissspidy, @valendesigns, @westonruter, @wpfo, @xknown, and @Zuige for their contributions!

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