Make WordPress Core

Updates from October, 2016 Toggle Comment Threads | Keyboard Shortcuts

  • Nick Halsey 2:49 am on October 24, 2016 Permalink |
    Tags: ,   

    Customize Update 2016-10-23 

    This is the weekly update post for the customize component. It includes a summary of this week’s meeting, recent commits, and next week’s meeting agenda.

    4.7 Feature Proposals & Merges

    Three proposal posts have been published and approved since our last update:

    Customize Changesets (formerly Transactions) Merge Proposal

    Customize Changesets Technical Design Decisions

    Feature Proposal: Better theme customizations via custom CSS with live previews

    All five of the major customize feature projects proposed for WordPress 4.7 have been successfully merged (in order):

    Work continues on follow up tickets for many of these projects. Please test everything in the customizer and report any bugs to trac. We still have a few pending enhancements that need to be completed by this Wednesday, 10/26, 4.7 beta 1, sorted by priority:

    1. #27403 Improve UI for linking areas of Customizer preview to corresponding controls (desktop and mobile) – has-patch, needs testing and adjustments
    2. #38263 Color picker: add a hue-only mode – has-patch, needed for Twenty Seventeen
    3. #28536 Add browser history and deep linking for navigation in Customizer preview – needs-patch punted
    4. #38164 Customize: assign static front page and posts page to new pages – has-patch
    5. #37964 Allow customizer controls to be encapsulated by accepting pre-instantiated settings – has-patch, needs adjustments
    6. #22058 Improve custom background properties UI – has-patch
    7. #29158 Customizer UI Design lacks contrast for visual hierarchy and does not match wp-admin – has-commit, has-patch for revisions

    Weekly Customize Meetings

    Our past two weekly meetings have focused on preparing our projects for commit. We’ll continue our weekly 4.7 meetings into beta and RC pending the volume of customize tickets remaining in the milestone. For this week’s meeting, our priority will be ensuring that the 7 remaining customize enhancements for 4.7, listed above, are committed before beta 1.

    Our weekly update posts will continue on a reduced schedule now that the bulk of 4.7 development is complete, and we’ll also continue posting dev notes for changes in 4.7.

    Recent Customize Commits

    Here are the customize-related commits for the past two weeks:

    • [38765]: Customize: Ensure `customize_validate_{$setting->id}` filters apply on input post_values for WP_Customize_Setting subclasses that neglect to apply the filter themselves.
    • [38766]: Customize: Improve message displayed in widgets panel when there are no widget areas currently displayed in the preview.
    • [38767]: Customize: Show Pages section first and pre-expanded in list of available menu items.
    • [38794]: Customize: Move Pages below Custom Links in available nav menu items panel.
    • [38807]: Customize: Skip triggering initial click on pages section for available nav menu items if already open.
    • [38810]: Customize: Implement customized state persistence with changesets. 
    • [38811]: Customize: Split out link `click.preview` and form `submit.preview` event handlers…
    • [38813]: Customize: Introduce a new experience for discovering, installing, and previewing themes in the customizer.
    • [38829]: Customize: Introduce custom CSS for extending theme styles.
    • [38830]: Customize: Fix unit tests when `twentyfifteeen` is `WP_DEFAULT_THEME` instead of twentyfifteen.
    • [38831]: Customize: Improve the labeling of background and header images in the list mode of the media library.
    • [38837]: Twenty Seventeen: Fix a PHP warning on fresh installs.
    • [38850]: Tests: Prevent Twenty Seventeen from interfering with Customizer tests.
    • [38851]: Tests: Prevent Twenty Seventeen from interfering with Customizer ajax tests.
    • [38853]: Customize: Add sticky headers for panels and sections.
    • [38862]: Customize: Revert part of [38859] which caused sections to get deactivated in the customizer.
    • [38867]: Twenty Seventeen: Add theme support for customize selective refresh.
    • [38881]: Customize: Keep previously uploaded header images in place.

    Big thanks to those who contributed to patches committed this week: @johnregan3, @celloexpressions, @folletto, @westonruter, @deltafactory, @coreymcollins, @desrosj, @pento, @delawski, @davidakennedy, @afercia, @karmatosed, @ryankienstra, @valendesigns, @utkarshpatel, @stubgo, @lgedeon, @ocean90, @mihai2u, @dlh, @aaroncampbell, @jonathanbardo, @jorbin.

    We’re always looking for more contributors; check out the open customize tickets and swing by #core-customize in Slack to get involved. Tickets in the Future Release milestone will be considered first for 4.8 if they have a patch.

  • Andrew Rockwell 3:13 pm on October 20, 2016 Permalink |  

    Week in Core, October 5 – 18, 2016 

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

    • 74 commits
    • 76 contributors
    • 129 tickets created
    • 20 tickets reopened
    • 124 tickets closed

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


    • Accessible Tags autocomplete: [38797] #33902
    • Better consistency for the Media, Add Plugins, and Add Themes toolbars. [38795] #38010

    Build/Test Tools

    • Continue eliminating randomness in tests. [38763] #37371
    • Begin eliminating unnecessary randomness in tests. [38762] #37371
    • Revert [38759]. PHPUnit’s @requires syntax was introduced in PHPUnit 3.7, but the tests for PHP 5.2 use PHPUnit 3.6 because it’s the latest version that supports PHP 5.2. [38761] #38256
    • Make use of PHPUnit’s @requires notation. [38759] #38256
    • HTTP API: Remove an unnecessary duplicate HTTP request in the HTTP tests. [38758] #30017
    • HTTP API: Convert the POST redirect test to use a dataProvider in order for its speed to be more accurately measured. [38757] #38237


    • Allow _canonical_charset() to handle mixed-case strings. [38809] #38337


    • When checking comments, returned error object should include HTTP status code. [38783] #36901
    • Abstract die() calls from comment submission routine. [38778] #36901
    • Pass $comment to the comment_max_links_url filter. [38748] #37955
    • Account for the comment_order option in get_page_of_comment(). [38740] #31101
    • Improve check for previous comments for authenticated users in check_comment(). [38738] #28603


    • Implement customized state persistence with changesets. [38810] #28721, #31089, #30937, #31517, #30028, #23225, #34142, #36485
    • Skip triggering initial click on pages section for available nav menu items if already open. [38807] #36984
    • Move Pages below Custom Links in available nav menu items panel. [38794] #36984
    • Show Pages section first and pre-expanded in list of available nav menu items. [38767] #36984
    • Improve message displayed in widgets panel when there are no widget areas currently displayed in the preview. [38766] #36922
    • Ensure customize_validate_{$setting->id} filters apply on input post values for WP_Customize_Setting subclasses that neglect to apply the filter themselves. [38765] #37638
    • Add workaround for Safari bug causing preview frame to be unscrollable via mousewheel after a refresh. [38742] #38149



    • Add a role button to the Tags meta box tag cloud links. [38800] #38318
    • Do not send the request for releasing the post lock on unload when post_ID or active_post_lock is missing. [38772] #38271


    • Docs: In get_pages() and wp_list_pages(), note that post_status argument can also be an array. [38798] #38136
    • XML-RPC: Re-add a global $wpdb missed in [38768]. [38775] #37699
    • Restore usage of $wpdb, instead of $this->db. [38768] #37699
    • Login: Don’t rely on wp_is_mobile() for functionality. [38739] #33704


    • Media modal: make it possible to reorder images by dragging on devices with both touch screen and mouse support. [38793] #31652
    • Correct the hostname used in the wp_get_attachment_metadata() test. [38760] #36246



    • Emoji: Update Emoji CDN filter default for resource hints. [38764] #38724
    • Updates for 4.6. Merge of and to the 4.6 branch.

    Networks and Sites

    • Multisite: Maintain switched state in site icon/logo functions. [38786] #38253
    • Multisite: Clarify that get_site_by_path() does not return exact matches. [38781] #38152


    • Add new pre_trackback_post action before a trackback is added to a post. [38791] #37007
    • Trackbacks: Allow the error message strings passed to trackback_response() to be translatable. [38741] #38214


    • Docs: Improve documentation for install_plugin_install_status(). [38805] #36912
    • Correctly display the current plugin in the plugin editor. [38745] #24122, #17552

    Posts, Post Types

    • Docs: Document global variables used by get_the_content(). [38746] #37173


    • Allow the hyphen-prefix-for-search-exclusion feature to be disabled by filter. [38792] #38099


    Rewrite Rules

    • Make sure rewrite rules are not written until wp_loaded has fired [38751] #37892


    • Disregard the order of capabilities when testing that single site and multisite capability tests match. [38802] #38191
    • Add tests for all user roles that check custom capabilities that do not have any form of handling (eg. in a map_meta_cap filter). [38769] #38191



    • Cache results of term count queries. [38784] #38295
    • Specify taxonomy when populating cached object terms. [38779] #37291
    • Avoid a fatal error in the_tags() in the event that get_the_term_list() returns a WP_Error. [38777] #37291
    • Better error handling when fetching object terms from cache. [38776] #37291
    • On wp-admin/term.php, don’t show a ‘Back to’ link which links to the current page. [38753] #37573
    • Remove paged argument from referer and add it only if current page is greater than 1. [38752] #38194
    • Don’t drop term order and current page when bulk deleting terms. [38750] #38194
    • Introduce WP_Taxonomy and use it in register_taxonomy() and unregister_taxonomy(). [38747] #36224, #36217
    • Docs: Improvements to register_taxonomy() docblock. [38737] #38007


    • Improve the inline documentation for the get_*_template() functions by providing examples instead of verbose explanations. [38789] #38249, #37770
    • Do not show an update button if there’s no update package. [38788] #37774
    • Remove paged.php from the theme template hierarchy. [38755] #38162


    • Remove the calls to getBookmark() and moveToBookmark() in IE. [38808] #38335
    • When editing pages, add body class with the page template, or page-template-default. [38803] #37599
    • Restore the monospace font in textareas in the TinyMCE UI. Make it same as in the Text editor. [38801] #38125
    • Prevent applying Indent and Outdent while an image with a caption is selected. [38796] #38313
    • Prevent iOS Safari from expanding the iframe width beyond the container width. [38782] #38289
    • Update the charmap plugin to the latest dev. version. [38780] #37936
    • Add support for custom dashicon for wp.mce.View.setLoader(). [38774] #37900
    • Update to 4.4.3, changelog: ​https://www.tinymce.com/docs/changelog/#version443-september12016 [38773] #38081, #38245, #37507, #37808, #38000
    • Allow pasting in image captions. Remove blocks and insert “ tags instead, also remove elements that would break the caption like other images, video, audio, etc. [38756] #36211


    • Show correct time of last checked update. [38743] #37554
    • Updates: Remove the ‘Download’ button on the Updates screen. [38736] #36811


    • Use the role name instead of the role display name when fetching the list of users with no role. This avoids false positives when dealing with user roles that, for example, contain spaces in the display name. [38787] #38234

    Thanks to @aaroncampbell, @abrightclearweb, @achbed, @adamsilverstein, @afercia, @akibjorklund, @aniketpant, @azaozz, @birgire, @bobbingwide, @boonebgorges, @boonebgorges for review, @celloexpressions, @Cheffheid, @choongsavvi, @choongsavvii, @Chouby, @chriseverson, @clarionwpdeveloper, @dd32, @desrosj, @dlh, @dmsnell, @DrewAPicture, @dshanske, @dungengronovius, @flixos90, @goranseric, @helen, @jamesacero, @jayarjo, @jdgrimes for initial patch, @jeremyfelt, @johnbillion, @jonathanbardo, @jorbin, @karmatosed, @koenschipper, @kraftbj, @lgedeon, @mattking5000, @MattyRob, @michalzuber, @mihai2u, @mikeviele, @morganestes, @mt8.biz, @needle, @ocean90, @pbearne, @pdufour for research, @pento, @peterwilsoncc, @PieWP for initial patch, @procodewp, @rachelbaker, @ryankienstra, @ryankienstra for initial patc, @sayedwp, @SergeyBiryukov, @solarissmoke, @stevenlinx, @stubgo, @sudar, @swissspidy, @tristangemus, @tristangemus for initial patch, @tywayne, @tyxla, @utkarshpatel, @valendesigns, @voldemortensen, @webmandesign, @websupporter, @westonruter, and @WraithKenny for their contributions!

    • programmin 3:27 am on October 22, 2016 Permalink | Log in to Reply

      Nice! Will the fix making galleries draggable in media modal on all browsers be fixed in 4.6.something or in 4.7?

  • Jeff Paul 4:00 am on October 20, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: October 19 (4.7 week 9) 

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


    Dev Notes / Field Guides

    • In general, if you worked on something that needs to be called out for testing or building upon, there should be a post about it.  These are all tagged as `dev-notes` on the Make/Core site.  The target is everything written before beta 2 so we can get a field guide summarizing them and an email sent to all plugin developers while we are still in beta. In general all active components should have at least one post about what has changed.

    Final Merge Decisions

    • Twenty Seventeen (@davidakennedy)
      • Merge Proposal & Trac ticket
      • 59 contributors. Merging later today.
      • There are 34 issues left, some of which will be moved to Trac. There are 0 pull requests left.
      • A code review was performed by @aaroncampbell, and he didn’t find anything that should hold up merge.
      • Theme does not depend on any core features being merged before/at the same time, but will greatly benefit from any completed.
      • Video headers (#38172) needs consensus on the best approach and testing of functional patches
      • Merge proposal accepted. 🎉
    • REST API: Content API (@kadamwhite)
      • Merge ProposalSuccess metrics
      • 99 contributors. 25 merged PRs in the past 3 days. 27 issues left in the current milestone and a few stray PRs, which will be closed out shortly or moved to Trac.
      • Monday meeting in #core resulting in conditional merge approval
      • Conditions:
        • 1) 4.7: Press This / Quick Draft Core feature (#38343 and #38342)
        • 2) 4.7: Object / non-single level meta. @joehoyle, @jnylen and others have been working on this, tracking via GitHub.
        • 3) 4.7: Define success metrics (see link above)
        • 4) 4.7: Continuing to ensure the API forward compatibility (EVERYONE should be building things with it).
        • 5) 4.7: Review .com API settings discrepancies, determine how to resolve or where to document. @joehoyle, @jnylen and others have been working on this; Progress/documentation.
      • WP-API is code-frozen at this time; open enhancements will be ported over by @rachelbaker as appropriate.
      • Merge proposal accepted (“Let’s do it.”). 🎉

    Components and Other Enhancements

    • i18n (@swissspidy)
      • Nothing newsworthy from the i18n side which isn’t already on Make/Core.
    • Make it easier to visualize where to put your content in a given theme (aka “dummy content”)
      • If there are people out there interested in content writing and stuff like customizer integration, hit up @helen.
    • Media (@mikeschroder, @joemcgill)
      • We’re working on trying to get #31050 (Better PDF Upload Management) into shape for commit this week. Still some issues to iron out, but it’s getting close.
      • I want to call out that we’ve removed the automatic fallbacks for generating `alt` attributes from images with consultation from the a11y team to improve the user experience for screen readers. See: #34635 for details.
      • We have a few other things we’re looking at this week, but if there is anything pressing that needs eyes specifically from someone on the Media team, please reach out in #core-media.
    • Customize (@westonruter, @celloexpressions)
      • Remaining three major 4.7 feature projects merged in the last 24 hours.
      • #27403 and #38164 are our larger remaining tickets needing attention currently, with #29158 and #22058 pending final patches for review and discussion.
    • Editor (@azaozz, @iseulde)
      • TinyMCE: allow pasting in image captions (#36211) needs some more testing
        • Add an image in the editor, add a caption, then try pasting different things copied from another web page in it. This makes some assumptions of what the user expects, and what should happen, i.e. when pasting an image into a caption it should remove the image but let the text in, or keep all that is pasted but move it under the caption?
  • K.Adam White 11:15 pm on October 13, 2016 Permalink |
    Tags: ,   

    Merge Proposal Discussion: REST API Content Endpoints 

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

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

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

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

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


    Have the content API endpoints been thoroughly reviewed for security?

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


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

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

    User Feedback

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

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

    Do Content Endpoints Benefit Core Development?

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

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

    Will Merging Negatively Impact API Development?

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

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

    Do Content Endpoints Belong on Every WordPress Site?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    REST API Team Update, 4.7 Week 8 

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

    REST API v2 Beta 15 released

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

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

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

    New Questions & Discussion Items

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

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

    Meeting Notes

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

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

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

    OAuth’s place in the Merge Proposal

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

    Content Endpoints Without OAuth

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

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

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

    In Summary

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

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

    Media Weekly Update (Oct 7) 

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

    Summary from last week

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

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

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

    Agenda for the next meeting

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

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

  • Weston Ruter 5:29 am on October 12, 2016 Permalink |
    Tags: , , ,   

    Customize Changesets (formerly Transactions) Merge Proposal 

    This is a merge proposal and overview of Customize Changesets (#30937), a project formerly known and proposed as Customizer Transactions back in January 2015. The customizer is WordPress’s framework for doing live previews of any change on your site. One of the biggest problems the customizer faces right now is that changes are ephemeral. If you navigate away, you lose what you are working on. Additionally, you can not share proposed changes with others, nor can you take the changes you are working on and save to continue working later.

    Imagine a WordPress user named Tina. Tina is building a website for her daughter’s band. The band has been getting more and more popular, and Tina wants to experiment with some new widgets in the sidebar but also wants to be able to share the proposed solutions with her husband Matthew. Right now, Tina and Matthew would need to be in the same room to collaborate. Or Tina would need to take screenshots, but that kind of defeats the purpose of live preview. If only there was a way to make customizer changes persistent without publishing them.

    Introducing Customize Changesets

    Customize changesets make changes in the customizer persistent, like autosave drafts. Users can make changes to one theme and switch to another in the customizer without losing the changes upon switching. A customizer session can be bookmarked to come back to later or this URL can be shared with someone else to review and make additional changes (the URLs expire after a week without changes). The new APIs make possible many new user-facing features in future releases and feature plugins, including saving long-lived drafts, submitting changesets as pending for review, scheduling changes, seeing the previewed state on the frontend without being in an iframe, sharing preview URLs with others who do not have customizer access, and others.

    Customize changesets allow each change you make in the customizer for a given live preview session to be persistent in the database. A unique identifier (a UUID like f67efbbf-c663-4271-ab1c-95ce1d447979) for each live preview session is generated and as soon as a change is made, the change setting value is sent in an Ajax request to be written into a custom post type whose post_name is the UUID for the customizer session. Once the changes have been written into the changeset post, then any request to WordPress (including to the REST API) can be made with a customize_changeset_uuid query param with the desired UUID and this will result in the customizer being bootstrapped and the changes from that changeset being applied for preview in the response. The unique UUID means that customizer sessions can be sent to other users and also that they can be used as query parameters on the front end.

    Design and Technical Decisions

    For the initial core merge, no UI changes are being proposed. The feature will be only be exposed as the new query parameter on the URL. Adding a UI to this feature will happen in a future release. As such, the proposal for customize changesets is similar to the proposal for including the REST API infrastructure: it provides a foundation for new core features in future releases and a platform for plugins to add new features. Nevertheless, while the customize changesets patch doesn’t introduce any new features it does fix several long-standing issues related to incompatibilities between JavaScript running on the site’s frontend when previewed in the customizer. Under the hood, the customize changesets patch touches on many of the lowest level pieces of the customizer. Please check out the Customize Changesets Technical Design Decisions to see what is happening under the hood.


    Please test! If you use any plugins that extend the customizer, please ensure that there aren’t any regressions. The patch is intended to be fully backwards compatible and users shouldn’t notice any difference in normal use. Two things to look for when testing is as soon as you make a change, you should see a customize_uuid query param added to the URL. You should be able to reload and find your changes persist (note the AYS dialog is retained because there is no UI yet for listing changesets). Also, when you navigate around the preview it should feel much more natural like normal browsing as opposed to having a fade effect. Otherwise, previewing settings that require refresh should still work as normal, as will settings that preview with JavaScript and selective refresh.

    The patch is in a GitHub pull request and you can apply the patch via:

    grunt patch:https://github.com/xwp/wordpress-develop/pull/161

    If you’re using the Git repo from develop.git.wordpress.org then you can check out the branch directly via:

    git remote add -f xwp https://github.com/xwp/wordpress-develop.git && git checkout xwp/trac-30937

    I’d appreciate code review feedback directly on the pull request. For any revisions to the patch, please open a pull request to that trac-30937 branch if possible.

    The Future

    In future releases we can explore new UIs to take advantage of the new capabilities that changesets provide. New UIs can provide a way to schedule changes, the ability to undo the last change, show an audit log (revision history) for changes, collaborative editing of a customizer changeset, and so on. Future feature projects will explore many of these and feature plugins will start to prototype them.

    Thanks to @jorbin who contributed to this proposal post.

    • Dominik Schilling (ocean90) 8:34 pm on October 12, 2016 Permalink | Log in to Reply

      The customizer needs this to get rid of some odd limitations and to provide a more “native” live-preview feeling. +💯 from me.

    • Ahmad Awais 10:06 pm on October 12, 2016 Permalink | Log in to Reply

      ^What Dominik said! +1 for Customize Changeset.

    • Philip Ingram 7:41 pm on October 19, 2016 Permalink | Log in to Reply

      Love this idea. Curious to see how this can be applied to team development workflows to the live css topic we’ve been discussing

      • Weston Ruter 10:59 pm on October 19, 2016 Permalink | Log in to Reply

        @pingram3541 you can collaborate on the CSS now by making a change, copying the customizer URL with the changeset_uuid query param intact, sending the URL to a colleague, your colleague can make some changes, and then you can reload the customizer on your end and their changes will be visible on your end for additional changes. Note that the changeset is autosaved every 60 seconds or whenever focus is removed from the customizer window (or when it is unloaded). Eventually there should be a “Save Draft” button to proactively save the state (#31089), and there should also be support for concurrency locking (#31436).

        • Philip Ingram 2:40 pm on October 20, 2016 Permalink | Log in to Reply

          @westonruter Thanks Weston this is really great stuff. I often help other devs where css is not their strength and this is a perfect way for me to suggest an edit and let them preview it without actually applying the changes on the public side. I could see a great use case for an enhancement plugin to provide diffs revealing the proposed changes even more clearly

  • Jeff Paul 6:06 pm on October 7, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: October 5 (4.7 week 7) 

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


    Components & Features

    • Non-4.7 Feature Proposal: Notifications API (@johnbillion)
      • Discussion on this in #feature-notifications, but no meeting scheduled
    • Non-4.7 Feature Proposal: Status API for taxonomy terms (@boonebgorges)
    • Customize (@westonruter, @celloexpressions)
      • Feature proposal for 4.7: Discovering and installing themes in the customizer (@celloexpressions)
        • Deadline for feedback and review from various teams is Wednesday, October 12th
        • Need review/audit from Flow (and mobile), Docs, Security, Polyglots/i18n, Design/UX, Accessibility, and when those are done a Code Review (@westonruter)
        • Would like user testing & testing of the patch itself
        • Please provide feedback as a comment on the Feature Proposal Post, User Testing Post, or via Trac
        • The plan is to begin final code review/commit next Wednesday, October 12th, so feedback needs to be received by then
      • Merge proposal for Customize Changesets (fka Transactions) – Trac & Github
        • Needs developer attention, specifically on expected/best behavior on maintaining changesets across multiple theme previewing/testing. Details to be included in a Make/Core post by @westonruter with discussion continuing in #core-customize
      • Otherwise we’re working toward finalizing patches for all of our other projects and will publish a feature proposal for custom CSS in the next week. All 4.7 customize non-bugs have an owner assigned to work toward commit or punt to a future release.
    • Twenty Seventeen (@davidakennedy, @melchoyce)
      • Highlight: start testing the theme, we need help on the features from a development perspective, plan is theme merging into core by October 19th with enhancements needing to complete by October 26th
      • Latest theme update
      • Latest features update
      • Theme recap: This week the initial design implementation was merged into the master branch on GitHub. The rest of the theme is moving along nicely, and the initial design implementation should make it easier to test the theme’s features. Please start testing, and creating issues! The next step is to get a public demo up to help with that. Best way to test is to get it via GitHub ( if using wp-cli, wp theme install <github-url> --activate).
      • Features recap: For the multi-panel feature, at the weekly meeting, the feature was reduced in scope to focus only on the front page of sites, only include content from pages and be implemented in the Customizer. @karmatosed has some mocks posted (including live preview). For the video headers feature, it still needs to be focused with a reasonable MVP defined. Although, some recent feedback on the ticket is helping there.
      • Twenty Seventeen needs you. Home pages should be fun to create and a heck of alot easier. Headers can be even more captivating. If you’re interested in working on either of these projects, please let @davidakennedy know.
    • REST API (@krogsgard, @kadamwhite)
      • Settings (PR against the main plugin repo) and Meta (PR here against the meta repo) are still open for review from the team; we’ll be formally posting updates on Make/Core outlining the new functionality as these land
      • Need a lot of eyes on Authentication, released v2 beta 14 last weekend and intend to release a beta 15 with the merge-candidate functionality. Plan to propose that OAuth1 be included in the merge.
      • Testing and review is top priority right now. Docs for folks getting up and running with the API will be getting a strong push post-Proposal.
      • Next meeting: Thursday at 2pm UTC
    • Media (@mikeschroder, @joemcgill)
      • Latest update
      • Media search doesn’t include file name (#22744): Just committed a fix for a bug that was trampling existing JOINs. Please test, especially if you’re doing any custom filtering to media queries that might be impacted.
      • Starting work on potential feature plugin to introduce additional UX improvements to the media library. Likely future release material, but expect to fix some bugs and lay groundwork during this release. Development will happen in GitHub. Plan to make a feature project proposal after we’ve had some initial conversations about UI/UX direction.
      • After some conversation with @sheri, may still try to land a core media widget (#32417). Most of the work here has already been done, but need to make some decisions. We’ll plan to talk about this during our meeting on Friday at 5pm UTC in #core-images.
    • i18n (@swissspidy)
      • User Admin Language (#29783) landed this week. It allows each user to set their language (locale) and the admin will be translated accordingly for them. A dev note has yet to be written.
      • Focusing on making use of that feature by sending emails in the respective user’s locale. See #26511 if anyone wants to help with a new patch.
      • Introduce some JavaScript i18n functions (#20491): progress currently happens outside of core. There’s a proof of concept for extracting strings from JavaScript files as well as a PR on the GlotPress repository to add JSON export functionality.
    • Editor (@azaozz, @iseulde)
      • We’ll work on a better experiences for when nonces expire; posted an idea dump in #core-editor, thoughts on any points are very welcome.
      • Bug scrub Thursday at 4pm UTC in #core-editor.
      • In order to move ahead with several UI proposals/tickets we will need to get more usage data.
      • Planning to update TinyMCE next week, even if no new version by then.
  • Grant Palin 6:13 am on October 7, 2016 Permalink |  

    Week in Core, September 28 – Oct 5, 2016 

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

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

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

    Code Changes


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

    Admin Bar

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








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



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



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




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




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



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


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



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



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


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

    Unit Tests

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


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


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

  • Jeff Paul 8:37 pm on September 29, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: September 28 (4.7 week 6) 

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


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

    Components & Features

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