WordPress.org

Make WordPress Core

Updates from February, 2016 Toggle Comment Threads | Keyboard Shortcuts

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

  • 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 …)

     
  • Ryan McCue 7:29 am on August 14, 2015 Permalink
    Tags: , , , ,   

    WP REST API: Versions 1.2.3 (Security Release) and 2.0 Beta 4 

    First and foremost: version 1.2.3 of the REST API is now available. Download it from the plugin repository or from GitHub. This is a security release affecting sites running version 1.2 or a 2.0 beta releases.

    Security Release

    Recently, we were alerted to a potential XSS vulnerability introduced in version 1.2 of the API related to the JSONP support. This vulnerability also existed in version 2.0. Thanks to Alex Concha (@xknown) 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.3, 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 releases update the plugin immediately.

    If you’d prefer not to upgrade, you can instead disable JSONP support through a filter. For version 1:

    add_filter( 'json_jsonp_enabled', '__return_false' );

    To disable JSONP on version 2:

    add_filter( 'rest_jsonp_enabled', '__return_false' );

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

    Version 2.0 Beta 4

    Alongside the security release for version 1.2, we’re also releasing the latest beta for version 2.0: 2.0 Beta 4 “See My Vest”. You can download this from the plugin repository or from GitHub.

    This beta release includes the security fix from version 1.2.3, so we recommend everyone running a version 2 beta update immediately to fix the issue.

    As well as the security release, this beta also includes a bunch of other changes. Here’s some highlights:

    • Show public user information through the user controller.

      In WordPress as of r32683 (scheduled for 4.3), WP_User_Query now has support for getting users with published posts. To match current behaviour in WordPress themes and feeds, we now expose this public user information. This includes the avatar, description, user ID, custom URL, display name, and URL, for users who have published at least one post on the site. This information is available to all clients; other fields and data for all users are still only available when authenticated.

    • Send schema in OPTIONS requests and index.

      Rather than using separate /schema endpoints, the schema for items is now available through an OPTIONS request to the route. This means that full documentation is now available for endpoints through an OPTIONS request; this includes available methods, what data you can pass to the endpoint, and the data you’ll get back.

      ⚠️ This breaks backwards compatibility for clients relying on schemas being at their own routes. These clients should instead send OPTIONS requests.

    • Update JavaScript API for version 2.

      Our fantastic JavaScript API from version 1 is now available for version 2, refreshed with the latest and greatest changes. Thanks to Taylor Lovett (@tlovett1), K. Adam White (@kadamwhite) and Nathan Rice (@nathanrice).

    • Embed links inside items in a collection.

      Previously when fetching a collection of items, you only received the items themselves. No longer! You can now request a collection with embeds enabled (try /wp/v2/posts?_embed).

    • Move /posts WP_Query vars back to filter param.

      In version 1, we had internal WP_Query vars available via filter (e.g. filter[s]=search+term). For our first betas of version 2, we tried something different and exposed these directly on the endpoint. The experiment has now concluded; we didn’t like this that much, so filter is back.

      ⚠️ This breaks backwards compatibility for users using WP Query vars. Simply change your x=y parameter to filter[x]=y.

    • Respect rest_base for taxonomies.

      ⚠️ This breaks backwards compatibility by changing the /wp/v2/posts/{id}/terms/post_tag endpoint to /wp/v2/posts/{id}/tag.

    As always, we have a detailed changelog as well as the full set of changes if you’re interested.

    (Note that while this version 2 beta breaks backwards compatibility, the 1.2.3 security release does not break compatibility with the 1.2 branch.)

    This release had 11 contributors, and we’d like to thank each and every one of them:

    $ git shortlog 2.0-beta3...2.0-beta4 --summary
         1   Daniel Bachhuber
        11   Daniel Jalkut
         1   Fredrik Forsmo
         1   Jared Cobb
         3   Jay Dolan
        26   Joe Hoyle
        10   Josh Pollock
        25   Rachel Baker
        50   Ryan McCue
        24   Stephen Edgar
         8   Taylor Lovett
    

    Thank you again to all of our beta testers, and thanks to everyone who let us know how you’re using the API. We’re taking note of all of your feedback, and you might see some further changes related to that in coming releases.

     
    • Ahmad Awais 8:18 am on August 14, 2015 Permalink | Log in to Reply

      Hey, Ryan!
      Did you change the folder name or main file name in WP REST API 1.2.3 since I am using 1.2.2 and I didn’t get any update notification, which is weird.

      • Ryan McCue 10:10 pm on August 14, 2015 Permalink | Log in to Reply

        The patch in 1.2.3 is minimal and didn’t change the filename. If you’re using the API from GitHub, your folder might accidentally be called WP-API, whereas it should be json-rest-api to match the repo.

    • CotswoldPhoto 9:40 am on August 14, 2015 Permalink | Log in to Reply

      Great work team REST API. I really hope that this makes it into core for 4.4.

    • Rachel Baker 12:56 pm on August 14, 2015 Permalink | Log in to Reply

      Oh, please won’t you see my vest! 🎶

  • morganestes 1:37 pm on March 6, 2015 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Howdy, and welcome to this week’s installment of WordPress Core Weekly – covering February 26, 2015 [31545] through March 4, 2015 [31620].

    If you want to 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.

    Let’s start with a warm welcome to our new Component Maintainers, who play an important role in the development process.

    Build/Test Tools: @voldemortensen
    Comments: @rachelbaker
    Editor – Press This: @Michael-Arestad, @stephdau
    General: @SergeyBiryukov
    I18N: @SergeyBiryukov
    Options, Meta APIs: @MikeHansenMe
    Themes – Customize: @voldemortensen
    Users: @justinsainton

    These maintainers are vital to keeping WordPress development running as smoothly as possible. They triage new tickets, look after existing ones, spearhead or mentor tasks, pitch new ideas, curate roadmaps, and provide feedback to other contributors.

    Dev Chat Notes

    This week’s Dev Chat was a lively one, with updates on the Customizer and Press This (with an emphasis on accessibility, hooray!), Shiny Updates (needs helping hands, see the todo list), Emoji (not just for smiles), and Accessibility (revisiting the age-old a vs button question).

    If you missed the meeting, or need a reminder of what was discussed, take a few minutes to read the transcripts.

    A couple of reminders: we’re a week away from Beta 1, and Daylight Saving Time is coming so make sure to check the time of next week’s Dev Chat so you won’t miss it!

    Tickets needing a look:

    • #5305: permalinks broken when article name is numeric
    • #31349: Screen options posts/pages/etc. per page label
    • #17817: do_action/apply_filters/etc. recursion on same filter kills underlying call
    • #29820: Smooth installation and updating of plugins and themes

    Code Updates

    It’s been a busy week with lots of commits, so let’s get into the ticket overview:

    Media

    • Allow inline editing of width and height parameters while previewing an embed in the media modal. [31620] #31139
    • Media modules: set $ to Backbone.$, instead of jQuery, so fewer globals are imported. [31618] #28510
    • When viewing media in List mode, auto-submit the form for attachment filters when the value of a <select> changes. This makes it behave similar to Grid mode and “feels” more performant, even though it is a full page load. [31582] #30333
    • Allow attachments to be detached from their parent in media grid and list modes. [31619] #6820
    • In the Insert From URL state of the Post frame, add the necessary CSS for focus styles for images. [31585] #28820
    • Build: Let RTLCSS handle swapping the codes for right/left arrows from Dashicons. [31579] #31478
    • Support GIMP files in the Media Library. We already support Photoshop files. [31578] #31146
    • In the ->multi_resize() method of the WP_Image_Editor subclasses, when looping through potential crops, we need to make sure the crop isn’t the exact same dimensions as the original image before copying it as a new crop. [31576] #31296
    • Make a new function, wp_delete_file(). Use it. [31575] #17864
    • Improve get_media_embedded_in_content() so that it returns the media it finds in the same order that it appears in the content. [31574] #26675
    • Customize Widgets: Don’t return undefined items in getWidgetFormControls method. [31570] #31465
    • CSS: Move relevant #sidemenu rules into deprecated-media.css and remove the cruft. [31564] #27956
    • Persist search terms across grid/list modes. [31562] #30583

    Comments

    • Respect comment_date and comment_date_gmt params in wp_new_comment(). [31615] #14279
    • In get_next_comments_link(), ensure proper pagination when no ‘cpage’ query var is found. [31617] #20319
    • wp_insert_comment() should be checking and setting $compacted, not the non-existent $post_data. [31553] #21212

    TinyMCE/Editor

    wpView

    • decode HTML entities before trying to insert view markers. [31612] #31412
    • introduce getText() and remove() methods, improved getInstance(), better docs. [31559] #31412
    • Better structure; simpler “view” registration; better extensibility; better inline documentation; don’t show a placeholder for pasted link until we know the link is “embeddable’. [31546] #31412
    • Remove the (obsolete) get/setViewText methods. Update stopping/pausing of multiple ME media players. [31548] #31412

    wpLink

    General

    • Autocomplete: Update CSS based on both jQuery UI and general visual changes. [31611] #31427
    • Add wp.a11y.speak() for audible alerts/updates in screen readers. [31594] #31368
    • Remove the once-placeholder-esque “tag hint”, which has not worked in quite some time. [31607] #31485
    • When sanitizing a URL to redirect to, UTF-8 characters can be URL encoded, instead of being removed. [31587] #31486
    • Introduce get_object_terms filter in wp_get_object_terms(). [31581] #18828
    • In get_avatar_data() and get_avatar(), allow height and width to be specified separately (both default to size). Also allow arbitrary attributes on the <img> via the extra_attr arg. [31561] #31469
    • Permalinks: In wp_get_attachment_url(), convert to HTTPS when possible. [31614] #15928

    Posts, Post Types

    • List tables: Display front and posts page indicators. [31610] #30190
    • Hide irrelevant UI and display a message when editing the page for posts. [31550] #17470

    Press This

    • Add missing access modifiers to WP_Press_This. [31552] #31456
    • Add press-this.css to the list of stylesheets that are minified and to list of RTL styles. [31547][31572] #31373
    • Make sure buttons.css is loaded before press-this.css. [31597] #31373
    • Use correct URL for update bookmarklet link. [31556] #31461
    • Go back to loading the minified bookmarklet content with file_get_contents(). Add Grunt task to minify bookmarklet.js on precommit and update it in /src. [31545] #31373
    • Improve handling of the data, both from the bookmarklet and from server-side parsing. [31609] #31373
    • Remove unneeded passing of post formats strings to JS. Set the currently selected post format name with jQuery. [31589] #31373

    [31601] #31493

    • Remove classes from suggested HTML for the editor.
    • Improve the filter, pass an associative array as param.
    • Use <em> instead of <cite>.

    [31595] #31373

    • Simplify getSuggestedContent() and helpers. No need to override the global data.
    • Replace the press_this_source_string and press_this_source_link filters with press_this_suggested_html that allows filtering of the link and the wrapper HTML tags.

    [31588] #31373

    • Backwards compatibility enhancements.
    • Add missing actions for printing styles/scripts.
    • Since $hook_suffix is null, hardcode press-this.php.
    • Restore body classes, add filter.
    • Use wp_json_encode().
    • Update docs for filters in script-loader.php.

    General

    • TinyMCE: set ‘directionality’ and add the LTR button when in RTL. [31580] #31474
    • RTL improvements: [31577] #31478, #31474
    • Fix and update buttons styles. [31598] #31498
    • When there is a protocol mismatch (http vs. https), use server-side media detection instead of submitting a form as it triggers “Unsafe data” warning in some browsers. [31584] #31468
    • Fix selecting a post format (radio buttons) with the keyboard. [31583] #31440
    • Accessibility enhancements [31566] #31449
    • Enable scrollbars in Firefox, remove overflow-x: hidden from the html element. [31565] #31455
    • Fix notices/errors classes. [31549] #31456

    Administration

    • Fix a typo in the $args parameter hash notation description for add_settings_field(). [31593] #28975
    • Nav menus: Better JS performance on initial load of edit screen. [31604] #25698
    • Themes: Avoid jumping when selecting a feature in the feature filter on Add Themes screen. [31603] #31497

    External Libraries

    Administration

    • Settings API: Allow passing a class to add_settings_field() via the $args array. [31560] #30168, #28975

    Build/Test Tools

    • RTL CSS generation: Switch from CSSJanus to RTLCSS. [31573] #31332
    • Run unit tests on Travis CI with PHP nightlies. With PHP7 in active development, this will help us identify issues there. [31558] #31454
    • Update grunt-patch-wordpress to 0.3.0. [31557] #31466

    Thanks to @abhishekfdd, @afercia, @alexkingorg, @atimmer, @azaozz, @boonebgorges, @couturefreak, @doublesharp, @DrewAPicture, @floriansimeth, @GrahamArmfield, @HarishChaudhari, @helen, @ipm-frommen, @iseulde, @joemcgill, @jorbin, @kopepasah, @kraftbj, @Michael-Arestad, @MikeHansenMe, @miqrogroove, @MomDad, @morganestes, @nacin, @ocean90, @kadamwhite, @oso96_2000, @pento, @postpostmodern, @rodrigosprimo, @scribu, @SergeyBiryukov, @sevenspark, @solarissmoke, @stephdau, @swissspidy, @valendesigns, @welcher, @westonruter, and @wonderboymusic for their contributions!

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

  • Mike Schroder 8:55 pm on March 19, 2014 Permalink
    Tags: ,   

    Last Week in WordPress Core 

    Hey Everyone! This is Last Week in WordPress Core for the week of March 10–16. It’s been a busy week after Beta 1. Here are some highlights from the week:

    • Appearance: Bring the theme browsing experience from 3.8 to the theme installer. [27499] #27055
    • Customizer: Add header image uploads with cropping to the customizer. [27497] #21785
    • Plugin Management: Restyle the plugin install details modal to match the rest of the admin. [27559] #26952
    • Edit Post: Correct the “View Post” button link when changing a post slug. [27508] #16477
    • Admin Colors: Revert [27203], fix color scheme stylesheets. Restores [27111]. [27515] #27175; see #20729.
    • Editor: figcaption should not be treated as a block-level element by wpautop(). [27527] #25646
    • TinyMCE: add internal command and shortcut (Alt+Shift+X) for toggling <code>. Define a button that can be added to any toolbar as wp_code. [27545] #6331
    • Permalink Settings: Don’t show “update your .htaccess now” if nothing needs to change. [27549] #19268.
    • Query: In WP_Query::get_queried_object(), account for pre_get_posts by checking for tag when tag_id isn’t present. Tags still need to be rolled up into tax_query.  [27511] #27362
    • Filesystem: Update request_filesystem_credentials() to handle the correct ssh value of FS_METHOD. [27546] #27265

    Widget Customizer:

    • Move widget area sections to bottom, as a theme can have a lot of widget areas and we don’t want to bury other sections. [27541] #27401
    • Introduce a customizer processing state to prevent saves while updates are occurring. [27540] #27390
    • Make temp hooks permanent. New hooks are: dynamic_sidebar_before, dynamic_sidebar_after, dynamic_sidebar_has_widgets and is_active_sidebar. [27543] #25368

    Media:

    • Start embedding functional audio/video players in the editor, instead of placeholders. [27528] was reverted in [27530] but added back this week in [27615]. Whitelist media types by browser. [27539] [27542]. See also [27534] [27535] [27536] [27537] [27538] and others. Everything is contained in #27389.
    • The Image Editor should apply changes to custom image sizes by checking registered image sizes. [27522] #19889
    • Remove Qik from the oEmbed provider list as it’s shutting down. [27526] #27302
    • Smooth out some display and race condition issues with the media modal loading spinner. [27516] #24859

    XML-RPC:

    • Avoid saving slashed data in XML-RPC’s wp.setOptions. [27551] #22936
    • Allow query strings for servers in IXR_Client and WP_HTTP_IXR_Client. [27552] #26947
    • Include sticky in the struct returned from metaWeblog.getRecentPosts. Using wp.getPosts is preferred and non-WP XML-RPC APIs are no longer actively maintained. This is simply for parity with existing MW methods. [27553] #26679
    • In wp.editPost, Remove all terms in a taxonomy when an empty array is explicitly passed. [27554] #26686

    For the complete list of commits to trunk, check out the log on Trac.

    Interested in joining in? Write or test a patch for 3.9. The goals for this week — besides releasing Beta 2 — are two-fold:

    Thanks to @aubreypwd, @avryl, @azaozz, @bravokeyl, @cfinke, @danielbachhuber, @DrewAPicture, @ehg, @enej, @ericmann, @gcorne, @helen, @jayjdk, @jnielsendotnet, @johnpbloch, @joostdevalk, @jstraitiff, @JustinSainton, @kadamwhite, @klihelp, @kovshenin, @ldebrouwer, @mattonomics, @matveb, @mauryaratan, @maxcutler, @mcsf, @MikeHansenMe, @nacin, @nendeb55, @ocean90, @oso96_2000, @Otto42, @paulwilde, @pento, @rodrigosprimo, @SergeyBiryukov, @soulseekah, @tlovett1, @westonruter, @wonderboymusic, and @wpsmith for their help this week!

     
  • Mike Schroder 10:29 am on March 13, 2014 Permalink
    Tags: ,   

    Last Week in WordPress Core 

    Hi there! Welcome to Last Week in WordPress Core for the week of March 3–9. By now, you’ve heard that WordPress 3.9 Beta 1 is available! Thank you for your hard work this last week. Now we’re done adding new enhancements, and on to bugs. Your help is appreciated as we continue to test and squash bugs on the way to a stable RC.

    There are a couple important things that landed on Monday that are not covered in this post, but shipped in beta. Namely, please test the Theme Install screen refresh and the ability to crop headers from within the Customizer.

    Admin:

    • Widgets: Add widget management to the customizer. This brings in the Widget Customizer plugin. [27419] #27112
    • Admin Menu: Introduce a .dashicons-before CSS class and use it in the admin menu. Lets you use a Dashicon before an element without copying the entire .dashicons styling to your :before styling. [27418] [27425] [27444] [27482] #26630
    • Editor: Show “View Post” for any post the author can read. This expands it to private posts and matches the logic in the toolbar. [27483] #27059

    Media:

    • First pass at bringing the Image Editor into the media modal. Please test me! [27445] #21811
    • First pass adding a loading indicator to the Media Library. [27438] #24859
    • Allow $crop in add_image_size() and set_post_thumbnail_size() to receive crop anchors (top, left, right, bottom, center). [27472] #19393.
    • Add subtitle support to Video editing in the Media Modal. [27481] #27016
    • Do not output default gallery styles if the theme has opted into HTML5 galleries. [27396] #27045; see #26697
    • Add a class attribute to the caption shortcode to allow additional classes to be specified. [27404] #25295
    • Add playlist_styles and wp_playlist_scripts filters to allow users to roll their own playlist themes. [27486] #26631 & [27488] #26631

    TinyMCE:

    • Update TinyMCE to 4.0.18. [27387] #24067
    • Add TinyMCE placeholders for audio and video shortcodes and provide a UI to both edit shortcode attributes and replace the src media file in an audio or video shortcode. Also, a flurry of improvements and fixes to them, visible in the full changelog. [27411] #27016
    • Add a Ctrl+K shortcut to open the linking dialog, which is the “de-facto standard”. [27449] #27305
    • Add the <hr> plugin and button to the toolbar. [27428] #27159
    • With drag-and-drop uploading, support multiple editor instances, limit to IE10+, and other small fixes. [27378] [27372] [27464] #19845
    • When parsing a caption shortcode, recreate missing width attributes using the image tag’s width. [27426] #23103
    • Restore the “link” button state to disabled by default and enabled when text or image is selected. Remove the (recently added) default link plugin; not needed. [27447] #27309

    Templates:

    • Add has-post-thumbnail as a post class. [27429] #18804
    • Rename the new page_templates filter to theme_page_templates, and pass it a post object for proper context. [27470] [27471] #13265
    • Introduce get_the_permalink() as an alias for get_permalink(). This better aligns it with other the_* and get_the_* function pairs. [27409] #24164
    • Let get_the_date() accept a post object. [27380] #13771
    • Add the ability to short-circuit wp_nav_menu() via the pre_wp_nav_menu hook. [27386] #23627
    • Better plural handling for labels in wp_generate_tag_cloud() / wp_tag_cloud(). [27376] #27262, see #7989, #14424

    Multisite:

    • Incremental improvements and bug fixes with the multisite load process. Please test your networks! [27406] [27439] [27407] #27003
    • Fix bulk activation of network-only plugins. [27413] #26487

    Query:

    • Add has_password and post_password query variables to WP_Query. has_password true means posts with passwords, false means posts without. post_password can query for posts with a particular password. [27395] #20308
    • Allow a posts_per_rss query variable to be set to override the posts_per_rss option. [27456] [27455] #25380
    • Allow get_page_by_path() and get_page_by_title() to accept an array of post types. [27423] #24763

    Internals:

    • Allow for custom authentication handlers for all requests. Turn the logic used by wp_get_current_user() into a determine_current_user filter. [27484] #26706
    • Allow the role attribute in kses for all elements. [27388] #24098
    • Add a pre_set_theme_mod_$name filter to set_theme_mod(), modeled after pre_update_option_$option in update_option(). [27393] [27402] #14721.
    • Improve HHVM compatibility by eliminating some of our last remaining create_function() calls and making OBJECT a case sensitive constant. [27373] [27374] [27465] #14424 [27377] #27231
    • Pass $reassign parameter to delete_user and deleted_user actions. [27462] [27466] #23057
    • Bail early from shortcode functions if no delimiter is present. It’s the little things; performance results on-ticket. [27394] #23855
    • Update PHPMailer to 5.2.7 from 5.2.4. Includes two trivial modifications for WordPress (no impact to plugin developers); see the commit message. [27385] #25560
    • Use SSL when linking to WordPress.org. [27469] #27115

    For the complete list of commits to trunk, check out the log on Trac. Interested in joining in? Write or test a patch for 3.9.

    Thanks to @adamsilverstein, @akeda, @avryl, @bassgang, @bigdawggi, @bobbravo2, @bpetty, @bradt, @celloexpressions, @coffee2code, @danielbachhuber, @dd32, @DJPaul, @DrewAPicture, @empireoflight, @ericlewis, @ericmann, @frank-klein, @gcorne, @genkisan, @gradyetc, @hakre, @Hanni, @Jayjdk, @jenmylo, @johnregan3, @jorbin, @JoshuaAbenazer, @kadamwhite, @kasparsd, @Kopepasah, @kovshenin, @kpdesign, @lpointet, @markjaquith, @mcadwell, @melchoyce, @michael-arestad, @mikecorkum, @mordauk, @nacin, @obenland, @Otto42, @pavelevap, @Rarst, @rhyswynne, @ricardocorreia, @rmccue, @robmiller, @seanchayes, @SergeyBiryukov, @shaunandrews, @simonwheatley, @sirzooro, @tanner-m, @TobiasBg, @tomauger, @topher1kenobe, @topquarky, @toszcze, @westonruter, @wokamoto, @wonderboymusic, @zbtirrell, and @zodiac1978 for their efforts this week!

     
  • K.Adam White 7:58 pm on November 13, 2013 Permalink
    Tags: , , JSHint   

    Finding and Fixing JavaScript errors with JSHint 

    The JavaScript Coding Standards have been updated, so it’s time to move on to tackling our JSHint errors!

    JSHint is a tool to check for errors in JavaScript code. As was discussed last week, we’re kicking off a small effort to work through our core JavaScript files. To get through the errors revealed by JSHint as quickly as possible, we’re following the model established by the Inline Docs team and posting a list of files with issues so that people can “claim” the files they’d like to fix!

    At the bottom is a list of every file in core that is displaying JSHint errors. Files with a checkmark have been patched and should now be passing lint. Files marked with (@username #xxxxx) are already claimed, and being worked on.

    Please read and understand the process we’ll be following to address these issues! Many thanks to @azaozz, @nacin and @jorbin for helping identify the safest way to approach fixing these errors, and to @rzen for posting the Inline Docs article on which we based this guide.

    How to contribute:

    1. Leave a comment on this post with the file* you’re about to edit (check the list first to make sure it hasn’t already been claimed).
    2. Update your local WordPress SVN to the latest version of WordPress trunk (currently 3.8-alpha).
    3. Create a new ticket on Trac for the file.
      JSHint-related trac ticket settings

      • Format the title as “jshint shouldn’t throw errors – path/to/file.js”.
      • Assign the ticket to the “Build Tools” component.
      • Make sure your email is stored in Trac’s preferences

      If you are logged in, you can click this link to automatically open a ticket with the right settings.

    4. Edit the file, and make a patch. Please make sure you create the patch from the root directory of your WordPress SVN checkout. If you are working on a large file, consider making multiple patches for each type of change.
    5. Upload your patch to the Trac ticket you created, and add the keyword “has-patch”.

    *Note: We strongly encourage you to work on one file at a time. These shouldn’t take very long, but if you call a bunch at once and get tied up, we won’t be able to get through these as quickly as possible. To quote @rzen from the inline docs effort, “your edits should be made and patched swiftly so that they aren’t invalidated by (or don’t invalidate) another patch.”

    Keeping Discussions Focused:

    Any discussion about the specifics of a patch itself should happen on Trac. Discussion about the overall effort should take place during our standing weekly meeting, on Wednesdays at 1900 UTC in #wordpress-dev*.

    Files needing patches:

    Checked files are now passing JSHint

    See all open tickets in the Build Tools component

    For tips on dealing with global variables, inlined third-party code within first-party scripts, etc, see the JSHint tips in the JavaScript Coding Standards

    For the curious, this list was created with a jazzy little command @nacin came up with to pipe Grunt output through ack:

    grunt jshint --force | ack '^Linting src/' | ack -o 'wp-.*.js' | sort | uniq -c | sort

    What we’re NOT doing

    The two JSHint options called out in the earlier post, “curly” and “eqeqeq,” would ordinarily make up the vast majority of the errors JSHint reports in our files. We’ve currently set Grunt and JSHint to ignore these two types of errors when JSHint is run against core. While these are best practices, we’ll come back to them once we address the more significant code smell issues like undefined variables.

    Also note that we’re not tackling whitespace or non-JSHint-related refactoring during this effort. We’ll get there, but we have to mitigate the risk to core as much as possible so we don’t interrupt the 3.8 cycle. Keep your changes focused on passing JSHint this go-around.

     
  • K.Adam White 9:48 pm on November 5, 2013 Permalink
    Tags: ,   

    JavaScript Coding Standards 

    The PHP files in WordPress core become cleaner and easier to read with every release, thanks in part to our standards for PHP code style. Our JavaScript, on the other hand, hasn’t gotten nearly enough love. This post is intended to open up the recent discussion around JavaScript style to the greater community so we can make up for lost time.

    Don’t we already have a style guide for JavaScript?

    Back in March, @tommcfarlin added a set of coding standards for JavaScript to the developer handbook. These WordPress JS coding standards are a great work-in-progress, but weren’t fully comprehensive (leading to some comment threads clarifying various areas). More importantly, without any clear implementation plan the style guide failed to gain traction.

    At WordCamp Boston’s core contributor day I revisited this style guide with @mattwiebe and Corey Frang (@gnarf37). It is important to identify *and implement* conventions for JS style ASAP because syntax issues in the JS within WordPress may hide latent bugs, and inconsistent code discourages contribution. Focusing on implementation lead us to look for an existing, proven JS style guide with a .jshintrc file (a set of configuration options for the JSHint code quality tool) which we could adopt largely as-is: Getting JSHint in place lets us see the biggest issues in our JS, so we can begin tackling them incrementally (perhaps in the same manner as the inline docs effort).

    After looking at Idiomatic.js and several other widely-adopted JS style guides, we feel the jQuery Foundation’s jQuery Core JavaScript Style Guide guide is the closest match for what we need in WordPress.

    Adopting the jQuery Core JavaScript Style Guide

    jQuery’s guide shared WordPress core’s love of white space—the same “when in doubt, space it out” mantra from the existing JS style page. Moreover, jQuery’s code conventions have been referenced in trac tickets as an example of how we should be writing our code. Adopting their guide wholesale capitalizes on our stylistic similarities, and will let us adopt their .jshintrc and any future code quality tools they write with minimal changes.
    (More …)

     
    • Pbearne 9:55 pm on November 5, 2013 Permalink | Log in to Reply

      I will be happy do a bit of this.

    • deltafactory 9:57 pm on November 5, 2013 Permalink | Log in to Reply

      I’ve been thinking about threequals and curly-braces since Boston. It’s hard to break the habit.

      I’d like to help with the cleanup effort. It would benefit me to familiarize myself with more of the JS bits of WordPress.

    • Mike Bijon 9:58 pm on November 5, 2013 Permalink | Log in to Reply

      After reading the summary in email, my only concern was jQuery’s use of double-quotes vs. ours … seeing the longer article, that’s handled and I can’t think of any reasons to object.

      On the + side, adopting jQuery’s standards wholesale should reduce maintenance & debate. Plus, getting started sooner than later to *any* standard should help speed JS work & maybe help a few overly-debated JS tickets in Trac.

      Looking forward to seeing the sprint schedules

    • adamsilverstein 10:27 pm on November 5, 2013 Permalink | Log in to Reply

      Great post, thanks! I will try to make the meeting tomorrow and assist in the cleanup effort.

    • Matt Wiebe 10:46 pm on November 5, 2013 Permalink | Log in to Reply

      I have another (virtual) meeting at the same time, but I should be able to chime in.

      Thanks for pushing this forwards @kadamwhite 🙂

    • ericsherred 10:59 pm on November 5, 2013 Permalink | Log in to Reply

      Sounds like fun to me.

    • Dion Hulse 12:07 am on November 6, 2013 Permalink | Log in to Reply

      Wouldn’t it be better for us to standardise on for ( var i = 0; i < 100; i++ ) { instead of including var outside of the iterator? IIRC, including it outside was for some rather old browsers that we no longer (and probably haven’t for a long time) supported.

      • Andrew Ozz 1:12 am on November 6, 2013 Permalink | Log in to Reply

        As far as I remember defining all vars at the beginning of the scope mimics the actual way the script is parsed. Don’t think defining vars in the middle or end was a problem in any browser.

        • Dion Hulse 1:19 am on November 6, 2013 Permalink | Log in to Reply

          I thought I’d heard a rumour of an early IE bug.. but you’re probably right, defining it earlier is most likely only a parsing optimization, something we probably don’t need to worry about.

        • Tom McFarlin 1:52 am on November 6, 2013 Permalink | Log in to Reply

          +1 to this.

          Including all var declarations at the beginning of the function is how the script is parsed, and for those who are fans of JSLint, you’ll notice that combining all var declarations together is preferred[0].

          0.http://www.jslint.com/msgs.html

        • K.Adam White 2:14 am on November 6, 2013 Permalink | Log in to Reply

          As Tom notes, Andrew is correct—Variable declarations are “hoisted” to the top of the function’s scope, so declaring all your variables first is a best practice (it unifies the code’s visual structure with how it is parsed by the JS engine). There’s actually a “onevar” parameter in JSHint to enforce this style.

      • WraithKenny 2:10 am on November 6, 2013 Permalink | Log in to Reply

        I think it’s better, considering `for ( i = 0; i < 100; i++ ) { … } … var i = 2; alert( i );` would be confusing ('100') because of hoisting.

    • Andrew Ozz 1:47 am on November 6, 2013 Permalink | Log in to Reply

      Re-reading jQuery Core JavaScript Style Guide again: apart from the single/double quotes, other differences are the lack of indentation for `case` in `switch` and the hard limit to 100 characters per line (counting tabs as 4 chars). All of the rest more or less match our PHP and current JS coding standards. We also (used to?) have few more, like the strong discouragement of using nested ternary operators.

      So the question is: should we adopt the jQuery standard “wholesale” and depart from our PHP coding standard or should we continue to keep our PHP and JS coding standards as close as possible?

      • Tom McFarlin 1:58 am on November 6, 2013 Permalink | Log in to Reply

        I’m for the adoption of jQuery standards as much as possible; however, I do err on the side of keeping the JavaScript closely-related to our PHP coding standards (which is what I tried to do with the first draft of the standards).

        The reason being is that I don’t think we, as developers, should have to maintain two different set of standards.

        When working on client-side code, I often find myself thinking What’s the server-side standard for this, again? and then I try to apply that.

        Because I – and I’m sure most of us – are so familiar with the PHP standards, perhaps we should implement a “when it doubt, default to PHP standards.”

      • K.Adam White 2:26 am on November 6, 2013 Permalink | Log in to Reply

        I’m of a case-by-case mind on this. For example, I’ve encountered very few situations where >100 characters in a line were truly needed (and not just a symptom of hard-to-read or overly-nested code), so I’d be inclined to keep that. On the flip side, I’m all for keeping indentation rules consistent with PHP.

        Thanks for raising these questions, this is exactly what we need! Both here and during tomorrow’s chat I hope to identify any other differences between our PHP style and the proposed guide, and make decisions about which way to go. We’ve already identified a few areas in which we want to go a different way than jQuery. It’s a useful set of default behaviors, but what style guide we adopt isn’t what’s important—what is important is that consistency.

        • Andrew Ozz 2:47 am on November 6, 2013 Permalink | Log in to Reply

          Yes, the “around 80, max 100 chars” limit might eventually surface when something has many levels of indentation (5 – 6 tabs). This is not so hard to hit with longer jQuery chains which should probably be broken on multiple lines. Thinking it may be nice to have it as a rule in the PHP coding standard too, just not sure if it needs to be enforced.

    • Tom McFarlin 2:02 am on November 6, 2013 Permalink | Log in to Reply

      I’m going to try to make it to the meeting – what server and channel will the meeting take place?

      • K.Adam White 2:12 am on November 6, 2013 Permalink | Log in to Reply

        Good point, that’s something people need to know: Freenode, right in #wordpress-dev. (Note: That time was selected because I was not aware of any conflicting meetings; If anybody has a meeting in #wordpress-dev scheduled at that time, please let us know and we’ll get another room!)

    • Paul Clark 4:09 am on November 6, 2013 Permalink | Log in to Reply

      Count me in for a JSHint sprint!

    • Gary Jones 9:22 am on November 6, 2013 Permalink | Log in to Reply

      Not sure I can make it tonight, so I’m leaving my thoughts here that hopefully someone can take into consideration during the meeting.

      General adoption of the jQuery standards: +1
      Two exceptions to those standards: +1

      Would like to see a push towards named rather than anonymous functions = more self-documenting code, fewer nested levels -> avoid hitting line limits, reduce complexity.

      Consider use of ‘es3’ option in .jshintrc, since WP still needs to support IE8-9, and that will catch use of reserved words being used as properties with dot notation etc.

      I’m up for helping out with some JS tidying.

    • K.Adam White 1:00 am on November 10, 2013 Permalink | Log in to Reply

      Just a heads-up for everybody waiting for an update on this: Hang tight for a day or two, I’m working with @kpdesign to get the JS Standards handbook page updated and up to our standards.

    • Lance Willett 3:36 am on November 12, 2013 Permalink | Log in to Reply

      Thanks for your work on this—more vigorous standards and cleaner code FTW.

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