WordPress.org

Make WordPress Core

Updates from May, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Rachel Baker 11:11 pm on May 18, 2015 Permalink |
    Tags:   

    WP REST API: Version 1.2.2 (Security Release) 

    WP REST API versions 1.2.2 and 2.0 Beta 1.1 are now available. These are critical security releases affecting versions 1.2.1 and 2.0 Beta 1.

    On Saturday, the WP REST API team was made aware of an issue where authenticated users were able to escalate their privileges bypassing the expected capabilities check. Thanks to Kacper Szurek (@kacperszurek) for reporting this issue to the team responsibly.

    This release was coordinated by the REST API team and the WordPress core security team. The security team is pushing automatic updates for version 1.2.2, but do not wait or rely on the automatic update process. We recommend sites or plugins that are using either v1.2.x or 2.0 Beta 1 update the plugin immediately.

    Update with one click from Dashboard → Updates, get it from the plugin directory (zip), or pull it from GitHub.

    If you believe you have discovered a potential security vulnerability with the WP REST API, please disclose it to us privately by sending an email to security@wordpress.org. Security issues can also be reported via HackerOne.

    If you have a question about the release, you can find the team in #core-restapi on WordPress.org Slack, or you can privately message @rachelbaker, @rmccue, @danielbachhuber, or @joehoyle.

     
  • Jeremy Felt 11:22 pm on May 12, 2015 Permalink |
    Tags:   

    Multisite Office Hours Recap (May 12, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite.

    4.3 Release Objectives

    Our objectives for 4.3 can be split between UI/UX and back-end core. Here’s what we’re working on along with who is assigned or expressed interest in the past.

    Network Admin UI:

    1. Capture mobile flows and find areas to improve. @sofiarose, @kraftbj, @ubernaut
      • See last week’s office hours recap for a list of flows we’d like to capture
      • @hugobaeta has posted some desktop flow
      • This objective will likely mirror some of what the Admin UI group is doing. We’ll know more about individual opportunities as we dive in deeper.
    2. Combine scheme/domain/path in Add New Site and Edit Site workflows. @hugobaeta
      • When adding a new site, you should be able to just type the site’s new address without worrying about where to put each of the individual parts. https://wordpress.org should split into a scheme of https, domain of wordpress.org, and path of /
      • If an admin email is added that does not belong to an existing user, a user will be created with the site’s name and the user’s email address. There should be an opportunity to provide the user’s username and email in this scenario.
      • Related tickets: #22383, #31240, #14172, #14215
      • @hugobaeta will be working on some mock-ups
    3. Improvement of network upgrade workflow (ajaxify)
      • The current network upgrade process cycles through sites 5 at a time and processes the database upgrades. After each set of 5, the page refreshes and the next 5 are loaded. If one encounters an error, the entire process is stopped to await manual interaction. This should be something handled nicely via ajax.
      • Related tickets: #11869, #18292, #22589, #24922, #26056, #31405
      • @boren has posted a Mac/Chrome network upgrade flow

    Multisite core:

    1. Provide validation for domains, paths, emails. @boonebgorges, @johnbillion, @jeremyfelt
      • The combined scheme/domain/path objective above relies on the validation of domains, paths, and emails. There are several quirky restrictions in multisite that would be nice to clear up. The first step is to establish validation functions so that we can write tests and then change the results as needed.
      • Related tickets: #17397, #18777, #20019, #19724, #21994, #15936, #16126, #17904, #26784
    2. Introduce WP_Site, WP_Network, WP_Site_Query, WP_Network_Query. @johnjamesjacoby, @earnjam, @rmccue, @jeremyfelt

    If you’re interested in your name being attached to one of these objectives, please leave a comment here or a ping in #core-multisite.

    There may be room for more, or reason to swap one of these with something else once we start progressing. Let’s keep the list about this size for now so that we have something consumable. We’ll continue to revisit these objectives weekly throughout the cycle.

     
  • Rachel Baker 1:51 pm on March 24, 2015 Permalink |
    Tags:   

    WP REST API: Version 1.2 

    Hello everyone. Remember us? Today, I can finally announce the release of version 1.2 of the WP REST API.

    A short nine months after our last release we have support for Cross-Origin Resource Sharing, full request hijacking, JSON encode/decode errors, and a swarm of bug fixes.

    Here are the expanded highlights:

    • Add handling for Cross-Origin Resource Sharing (CORS) OPTIONS requests.

      Preflighted requests (using the OPTIONS method) include the headers Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Credentials in the response, if the HTTP origin is set.

      (props @rmccue, #281)

    • Allow overriding full requests.

      The json_pre_dispatch filter allows a request to be hijacked before it is dispatched. Hijacked requests can be anything a normal endpoint can return.

      (props @rmccue, #281)

    • Check for JSON encoding/decoding errors.

      Returns the last error (if any) occurred during the last JSON encoding or decoding operation.

      (props @joshkadis, @rmccue, #461)

    • Add filtering to the terms collection endpoint.

      Available filter arguments are based on the get_terms() function. Example: /taxonomies/category/terms?filter[number]=10 would limit the response to 10 category terms.

      (props @mauteri, #401, #347)

    • Add handling for the role parameter when creating or updating a user.

      Allow users to be created or updated with a provided role.

      (props @pippinsplugins, #392, #335)

    • Add handling for the post_id parameter when creating media. Allow passing the post_id parameter to associate a new media item with a post.

      (props @pkevan, #294)

    • Handle route matching for - in taxonomy and terms.

      Previously the regular expression used to match taxonomy and term names did not support names with dashes.

      (props @EdHurtig, @evansobkowicz, #410)

    • Handle JSONP callback matching for . in the function name.

      Previously the regular expression used to match JSONP callback functions did not support names with periods.

      (props @codonnell822, #455)

    • Fix the Content-Type header for JSONP requests.

      Previously JSONP requests sent the incorrect application/json Content-Type header with the response. This would result in an error if strict MIME checking was enabled. The Content-Type header was corrected to application/javascript for JSONP responses.

      (props @simonlampen, #380)

    • Add $context parameter to json_prepare_term filter.

      Terms responses can now be modified based on the context parameter of the request.

      (props @traversal, #316)

    • Move the JavaScript client library into the plugin.

      Previously, the wp-api.js file was a separate repository. The JavaScript client has moved back into the plugin to coordinate code changes.

      (props @tlovett1, #730)

    • Always return an object for media sizesThe media sizes value should always be an object even when empty.

      Previously, if a media item did not have any sizes set, an empty array was returned.

      Compatibility warning: Clients should be prepared to accept an empty object as a value for media sizes.

      (props @maxcutler, #300)

    • Give top-level posts a null parent value.

      For date type consistency, post parent property should be null. Previously, parent-less posts returned 0 for parent.

      Compatibility warning: Clients should be prepared to accept null as a value for post parent.

      (props @maxcutler, #391)

    • Move permission checks out of WP_JSON_Posts.

      Introduce json_check_post_permission() function to allow post object capability checks to be used outside the WP_JSON_Posts class.

      Deprecation warning: Calling WP_JSON_Posts::check_read_permission and WP_JSON_Posts::check_edit_permission is now deprecated.

      (props @rachelbaker, #486, #378)

    • Split comment endpoints into separate class.

      All comment handling has moved to the WP_JSON_Comments class.

      Deprecation warning: Calling WP_JSON_Posts::get_comments, WP_JSON_Posts::get_comment, WP_JSON_Posts::delete_comment, and WP_JSON_Posts::prepare_comment is now deprecated.

      (props @whyisjake, @rmccue, @rachelbaker, #378)

    • Split meta endpoints into separate class.

      All post meta handling has moved to the new WP_JSON_Meta_Posts class.

      Deprecation warning: Calling WP_JSON_Posts::get_all_meta, WP_JSON_Posts::get_meta, WP_JSON_Posts::update_meta, WP_JSON_Posts::add_meta, WP_JSON_Posts::delete_meta, WP_JSON_Posts::prepare_meta, and WP_JSON_Posts::is_valid_meta_data is now deprecated.

      (props @rmccue, @rachelbaker, #358, #474)

    • Rename internal create methods.

      Deprecation warning: Calling WP_JSON_Posts::new_post, WP_JSON_CustomPostType::new_post and WP_JSON_Posts::new_post is now deprecated.

      (props @rachelbaker, @rmccue, #374, #377, #376)

    • Fix discrepancies in edit and create posts documentation examples.

      Corrected the edit and create posts code examples in the Getting Started section. The new post example was updated to include the required content_raw parameter. The new and edit posts examples were updated to use a correct date parameter.

      (props @rachelbaker, #305)

    • Update the cookie authentication documentation examples.

      With 1.1 the localized JavaScript object for wp-api.js changed to WP_API_Settings. This updates the Authentication section documentation nonce example to use the updated object name.

      (props @rachelbaker, #321)

    • Add flexibility and multisite support to unit tests.

      Tests can be run from any WordPress install, and are not limited to only as a plugin installed within a WordPress.org develop checkout. Unit tests are now run against a multisite installation.

      (props @danielbachhuber, #397)

    As always, we’ve got a full list of all the changes and a longer changelog.

    Here’s who contributed to this release:

    $ git shortlog 1.1.1...1.2 --summary
        1  Chris O'Donnell
        12  Daniel Bachhuber
         1  David Hayes
         4  DrewAPicture
         7  Eddie Hurtig
         2  JDGrimes
         1  Japh
         5  Josh Kadis
         1  Josh Pollock
         1  Justin Sternberg
         2  K.Adam White
         1  Marko Heijnen
         2  Max Cutler
         2  Mike Auteri
         1  Milan Dinić
         1  NikV
         3  Paul Kevan
         2  Pippin Williamson
        86  Rachel Baker
        73  Ryan McCue
         7  Sarah Gooding
         1  Simon Lampen
         2  Taylor Lovett
         1  Travis Hensgen
         1  Wayne K. Walrath
         1  ironpaperweight
         1  kalenjohnson
         1  kellbot
         1  paul de wouters

    Release Plan

    1.2 will be the last major release on the 1.x branch of the plugin. We’ve been working hard over the past four months, with the aim of releasing a beta for version 2.0 next month.

    For existing code written for version 1.x we will issue a final 1.x release as a compatibility shim to seamlessly connect existing code to version 2.

     
    • Heather Acton 1:55 pm on March 24, 2015 Permalink | Log in to Reply

      Woohoo!!! Congratulations! Great work to all.

    • Emyr Thomas 2:02 pm on March 24, 2015 Permalink | Log in to Reply

      This is great news, thanks for the update. Two quick questions…

      1. What’s the current status for getting this into WordPress core? I assume if it’s still going to make it into core, that won’t happen until version 2?
      2. What’s the situation with regards to the overlap between this project and the Jetpack/WP.com JSON API? Are both projects going to remain separate, or are there plans to merge somewhere down the line?

      • Rachel Baker 2:46 pm on March 24, 2015 Permalink | Log in to Reply

        Emyr,

        It would be version 2 that makes it into WordPress core, and the timeline for that is “sometime in 2015″. I cannot speak for the Jetpack/WP.com team, but our goal is to make the WP REST API too impressive to refuse.

        • John Teague 3:58 am on March 25, 2015 Permalink | Log in to Reply

          I’ve reviewed v4.2. Believe me, REST API is already too impressive to put off including in core any longer. Not that I don’t appreciate a solid 100% commitment towards maintenance, but a a solid innovative inclusion in core would be a breath of fresh air these days :)

  • Mike Schroder 8:49 am on November 14, 2014 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Hi Everyone!

    It’s that time again: WordPress Core Weekly is here. This is a catchup post and covers all commits since the last post up until 11/9/2014.

    First, a couple quick notes!

    Taxonomies

    • Do not create shared taxonomy terms. [30240] #21950; See #5809.
    • Split shared taxonomy terms during term update. [30238] [30239] [30241] #5809
    • Don’t force child_of=0 for non-hierarchical taxonomies in get_terms(). [30265] #30275
    • In get_adjacent_post(), $excluded_terms should check term_id rather than term_taxonom_id. [30263] #29663, #22112.
    • Allow resource_type to be specified in get_ancestors(). Being explicit about resource type (taxonomy vs post_type) allows for the proper resolution of conflicts when a taxonomy and post_type share a slug. [30141] #15029
    • In wp_insert_term(), clean up accidental duplicate terms after insert. [30238] See #22023, #5809.
    • Add some unit tests for is_object_in_term(). These tests check a number of the ways that different kinds of values for $terms (integers that match term_id, strings that match term_id or name or slug) are handled. [30204] #29467
    • In in_object_in_term(), only check numeric string values against term_id. [30205] #29467
    • Introduce term_template param to get_the_taxonomies() to allow theme and plugin authors to specify the formatting on term links as they are parsed into the taxonomy list. [30209] See #27238.
    • Allow duplicate slugs across different post types. [30158] #18962
    • In get_terms(), do not override hierarchical and pad_count when parent is present. The previous behavior resulted in descendant terms being improperly excluded from the results when passing a parent, even when hierarchical had been set to true. [30107] #29815
    • Clean up get_term_by() caching, fix cache key/group modification that was missed in [30073], and update unit tests. [30108] #21760

    Twenty Fifteen

    Database

    • Bump db_version and add upgrade routine for schema change in [30056]. [30121] [30134] #22023
    • WPDB’s __get() function should perform strict comparisons against member names. [30292]

    Revisions

    • Allow revision Backbone classes to be used on pages other than revision.php. [30128] #30221
    • Add a single responsibility function for outputting Revisions JS templates: wp_print_revision_templates(). Use it in wp-admin/revision.php. [30129] #30220
    • Revisions modules should not rely on global settings; only pass in global settings on init, this allows the classes to be used agnostically elsewhere. [30131] #30219

    Metadata

    • Pass all updated meta IDs to filters in update_metadata(). [30140] #11683
    • Unserialize get_metadata() results when key is omitted. [30115] #15030

    Queries

    Admin

    • Display error message when Media Library upload fails. [30156] [30177] #29891
    • Delete admin_created_user_subject() rather than deprecate. As it was never used as anything more than a callback to a filter before the MU merge, and is only available in user-new.php in multisite, it is safe to remove this function entirely. [30176] #29915

    Customizer

    • Improve/introduce Customizer JavaScript models for Controls, Sections, and Panels, along with a reference. [30102] see #28032, #28579, #28580, #28650, #28709, #29758. Fixes #29529.
    • Improve ColorControl‘s wpColorPicker to update UI based on setting changes. Update Twenty Fifteen’s colorScheme control to properly interact with the API, using wp.customize.control(). [30126] #30031
    • Add stable sorting for panels, sections and controls in JS. Improve sorting in PHP. [30214] #30225
    • Bind input and propertychange events for range input types. [30219] #30223
    • Twenty Fourteen: Make featured content in Customizer contextual to the front page. [30143] #29578

    Templates

    • Introduce new template functions for archive titles and descriptions: [30223] #21995
      • get_the_archive_title() and the_archive_title() for returning/displaying the title of the current term, date, post type, post format, or author archive.
      • get_the_archive_description() and the_archive_description() for returning/displaying the description associated with the current term archive.
    • In get_page_children(), only check $page->ancestors once to avoid duplicates when the function recurses. Adds an argument, $ancestors. [30246] #18962
    • Allow get_pages(), with child_of passed to it, to work with interrupted hierarchies. [30159] #18962

    Thanks to @afercia, @avryl, @azaozz, @bobbingwide, @boonebgorges, @bradyvercher, @Caspie, @celloexpressions, @dancameron, @davidakennedy, @davidjlaietta, @dikiy_forester, @dlh, @donutz, @DrewAPicture, @ericlewis, @filosofo, @florianziegler, @garyc40, @gcorne, @greuben, @hereswhatidid, @iamtakashi, @iandstewart, @imath, @Jayjdk, @jeremyfelt, @jesin, @joedolson, @johnbillion, @jorbin, @kitchin, @kovshenin, @kraftbj, @kurtpayne, @lancewillett, @landakram, @loushou, @markjaquith, @mattkeys, @mattwiebe, @mboynes, @MikeHansenMe, @mlteal, @mordauk, @morganestes, @nacin, @NikV, @nobinobi, @obenland, @ocean90, @pento, @philiparthurmoore, @realloc, @rmccue, @ryankienstra, @sakinshrestha, @SergeyBiryukov, @slobodanmanic, @TobiasBg, @tollmanz, @tywayne, @voldemortensen, @wedi, @westonruter, and @wonderboymusic for their core contributions!

    Revisions covered: [30094] to [30292]. For the complete list of commits to trunk, check out the log on Trac.

    Interested in joining in? Write or test a patch for 4.1.

     
  • Ryan Boren 8:15 pm on November 3, 2014 Permalink
    Tags:   

    Open Update Thread 

    What’s going on in your core development world this week? Drop a comment. Let it OUT.

     
  • Mark Jaquith 5:20 pm on September 10, 2014 Permalink
    Tags: ,   

    9/10 Agenda 

    WordPress 4.0 “Benny” is out the door, warming hearts, flying off shelves, and many other euphemisms besides. After a brief respite to enjoy our success and a job well done, we turn our eyes to the future: 4.0.1, 4.1, and more.

     
    • Ionel Roiban 5:31 pm on September 10, 2014 Permalink | Log in to Reply

      Congratulations, everyone!

    • Stephane Daury (stephdau) 5:43 pm on September 10, 2014 Permalink | Log in to Reply

      4.1 release lead nominations: I’m going to go right in crazy mode and suggest @rmccue.
      Note: I have not discussed that with him, so it’ll catch him by surprise.
      My logic is as so:

      • in May, we had a big IRC convo during our weekly chat about committing to WP API.
      • From what I can tell, said API is quite ripe for 4.1, or could be with the proper effort.
      • Making Ryan a lead (if he can afford to) could be a good way to make WP API the big ticket item for 4.1
      • Stephane Daury (stephdau) 5:46 pm on September 10, 2014 Permalink | Log in to Reply

        That’s also obviously my vote for the focus in 4.1. :)

      • Justin Sainton 6:41 pm on September 10, 2014 Permalink | Log in to Reply

        Really great suggestion! I think @rmccue would make an awesome lead, but I just don’t know about it for the release where he’s the lead on such a major component as the WP-API.

        Just spitballing here, but I wonder if it wouldn’t be a better situation to have someone as a release lead who can shepherd the whole release, not just that specific component? In my imagination, getting the API in the 4.1 release would require someone like Ryan to be more fully devoted to that specific component than to the whole release.

        Just my two cents.

      • Andrew Nacin 6:41 pm on September 10, 2014 Permalink | Log in to Reply

        When the API is merged in, we’d probably be best served with Ryan’s focus to be 100% on the API, and not need to worry about anything else also going on. The release lead is as much a project manager as it is a final arbiter, shepherd, and what not. Also, the API is going to be a big ticket item in the release it’s in, no matter what. :)

      • Michael Beil 4:44 am on September 12, 2014 Permalink | Log in to Reply

        I concur with having @rmccue at the helm.

    • Stephane Daury (stephdau) 5:51 pm on September 10, 2014 Permalink | Log in to Reply

      Call to action on feature plugins for 4.1 and beyond: in the same line as my WP API suggestion, and if it does make it in 4.1, I (we?) would like to resume work on the Press This rewrite, with the twist of building it as a WP API client. It could act as a great bundled example.

    • Andrew Nacin 6:57 pm on September 10, 2014 Permalink | Log in to Reply

      Some questions to ask:

      • What have we done in the last few releases that could benefit from a v2, even small things?
      • What have we added in the last few releases that needs to be propagated to other areas?
      • What have we not touched in a very long time and is long overdue for a revisit?
      • What brand new features should we consider working on?
      • What existing features need a complete rethink?
      • What are some bite-sized things that we could do to make a big impact? (3.9 and 4.0 were full of these.)
      • What are big things that are broken and that we feel like we could fix / make better?
      • What might Twenty Fifteen benefit from having in core?

      Also, if you want to help lead a release or want to suggest someone, be sure to read this post from 4.0.

      • Stephane Daury (stephdau) 7:08 pm on September 10, 2014 Permalink | Log in to Reply

        For #1 and #2: we delayed a move to Backbone.js (propagate) for the plugins browser/modal (updated in last release) in 4.0, under my advice, to focus on functionality rather than getting bogged down in a library switch. Should that be tackled that in 4.1, building on the experiences of the Media Grid et al?

      • Nick Halsey 7:30 pm on September 10, 2014 Permalink | Log in to Reply

        To address several of those points, I’d like to continue iterating on the Customizer. Starting to build out better JS APIs in particular, building up to several features that’ve been delayed due to the lack of structure here.

        I’d really like to get media in the Customizer rebuilt (initial patch on #21483), and to officially deprecate and redirect/deep-link the old header and background admin screens. Given Twenty Fifteen’s emphasis on those features, this seems like a good time to finally pull the trigger here.

      • John Blackbourn 7:31 pm on September 10, 2014 Permalink | Log in to Reply

        What have we not touched in a very long time and is long overdue for a revisit?

        I think we need to have a think about all the JavaScript which is landing in WordPress these days, and make sure we are documenting it well enough, whether we need to prioritise an action/filters API for this, whether we are doing enough to educate contributors and other developers on the JavaScript APIs, whether we need a better structure for the .js files, etc etc. See also Eric’s post on wp-hackers.

        What are some bite-sized things that we could do to make a big impact?

        Fix the currently rubbish comment notification settings. See #6286, #14676, #761, Email Alerts plugin.

      • Ihor Vorotnov 2:01 am on September 11, 2014 Permalink | Log in to Reply

        Jumping in here. The feature which is highly anticipated by literally any WP developer outside US and several other english-speaking countries is… some multilingual features in core.

        Here’s my idea in details: https://wordpress.org/ideas/topic/native-multilingual-cms-features-one-more-time#post-27185

        Basically, even making terms slugs non-unique and adding some super-taxonomy `language` will allow major plugin developers (WPML, Polylang) do the rest. WPML currently allows to have posts and pages with same slugs, but not categories, tags and custom taxonomies.

        Right now I’m building a pretty large international website, which will function a s a website and a mobile app platform (backend) – thanks to JSON API. Having urls like `example.com/ru/profile-2/edit` or `example.com/ru/profile-ru/edit/` (just plain simple hierarchical pages) is kind of freaky. Or `example.com/ru/events/country/canada-2/city/toronto-2` and `example.com/ru/events/country/canada-ru/city/toronto-ru`…

        Sooner or later, we need to add solid multilingual features to core to become CMS / Framework, not a blog platform.

    • Zach "The Z Man" Abernathy 7:18 pm on September 10, 2014 Permalink | Log in to Reply

      I personally would love to see a little more work in the area of media with respect to actually managing the media items. For instance, being able to group things in folders would be a huge improvement.

    • John Blackbourn 7:21 pm on September 10, 2014 Permalink | Log in to Reply

      I would like to get the ball rolling on open and closed Multisite networks which didn’t get any traction in 4.0 due to time constraints.

    • Boone Gorges 7:23 pm on September 10, 2014 Permalink | Log in to Reply

      I won’t be able to make this meeting, but I’d like to spend some time during the 4.1 cycle improving WP_*_Query classes. Improved test coverage (see eg #29560), followed by fixing some of the more egregious bugs (such as #19623), and adding what I see as some missing features (#29181, #29181, and a few others I am cooking up). May also look into abstracting some of the common logic into some sort of base class that the others will extend.

    • Robert Dall 8:01 pm on September 10, 2014 Permalink | Log in to Reply

      I’d like to fix the poor UI In the widgets since they were last updated. Specifically #27180 I know we can do better.

    • Aaron Jorbin 8:12 pm on September 10, 2014 Permalink | Log in to Reply

      I’d like to work on getting our JS unit tests running automatically on multiple browsers. I’d also like to look into some automated tests around front end performance of the admin and finding areas that we can speed things up (and also maintain a benchmark of how things are).

    • Xavier Borderie 8:16 pm on September 10, 2014 Permalink | Log in to Reply

      I’d vote for changing the in-editor image update, making like the one in Confluence. I use this wiki tool at my job, and love that, while WP uploads the file and shows the library, letting me inserting the media, when I really want to directly insert it in place. Makes a huge difference.

      • Xavier Borderie 8:17 pm on September 10, 2014 Permalink | Log in to Reply

        “in-editor image upload*”

      • Xavier Borderie 8:35 pm on September 10, 2014 Permalink | Log in to Reply

        Top notch foreign typography. It’s very hard, for instance, using French quotes or non-breaking spaces in the editor without resorting to copy-paste. The editor tries to hot-swap curly quotes but fails in many cases.

      • Xavier Borderie 8:39 pm on September 10, 2014 Permalink | Log in to Reply

        For translators: mark clearly strings that are used in JS, HTML labels/title tags or e-mail, because some translations use HTML entities to get some local things done, and that obviously does only work in HTML situations, not the others. I’m willing to work on that.

      • Xavier Borderie 8:29 am on September 11, 2014 Permalink | Log in to Reply

        Finally tackling that multilinguism issue — or at least build the foundations in 4.1, because it’d make for a great 4.2 announcement (‘cos, y’know, 42, Hitchhiker’s Guide, the Babel fish, all that :) ). Allegedly, the SPIP CMS does it very well (see here for their introductory post).

        • Vincent Mimoun-Prat 8:01 am on September 18, 2014 Permalink | Log in to Reply

          +1 For that too. Multilingual support is as of today more or less buggy depending on the plugin you are using. There are very few options out there and they all are flawed to some extend.

          It would be great to see at least a first step towards a multilingual base framework that plugins could eventually use to build a UI on top of that.

          Current approaches:

          • WPML has CPT and lots of meta data to translate taxonomies -> extra useless queries, bloated UI and code, …
          • Multilingual Press requires one subsites per language -> lots of duplicate site setup required + does not work for e-commerce where you would need two separate shops, would have two separate stocks, …
          • Some other plugins use markup within posts/taxonomies -> Makes editing a nightmare.

          Basically because no foundation for multilingual support is there, we don’t have a mean to get a decent solution to the problem.

      • Xavier Borderie 12:44 pm on September 15, 2014 Permalink | Log in to Reply

        Oh, and since I just got another two requests for that non-ending issue: please do something about the “WordPress address (URL)” and “Site address (URL)” setting fields! People keep using it with no other thought, this bringing their site down, hoping for others to help them out! There must be a better way: hide it, add a warning, anything else than giving the impression that the use can enter URL in these fields and that WordPress will magically set everything in place :)

    • Stephen Edgar 9:50 pm on September 10, 2014 Permalink | Log in to Reply

      The Export API was proposed for 4.0 and didn’t make it, would be great for 4.1:
      Export API improvements/overhaul #22435

    • Dan Milward 11:34 pm on September 10, 2014 Permalink | Log in to Reply

      I agree with Nick Halsey. For me it’d be something small and scene setting for more socket.io integration in the future – its hard to argue against the technology on the basis that Automattic acquired it right?

    • Brandon Wamboldt 2:15 am on September 11, 2014 Permalink | Log in to Reply

      The last few releases have made great strides in user experience in the admin, but now I think the team should focus on developers a bit for 4.1. As somebody who works frequently in WordPress, a big pain point is still list tables.

      I frequently create custom tables for data that really don’t fit the mold of post types, and I often have to duplicate large amounts of code to create a list view that mimics the other list views (posts/pages/etc). If you guys could ease that, it would be awesome!

    • Shail 5:00 am on September 11, 2014 Permalink | Log in to Reply

      For me most awaited feature is taxonomy meta. Is this feature in race? I know this is a very big change but I like to see it in core.

    • Ryan Boren 12:50 pm on September 11, 2014 Permalink | Log in to Reply

      I’ll dump my rough notes.

      Mobile and media. Media and mobile.

      Context, Trust, Awareness, Flow

      Press This. With the mobile improvements to the media modal that landed in 4.0, Press This can use the modal without being crippled on phones. The wordpress.com/post/ editor on wordpress.com has worked through some of the same problems that Press This needed to work through, hopefully smoothing the way. The /post/ editor also showed what you can and cannot get away with. Media, preview, and links are important. wpviews and wplinks are must haves. Media must be visual, not raw html, short codes, or even placeholders. Creating galleries should be possible and easy. Press This has a freedom that the /post/ editor does not. PT doesn’t have to worry with existing content edit flows. It can be tailored to a fairly one way creation flow (akin to Tumblr). It also has an advantage in that it can and does allow escaping to the full editor in the admin when the user needs more than PT provides.

      Press This is not just UI. It is bookmarklets, extensions, side-loading, re-blogging, and sharing. It is the sharing mechanism in Android and iOS8. Someday it will be accommodated by the apps. Keep the entire Press This and sharing ecosystem in mind. When dev resumes, prioritize bookmarklets and fleshing out the sharing mechanisms, especially on mobile. Press This the UI is, in part, a trojan horse for getting a decent mobile posting interface on phones, but the sharing big picture should not be lost to new UI fascination.

      Press This the UI should be a marquee user of WP API.

      Large (full screen-ish) images should be a tap/click away in the media modal. Creating and captioning galleries is difficult when provided only thumbnails. Maybe borrow the attachment details modal from grid view.

      Re-think media modal for touch devices. Get rid of tabs, especially in the absence of multi-select. Full images on tap with details below (like the attachment modal) rather than opening the sidebar and presenting another thumbnail sized image. That sidebar is awful on phones.

      Re-think the media modal in general. We know more about how it is used than we did back when. We know what plugins are actually rather than speculatively doing with it. Is having a separate gallery flow still a necessary compromise? Is a sidebar the best way for plugins to integrate? Is there anything blocking VideoPress and Dropbox plugins from integrating? Which plugins integrate well with the media modal?

      Create gallery and image posts from the media library grid view. Give bulk selection a purpose. This will accommodate mobile flows where images are uploaded to the media lib from a mobile device (via Android’s multi-select capable sharing mechanism, for example) and then gallery posts are later created from a desktop. This is a means of working around our lack of mobile multi-select and gallery creation interfaces.

      Phone UX improvements, particularly menus. Is it possible to swipe to open/close side menus on the mobile web? Side menus must have swipe to be usable. Tapping a menu icon in b’ar should dismiss the menu instead of visiting a link. There is often no safe “tap outside” room on a phone, so all menus should dismiss when their icons are tapped. Very aggravating.

      When adding links on mobile, don’t require highlighting text to activate link icons. Buggy on phones.

      Tweak wplinks for phones. It’s already pretty good and keyboard up/down responsive, but mostly by accident.

      Multi-select upload everywhere.

      B’ar consistency. The front page b’ar on touch devices is my favorite. Tablets in landscape show the narrower b’ar in the admin, which always disappoints me.

      Images uploaded to the media library and then added to a post don’t show up in the “Uploaded to this post” filter. Not being able to filter down to images already on the post makes setting featured images tedious. Uploading from mobile to media lib and then posting later is a common mobile flow.

      Fix the image editor on phones.

      Lose media-new.php?

      Oh wouldn’t it be nice…

      Settings that don’t suck.

      An index.php featuring Press This and a reader.

      Reader views for all list table screens.

      Theme switching from the customizer.

      Notifications, Stream.

    • Paal Joachim Romdahl 11:01 pm on September 11, 2014 Permalink | Log in to Reply

      Improving/renewing Settings was briefly touched upon but stopped up. Having a real useful Settings section would of course be really helpful. I bet a lot of people would have input about this and I bet there are also a few developers that really would like to come together and make this happen.

    • Stephen Edgar 5:54 am on September 12, 2014 Permalink | Log in to Reply

      Another suggestion, and with 99 stars at the time of writing:
      https://core.trac.wordpress.org/ticket/12706 – Custom post status bugs in the admin

      • pampfelimetten 8:37 am on September 18, 2014 Permalink | Log in to Reply

        Oh, yes please! I’m waiting for ages to have this fixed. It’s pretty weird that so much of the post status functionality is hardcoded, when you can tailor pretty much everything else to your needs in wordpress.

    • leemon 6:11 pm on September 12, 2014 Permalink | Log in to Reply

      Please, tackle the following taxonomy bugs once and for all:
      https://core.trac.wordpress.org/ticket/5809 – Updating a term in one taxonomy affects the term in every taxonomy
      https://core.trac.wordpress.org/ticket/5034 – Impossible to have duplicate category slugs with different parents

      Fixing this would be cool too:
      https://core.trac.wordpress.org/ticket/22938 – Presentation of hierarchical taxonomy in Media modal should be checkboxes rather than comma-separated tag list

      Thanks

    • Paal Joachim Romdahl 9:12 pm on September 12, 2014 Permalink | Log in to Reply

      Certain features are directed toward a developer and would not really help a “regular” user as much. I am thinking that features also could be placed into categories of who would this be helpful for. Placing a feature into: Developer, Designer, Advanced Users, Basic Users. Most people who are associated with being here on this forum are very likely Developers. A few probably Designers and a very very would then place themself into the remaining two categories.

      As I work with education I identify myself have very strong empathy for a person who has just began with WordPress. And oftentimes see WordPress through their eyes. Core needs eyes on features from people with different backgrounds that can share thoughts and their perspectives into seeing a much larger view.

    • Rodrigo Primo 8:59 pm on September 16, 2014 Permalink | Log in to Reply

      Fixing the performance issue with the algorithm used to display a list of hierarchical posts (pages or another custom post type) would be a great improvement for 4.1. This ticket has a patch already and is waiting for dev feedback.

      https://core.trac.wordpress.org/ticket/15459

    • Vincent Mimoun-Prat 7:53 am on September 18, 2014 Permalink | Log in to Reply

      Hi,

      I have just updated the patch I had submitted for 3.8 and 3.9 on an important performance improvement for meta queries. It would be great if that could be reviewed and included in 4.0.1 or 4.1

      https://core.trac.wordpress.org/ticket/24093

    • Paal Joachim Romdahl 12:22 am on September 22, 2014 Permalink | Log in to Reply

      Improving the WordPress importer/exporter plugin would be nice. To have a separate section for media or improving on the media aspect of the import/export.

    • Dave Clements 6:39 pm on September 22, 2014 Permalink | Log in to Reply

      It’d be great to see the work already carried out on #21506 (Standard Theme Hooks) carried forward through testing and implementation.

    • JakePT 7:39 am on September 24, 2014 Permalink | Log in to Reply

      I’m desperate for #20943 to be fixed.

  • Ryan McCue 2:01 am on June 23, 2014 Permalink
    Tags:   

    JSON REST API: Version 1.1 

    I’m happy to announce the availability of version 1.1 of the JSON REST API.

    This release is a bit of a smaller, more focussed release as we work on increasing test coverage and squashing bugs. Here’s the juicy details:

    • Add new routes for taxonomies and terms.

      Taxonomies and terms have now been moved from the /posts/types/<type>
      namespace to global routes: /taxonomies, /taxonomies/<tax>,
      /taxonomies/<tax>/terms and /taxonomies/<tax>/terms/<term>

      Test coverage for taxonomy endpoints has also been increased to 100%.

      Deprecation warning: The /posts/types/<type>/taxonomies endpoint (and
      sub-endpoints with the same prefix) have been deprecated in favour of the new
      endpoints. These deprecated endpoints will now return a
      X-WP-DeprecatedFunction header indicating that the endpoint should not be
      used for new development, but will continue to work in the future.

      (props @kadamwhite, @rachelbaker, @rmccue, #198, #211)

    • Allow customizing the API resources prefix

      The API base (typically wp-json/) can now be customized to a different
      prefix using the json_url_prefix filter. Note that rewrites will need to be
      flushed manually after changing this.

      (props @ericandrewlewis, @rmccue, #104, #244, #278)

    • Give null as date for draft posts.

      Draft posts would previously return “0000-00-00 00:00:00″ or
      “1970-01-01T00:00:00″, as draft posts are not assigned a publish date. The API
      now returns null where a date is not available.

      Compatibility warning: Clients should be prepared to accept null as a
      value for date/time fields, and treat it as if no value is set.

      (props @rmccue, #229, #230)

    • Fix errors with excerpt.

      Posts without excerpts could previously return nonsense strings, excerpts from
      other posts, or cause internal PHP errors. Posts without excerpts will now
      always return an excerpt, typically automatically generated from the post
      content.

      The excerpt_raw field was added to the edit context on posts. This field
      contains the raw excerpt data saved for the post, including empty
      string values.

      (props @rmccue, #222, #226)

    • Only expose email for edit context.

      User email addresses are now only exposed for context=edit, which requires
      the edit_users permission (not required for the current user).

      The email address field will now return false instead of a string if the
      field is not exposed.

      (props @pkevan, @rmccue, #290, #296)

    • Correct password-protected post handling.

      Password-protected posts could previously be exposed to all users, however
      could also have broken behaviour with excerpts. Password-protected posts are
      now hidden to unauthenticated users, while content and excerpts are shown
      correctly for the edit context.

      (Note that hiding password-protected posts is intended to be a temporary
      measure, and will likely change in the future.)

      (props @rmccue, #286, #313)

    • Add documentation on authentication methods.

      Full documentation on authentication
      is now available. This documentation explains the difference between the
      various available authentication methods, and notes which should be used.

      (props @rmccue, #242)

    • Include new client JS from github.io

      The WP-API Javascript library is now loaded dynamically from
      wp-api.github.io to ensure it is always up-to-date.

      (props @tlovett1, #179, #240)

    • Don’t allow setting the modification date on post creation/update.

      As it turns out, WP core doesn’t allow us to set this, so this was previously
      a no-op anyway. Discovered during test coverage phase.

      (props @rachelbaker, @rmccue, #285, #288)

    • Check post parent correctly on insertion.

      Posts could previously be added with an invalid parent ID. These IDs are now
      checked to ensure the post exists.

      (props @rmccue, #228, #231)

    • Make sure the type is actually evaluated for json_prepare_${type} filter.

      This value was previously not interpolated correctly, due to the use of the
      single-quoted string type.

      (props @danielbachhuber, #266)

    • Return WP_Error instead of array of empty objects for a revisions
      permissions error.

      Previously, when trying to access post revisions without correct permissions,
      a JSON list of internal error objects would be returned. This has been
      corrected to return a standard API error instead.

      (props @rachelbaker, @tlovett1, #251, #276)

    • Flip user parameters check for insert/update.

      Previously, you could add a user without specifying username/password/email,
      but couldn’t update a user without those parameters. The logic has been
      inverted here instead.

      (props @rmccue, #221, #289)

    • Add revision endpoints tests

      (props @danielbachhuber, @rachelbaker, @rmccue, #275, #277, #284, #279)

    • Add post endpoint testing

      Now at >54% coverage for the whole class, and >80% for the main methods. This
      figure will continue to rise over the next few releases.

      (props @rachelbaker, @rmccue, #99)

    • Separate helper functions into global namespace.

      WP_JSON_Server::get_timezone(), WP_JSON_Server::get_date_with_gmt(),
      WP_JSON_Server::get_avatar_url() and `WP_JSON_Server::parse_date() have
      all been moved into the global namespace to decouple them from the server
      class.

      Deprecation warning: These methods have been deprecated. The new
      json_get_timezone(), json_get_date_with_gmt(), json_get_avatar_url() and
      json_parse_date() methods should now be used instead.

      (props @rmccue, #185, #298)

    As always, we’ve got a full list of all the changes and a longer changelog. Here’s who contributed to this release:

    $ git shortlog 1.0...1.1 --summary
         8  Daniel Bachhuber
        12  DrewAPicture
         3  Eric Lewis
         2  JDGrimes
         9  K.Adam White
        54  Rachel Baker
       128  Ryan McCue
         4  Taylor Lovett
         1  jeremyfelt
         1  pkevan

    Version 1.2

    We’ve already started work on 1.2, and as always, we’re looking for help!

    With version 1.2 and onwards, we’ll be tackling a bunch of extra testing for our endpoints, with the aim of eventually reaching >90% coverage. As always, we’ll also be adding new features and fixing bugs.

    We’re also working on improving the new documentation site, and expect to see the majority of documentation migrated over there. Thanks to Sarah Gooding for helping out on the documentation side.

    Core Integration

    In case you missed it, the API is now slated for integration in WordPress 4.1. WP Tavern has a great writeup on the details.

    As always, we look forward to seeing you at the team o2 and on GitHub. Now’s also a great time to remind you that you can get support for the plugin on WP.org, or by tweeting at me. Thanks to everyone who made this release great, and thanks to everyone using the plugin!

     
    • Ian Dunn 4:14 pm on June 23, 2014 Permalink | Log in to Reply

      Include new client JS from github.io

      Is this intended to be a permanent change? I could be wrong, but I think Core’s policy (and also the wporg plugin directory’s) is that assets should be local.

      (Open Sans is an exception, because it’s very difficult to reproduce everything that Google’s API does locally.)

    • Stephane Daury (stephdau) 6:20 pm on June 25, 2014 Permalink | Log in to Reply

      Awesome work, gang.

  • Ryan McCue 4:45 am on May 25, 2014 Permalink
    Tags:   

    JSON REST API: Version 1.0 

    I’m incredibly excited to announce the availability of version 1.0 of the JSON REST API.

    This version is a huge release and introduces a bunch of new features, such as user, revision and post meta endpoints. It also introduces our long-term backwards compatibility policy, aligning with WordPress core backwards compatibility.

    Here’s a selection of the new stuff:

    • Add user endpoints.

      Creating, reading, updating and deleting users and their data is now possible
      by using the /users endpoints. /users/me can be used to determine the
      current user, and returns a 401 status for non-logged in users.

      Note that the format of post authors has changed, as it is now an embedded
      User entity. This should not break backwards compatibility.

      Custom post types gain this ability automatically.

      (props @tobych, @rmccue, #20, #146)

    • Add post meta endpoints.

      Creating, reading, updating and deleting post meta is now possible by using
      the /posts/<id>/meta endpoints. Post meta is now correctly embedded into
      Post entities.

      Meta can be updated via the Post entity (e.g. PUT to /posts/<id>) or via
      the entity itself at /posts/<id>/meta/<mid>. Meta deletion must be done via
      a DELETE request to the latter.

      Only non-protected and non-serialized meta can be accessed or manipulated via
      the API. This is not predicted to change in the future; clients wishing to
      access this data should consider alternative approaches.

      Custom post types do not currently gain this ability automatically.

      (props @attitude, @alisspers, @rachelbaker, @rmccue, @tlovett1, @tobych,
      @zedejose, #68, #168, #189, #207)

    • Add endpoint for deleting a single comment.

      Clients can now send a DELETE request to comment routes to delete
      the comment.

      Custom post types supporting comments will gain this ability automatically.

      (props @tlovett1, @rmccue, #178, #191)

    • Add endpoint for post revisions.

      Post revisions are now available at /posts/<id>/revisions, and are linked in
      the meta.links.version-history key of post entities.

      Custom post types supporting revisions will gain this ability automatically.

      (props @tlovett1, #193)

    • Respond to requests without depending on pretty permalink settings.

      For sites without pretty permalinks enabled, the API is now available from
      ?json_route=/. Clients should check for this via the autodiscovery methods
      (Link header or RSD).

      (props @rmccue, #69, #138)

    • Add register post type argument.

      Post types can now indicate their availability via the API using the
      show_in_json argument passed to register_post_type. This value defaults to
      the publicly_queryable argument (which itself defaults to the
      public argument).

      (props @iandunn, @rmccue, #145)

    • Remove basic authentication handler.

      This breaks backwards compatibility for clients using Basic
      authentication. Clients are encouraged to switch to using OAuth
      authentication
      . The Basic Authentication plugin can be
      installed for backwards compatibility and local development, however should
      not be used in production.

      (props @rmccue, #37, #152)

    • Require nonces for cookie-based authentication.

      This breaks backwards compatibility and requires any clients using cookie
      authentication to also send a nonce with the request. The built-in Javascript
      API automatically handles this.

      (props @rmccue, #177, #180)

    • Clean up deprecated methods/functions.

      Functions and methods previously deprecated in 0.8/0.9 have now been removed.
      Future deprecations will take place in the same manner as WordPress core.

      This breaks backwards compatibility, however these were marked as
      deprecated in previous releases.

      (props @rmccue, #187)

    • Only expose meta on ‘edit’ context as a temporary workaround.

      Privacy concerns around exposing meta to all users necessitate this change.

      This breaks backwards compatibility as post meta data is no longer
      available to all users. Clients wishing to access this data should
      authenticate and use the edit context.

      (props @iandunn, @rmccue, #135)

    • Add json_ensure_response function to ensure either a
      WP_JSON_ResponseInterface or a WP_Error object is returned.

      When extending the API, the json_ensure_response function can be used to
      ensure that any raw data returned is wrapped with a WP_JSON_Response object.
      This allows using get_status/get_data easily, however WP_Error must
      still be checked via is_wp_error.

      (props @rmccue, #151, #154)

    • Use version option to check on init if rewrite rules should be flushed.

      Rewrite rules on multisite are now flushed via an init hook, rather than
      switching to each site on activation.

      (props @rachelbaker, #149)

    As always, you can view all commits or the longer changelog.

    For those interested, here’s the list of contributors to this release:

    $ git shortlog --summary 0.9...
         1  Chris Marslender
         1  Eric Lanehart
         2  K.Adam White
         1  Kat Hagan
         2  Matth_eu
        41  Rachel Baker
       139  Ryan McCue
         5  Taylor Lovett
        10  Toby Champion
    

    There’s a few really important things to note with this release.

    Authentication Changes

    Authentication has changed significantly in 1.0. If you’ve been using Basic authentication previously, you’ll now need to install the Basic authentication plugin. This plugin is designed for local development, as Basic authentication requires sending your plaintext credentials over the wire, which is unsafe for production.

    Production users have two choices: built-in cookie authentication, or OAuth authentication. OAuth 1.0a is an authorization protocol that allows you to authorize clients to act on your behalf, and does not require giving your username and password to the client. It does, however, require a significantly more complicated authentication/authorization process, and clients are required to register on the site beforehand. We’re working on long-term solutions to this.

    Plugins and themes can also use built-in cookie authentication. This is the normal WordPress login process, however requires a nonce for authentication to the site. This is automatically handled for you when using the built-in Javascript client.

    Backwards Compatibility

    From this release forwards, backwards compatibility will not be broken. This includes both the internal PHP API, as well as the REST API we expose. New endpoints may be added, as well as new data, but responses will continue to be supersets of the current response.

    The exception to this is for security concerns. As we continue development, we may need to change some endpoints for security issues, as we did with post meta for this cycle. These will be announced well before release where possible.

    Please note also that this release has removed some previously deprecated methods and changed some internal implementation details. This only affects plugins or themes that extend the API.

    Core Integration

    We’re pushing hard for integration into 4.0 this cycle, and we need your help. Our core integration plan outlines the motivation behind the project and the specific plan for integrating it into core. We’re currently working on a comparison document for the API compared to the WP.com/Jetpack API and others, and will be publishing that soon.

    We need your help to make it into 4.0. Developers, we’d love to know what you’ve built with the API, whether public or internal (even vague details help!), and we’d especially love to see things built with the API. We’re currently in danger of not making it in this cycle, so anything you can do to help us here would be fantastic.

    As always, we’re also looking for help. The main API always needs help, and the other related projects do too. Both the WP-CLI client and Javascript client need help here.

    You’re always welcome over at the team o2, and our next meeting will be at Tuesday, 00:00 UTC; we’d love to see you there. If not, see you soon for version 1.1!

     
    • Nikola Nikolov 7:45 am on May 25, 2014 Permalink | Log in to Reply

      I’ve used the JSON API to make front-end submissions to a budgeting app I did for my family.
      I basically only use it for publishing entries in custom post types. I started using the plugin while it was at .6, or .7, so I had to extend it in order to get the endpoints and post meta handling that I needed, but it wall worked out just great.
      I haven’t had the time to update from 0.8 to the latest version, since I’m not sure how much code I’d have to change and I don’t really have lots of free time these days :)

      But in any case, it saves time(once you have it figured out), it’s reliable, well-written and I personally would love to see it in core. Because if it’s in core, more people would actually use it(which means having a more unified experience for developers). I’m sure almost everyone right now is using one of three methods in order to push/pull data via AJAX:

      • request to /wp-admin/admin-ajax.php
      • request to /wp-content/plugins/…./plugin-ajax.php
      • request to the current url, with a hook on init or something else

      — Nikola

    • Nashwan Doaqan 2:12 pm on May 25, 2014 Permalink | Log in to Reply

      Good work @ryan and all the team.. it’s really a big project :)

    • cemdev 3:17 pm on May 25, 2014 Permalink | Log in to Reply

      Please, please, please let this make it into 4.0. The xml-rpc API is soooooo crap. And insecure. Really looking forward to leveraging a modern, more secure API for our customers.

    • Mikel King 3:21 pm on May 25, 2014 Permalink | Log in to Reply

      Very cool! Thank you @ryan and the whole team I can’t wait to mess around with this! I would love to see a talk on this at WordCamp NYC in Aug…

    • Towfiq I. 3:48 pm on May 25, 2014 Permalink | Log in to Reply

      +1 this SHOULD be in core!!

    • memuller 11:47 pm on May 25, 2014 Permalink | Log in to Reply

      This is really, really impressive. curl’ing those API endpoints is a lot of fun.
      Will surely use in future projects, regardless of its inclusion on core. It’s superior to the Jetpack API, and clearly superior to the default one.

      As Nikola pointed out, the ways currently in use to perform data operations via AJAX are a little awkward. As someone that is frequently sough for WP-related advice, I would *really* appreciate if this was included on core, since them I could teach novices to use it for AJAX calls – if it remains as a plugin, it would be a little irresponsible to do so. I think that’s an important point – experienced developers will always be able to use this API as a plugin, regardless of its inclusion on core; but we can’t expect first-time wordpressers to depend on a plugin; they will just google for the “standard” way of doing things and will stick to it.

      I used to work in a local media conglomerate, heavily dependant on WordPress. At the time, I did a *lot* of integration between WP and other applications – a work that would have been a lot easier if this API already existed; specially since most of those apps were quite RESTfull (rails applications, sinatra and node middlewares and the like). It would have allowed us to keep a higher quality standard on our infrastructure – without it, we did some integrations with the Jetpack API, some with RPC, and some even by mucking with the database directly. This API would have provided us with a way that was so much better and easier than the alternatives, that no developer – regardless of skill level – would have been able to ignore it.

    • Eric Andrew Lewis 2:31 am on May 26, 2014 Permalink | Log in to Reply

      Will there be some kind of versioned usage of the API, so that breaking changes can be made in a new version, but the old version can still be supported?

      • Ryan McCue 4:07 am on May 26, 2014 Permalink | Log in to Reply

        Beau Lebens asked the same over on the o2, here’s my response:

        The plan for versioning, if it’s ever needed, is to use Content-Type headers to indicate the version, much the same way that GitHub versions their APIs. This doesn’t affect the current approach, so it’s not something needed at this point.

        • Eric Andrew Lewis 9:11 am on May 26, 2014 Permalink | Log in to Reply

          B)

        • Aaron Jorbin 6:05 pm on May 28, 2014 Permalink | Log in to Reply

          I don’t like this approach for a couple of reasons. 1) It makes it harder to use tools like Curl for testing. 2) It would make debuging by looking at server logs harder. 3) It also adds a higher barrier to entry for developers as not all developers know how to add headers. Yes this can be solved with education, but I don’t think every problem should be solved with education.

          I think we should add the version string into the url.

          • Mikel King 7:27 pm on May 28, 2014 Permalink | Log in to Reply

            I have to imagine that WP_Http (where adding headers is really rather trivial) is preferred over curl.

            • Aaron Jorbin 7:31 pm on May 28, 2014 Permalink

              I’m was talking about from the command line, not from php. Sorry that wasn’t clear.

    • Eric Lanehart 6:07 pm on May 27, 2014 Permalink | Log in to Reply

      We’ve been using WordPress as an API at sparkart for many of our projects, starting with the Americas Cup (http://sparkart.com/work/americas-cup) in 2012/13. That project used Dan Phiffer’s JSON API plugin in a manner similar to what he built that plugin to do for the MoMA: supply content to a Ruby-based server. Nowadays we use node.js (http://github.com/solidusjs) in the same fashion. This allows us to easily integrate data from other sources and simplify our production and development environments by removing a database dependency. Our production sites are essentially static, fronted by a CDN for fast performance around the world. Unlike static site generators content is refreshed as it expires.

      YoungMoney.com, official site of Lil Wayne, is using the JSON REST API plugin today. All sites in development also rely upon it. We’re actually planning to migrate all content from a legacy, proprietary CMS to WordPress. We began using the plugin as of 0.6, seeing a much clearer future than the existing JSON API plugin and appreciating the thoughtful design behind it. We also considered the Thermal API plugin but found it’s implementation, particularly around media, to be uneven. The response schema also seemed too much of an abstraction.

      This maybe isn’t the most compelling use case since we flout much of the WordPress ecosystem (themes, widgets, plugins, etc). But a new class of CMS’s have emerged in this time (Osmek, Contentful, Prismic.io) that are essentially the same proposition: content management without the presentation layer. The problems they solve around support for mobile apps and other non-browser based environments connected to the web is also tremendously valuable. The Quartz use case along with some examples of similar node.js-fronted sites like the WSJ, other Dow Jones properties, and Artsy have helped validate our approach in my mind. Except unlike Quartz we don’t need expensive WordPress VIP installations to scale to millions of visitors.

      As developers we’re all about the Unix philosophy of small, focused tools. We strongly prefer these tools to be open whenever possible, and this is one reason we continue to use WordPress despite the existence of these services.

    • paulkevan 9:55 am on May 28, 2014 Permalink | Log in to Reply

      Although we (metro.co.uk) haven’t used any the JSON api plugin, due to using WP.com VIP, we have built replica json endpoints so we can consume some of our post meta fields in other applications.

      The other area we use is the XML-RPC endpoints to push in images from our picture management system and as previously mentioned this isn’t the nicest method to use.

      I’d be happy to get involved in the testing of any post meta based endpoints and also the development of the media endpoints, in particular the extending of what data can be send through these endpoints for each media item.

    • K.Adam White 8:44 pm on May 28, 2014 Permalink | Log in to Reply

      We’re using the API as the content backend for an in-development Node.js website and several single-page applications; nothing I can share publicly yet, but the API project was the tipping point that let me convince my colleagues that WordPress was a suitable backend for a non-PHP application. We’re really excited about the work we’re doing and I look forward to sharing it later in the year.

  • Mike Schroder 7:33 pm on April 9, 2014 Permalink
    Tags: ,   

    Last Week in WordPress Core 

    Howdy everyone! This is Last Week in WordPress Core for the week of March 31-April 7. I’m including all of the commits up to RC1 this week, which was released yesterday. Things are looking good, with very few remaining tickets open.

    3.8.2 and 3.7.2 were also released with security fixes, and automatic updates are rolling out.

    Developers, please test with your plugins and themes and let us know if you find issues.

    TinyMCE: As a quick note, since I’ve seen this brought up in the forums — in this release, TinyMCE no longer uses wpdialogs. This means it now needs to be enqueued by any plugin that wants to use it. As of [28024], there is a clarified warning that will appear in the JavaScript console if you attempt to use it, and it’s not enqueued.

    IE8 & wpview: Due to IE7/8 compat being necessary in TinyMCE (to resolve caret issues), IE8 and wpview are not currently the best of friends. Post RC1, fixes landed for #27546 that make wpviews degrade more gracefully.

    Media:

    • Playlists: Make elements in playlists responsive and fix playlist advancement on mobile. [27894] [27895] #27625
    • Playlists: Set preload='none' for the empty <audio|video> tag. [27974] #26779
    • Playlists: Make tracks keyboard-accessible. [28023] #27644
    • A/V Shortcodes: Remove support for a caption in audio and video shortcodes. This was part of a UX iteration for the related MCE views, but these captions have since been excluded. See [27640]. [27979] #27320
    • Edit Image Modal: Make the calculation of the aspect ratio more robust. [27942] [27948] #27366
    • Do not show featured images for image attachments; remove post_supports_thumbnails() and theme_supports_thumbnails() for now. [28051] #27673

    HTML5 Galleries:

    • Remove <br> elements for HTML5 galleries; see #26697. [27914] #27637
    • Twenty Thirteen and Fourteen: Update styles to support the new HTML5 line-break-less galleries. [27926] #27637

    Admin:

    Theme Installer:

    Widgets

    • Trigger jQuery events for widget updates. widget-added when a widget is added to a sidebar and widget-updated/widget-synced for widget soft/hard updates. [27909] [27969] #19675; #27491
    • In WP_Widget, introduce is_preview() method to allow widgets to check to see if they’re currently being previewed via the customizer. [27966] #27538
    • Widget Customizer: Improve compatibility with plugin custom scripts and styles for widgets. [27907] #27619
    • Widget Customizer: Rename inject_preview_css to print_preview_css. [27968] #27534
    • Widget Customizer: Use postMessage to highlight widgets in preview or sections/controls in Customizer. [27892] [27893] #27622
    • Widget Customizer: Refactor and clean up WidgetCustomizer as wp.customize.Widgets, and make available widgets panel a Backbone view. [27985] [27986] [27988] [27995] [28034] #27690

    TinyMCE

    • Update TinyMCE to 4.0.21. [27897] #24067
    • Image Details Modal Improve look-and-feel, and add a Custom Size option to the size drop-down that reveals fields for soft-resizing the inserted image. [27918] #27366
    • Image Details Modal: Move all advanced options under a single toggle, bring back the field for CSS Class, and optimize CSS for responsive layout. [27898] #27366
    • Drag and Drop Uploading: Add new argument to wp_editor() to enable. [27901] #27465
    • Gallery Views: Avoid JS errors when image attachments lack metadata. [28008] #27691
    • Return to loading /langs/[locale].js and /langs/[locale]_dlg.js from PHP to prevent errors with missing translation files when requireLangPack() is used without its second argument. Back to using ISO 639-1 (two letter) locales. #24067; [27922] #27610
    • Clarify error when wpdialogs is not enqueued. Add wp_enqueue_editor action fired when scripts and styles for the editor are being enqueued. [28024] #16284
    • Update translatable strings. [27927] #27453, #24067
    • Tighten up toolbar and tab styles. [27978] [27983] #27279
    • Expose toolbar keyboard shortcut in Help documentation for TinyMCE, and clean up TinyMCE help dialog, removing duplicated text and leaving only Keyboard Shortcuts. [28029] #27024; [28032] #27100

    Database:

    • Fall back from ext/mysqli to ext/mysql if the connection fails. This allows us to avoid breaking a site that works under ext/mysql but is misconfigured for ext/mysqli. [27935] #21663
    • Add $allow_bail argument to wpdb::check_connection() to match the connect method. [27925] #27240
    • Don’t pass a second argument to mysqli_fetch_field(). [28002] #27693
    • Rename USE_EXT_MYSQL to WP_USE_EXT_MYSQL. [28022] #21663

    Internals:

    • Updates: Record Plugin & Theme update statistics like we do for Core updates. [27905] [27906] #27633
    • Pingbacks: Forward pingback IP during verification. [27872] #27613
    • Dashicons: [27989] [28005] [28013] #26936
      • New icons: .dashicons-external, .dashicons-editor-contract and .dashicons-universal-access-alt.
      • Updated icons: .dashicons-code, .dashicons-universal-access, .dashicons-arrow-x-alt and .dashicons-arrow-x-alt2.
      • Restores .dashicons-post-trash as an alias for .dashicons-trash, which is the new one.
      • Use new icons in Widget Customizer.
    • Don’t try to resolve symlinks for single-file plugins. plugins_url() should not be used in this context anyway. [27999] #16953
    • Remove old links_recently_updated_* DB options that never had a UI. [27916] #27649
    • Deprecate wpmu_current_site(). [28009] #27702

    Many thanks to @adamsilverstein, @andykeith, @avryl, @azaozz, @bramd, @chiragswadia, @davidmarichal, @dd32, @dpe415, @duck_, @DrewAPicture, @DrProtocols, @ehg, @eightface, @empireoflight, @gcorne, @helen, @jackreichert, @jdgrimes, @jeremyfelt, @jesin, @joedolson, @johnbillion, @jorbin, @jond3r, @kovshenin, @kpdesign, @leewillis77, @markjaquith, @matveb, @mcsf, @melchoyce, @michael-arestad, @nacin, @Nessworthy, @norcross, @obenland, @ocean90, @pento, @plocha, @rachelbaker, @rmccue, @sdasse, @SergeyBiryukov, @siobhan, @sonjanyc, @tellyworth, Tom Adams, @vancoder, @westonruter, and @wonderboymusic for their help this week!

    For the complete list of commits to trunk, check out the log on Trac. Since we’re getting very close to release, the best way to help is to test! Let us know if you run into problems in the Alpha/Beta forums or on trac.

     
  • Ryan McCue 6:49 am on April 6, 2014 Permalink
    Tags:   

    JSON REST API: Version 0.9 

    Hi everyone! I’m happy to announce that version 0.9 of the JSON REST API is finally available.

    Apologies for the extremely long delay here. I would have liked to ship OAuth authentication with 0.9, and the release was delayed due to that. However, it’s still not in a shippable state, and we’re well overdue for a release.

    Important note: There are backwards compatibility breaks and deprecations in this release. These are all listed before, but exercise caution in upgrading. Backwards compatibility will be maintained from 1.0 onwards only.

    Here’s the big changes:

    • Move from wp-json.php/ to wp-json/

      This breaks backwards compatibility and requires any clients to now use wp-json/, or preferably the new RSD/Link headers.

      (props @rmccue, @matrixik, #46, #96, #106)

    • Move filter registration out of CPT constructor. CPT subclasses now require you to call $myobject->register_filters(), in order to move global state out of the constructor.

      This breaks backwards compatibility and requires any subclassing to now call $myobject->register_filters()

      (props @rmccue, @thenbrent, #42, #126)

    • Introduce Response/ResponseInterface

      Endpoints that need to set headers or response codes should now return a WP_JSON_Response rather than using the server methods. WP_JSON_ResponseInterface may also be used for more flexible use of the response methods.

      Deprecation warning: Calling WP_JSON_Server::header, WP_JSON_Server::link_header and WP_JSON_Server::query_navigation_headers is now deprecated. This will be removed in 1.0.

      (props @rmccue, #33)

    • Change all semiCamelCase names to underscore_case.

      Deprecation warning: Any calls to semiCamelCase methods require any subclassing to update method references. This will be removed in 1.0.

      (props @osiux, #36, #82)

    • Add multisite compatibility. If the plugin is network activated, the plugin is now activated once-per-site, so wp-json/ is always site-local.

      (props @rachelbaker, #48, #49)

    • Add RSD and Link headers for discovery

      (props @rmccue, #40)

    • WP_JSON_Posts->prepare_author() now verifies the $user object is set.

      (props @rachelbaker, #51, #54)

    • Added unit testing framework. Currently only a smaller number of tests, but we plan to increase this significantly as soon as possible.

      (props @tierra, @osiux, #65, #76, #84)

    As always, you can view all changes on GitHub as well as view all closed tickets.

    For those interested, here’s the list of contributors to this release:

    $ git shortlog 0.8... --summary
         1  Aaron Jorbin
         1  Anders Lisspers
         6  Bryan Petty
         1  Dobrosław Żybort
         7  Eduardo Reveles
         1  K.Adam White
        10  Rachel Baker
        41  Ryan McCue
         2  Taylor Lovett
    

    I’m still desperately seeking feedback on our OAuth implementation. This is a hugely important part of the API, and we need to get this nailed down as soon as possible.

    General comments and posts are always welcome on our team o2.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar