Make WordPress Core

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • David A. Kennedy 9:56 pm on October 18, 2016 Permalink |
    Tags: , ,   

    Twenty Seventeen: Merge Proposal for 4.7 

    A note from @helen: Before we get into the proposal itself, I’d like to officially introduce its author, @davidakennedy, as a committer for bundled themes. We really should have done this ages ago, but now he’ll get to make a big splash with Twenty Seventeen. Congrats, David! ūüéČ


    The team behind Twenty Seventeen has reached that point that we’re ready to propose Twenty Seventeen as the new default theme for WordPress in 4.7. It’s an ambitious theme that focuses on a creative home page and an easy site setup experience for users.

    Like last year, with Twenty Sixteen, the development process happened on GitHub. The theme will be merged into WordPress from the beta period on, and development will move to Trac. Some remaining tickets will move over to Trac at that time.

    Features of Twenty Seventeen

    Created with the feedback on previous default themes in mind, and the desire to reach a new audience, Twenty Seventeen was designed for business websites. It offers:

    • multiple sections on the front page, selected in the Customizer.
    • a striking asymmetrical grid.
    • custom color schemes, built on top of a monochromatic foundation, and adjustable via a hue picker.
    • different headline placement for pages, changeable in the Customizer, via theme options.
    • a great experience in many languages, thanks to language-specific font stacks.
    • SVG icons (a first for a default theme).
    • support for custom logo, custom header image and many post formats.
    • the use of new functions in Core for making child theming easier.


    As usual, a default theme couldn’t happen without the community. This year, Twenty Seventeen has benefited from 57 amazing contributors so far (up from 38 at this point last year). They have helped with:

    • triaging issues.
    • providing code reviews.
    • testing and recommending language specific font stacks.
    • improving the theme‚Äôs accessibility.
    • browser and device testing.
    • numerous bug fixes, code tidying and countless improvements.

    Testing, Feedback and Next Steps

    While contributors have tested Twenty Seventeen on various devices and browsers throughout the development process, edge cases still exist. Please test Twenty Seventeen in as many different environments as you can.

    Until the merge deadline, contributors to Twenty Seventeen will work on the Core Merge milestone in GitHub, knocking out as many issues as possible.

    A big thank you to everyone that has helped make Twenty Seventeen come to life.

    • hiddenpearls 10:28 pm on October 18, 2016 Permalink | Log in to Reply

      is very happy to take part in making this awesome theme ready for such a big audience.
      Congrats Theminator @davidakennedy

    • Mark Root-Wiley 11:13 pm on October 18, 2016 Permalink | Log in to Reply

      This is very exciting! Is there a public live beta version of this site available for easy front-end testing (especially on mobile devices?)

    • Tara 12:39 am on October 19, 2016 Permalink | Log in to Reply

      How about creating the next theme designed ONLY for blogging websites (NOT business)!

      • Aaron Jorbin 3:22 pm on October 19, 2016 Permalink | Log in to Reply

        There are a number of default themes that have blogging as a main goal. Twenty Fifteen and Twenty Thirteen are two that I really like.

      • Knut Sparhell 5:07 pm on October 19, 2016 Permalink | Log in to Reply

        Most of the Twenty* themes are for excellent for blogging. Twenty Seventeen is the first one I personally see as a not-so-good-for-simple-blogging Twenty-theme. I would recommend both Twentu Fifteen and Sixteen as a simple, light-weight and modern themes for blogging. Twenty Ten and Eleven are technically a bit old, and old fashioned today, so forget them, if not for “retro” look.

  • Pascal Birchler 7:26 am on October 18, 2016 Permalink |
    Tags: ,   

    Preferred Languages 

    With the introduction of language packs two years ago ([29630]), it’s easier than ever for users to change the main language¬†of their site. However, in some cases a single locale (i.e. the¬†language variant, like Canadian French) is not enough.

    Let’s say a site of mine is running German (Switzerland), which there is a language pack for. However, most plugins only have a German (Germany) translation, or perhaps only even a¬†de_DE_formal¬†translation. As a native German speaker, I’d prefer to read a German (Germany)¬†translation instead of English, if a German (Switzerland)¬†version did not exist.¬†Instead of getting translations¬†as I’d wish (as the translations are very similar),¬†WordPress falls back to the¬†original English strings. That’s a poor user experience for many non-English speakers. Now, since the addition of a user-specific¬†language (#29783), this issue¬†is even more important.

    There’s been a long discussion about this issue in #28197, where possible solutions have been suggested without any¬†consensus. Instead of directly talking about¬†how this can be technically implemented, we should first¬†explore the actual user experience problems and see what’s possible and how it might look.

    For this, I began researching how other software approach this problem. Those of us interested in this problem can learn from existing solutions and proceed from there.

    These screenshots should give you a better understanding of¬†what I’m talking about:

    As you can see, these software products create a ‚Äúfallback chain‚ÄĚ for the user’s preferred languages.¬†In theory, I could also set my preferred languages¬†to¬†es_ES -> de_DE -> en_GB -> en_US, if that was the order in which I preferred translations.

    To keep momentum and continue thinking through this problem, I want to kick off a feature project, about improving the experience for WordPress users who use the product in non-English languages, of which multiple locales may exist.

    Get Involved

    Your feedback is incredibly important to ensuring we get this right. Leave any thoughts in the comments below. Would you like to help out? Awesome. Let’s have an initial chat on Wednesday, 26 October 2016, 17:00 UTC in the #core-i18n Slack channel and go from there.

    I’ve set up a GitHub repository that can be used¬†as a playground for discussions,¬†prototypes, and eventually¬†a working solution. For this, design and accessibility feedback would be very helpful. I’m confident that we can build¬†something that we can propose for inclusion in a future WordPress release!

    • Chantal Coolsma 7:42 am on October 18, 2016 Permalink | Log in to Reply

      I will definitely help testing this when it is available for testing.

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

      Count me in !
      This is very useful for smaller teams e.g. fr_BE to be able to have fr_FR translations if the plugin/theme is not yet translated into fr_BE
      But also for a ‘startup’ locale like nl_BE where people could already switch from the beginning to nl_BE but still have nl_NL as backup language while nl_BE is started.
      However please remember the final goal is that the plugin/theme gets translated into the main language of the site, so warnings/indications that it uses the backup language should be indicated somewhere and point to e.g. GlotPress where people could contribute.

      • Pascal Birchler 8:31 am on October 18, 2016 Permalink | Log in to Reply

        However please remember the final goal is that the plugin/theme gets translated into the main language of the site, so warnings/indications that it uses the backup language should be indicated somewhere and point to e.g. GlotPress where people could contribute.

        The user’s desire is to simply have a great experience with functioning translations. A warning doesn’t sound like a great experience, but we can try to pick this topic up during the chat. It sounds more like a case for #23348 / #33007 though.

    • Torsten Landsiedel 9:21 am on October 18, 2016 Permalink | Log in to Reply

      I think Bernhards Plugin is working for most uses cases here:

      And if you need more, there is a filter for doing a “fallback chain”.

      I don’t know if it is needed to provide a UI to configure a fallback chain (as seen in the screenshots) as I don’t think it is needed by the majority os users.

      I really would like to see this in core and I’m happy to help with testing it.

    • pix365 9:48 am on October 18, 2016 Permalink | Log in to Reply

      I’d go for this be in the core – With the provision that it has ta UI. Why? as i think this provides a simpler management work-flow that will suit none tech savvy users, without this UI, how would one change the preferred languages and their order? ( custom coding, I guess.)

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

      Sounds great to me! Is there any sort of standard that lists sets of languages with fallbacks that could simplify the UI here? (i.e. “de-ch should fallback to de-de”) Having the UI available still would be nice for the case where you know two unrelated languages, however, so I think the UI does make sense.

      • Pascal Birchler 10:10 am on October 18, 2016 Permalink | Log in to Reply

        I initially suggested something similar in the ticket:

        Why not create a new translatable string for a fallback chain. For example, in de_CH_formal we’d say we want to fall back to de_CH, de_DE_formal, de_DE ‚ÄĒ and of course to en_US in the end. This information could be translated on translate.wordpress.org by each locale.

        Leaving such a decision to translation maintainers or even plugin developers wasn’t perceived as a great idea back then, as it might not work under all circumstances. Using such a list to help simplify a UI might be worth exploring though.

        • Bernhard Kau 11:27 am on October 18, 2016 Permalink | Log in to Reply

          I liked the idea of a translatable string, as the translation maintainers usually know best which fallback chain is best. Adding a filter would also enable a developer to change it.

      • Mike Nelson 4:30 pm on October 18, 2016 Permalink | Log in to Reply

        +1 to having core just have default fallbacks if possible. If that’s able to serve 90% of users, then I think its reasonable for the other 10% to use a plugin which gives them a UI for customizing the fallback behaviour

      • Ze Fontainhas 7:51 pm on October 18, 2016 Permalink | Log in to Reply

        Much as I completely understand the drive for “standard fallbacks”, I’m not sure I love the idea, as it very much sounds like an engineering solution to a problem that isn’t one, or at least one that can’t be tackled by an algorithm. My problem with the approach is that it tries to impose hierarchy (i.e. “this language/variant is more… something than this other language/variant”), when not only does such hiereachy exist in real life, but simply cannot exist. To give an example, it is perfectly reasonable to imagine that users of pt_PT (Portuguese, Portugal) would fallback to pt_BR (Portuguese, Brazil) and that users of pt_BR would fallback to pt_PT. In fact, we (pt_PT) do it quite often, as do they (pt_BR). Why would one of those two be more…something than the other?

        • Bernhard Kau 10:52 pm on October 18, 2016 Permalink | Log in to Reply

          If we have a translatable string, each language pack could define it’s own fallback chain. So pt_PT could have pt_BR and pt_BR could have pt_PT.

          I agree that it’s not possible to have a perfect hierarchy, as this just doesn’t exists. But making it possible for the GTE to define a standard and adding a filter to enable (plugin) developers to change it, looks like a pretty good idea to me. And all is better than the current, non-existing, fallback to English.

          • Ze Fontainhas 10:58 pm on October 18, 2016 Permalink | Log in to Reply

            Fine, but

            > each language pack could define it’s own fallback chain.

            Let’s bring in another variant of pt_, say pt_AO (Angola, non-existant as of yet, but the case can be made with all the es_ variants). I, as a language pack admin, wouldn’t want to impose my vision (because it *is* a vision, and a subjective one at that) that the chain should be, say, PT, BR, AO. Why not PT, AO, BR?

            I think it’s for each user/site admin to determine that.

            • Bernhard Kau 11:03 pm on October 18, 2016 Permalink

              Which they could do using the filter or a plugin.

              Decisions, not options ūüėČ

              I would bet any other software that has a fallback did make that decision.

            • Ze Fontainhas 11:20 pm on October 18, 2016 Permalink

              Please, it’s not an option, it’s a decision. It’s just one that isn’t up to the language pack admin to make.

        • Samuel Wood (Otto) 11:54 pm on October 18, 2016 Permalink | Log in to Reply

          Ze, computers can’t make the decision for you. A hierarchy must exist so that the computer knows what to do. Therefore, somebody must make the decision.

          If there is no pt_pt, but there’s both pt_br and pt_ao available, which do you use? Some logic must exist to make that choice.

          Putting such a thing back on the user is avoiding the problem instead of solving it.

          • Ze Fontainhas 12:18 am on October 19, 2016 Permalink | Log in to Reply

            > computers can’t make the decision for you

            Nor ought they, and that is precisely my point. For a user, the fact that a “language pack admin” or “a computer” made that decision is the same: it is all “computer says x”.

            > Some logic must exist to make that choice.

            Indeed it must. I’m saying is that that logic will inevitably be the site’s administrator’s, not someone else’s (me, the language pack admin.) I’m saying that it is not possible to guess that logic for every single site administrator (and sorry, no, filters and more plugins are most clearly *not* editorial tasks.)

            Look, I’m wasn’t being religious about this, sorry if it came across that way. I will of course embrace the consensus decision, as always. It’s just that making these kinds of (eminently editorial) calls in spite of the sites’ owners gives me an itch.

            • Samuel Wood (Otto) 1:24 am on October 19, 2016 Permalink

              The site administrator is the “user” in my view. Sorry if that wasn’t clear.

              I’m cool with ways to override things, naturally. But a default should exist so that people don’t have to make that choice if it’s pretty standard for most cases.

    • Jonathan Bardo 12:55 pm on October 18, 2016 Permalink | Log in to Reply

      I like the idea of a chain of fallback that we would be able to reorder as the user see fit. I also don’t think there is a universal pattern here and we shouldn’t assume anything when it comes down to what is the best fallback for any geographic location.

    • Greg Ichneumon Brown 3:28 pm on October 18, 2016 Permalink | Log in to Reply

      Have you already looked at HTTP_ACCEPT_LANGUAGE? I don’t see it used anywhere in core. Those FF and Chrome settings get converted to HTTP headers which then define fallbacks. We use this on wp.com for trying to select the best language for a user during initial signup. Ping me on .org Slack for example code if that helps.

      I don’t know the extent to which users properly set multiple fallback languages though.

      • Samuel Wood (Otto) 11:57 pm on October 18, 2016 Permalink | Log in to Reply

        They often don’t, but I’d say that is a valid use case for choosing default languages to display in admin on a per user basis, if such a thing happens. But maybe not the best choice for deciding fallback to other language variants.

    • John Blackbourn 4:29 pm on October 18, 2016 Permalink | Log in to Reply

      As Greg mentioned, the browser language settings get sent with each request via the HTTP_ACCEPT_LANGUAGE header. It would be very worthwhile researching whether these settings could be used either as a seed for the user’s settings in WordPress, or whether it could be used as the actual language stack in place of a new UI in WordPress, or as a fallback for when the user has yet to set their language stack in WordPress.

    • Patrick Robrecht 5:23 pm on October 18, 2016 Permalink | Log in to Reply

      +1 for language fallbacks in the core. I don’t see any need for a fallback list UI for the list as fallbacks seem be quite clear:

      • For de_CH_informal the fallback list could be (in this order) de_DE (informal), de_CH_formal, de_DE_formal
      • For de_DE_formal the fallback list could be de_CH (formal), de_DE (informal), de_CH (informal)

      i. e. choosing other locales of the same language, but for languages with formal and informal versions consider about the formal/informal variant if available.

      As @casiepa I think that it’s important to show administrators if a fallback is used such that I’m informed if the de_DE is used instead of de_DE_formal as a company having set the German “Sie” as language might not want to use the “du” variant as fallback. If they get notified, then can check whether this is relevant for the plugin they use or simply contribute the missing translations.

      +1 for showing a hint “X isn’t available in your language yet. Translation is at y % – you can contribute translations at “. X could be WordPress itself or any plugin or theme.

    • Dirk Weise 6:10 pm on October 18, 2016 Permalink | Log in to Reply

      I’d rather see my native language in my blog’s backend when I log in from a Chinese internet caf√© to update my page with my latest impressions instead of having to guess what I’m doing. I think this header is more useful for displaying a fitting front end language to a visitor than choosing an administration page language.

    • Knut Sparhell 3:54 am on October 19, 2016 Permalink | Log in to Reply

      Both language preference and most of the fallback question was solved over 20 years ago and communicated over HTTP_ACCEPT_LANGUAGE. If user language option is not set, and the preferred language in HTTP_ACCEPT_LANGUAGE is installed, use that, top down.

    • Dominik Schilling (ocean90) 11:04 am on October 19, 2016 Permalink | Log in to Reply

    • Juniper 7:24 pm on October 20, 2016 Permalink | Log in to Reply

      Great brainstorming on an excellent idea! Configurable language-variant stacks.

      The data themselves could be stored as a simple string ‘aa_ee, aa_bb, cc_gg’ on three levels: WordPress defaults set in code or database, site defaults defined in wp_config or set in wp_options, and user defaults in usermeta; then concatenated to prefer user stack then site stack then wp stack.

      The add/remove/order UI could make it easy to select a language family (a cluster of related language-variants) at one go and then order & remove individual variants within it.

      Like it or not, we can’t avoid setting fundamental defaults for the underlying code to guide fallbacks in case none of the requested variants are available, even if doing so might feel like linguistic bias. If a stack consists of ‘de_ch_formal, de_ch’ but no Swiss German variant is available, I’d hope the software would be clever enough to default to any DE on hand before it defaulted to EN. But if EN is not the underlying default, what will be? Since we can’t avoid that ultimate bias, I figure we might as well create a variety of biases from which to choose; in selecting a language-specific version of WordPress to install or download, one implicitly selects a set of language stack defaults that is biased toward, variously, English or Chinese or Portuguese, etc.

      Pascal – “improving the experience for WordPress users who use the product in non-English languages, of which multiple locales may exist.” I would prefer, “who use the product in languages for which multiple locales exist.” Prithee don’t omit English from consideration of significant locale variants. Even if the variations are more often orthographic (spelling) rather than lexical (word choice), the differences do matter.

      Perhaps this goes without saying, but I easily see the same mechanism catering to both back-end and front-end users. While a language-selection UI may become part of the standard back-end admin settings it also could and arguably should have (perhaps as a bundled plugin) a stylable, configurable widget to be used by website visitors to set their language preference in the front end. In such a widget, storing its data in a cookie if the user isn’t logged on, the default presentation could simply be a single-selection menu of available language groups and/or variants as pre-selected by the site admin without any of the back-end’s stack-editing complexity.

  • K.Adam White 12:28 am on October 18, 2016 Permalink |
    Tags: , ,   

    REST API Team Meeting Notes, 2016-10-17 

    As a reminder, in just 30 minutes there is a meeting in #core to decide whether the REST API Content Endpoints will be merged as a part of WordPress 4.7! See the ongoing discussion of this proposal here. Note that the OAuth server is no longer proposed for merge at this time, but authentication options will be a primary focus area for the API project during the 4.8 development cycle.

    The¬†REST API Content Endpoints provide a new foundation upon which the WordPress developer community¬†can build themes, plugins, and core feature. They represent¬†a common standard and consistent interface across WordPress’s core content data types, and provide¬†robust support for custom post types and meta values.¬†These endpoints lay the foundation upon which future releases will add remote authentication options, even deeper querying abilities, and broader endpoint coverage for site management. This iterative approach fits WordPress’s development model and philosophy, advancing the project’s long-term goal of¬†opening WordPress up to a wider¬†developer audience¬†and¬†helping to ensure continued work on the REST API in the release cycles and years to come.

    Meeting Notes

    At today’s weekly API team meeting in core-restapi (agenda here) the team resolved all outstanding decisions milestoned for the REST API 2.0 / WordPress 4.7 merge candidate:

    • The ?filter query parameter will be removed from the REST API plugin prior to core merge, a breaking change that improves the consistency of querying the API and eliminates a set of parameters that could introduce backwards compatibility issues were they to be committed to WordPress core. A separate plugin will be published to reinstate the `filter` parameter on a strictly opt-in basis.
    • Comments on password-protected posts are being deferred as a future enhancement until a robust solution is proposed that permits the API to adequately mirror existing functionality.
    • The unfiltered_html capability should be respected by the API, and a patch will be submitted to bring the API’s behavior in line with core’s.

    There are 29 tickets left in the 2.0 milestone, several of which have open pull requests already. These issues represent a mix of outstanding bugs, documentation needs and improvements that will be moved to trac should the merge proposal be accepted.

    The REST API team leads would like to recognize that the content endpoints plugin now has 95 contributors: thank you and welcome to all of the new participants who have joined the project in the past week!

  • Pascal Birchler 9:49 am on October 15, 2016 Permalink |
    Tags: ,   

    Shiny Updates v3 Kickoff Chat 

    While the biggest chunk of Shiny Updates v2 was merged into WordPress 4.6, there were still¬†plenty of ideas that didn’t make it in time. I think it would be worthwhile to¬†bring more shininess to WordPress 4.8 or 4.9. Regular chats have been dormant for a while, but I’d like to continue them starting¬†Wednesday, 19 October 2016, 17:00 UTC¬†in the #feature-shinyupdates Slack channel.

    Topics for the first chat will include a brief update on current shiny updates bugs in WordPress core and the planned goals for Shiny Updates v3 (e.g. update-core.php). Some of the ideas can be found on GitHub.

    Now is a great time¬†to get involved and help making WordPress updates even more shiny. Please¬†come join us next week and contribute to the continuing abolishment of The Bleak Screen of Sadness‚ĄĘ.

    • Philip Ingram 3:30 pm on October 15, 2016 Permalink | Log in to Reply

      I won’t be able to make the chat but one thing that struck me again yesterday as a frustration (and not sure this actually falls under shiny updates) is why are we still not opening screenshot images for plugins in some type of light box modal vs forcing browsers to download the images. It’s not very convenient when one simply wants to view the image in larger form and I don’t think this would be that hard to pull off either.

      • Pascal Birchler 3:42 pm on October 15, 2016 Permalink | Log in to Reply

        Are you referring to the plugin directory? If so, the images should open in a new tab right now. If the images is being downloaded, it has the wrong mime type associated with it and the developer should fix this in Subversion (at least that’s required right now).

        For adding a light box, I’d suggest requesting that in #meta or https://make.wordpress.org/meta/. The new plugin directory is currently in the works and I’m sure the team will happily consider it.

  • K.Adam White 10:26 pm on October 14, 2016 Permalink |  

    REST API: Agenda for Oct 17, 2016 Meeting 

    The meeting to decide whether to merge the REST API Content Endpoints in WordPress 4.7 will occur at 2016-10-18 01:00 UTC in #core!

    Please comment on this feedback post with your arguments for or against.

    In preparation for that meeting, we will be holding bonus weekend office hours at 2016-10-15 17:00 UTC and 2016-10-16 17:00 UTC in #core-restapi.

    Our usual team meeting is also happening, on Monday at 2016-10-17 14:00 UTC. The agenda for this meeting:

  • David A. Kennedy 4:38 pm on October 14, 2016 Permalink |
    Tags: , ,   

    Twenty Seventeen: Agenda for Oct 14, 2016 Meeting 

    Here’s the agenda for today’s weekly meeting on Twenty Seventeen. It will last 30 minutes, and I’ll be around in the #core-themes channel for at least 30 minutes afterward to answer any questions.

    • General theme update.
    • Flexbox.
    • Open floor.

    Reminder: Meetings are every Friday at 18:00 UTC. Twenty Seventeen Features meeting every Tuesday at 17:00 UTC.

    • Joy 5:11 pm on October 14, 2016 Permalink | Log in to Reply

      I’m pretty new to Slack, so it took me awhile to find where the meeting actually is
      http s://wordpress.slack.com/messages/core-themes/
      and not
      http s://wordpress.slack.com/archives/core-themes

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

  • Helen Hou-Sandi 8:01 pm on October 12, 2016 Permalink |
    Tags: , ,   

    Dev Chat Agenda for October 12 (4.7 week 8) 

    This is the agenda for the weekly dev meeting on October 12, 2016 at 20:00 UTC:

    If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

  • K.Adam White 6:36 pm on October 12, 2016 Permalink |
    Tags: ,   

    REST API Team Update, 4.7 Week 8 

    Summary: Beta 15 has been released, there are open questions that would benefit from your feedback, and the Content API Endpoints and OAuth Server are being proposed for merge as distinct, separate enhancements to the existing WordPress REST API infrastructure.

    REST API v2 Beta 15 released

    The 15th beta release of the REST API content endpoints plugin was released on October 7. This release builds on top of the recent Beta 14 to…

    • Add support for Post Meta, Term Meta, User Meta and Comment Meta within their parent endpoints
    • Introduce a settings endpoint to allow key site setting values to be retrieved & modified using the API
    • Introduce query parameters to query for posts that are NOT IN one or many terms of specific taxonomies
    • Resolve bugs, including bad comparison logic when updating comments.

    Please try it out and report any outstanding issues; the REST API project gained its 90th code contributor this week and the team is deeply grateful for the energy and support of the broader WordPress community in testing out this merge-candidate plugin!

    New Questions & Discussion Items

    Items which have arisen through final ticket triage & review on which the team seeks feedback:

    1. Should the `filter` shim should be removed prior to merge? It is the majority position of the API team that `filter` be deprecated to dramatically improve the simplicity and consistency of API query functionality
    2. How should comments be handled for password-protected posts? Should the password be passed as a query parameter with the PUT/POST request, or is there a better option?
    3. Should the API match core’s logic when users with the `unfiltered_html` capability are creating or updating Posts or Comments?

    Meeting Notes

    At the weekly team meeting on October 10 the group reviewed open issues in the 2.0 milestone, which represents the candidate for our merge proposal shared last week.

    Meeting attendees agreed to review open issues and pull requests individually, and to reconvene on Tuesday at 1500UTC to ensure all priority tickets had an owner.

    At that meeting on October 11, the team reviewed the incoming feedback around the OAuth plugin (linked above). While the API team feels that having a built-in authentication solution provides a much-needed service, particularly to developers building mobile and desktop applications, the design and usability feedback we have received does indicate that the plugin needs more work.

    OAuth’s place in the Merge Proposal

    The API Team believes that the identified issues are resolvable, that the OAuth plugin is on track and that it should still be considered for merge in 4.7. However, after discussion within the team, input from @matt, and advice from @aaroncampbell and other core committers, we have edited our merge proposal to submit the Content API Endpoints and OAuth server as separate merge candidates. The API Team proposes both components for merge, but we submit the content endpoints for consideration independently of the OAuth1 server.

    Content Endpoints Without OAuth

    The Content API endpoints are stable, well-tested, and in wide production use across a variety of applications. Theme and plugin developers will benefit from having canonical, well-tested API endpoints in core, which may be used to query WordPress both from PHP code and from JavaScript applications running on the front-end or admin of WordPress. Sharing the endpoints for core data types enables increased consistency of what data is exposed and how it is persisted across different plugins, improving consistency and shortening development time by using . These themes and plugins have full read and write access to the API using the existing cookie & nonce authentication.

    Mobile and desktop applications can leverage these same endpoints in a read-only capacity to create a variety of powerful reader-oriented applications and tools that expand the capability of what WordPress can do today, such as a unified reader for Make WordPress blogs and other experiments hypothesized by @jorbin.

    Should OAuth 1 not be accepted for 4.7, secure write access for these external applications would still be only a plugin install away; and while having an OAuth server in core will provide a canonical approach for authenticating from remote applications, depending on the needs of a specific site or specific client application other authentication schemes may actually be preferable. Plugins exist for JWT Authentication and of course OAuth 2, and should OAuth 1 not be accepted for 4.7 these plugins may still be installed to enable an external application to opt-in to secure write access to your WordPress site.

    In Summary

    The API team submits for 4.7 merge consideration two enhancements to the REST API infrastructure: the Content API Endpoints for core WordPress datatypes, and an OAuth server which will reduce the setup time needed to securely interact with those endpoints from outside of WordPress. We believe these enhancements are each individually sufficiently tested and mature to meet the quality and security standards of WordPress Core, and each individually provides wide-reaching benefit to WordPress developers, and through them to the authors, readers & publishers of the web.

  • Mike Schroder 6:26 am on October 12, 2016 Permalink |
    Tags: , ,   

    Media Weekly Update (Oct 7) 

    This post serves to jump-start discussion before the weekly check in, which takes place in #core-images on Slack. The next meeting is Friday, October 14 at 17:00 UTC and agenda for these meetings includes moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on Trac.

    Summary from last week

    The last meeting was Friday, October 7 at 17:00 UTC. You can read the entire chat log in the #core-images channel on Slack.

    Attendees: @karmatosed, @joemcgill, @mikeschroder, @swissspidy, @flixos90, @desrosj, @azaozz, @paaljoachim, @markoheijnen, @adamsilverstein, @jorbin, @designsimply

    • Media organization improvements:
      • @joemcgill opened up conversation about a feature project to start work on this, explaining that we have the chance to take a UI/UX first approach.
      • @karmatosed is going to head up the UI/UX side of things.
      • @joemcgill thinks the likely first step is exploration of base taxonomy support, and a review on how it is currently broken with media.
      • @karmatosed asked all those interested in working on this to create sketches of their ideal media categorization flow for review by next week.
    • Add new core media widget (#32417) ‚Äď @joemcgill noted that the runway for 4.7 is ending, but work can continue for a future release. @designsimply to refresh the current patch on the ticket by Monday (October 10), and may target images specifically as a first step (this is still missing a refreshed patch).
    • Rotate Full Size Images on Upload (#14459)@mikeschroder profiled this and found that while the clock time for checking and setting orientation is minimal, it took ~230ms for an iPhone 7-sized image to be rotated (total 5.6s resize time) on a shared test server. He thinks total resize time should be reduced before this is added, and that #37140 is a better step for 4.7. After discussion with @markoheijnen and @azaozz, consensus seems to be that benchmarking of upload vs manual rotation should be done to prove the UX case for #37140 over #14459.
    • Accents in attachment filenames should be sanitized (#22363)@joemcgill pointed out the new patch here from @gitlost, which looks promising. @swissspidy to take a look over the weekend (feedback is on ticket now, but could use more eyes).
    • Better PDF Upload Management (#31050) – Everyone likes this, but time running out for 4.6. @markoheijnen to target next patch by Wednesday (Oct 12) (this was moved out of the milestone, as it’s currently missing a refreshed patch).
    • Responsive images (srcset) can include images larger than the full size (#36477) ‚Äď @mikeschroder didn’t have time to performance test the patch. To do so shortly and post feedback on the ticket (feedback is on ticket now).

    Agenda for the next meeting

    This week, discussion will continue on priority projects for the 4.7 release. If you have specific tickets that you want to have discussed, feel free to leave a comment on this post or reach out on Slack in the #core-images channel.

    Edit: Updated post per status on Wednesday, Oct 12.

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