Make WordPress Core

Updates from February, 2016 Toggle Comment Threads | Keyboard Shortcuts

  • Adam Silverstein 3:11 am on February 11, 2016 Permalink |
    Tags: , ,   

    Core Dev chat notes for Feb 10 


    Schedule Notes, Status Updates, Open Floor

    Schedule Notes

    • Today is the feature plugin decision deadline: Responsive Preview and Selective Refresh will be merged.
    • Next Wednesday (Feb 17) is the deadline for merge for these, with beta scheduled for the week after, on Feb 24.
    • Reminder: once beta ships, no more enhancements can be committed, so anything that is left or close to finished needs to be shored up in the next two weeks. Enhancements mile-stoned for 4.5 need attention to make it into the release in time.
    • Any help triaging the 4.5 milestone is definitely appreciated.
    • The REST API team’s proposal is to merge the four main endpoints when they are ready, and they are not ready for 4.5. As such, no endpoints are targeted for WordPress 4.5. A summary of last week’s chat is on make/core: leave feedback there or in the #core-restapi Slack channel.

    Status Updates:

    • Image Improvements: @joemcgill
      •  Cache output of `wp_upload_dir()` to improve performance (#34359) is about ready to go in after some unit test updates )
      • Making progress on Improving Imagick file sizes (#33642) and Better animated GIF handling (#28474)
      • @markoheijnen made some interesting progress on generating thumbnails of PDFs in the media library and could use some feedback if you’re interested #31050.
    • HTTPS Improvements: @johnbillion
      • Plan is enforcing HTTPS on a per-feature basis (eg. enqueued assets, post content, redirects, canonical, links).
      • HTTPS-by-default on install will be something to aim for for 4.6, but we’ll see what happens over this next week.
    • Customizer: @westonruter, @celloexpressions
      • Pushed out the new version of the Customize Partial Refresh plugin. Needs testing!
      • Introduces a framework for registering partials (refreshable regions) with complete rewrites of nav menu partial refresh and re-implementation of widget partial refresh to use the new framework.
      • Going to write a Make Core post about it, documenting the API.
      • Biggest question is whether widgets should opt-in for selective refresh by default. Widgets that use JavaScript for their display will need get updated to work with selective refresh.
      • Responsive Preview (#31995) @valendesigns:  need to add unit tests and address any remaining issues
    • Multisite/WP_Site: @jeremyfelt
      • 15 tickets on the 4.5 milestone. Hoping to establish readiness for these over the next week and get some stuff in.
      • Going to start focusing more multisite related energy toward the REST API’s site (and meta) endpoints.
    • Editor: @azaozz, @iseulde
      • No updates this week: planning to get paste shortcuts in and work on mce views.

    Open Floor

  • Adam Silverstein 4:58 pm on February 5, 2016 Permalink |
    Tags: ,   

    REST API meeting summary, Feb 4 

    The core REST API team, members of the WordPress.com API team, and other interested developers met to discuss the REST API.  Full logs of the meeting are available on Slack.

    Existing endpoints

    The meeting opened with a discussion of the existing endpoints: what is and isn’t ready. @rmccue summarized:

    • The main focus has been on the 4 “core” objects in WordPress: posts, terms, comments, and users.
    • Posts
      • Password-protected posts are going to be ignored from the API until we have a good solution.
      • Meta
        • Post (and other) meta has been pushed out into a separate feature plugin led by @jeremyfelt. Discussion is on the github repo.
        • The main issue is that there’s no differentiation between meta fields. Meta could be added via the Custom Fields meta box, or by a plugin.
        • Enhancing register_meta() in core would allow opt-in to the meta REST API – requiring some core work. See the patch on #35658 for details.
        • There is no current way to explicitly register meta as public.
        • We need to support object meta (post, user, comment, term) and object types (custom post types, etc)
      • Media
        • Mostly complete (it’s a custom post type).
        • Some special handling around uploading media.
      • Autosaves and post previews
        • Tricky, but we think we have a solution for that moving forward.
        • Working on them in a separate feature plugin instead.
        • This will be an enhancement to the API in the future, and doesn’t block compatibility.
    • Terms
      • Work great.
    • Users
      • Works great; undergoing final review.
    • Comments
      • Works; custom comment types are harder until core better supports them.

    Merge proposal and discussion

    An extensive discussion ensued regarding the possibility and appropriateness of merging the endpoints into core. The discussion continued for over an hour; mainly covering whether we should merge the 4 core endpoints, or wait for a complete API before merging…  and what the definition of a complete API is.

    The REST API team’s proposal is that we merge the 4 core objects in the REST API with full read, create, update, delete support, then add more peripheral features when they’re ready. 

    @matt argued that we wait until the API supports everything you can do in wp-admin before merging.

    The discussion revolved around these proposals and what is best for the WordPress project. Would merging the existing well developed endpoints sooner help or hinder developer adoption, and further iteration/improvement? Would delaying the endpoint merge help or hinder progress?

    Here are some key comments from the discussion.

    • @rmccue  The approach to the API needs to change from “the API team creates all of the API” to “the API team controls the general shape of the API, and each team works with it”
    • @danielbachhuber Options / a Site Resource is more easily viable, as are Plugins and Themes. Widgets and Menus essentially need to be reinvented before they’ll work in a REST API
    • @jnylen It’s a question of when, and how much testing can be done first. Shipping an API that is read-only and incomplete in several key areas feels like a big mistake.
    • @kadamwhite we’re shipping an API with write capabilities but only cookie-based auth will be supported OOTB.
    • @matt  I would be pretty skeptical of merging a partial API into core…  no partial endpoints in core. let’s design a complete API, not half-do it.
    • @rmccue The API is specifically structured around progressive enhancement
    • @jorbin I think only supporting the four core object types allows for some amazing themes and amazing content editors to be created, but doesn’t allow for full wp-admin replacements. I’m ok with that.
    • @jnylen From what I’ve seen so far, I’m most concerned about shipping individual endpoints with missing features.
    • @jorbin I think the best way to pick up the pace is to get key things locked up and get the four core object types in core. This would help core develop API-first for those features
    • @codebykat On the WPCOM side, we’re committed to taking the plunge, but we’re not there yet which means things are untested.
    • @jnylen I think this needs more testing at large scale before shipping, including some of the more difficult and obscure features of WP.
    • @drew Shipping with full wp-admin replacement capability is unrealistic, imo. We need something flexible and stable that developers can use as solid jumping off point. All the rest can get separately iterated.
    • @mike I think that, realistically, to ship the API… we need an MVP, and I don’t think that defining our goalpost as “all of wp-admin” fits that criteria.
    • @matt Full wp-admin coverage is a firm goalpost, it gives us a super clear criteria for when it should be merged into core. is everything possible in wp-admin, possible through the API?
    • Matt Mullenweg 7:12 pm on February 5, 2016 Permalink | Log in to Reply

      We got on a bit of a rabbit hole on file editing in WP, and whether that should be in any API.

      I’m inclined toward no, but I think decisions about what we’re not going to support in the API should be made as deliberately as if we were removing the feature from WP itself. We should make that sort of decision explicitly and proactively, not allow things to die on the vine of existing in wp-admin but not the API.

      It’s also going to be difficult because there is often a big gap between what developers do and what people for whom WP is their entire interface do, which file editing accidentally illustrates very well. (What developer would trade their IDE or text editor for a form on a web page?)

      It might be easier to actually build out APIs for everything first and then choose whether to ship them or not than argue about whether they should be built in the first place, which is inevitably a realm of opinion, values, and sparse data.

      • Omaar Osmaan 7:47 pm on February 5, 2016 Permalink | Log in to Reply

        Absolutely- I like the idea of having API in core that allows to replace WP-Admin without loosing any feature it has. While so far I do have the itch of “get it in core faster”, but I really think your strategy is appropriately sound.

        It’s great to see the arguments- and for sure it all would make it only better in the end.

        My 2 cents.

    • Justin Sternberg 8:11 pm on February 5, 2016 Permalink | Log in to Reply

      Agree on iteration/MVP approach. Full wp-admin coverage, to me, is way overkill for initial merge to core. There is value in “paving the cow paths”… Let’s get the MVP working 100% and merged, and figure out what the next most valuable addition will be. Rinse and repeat.

    • K.Adam White 9:05 pm on February 5, 2016 Permalink | Log in to Reply

      The wp-admin parity argument caught me off-guard, which I believe stems from there being two basic types of use-case. Both types of usage are (and should be) valid:

      We (Bocoup, a non-WP-oriented company) have used the WP-API project to take advantage of the existing wp-admin editing interface, and has used the API solely to flow WordPress-authored data into or out of other applications. Without the API we would never have considered using WordPress for these projects: but the existence of a RESTful/non-XMLRPC interface made WP a big win for both us and our clients.

      Matt’s / Automattic’s experience is the complement to ours: Maintain the existing theme/plugin front-end, but put a custom admin interface behind it.

      The original “json-api” plugin was created by MoMA to flow WP data into a Ruby project; We’ve used the API to flow data into Node applications, and Java and C# clients for the WP-API are also under development. Our use-case is not new, and I believe it represents a significantly larger _potential_ target audience than any wp-admin re-skin does (at present). Daniel Bachhuber hypothesized recently that the way we’ll get WP to “100% of the web” isn’t by moving those sites to WordPress, but rather to allow WordPress to be integrated with existing platforms where appropriate.

      Waiting for API parity with wp-admin suits the Calypso use-case, but delaying core integration of API endpoints for basic WP data types will effectively block a significant group of potential adopters coming from external platforms. Right this second may not be the time, but unless we roll the API into core progressively (hopefully no later than 4.6/4.7) I think we are missing a tremendous opportunity.

      “ — Thank you to everyone involved with the project for being involved in this discussion.

    • Mike Nelson 4:44 am on February 6, 2016 Permalink | Log in to Reply

      > I would be pretty skeptical of merging a partial API into core… no partial endpoints in core. let’s design a complete API, not half-do it.

      Did @matt suggest that thinking it would be easier to iterate the API as a plugin than in core? Or what’s the motivation for this suggestion? I think lots of us give his suggestion a lot of weight, but because I wasn’t at the meeting I don’t understand it

      • Matt Mullenweg 9:30 pm on February 8, 2016 Permalink | Log in to Reply

        I’m 100% for continued iteration, and yes I think that would be easier as a plugin than in core.

        Everyone who wants the functionality today can have it in the plugin with just a few clicks, and we can update that with new functionality as much as often as we want, and if something goes wrong in only affects ~10k users. We know that most WP sites have 5 or 6 active plugins, with professionally-developed sites typically 2-3x that.

        In core we can only do major updates 3 times a year, at most, bundled with lots of other things and concerns that go into a major release, and those updates go out to tens of millions of sites. If we break something it’s in the mainstream tech news. What’s included or not depends on the release lead.

    • Philip Arthur Moore 11:03 am on February 6, 2016 Permalink | Log in to Reply

      I haven’t been involved in the development of this at all, but as a plugin/theme/custom web solutions developer I’d have to strongly agree with @matt with regard to setting full /wp-admin/ coverage as a firm goalpost before inclusion. What’s been keeping me from diving into the API and using it over what we have now is that I’m afraid of changes that may break things and not really sure what I can do with /wp-admin/ that I can’t do with the API. If there’s full parity then I can confidently jump into using the API; until then I feel largely like a spectator seeing how the development of the API plays out before overcommitting our resources to learning it and developing for it.

    • Mike Nelson 1:04 am on February 9, 2016 Permalink | Log in to Reply

      I didn’t think [putting the WP API scaffording in core would] increase the plugin usage, I thought it would increase plugins registering their own APIs, because they hadn’t before because of cross-plugin dependency see https://wordpress.slack.com/archives/core-restapi/p1454633785001643

      I don’t know about other plugins, but at least at Event Espresso we put our REST API, which depends on the WP API infrastructure, into our main plugin directly as a result of putting the WP API infrastructure into WP core 4.5. (See https://eventespresso.com/2016/01/rest-api-now-in-ee4-core/)

      We had some reservations though, thinking that maybe we would wait until the WP API endpoints were also in core (because that would be proof the WP API infrastructure would be more solid and less likely to break). It’s possible other plugins are having the same reservation?

      What’s more, the Event Espresso REST API is a little unique in that we’re using a LOT of custom tables, and our functionality is quite independent of WordPress’ posts etc, and so our REST API can exist quite happily without the WP API’s endpoints. I suspect most plugins’ APIs are much more dependent on WP API’s endpoints in order to work. Eg, there’s not much point in a YARPP REST API without WP API. Meaning, if WP API’s core endpoints are still in a plugin, their users STILL need to use the WP API plugin in order to use their plugin’s API… so just adding the WP API infrastructure isn’t much help to them: they need the endpoints too.

    • rclilly 7:18 pm on February 12, 2016 Permalink | Log in to Reply

      After reading this summary, as well as the entire discussion in Slack, I get the sense that, to a certain extent, people are talking past each other.

      @matt, I really don’t understand why you insist on ALL possible endpoints being completely ready before ANY endpoints can be merged into core.The four that are proposed cover a huge part of what many want the REST API for in the first place. I definitely think those four make for a minimum viable product, assuming they are, indeed, ready for prime time. The ability to completely replace the wp-admin goes way beyond an MVP for a REST API.

      My two cents: If there are endpoints ready for prime time, merge them. Let the others remain in the plugin.

  • Andrew Rockwell 7:14 pm on February 4, 2016 Permalink |
    Tags: ,   

    Week in Core, Jan. 26 – Feb. 2 2016 

    Hi everybody! Welcome back to the latest issue of Week in Core, covering changes from January 26th [36407] – February 2nd [36470], changesets [36407-36470]. Here are the highlights:

    • 64 commits
    • 16 contributors with props
    • 83 tickets created
    • 6 tickets reopened
    • 45 tickets closed

    Ticket numbers based on trac timeline for the period above.

    Note: If you want to help write the next WordPress Core Weekly summary, check out the schedule over at make/docs and get in touch in the #core-weekly-update Slack channel.

    Code Updates

    Networks and sites


    • Allow loading when only the mysqlnd extension is loaded. [36434] #33261


    • Add a close() method to wpdb, for when the connection needs to be manually closed. [36433] #34903


    • Fix searching for available nav menu items by updating reference to nonce. [36432] #35617
    • Export nonce, theme, and url app settings in preview as exported in pane. [36414] #27355, #35617
    • Improve parity between JS Setting models in preview with JS Setting models in pane. [36407] #27355, #35616


    • In wp_read_image_metadata() make sure that IPTC keywords are UTF8 encoded. [36429] #35316


    • Avoid displaying two spinners when adding selected menu items. [36427] #35682
    • After [36379] prevent “Quick Search” form submission when pressing Enter. [36426] #35374
    • Remove a redundant and unused 0 parameter from the Delete Menu link on the nav menus admin screen. [36419] #35641


    • Add back $req variable in comments_template(). Reverts [36322]. [36425] #35473
    • Add a back link to wp_die() comment form submission error display. [36424] #4332
    • Fix set up/tear down of post types in comment query test. [36415] #35633


    • Improve the install page language chooser button style. [36423] #34547


    • Remove all the occurrences of the old CSS clearfix. [36422] #26396


    • Add the global cache group sites to restore_current_blog() and wp_start_object_cache(). [36413] #32450
    • Add the global cache group networks to restore_current_blog(). Missed in [36258]. [36411] #35251


    • Simplify action placement in update_metadata(). [36420] #35652
    • Revert changes to wp_validate_redirect()  [35792]. This causes a regression and causes redirects to potentially fail. [35792]  #5114, #34028
    • Pass additional params to get_archive_links filter. [36418] #35573


    • Document the difference between site_url() and home_url()[36408] #35238

    External Libraries

    • Update Random_Compat to the latest version (1.1.6). [36421] #35665


    Thanks to @afercia, @boonebgorges, @dd32, @ericlewis, @helen, @jorbin, @kouratoras, @nexurium, @ocean90, @pento, @rachelbaker, @sebastianpisula, @shamess, @Shelob9, @westonruter, and @wonderboymusic for their contributions!

  • Adam Silverstein 3:03 am on February 4, 2016 Permalink |
    Tags: , ,   

    Core Dev chat notes for Feb 3 


    • @danielbachhuber announced a WP REST API meeting, happening tomorrow in #core-restapi on Slack: Thursday, February 4, 2016, 11:00 PM GMT. Full details are posted on the make/core blog.
    • A reminder that the feature plugin decision deadline is coming up next week, Feb 10th.
    • For the “Field Guide” posts, @jorbin proposed organizing around “focuses” and called on any feature plugins that get merged to make a post highlighting the following: anything with potential to break backwards compatibility along with significant new classes, functions, and hooks that you expect plugin, theme, and site developers to use. The goal is to have everything published before beta2.

    Feature Plugin Updates

    • Customizer Device Preview: @celloexpressions
      • Very close. Has UI/UX approval, a11y approval.
      • Waiting for fixes after dev review and security audit.
      • Consensus is that, pending the above, it is approved to merge in 4.5.
      • See #31195 and the related make post.
    • Application Passwords: @georgestephanis
      • Application passwords got split off from two factor auth, so we’re only talking about application passwords (Two-Factor is not dead, and will come back at a later date)
      • Lets you use an application password for XMLRPC and the REST API, instead of your normal password or oAuth 1.
      • Questions and discussion around whether there is a large enough use case to make this a core feature. Consensus is that at this point, it doesn’t benefit enough end users to warrant inclusion, but might after or when the REST API endpoints land in core.

    Focus Status Updates

    • Customizer: @westonruter, @celloexpressions
      • Customizer Pane Resize (#32296): Stalled.
      • Selective Refresh (#27355): Getting very close.
        • Selective refresh works well together with postMessage JS-updates, as the JS update can apply an immediate (approximate) preview while the Ajax request is being made to get the actual rendered content
        • Selective refresh `partials` have associated selectors and settings, so shift-clicking on any of the containers will focus on the corresponding control in the pane.
      • Customizer notification area (#35210): Needs help!
        • In progress, but an initial patch based on available mockups is needed here.
        • This is a dependency for the setting validation model (#34893) and creating page stubs via nav menus (#34923).
      • Transactions (#30937): Punting due to dependency on the REST API and on selective refresh.
    • Image Improvements: @joemcgill
      • Main focus on improving the default Imagick compression settings, some progress this week identifying the main hurdles there.
      • Could use additional opinions on #28474 (animated gif resizing) and whether it’s worth pursuing.
      • Could use some additional eyes on #34359 (particularly on multisite installs)
      • Weekly meeting is Friday at 20:00 UTC.
    • Multisite/WP_Site: @jeremyfelt
      • WP_Site is in with only minor issues surfacing.
      • Considering a `sites` endpoint for the REST API – primary use right now would be to refactor the My Sites menu.
      • A new repository for the site(s) endpoint has been set up on github.
      • Some renewed interest in a network settings API (or expanding the settings API to include networks)
      • Make/core post coming soon.
    • Editor: @azaozz, @iseulde
      • Going through and fixing edge cases for the inline link dialog. Please test!
      • Next will be the extending of “editing shortcuts”.

    View the full logs on Slack.

  • Adam Silverstein 10:54 pm on January 27, 2016 Permalink |
    Tags: , ,   

    Core Dev chat notes for Jan 27 


    • Extending the Feature Plugin decision and merge deadline by one week, taking them to Feb 10 and 17, respectively. This does not affect the rest of the release schedule, and betas, RC, and release are all the same dates. This gives feature plugins a little more time to have necessary discussions.
    • @ebinnion has graciously continued with the week in core post, and @rockwell15 volunteered to lend a hand.  If you like these posts, please help!  Many hand make light work.
    • @dd32, @jorbin and a few others are working on finishing up 4.4.2. Ticket owners should review the list of tickets tagged for the release.

    Focus Status Updates

    • Customizer: @westonruter, @celloexpressions
      • Posted a recent status update here on the make/core blog.
      • Customize Device Preview is up and ready for testing #31195, with a make/core post coming shortly.
      • Assistance requested with the Customizer Pane Resize plugin #32296.
      • Some movement on adding a notification area to Customizer #35210, with the need for an initial workup – help needed.
    • HTTPS Improvements: @johnbillion
      • Focusing on avoiding mixed content on https sites – a working http site is much preferable to an https site full of mixed content.
      • Working on a feature plugin which implements various granular controls over forcing HTTPS on a site: forcing enqueued assets to https, rewriting URLs in content on the fly to force their scheme to https, forcing redirects to the https version of the site, etc. Individual options with the ability to enforce the lot.
      • Adding a GitHub repo where this will be worked on and also posting a summary to make/core soon.
    • Image Improvements: @joemcgill
      • Good conversation last week about displaying responsive images in the editor.
      • Team could use help with profiling to Improve default Imagick compression settings #33642.
      • The old #feature-respimg channel has been renamed #core-images to be a place to talk about images in any/all capacities.
      • Weekly meeting is Friday at 20:00 UTC.
    • Editor: @azaozz, @iseulde
      • The inline link dialog is in. Please test! #33301
      • Looking into wpviews soon (Using the TinyMCE API).
      • Also looking at improving the shortcuts soon.
      • Could use help investigating using the image editing tools from TinyMCE for the media library.

    Open Floor

    • @veraxus brought up #16031 and the inability of handle new bulk actions in a non-hacky way (you can add the actions in the list, but not handle the action). Is it worth the effort to rework the patch? Will the core team support it?

    View the full logs on Slack.

  • morganestes 1:45 am on October 13, 2015 Permalink
    Tags: ,   

    Week in Core: Sept. 28 – Oct. 11, 2015 

    Welcome back to the latest issue of Week in Core, covering changes from Sept. 28 – Oct. 11, 2015, changesets [34659][35029]. Here are the highlights:

    See that ↑ right there? That’s an oEmbed. And it’s loaded from inside this site.

    Feature Plugins Merged

    The Responsive Images, oEmbed Provider, and the “baby” REST API feature plugins have been merged into core. Grab the latest version of trunk and test them out.

    WordPress logo with wordmark below

    Responsive images in your posts. Just upload and insert!

    Potent Notables

    These changes were big enough to merit their own blog posts:

    Deeper Reading

    Some commits pack in a lot of info, from detailed background to best practices in using hooks. Here are a few worth reading the entire commit message:

    • WP_Term class introduced [34997] #14162
    • Fix scalability performance problem for previewing multidimensional settings in the Customizer. [35007] #32103
    • Ensure that wp.customize.Widgets.savedWidgetIds is defined up front. [34883] #33901
    • The history and implementation of oEmbeds. [34903] #32522
    • Improve role-related arguments in WP_User_Query. [34875] #22212
    • Use wp_installing() instead of WP_INSTALLING constant. [34828] #31130
    • Introduce *_network_option functions for Multisite installs. [34777] #28290
    • Ensure that comment permalinks reflect pagination. [34735] #34068, #34073

    (More …)

  • morganestes 7:37 pm on September 29, 2015 Permalink
    Tags: ,   

    Week in Core: Sept. 21-27, 2015 

    Oh Snap!, it’s time to usher in a new edition of Week in Core! If you have the time, throw a house party with some friends and read the full force of changes on Trac; if not, don’t sweat it — take simple pleasure in these highlights.

    This post covers changesets [34362][34658], committed during Sept. 21–27, 2015. Let’s give a hi-five and some TLC to the 102 contributors for a combined 296 updates! Together, we’re making WordPress nice & smooth.

    (More …)

  • Gary Pendergast 12:45 am on September 23, 2015 Permalink
    Tags: , ,   

    Committer Reviews of the REST API 

    With the proposed merge of the REST API base code into Core, I’d like to try something a little bit different. The REST API is potentially going to cause one of the biggest shifts in workflow that WordPress has seen, so it’s important that all committers know how it works, and how it affects the parts of Core that they focus on.

    And so, here’s the plan. Before the REST API is merged into Core, it needs a code review from all active committers. The code being proposed for merge has been separated out into its own repo, for your viewing convenience.

    There are five areas I’d like to see covered:

    • Docs: Are the inline docs up to standard? What needs to be done before they’re ready? Official tutorials will be helpful, can they be fit into Devhub?
    • Security: Is it secure?
    • Performance: Are there any obvious performance issues in the base code? Are we encouraging plugin developers to write performant custom end points?
    • Ease of Use: Is it easy to write custom endpoints? Do we encourage quality code?
    • Forwards Compatibility: This is a little more nebulous, but can you envisage scenarios where we might need to break backwards compatibility in the future?

    Choose one or more of these focusses for your review, and tackle it from that perspective.

    You can also have a look at the proposed endpoints in the main repo, (scheduled for a later WordPress version), for inspiration on how it may interact with the areas of WordPress Core that you work on.

    Post your review as a comment here, and link to any relevant bug reports or pull requests you submit to the plugin repo.

    And finally, please have a think about how this process worked for you. I’d like this to be a model for future feature plugin merges, particularly those that touch many different areas of WordPress Core.

    PS: I’m not kidding about all active committers. I won’t hesitate to publicly shame you for holding up the REST API merge. 🙂

    • Ben Tremblay 2:37 am on September 23, 2015 Permalink | Log in to Reply

      For completeness?

    • Boone Gorges 2:57 am on September 23, 2015 Permalink | Log in to Reply

      Just spent a while reading through the api-core repository, and cross-referencing against some of the existing endpoints. This is my first time looking at the internals of the API; my previous experience is limited to writing a couple of custom endpoints for v1.

      Overall (and unsurprisingly) it seems like things have been nicely thought out. The syntax and conventions for registering endpoints seem easy to grok (they’re very WordPressy), without sacrificing flexibility and power.

      A few notes I jotted down while reading. I’ve opted not to open issues or PRs, as some of these are more questions than anything else – both for the core team and for the API team.

      • Why are we enabling JSONP by default? Is this for compatibility with browsers that don’t support CORS?
      • Is CSRF protection left to the endpoints? What will this look like without an HTML page to transport nonces?
      • I’d argue we should consider shipping WP_Rest_Controller as part of the “infrastructure” round. It’s hard to imagine building a very useful endpoint without it.
      • The API sends custom headers for deprecated functions and arguments. Should there be a corresponding header for _doing_it_wrong() notices?
      • Your first stop for fetching request data is $HTTP_RAW_POST_DATA, with a fallback to php://input. It should probably be the other way around – the global is deprecated in PHP 5.6 and removed in PHP 7.0.
      • Should error messages in the json_last_error_msg() shim be localizable?
      • Drew will probably have more to say about this, but docs formatting is inconsistent throughout, and will need a once- or twice-over.

      Thanks to the API team for their work so far!

      • Ryan McCue 6:44 am on September 23, 2015 Permalink | Log in to Reply

        Thanks for the review @boonebgorges. 🙂

        Why are we enabling JSONP by default? Is this for compatibility with browsers that don’t support CORS?

        Correct, and compatibility with servers that don’t allow sending CORS headers, or old client libraries, or etc.

        Is CSRF protection left to the endpoints? What will this look like without an HTML page to transport nonces?

        Authentication and authorisation is handled in the infrastructure. CSRF only applies to browser-based applications using cookie authentication, and you need the wp_rest nonce for that. (This is automatically output as WP_API_Settings.nonce and handled automatically when you use the JS client.)

        I’d argue we should consider shipping WP_Rest_Controller as part of the “infrastructure” round.

        The base controller is half way between infrastructure and endpoints, but it’s possible we’ll continue changing things in it, and it’s not as stable as the infrastructure proper. Realistically, it’s just a set of best practices, so it’s definitely possible to build useful endpoints without it; I have a tonne of basic endpoints written that just use straight up functions or closures, which you don’t need a controller class for.

        The API sends custom headers for deprecated functions and arguments. Should there be a corresponding header for _doing_it_wrong() notices?

        Potentially. The deprecated stuff can be trigger from request data, whereas _doing_it_wrong() is likely only triggered by plugin code, which is why we don’t handle it currently. I’d not be against adding it though.

        Your first stop for fetching request data is $HTTP_RAW_POST_DATA, with a fallback to php://input. It should probably be the other way around – the global is deprecated in PHP 5.6 and removed in PHP 7.0.

        php://input suffers from a fatal flaw: it can only be read from once. In case other code wants to use this, or we need to reuse the data ourselves, we load it into the variable ourselves. I don’t think we can change this, alas.

        Should error messages in the json_last_error_msg() shim be localizable?

        I’d argue no, for parity with the PHP built-in/extension.

        docs formatting is inconsistent throughout

        Definitely, we need a bunch of work on this.

        Thanks again!

    • Drew Jaynes 8:15 pm on September 23, 2015 Permalink | Log in to Reply

      For posterity: I’ve opened a PR for a core docs standards audit here: https://github.com/WP-API/WP-API/pull/1590

    • Aaron Jorbin 8:13 pm on September 30, 2015 Permalink | Log in to Reply

      I haven’t finished a full review, but here are some initial things:


      Does there really need to be an WP_HTTP_ResponseInterface interface? It feels like over abstraction for the sake of abstraction.

      — WP_REST_Server —

      Many of the constants in WP_REST_Server don’t seem to serve a purpose without endpoints. I would like to see some more inline documentation around how they are expected to be used. For example, why is ACCEPT_JSON set as 128?

      serve_request feels like a very long method compared to many of the others. It seems to handle two things, serving the request, but before that, routing the request. Could this become two different methods? One that does the setting/routing and the other that does the serving?

      A couple of other small changes I would look at:

      • Add a set_default_headers method that could be called and encompass lines 248 -255. There could also be a filter on this list to easily enable other default headers being added to every request.
      • rest_ensure_response is called on the $result on both lines 321 and 337 (in the rest_post_dispatch filter). The only change between those is that if it is an error, it goes through error_to_response which returns WP_REST_Response which doesn’t need to be ensured is a response.

      Should envelope_response be public? It seems like it only is needed in once one place and sdoesn’t need to be used outside of it.

      More to come

      • Jeremy Felt 4:44 am on October 2, 2015 Permalink | Log in to Reply

        rest_ensure_response is called on the $result on both lines 321 and 337 (in the rest_post_dispatch filter). The only change between those is that if it is an error, it goes through error_to_response which returns WP_REST_Response which doesn’t need to be ensured is a response.

        This caught me up as well when reading through `WP_Rest_Server`. I’m not sure if there’s a better way to handle it, but it is tricky when reading.

      • Rachel Baker 1:01 pm on October 2, 2015 Permalink | Log in to Reply

      • Ryan McCue 6:40 am on October 7, 2015 Permalink | Log in to Reply

        Many of the constants in WP_REST_Server don’t seem to serve a purpose without endpoints.

        These constants were leftovers from way back when we had bitwise flags. I’ve killed those now. The only constants left now are RESTful verbs (`READABLE`, `CREATABLE`, `EDITABLE`, `DELETABLE` and `ALLMETHODS`).

        Should envelope_response be public? It seems like it only is needed in once one place and sdoesn’t need to be used outside of it.

        Enveloping is super useful in third-party code, and there’s no real reason to make it protected. I’d like to keep it as part of the class’ public API. 🙂

        Working on the rest of the feedback.

    • Drew Jaynes 8:15 pm on September 30, 2015 Permalink | Log in to Reply

      I noted this to Rachel separately, but good to have it mentioned here:

      The wp-api.js file should be renamed to wp-rest-api.js, and the handle changed to ‘wp-rest-api’ or ‘rest-api’. In the broader scheme of WordPress, this is another of many APIs, not the WordPress API any longer 🙂

    • Dominik Schilling (ocean90) 8:16 pm on September 30, 2015 Permalink | Log in to Reply

      WP_HTTP_ResponseInterface – Do we need it? If it gets released once there is no way to extend it without potentially breaking plugins which are using this class.

      • Rachel Baker 12:59 pm on October 2, 2015 Permalink | Log in to Reply

        I chatted with @rmccue, who first introduced WP_HTTP_ResonseInterface (or as previously named WP_JSON_ResponseInterface) on Feb 17, 2014, and he **believes** it can be removed. He has to do some testing to confirm this theory.
        If we can remove it, we will. Otherwise @rmccue will provide the reasoning behind needing to keep it.

    • Weston Ruter 10:46 pm on September 30, 2015 Permalink | Log in to Reply

    • Rachel Baker 2:10 pm on October 2, 2015 Permalink | Log in to Reply

      We have a patch up in https://core.trac.wordpress.org/ticket/33982 that can be refreshed, if committers have any desired code changes.

  • morganestes 9:08 pm on September 21, 2015 Permalink
    Tags: ,   

    Week in Core: Sept. 13-21, 2015 

    Welcome to the Week in Core — Week Four, with super-exciting news from around WordPress-land, and Core changes and updates for Sept. 13–21, 2015 (commits [34093][34361]). This week’s core contributors number 106! I’m especially jazzed about the number of new names on the list, and want to thank everyone for your effort this week.

    News you can use

    The WP REST API team submitted a proposal to merge the plugin into core, with a two-phase integration plan. The merge proposal blog post also does a nice job of presenting the history of the plugin and some use cases.

    Do you use my-hacks.php in your site? Don’t. (A quick search through the plugin and theme repos shows only 10 plugins and 3 themes that mention the file.)

    Multisite is making some pretty big changes, including the addition of the  WP_Network class. Check out this blog post, which outlines some of the changes and a roadmap for future updates for 4.4.

    Interested in the user-focused part of WordPress? Of course you are! Join in the conversation about “Potential UI/UX projects in core.”

    Code changes

    Here are some highlights from the 268 change sets published to Trac; the complete report is available online in plain-text format for a bit more in-depth coverage.

    (More …)

  • morganestes 9:04 pm on September 16, 2015 Permalink
    Tags: ,   

    Week in Core: Aug. 31 – Sept. 12, 2015 

    Welcome to the Week in Core, with updates from weeks 2 & 3: Aug. 31 – Sept. 12, 2015, changesets [33821][34092].

    It’s been a busy couple of weeks in Core, with almost too many changes to count (for the record, this one covers 271 commits!). I’m going to keep this update shorter than usual and highlight some of the bigger changes.

    If you’re interested in helping write this weekly post, ping @morganestes in #core-weekly-update on Slack.

    Special Note: WordPress 4.3.1 was released this week, with three security-related fixes. Be sure to update your sites!

    Here’s some highlights of recent changes in core, along with some future plans and ongoing initiatives. Remember, Core moves pretty fast. If you don’t stop and look around once in a while, you could miss it.

    • WordPress will support PHP7 when it’s released. Huzzah!
    • HTTP/2 is coming! Here’s a list of tickets that need attention to get WordPress ready.
    • Get involved in Twenty Sixteen, which is in active development on GitHub.
    • Write better commit messages. The world will thank you for it. 🙂
    • As described in this post by @johnbillion, the show_ui flag for post types now gets fully honored. See #33763 for the ticket discussion.
    • A new helper function, wp_validate_action( $action = '' ), was introduced in [34059] and is used throughout admin instead of directly accessing $_REQUEST['action'].
    • A new file, wp-admin/includes/noop.php, was created to load all of the noop functions for load-script|styles.php and is only loaded by those files. DRYs in the process. [34037] #33813
    • Schema change introduced in [34030] to increase the length of wp_options.option_name to 191 chars. #13310
    • Implement a priority system for Help Tabs to add them at specific positions. [33985] #19828
    • Multisite: Don’t allow sites to be created with the following reserved slugs: wp-admin, wp-content, wp-includes [33952] #33615
    • Updated recommendations for minimum versions of PHP (5.6) and MySQL (5.5), with a special note that Oracle only actively supports MySQL for 5 years after a General Availability release. [33937] [33946]

    For the full report, visit https://core.trac.wordpress.org/log/?verbose=on&format=changelog&rev=34092&stop_rev=33821&limit=400&mode=stop_on_copy.

    Thanks to @adamsilverstein, @afercia, @amereservant, @ankit-k-gupta, @antpb, @austinginder, @azaozz, @BdN3504, @benjmay, @boonebgorges, @bradt, @brettz95, @celloexpressions, @cgrymala, @Cheffheid, @chriscct7, @codeelite, @CoenJacobs, @danielbachhuber, @daniellandau, @dannydehaan, @dd32, @dimadin, @dipeshkakadiya, @dlh, @DrewAPicture, @dustinbolton, @egower, @enshrined, @ericdaams, @ericlewis, @extendwings, @figureone, @filosofo, @gaelan, @GaryJ, @gitlost, @gnaka08, @gradyetc, @gregrickaby, @hauvong, @helen, @imath, @ippetkov, @iseulde, @ixkaito, @jazbek, @jeffstieler, @jeremyfelt, @jesin, @jobst, @johnbillion, @joostdevalk, @jorbin, @juliobox, @JustinSainton, @kevinlangleyjr, @khromov, @kitchin, @kraftbj, @lancewillett, @liljimmi, @lukecarbis, @macmanx, @MatheusFD, @mehulkaklotar, @mercime, @metodiew, @michielhab, @MikeHansenMe, @miqrogroove, @mitchoyoshitaka, @mordauk, @morganestes, @mrahmadawais, @mrmist, @Mte9, @nacin, @netweb, @nikeo, @nikolovtmw, @nofearinc, @obenland, @ocean90, @OriginalEXE, @Otto42, @paulwilde, @pavelevap, @pento, @peterwilsoncc, @racaseh, @rachelbaker, @rajnikmit, @rmccue, @rommelxcastro, @sc0ttkclark, @scribu, @SergeyBiryukov, @sillybean, @solarissmoke, @stevehenty, @swissspidy, @tmatsuur, @trepmal, @tyxla, @umeshnevase, @utkarshpatel, @wen-solutions, @wenthemes, @westonruter, @wojtekszkutnik, @wonderboymusic, @yoavf, and @zeo for their contributions!

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