WordPress.org

Make WordPress Core

Updates from November, 2016 Toggle Comment Threads | Keyboard Shortcuts

  • Nick Halsey 10:14 pm on November 30, 2016 Permalink |
    Tags: , ,   

    Customizer Improvements in 4.7 

    WordPress 4.7 has been the most active release on record for the customize component, with four major feature projects merging and shipping with 4.7 and over 90 tickets closed as fixed. This post summarizes the highlights of the user and developer-facing changes.

    4.7 Customizer Feature Projects

    Create pages within live preview during site setup

    Add new pages while building menus and setting a static front page; outline your site directly in the customizer.

    This project began with the ability to create posts and pages direction from the available menu items panel in the customizer, as originally proposed near the end of the 4.6 cycle:

    Feature Proposal: Content Authorship in Menus, with Live Preview

    Subsequent changes also added the ability to create new pages when assigning the front page and posts page in the Static Front Page section. Because this is now built into the core dropdown-pages customizer control, themes and plugins can also allow users to create new pages for their options instead of relying on existing content. The homepage sections in Twenty Seventeen include this new allow_addition parameter. Here’s how to register a dropdown-pages control supporting new pages:

    $wp_customize->add_control( 'featured_page', array(
    	'label'          => __( 'Featured Page', 'mytextdomain' ),
    	'section'        => 'theme_options',
    	'type'           => 'dropdown-pages',
    	'allow_addition' => true, // This allows users to add new pages from this dropdown-pages control.
    ) );
    

    Additionally, a proposal for term statuses was developed as a first step toward expanding the menus functionality to work for creating and previewing taxonomy terms in a future release (see #37915).

    Improvements to the Sliding Panels UI

    Customizer navigation is now faster, smoother, and more accessible.

    This project tackled a series of tickets focused on improving the usability of the “sliding panels” UI in the customizer controls pane. The first step was to refactor the section and panel markup so that sections and panels are not logically nested. This is the biggest internal change to the UI and has a dedicated post going into the details:

    Changes to Customizer Sliding Panels/Sections in WordPress 4.7

    This primary change resolved numerous problems with sections and panels not opening and closing properly, and eliminated situations where navigation to leave a section could become hidden. The next step was making section and panel headers “sticky” so that navigation is easier to access within long sections (such as for a menu); see #34343.

    Finally, hover and focus styling for navigation in the customizer has been updated to use the blue-border approach found elsewhere in core, including for the device-preview buttons in the customizer, in #29158. This completes a refresh of the customizer controls pane’s UI design that began in WordPress 4.3 with #31336. The core UI now uses the following consistent UI patterns in the customizer:

    • White background colors are used only to indicate navigation and actionable items (such as inputs)
    • The general #eee background color provides visual contrast against the white elements
    • 1px #ddd borders separate navigational elements from background margins and from each other
    • 15px of spacing is provided between elements where visual separation is desired
    • 4px borders are used on one side of a navigation element to show hover or focus, with a color of #0073aa
    • Customizer text uses color: #555d66, with #0073aa for hover and focus states on navigation elements

    Plugins and themes should follow these conventions in any custom customizer UI that they introduce, and inherit core styles wherever possible.

    Any custom sections and panels, as well as customizations to the core objects in plugins and themes, should be tested extensively to ensure that they continue functioning as intended with all of these changes in 4.7. It’s particularly important to ensure that things like the use of color match the core conventions so that the user experience is seamless between functionality added by plugins and core.

    Customize Changesets (formerly Transactions)

    Browse your site and switch themes more seamlessly within the customizer, as your changes automatically persist in the background.

    This project rewrote the internals of the customizer preview mechanism to make changes persistent. Each change made to a setting in the customizer is saved to a changeset (a new customize_changeset post type), facilitating future features such as scheduled changes, revisions, or saving and sharing drafted changes. Changesets also open the door to using the customizer to preview Ajax requests, headless sites, and REST API calls for mobile apps. In 4.7, changesets enable switching themes in the customizer without needing to decide between publishing or losing your customizations, as they’re automatically persisted in the background.

    For more details on changesets, check out the two dedicated posts:

    Customize Changesets (formerly Transactions) Merge Proposal

    Customize Changesets Technical Design Decisions

    Custom CSS

    Fine-tune your site and take your theme customizations to the next level with custom css in the customizer.

    #35395 introduced a user-oriented custom CSS option in the customizer. Now that the base functionality is in place, it will be further enhanced in #38707 in future releases. Read the feature proposal for details on the implementation and why it’s important for core:

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

    There’s also a dedicated post that walks through the process of migrating existing custom CSS options in themes and plugins to the core functionality – be sure to follow those steps if your plugin or theme does custom CSS:

    Extending the Custom CSS editor

    Other Changes with Dedicated Posts

    4.7 features several other features deserving special attention. Read the posts for visible edit shortcuts (which expand the functionality of customizer partials), video headers (which extend the custom header feature), and starter content for more information:

    Visible Edit Shortcuts in the Customizer Preview

    Video Headers in 4.7

    Starter content for themes in 4.7

    Additional User-facing Changes

    With over 90 tickets fixed in the customize component in 4.7, we can’t cover everything here. But, here are a few more highlights:

    Improved Custom Background Properties UI

    #22058 introduces a more comprehensive and more usable custom background properties UI when a custom background is set up. There are now presets to control all of the detailed options at once, and the individual options are presented in a more visual way. Background size and vertical position are also now available as standalone options when using a custom preset.

    Theme developers should update their add_theme_support() calls for custom-background to specify the default size, vertical position, and preset to reflect their default background image CSS. Perhaps the most significant improvement here is the ability for users to easily set up fixed full-screen backgrounds – and the ability for themes to make that behavior default if desired.

    And even more…

    4.7 also:

    • Loads the frontend preview iframe more naturally, eliminating a lot of weirdness with JS running in an unexpected location and ensuring that JS-based routing will work (#30028)
    • Allows the search results page to be previewed, and any forms that use the GET method in general can now be submitted whereas previously they would do nothing when submitted (#20714)
    • Hides edit post links in the customizer by default. Plugins, such as Customize Posts, can restore the links if they make post editing available in the customizer (#38648), although the visible edit shortcuts should generally be used instead.
    • Shows a cursor: not-allowed for mouse users when hovering over external links in the preview, as these can’t be previewed
    • Officially removes support for the customizer in Internet Explorer 8, preventing users of this outdated browser from accessing the customizer at all (#38021)

    Additional Developer-oriented Changes

    Hue-only Color Picker

    #38263 adds a hue-only mode to the Iris color picker, wpColorPicker, and WP_Customize_Color_Control. Built for Twenty Seventeen’s custom colors functionality, the hue-only mode allows users to select a hue and saves the hue degree as a number between 0 and 359. To add a hue-color control:

    $wp_customize->add_control( new WP_Customize_Color_Control( $wp_customize, 'colorscheme_hue', array(
    	'mode' => 'hue',
    	'section' => 'colors',
    ) ) );
    

    As demonstrated in Twenty Seventeen’s custom colors strategy, the hue-selection strategy opens up a whole new world of possibilities for custom color options in themes. Rather than introducing numerous text and background color options and requiring users to adjust them to ensure that adequate color contrast is provided, themes can consolidate their color options into one or more hue pickers. Then, the corresponding use of hsl colors in CSS allows themes to define color patterns where users customize color hues without impacting the lightness of a color option, thereby preserving the designer’s use of proper contrast between text and background colors, and any use of color lightness for visual hierarchy. Check out the implementation in Twenty Seventeen for inspiration (including instant live preview).

    Fix Sections that .cannot-expand

    When creating custom customizer sections that, for example, display an external link but don’t actually expand to show section contents, the cannot-expand class can be added to the section title container to prevent JS events and CSS hover/focus styles from being applied. Be sure to also remove the tabindex="0" from the container if you copy the core code since your custom section shouldn’t be focusable if it can’t expand (and any contained links or buttons would be keyboard-focusable automatically). See #37980 for details.

    Allow Plugins to do Comprehensive Late Validation of Settings

    To account for custom subclasses of WP_Customize_Setting that don’t apply the customize_validate_{{$setting_id}} filter, this filter now will be applied when WP_Customize_Manager::validate_setting_values() is called. This ensures that plugins can add custom validation for every setting. For more, see #37638.

    Credits

    Huge thanks to the 61 people (and counting) receiving props for the 120+ customize component commits in 4.7 (as of RC2): @westonruter, @celloexpressions, @afercia, @sirbrillig, @ryankienstra, @helen, @ocean90, @melchoyce, @bradyvercher, @folletto, @johnbillion, @delawski, @karmatosed, @georgestephanis, @dlh, @curdin, @valendesigns, @mattwiebe, @michaelarestad, @joemcgill, @sstoqnov, @lgedeon, @mihai2u, @coreymcollins, @stubgo, @utkarshpatel, @desrosj, @odysseygate, @johnregan3, @aaroncampbell, @mapk, @iseulde, @mrahmadawais, @vishalkakadiya, @sayedwp, @hugobaeta, @jonathanbardo, @jorbin, @tristangemus, @deltafactory, @kkoppenhaver, @seancjones, @presskopp, @Mista-Flo, @nikeo, @adamsilverstein, @lukecavanagh, @coffee2code, @peterwilsoncc, @presskopp, @pento, @Kelderic, @sebastian.pisula, @mckernanin, @FolioVision, @MikeHansenMe, @welcher, @cdog, @grapplerulrich, @iamfriendly, @flixos90.

     

     
  • 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 |
    Tags: ,   

    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.

    Administration

    • 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

    Charset

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

    Comments

    • 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

    Customize

    • 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

    Date/Time

    Editor

    • 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

    General

    • 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

    • 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

    Menus

    Misc

    • 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

    Pings/Trackbacks

    • 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

    Plugins

    • 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

    Query

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

    REST API

    Rewrite Rules

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

    Role/Capability

    • 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

    Security

    Taxonomy

    • 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

    Themes

    • 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

    TinyMCE

    • 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

    Upgrade/Install

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

    Users

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

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

    Reminders

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

     
  • Nick Halsey 6:20 pm on October 9, 2016 Permalink |
    Tags: ,   

    Customize Update 2016-10-09 

    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

    The feature proposal for themes was published last week; the deadline for feedback/review is this Wednesday, October 12th:

    Feature Proposal: A New Experience for Discovering, Installing, and Previewing Themes in the Customizer

    Look for feature proposals for custom CSS and customize changesets (formerly “transactions”) this week.

    Weekly Customize Meeting Summary

    On Monday we held our weekly 4.7 customize component meeting in #core-customize on Slack [logs]. Participants: @celloexpressions, @braad, @aaroncampbell, @abdulwahab, @westonruter, @karmatosed, @folletto. This summary also contains a few notes on action since the meeting.

    4.7 Projects

    • Customize changesets (transactions) – #30937 – @westonruter
    • Create pages within live preview during site setup – #37914#37915, #38002#38164 – @celloexpressions
      • @boonebgorges published a proposal for term statuses; however, this will likely happen in a future release, along with #37914 and #37915 (pending a final punt decision from Boone).
      • The design team decided to punt providing a path to edit newly-created pages, #38002.
      • The remaining item for 4.7 is #38164 – extending this functionality to creating new pages for static front pages. A design approach was agreed upon in the design chat, and the code can be lifted from the Customize Posts plugin to build this out.
    • A new experience for themes in the customizer – #37661 –@celloexpressions
      • The feature proposal was published, and there are currently no comments. See also the make/flow post and make/design post, which have some feedback.
      • Additional design issues and usability adjustments have been completed and frozen pending a couple of minor tweaks and major bugs.
      • The deadline for feedback from other teams is October 12th, leaving a week for final code review and commit. We’re awaiting feedback from security, docs, polyglots, flow (if any beyond what was provided on the post), and most notably accessibility with the latest patch.
    • Code-editing gateways, via CSS – #35395 – @johnregan3
      • @johnregan3 has prepared a new patch to incorporate the design by @folletto as well as the dev-feedback from last week’s chat. A few minor adjustments are needed, then this will be ready for final review and commit.
      • The feature proposal post is in review and should be published within the next day or two.
    • Customizer browser history#28536 – @westonruter
      • Parts of this are blocked by changesets, which is higher priority for now. Changesets also offer improvements here natively.
      • If it’s okay with @helen, we’s like to pursue this in the week before beta, after the major feature deadline, since it’s a smaller feature.
    • Improving sliding panels UI – #34391, #34343, #29158 – @delawski
      • An initial commit is in trunk, dev note published, and only a few minor bugs have come up so far.
      • @delawski shared a patch for #34343 that needs testing. We discussed pursuing #35186 as an alternative in the future, but that it would cause compatibility issues since the default section markup would (probably) change.
      • @folletto propsed a design for the remaining elements of #29158, which @celloexpressions will create a new patch for next week.
    • Twenty Seventeen – a few related projects are targeting 4.7 with significant customize changes
      • #27403: Improve UI for linking areas of Customizer preview to corresponding controls (desktop and mobile)
      • #37974: Add multi-panel feature to pages through add_theme_support
      • #38172: Enable Video Headers in Custom Headers

    Additional Tickets Needing Attention

    • Customizer notifications – #35210 – needs UX feedback and a patch
      • @delawski will try to work on this in time for 4.7.
      • This ticket is holding up some of the other tickets on the 4.7 milestone, such as #22037 and #29932, as well as aspects of changesets (transactions).

    Ticket Scrub

    We ensured that all 4.7 customize non-bugs have owners or were punted. See these remaining open tickets by owner here.

    Recent Customize Commits

    Here are the customize-related commits for the past week:

    • [38709] Customize: Improve the widgets and menu items search
    • [38742] Customize: Add workaround for Safari bug causing preview frame to be unscrollable via mousewheel after a refresh.

    Big thanks to those who contributed to patches committed this week: @ryankienstra, @melchoyce, @afercia, @westonruter, @tristangemus.

    We’re always looking for more contributors; check out the open customize tickets and swing by #core-customize in Slack to get involved. Fun fact: we’re 5 commits away from the 1000th commit that references customize.

    Agenda for 2016-10-10 Meeting

    Our next regularly-scheduled meeting is Monday, October 10, 2016, 17:00 UTC. Agenda:

    4.7 Projects

    Additional Tickets Needing Attention

    • #37335: Standardized API for themes to add info/links to the customizer
      • If the theme review team wants this solution in core for 4.7, we need a decision on their end in the next week. Otherwise, the ticket can be closed as maybelater. Their current recommendation is to use a custom section (that cannot expand). cc @greenshady

    Ticket Scrub

    We’ll see you next week!

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

      Love the proposals and the fact that we’re taking into account additional load as a result and that it’s pluggable via the API too. This along with shiny updates allowing for zip upgrades of both themes and plugins is a breath of fresh air. Maybe with a little 3rd party help we can also have built in roll back’s as well. Being able to preview is great, being able to preview with your own content inside the customizer is even better.

  • Ryan McCue 4:05 am on October 8, 2016 Permalink |
    Tags: , , merge-proposals,   

    REST API Merge Proposal, Part 2: Content API 

    Hi everyone, it’s your friendly REST API team here with our second merge proposal for WordPress core. (WordPress 4.4 included the REST API Infrastructure, if you’d like to check out our previous merge proposal.) Even if you’re familiar with the REST API right now, we’ve made some changes to how the project is organised, so it’s worth reading everything here.

    (If you haven’t done so already, now would be a great time to install the REST API and OAuth plugins from WordPress.org.)

    A brief history of the REST API

    The REST API was created as a proof-of-concept by Ryan McCue (hey, that’s me!) at the WordPress Contributor Summit in 2012, but the project kicked off during the 2013 Google Summer of Code. The end result was Version 1.0, which grew into a community supported initiative that saw adoption and provided for a solid learning platform. The team used Version 1 to test out the fundamental ideas behind the API, and then iterated with Version 2, which made some major breaking changes, including explicit versioning, the introduction of namespacing for forwards compatibility, and a restructure of the internals. Version 2 also led to the infrastructure of the REST API being committed to WordPress core in 4.4.

    This infrastructure is the core of the REST API, and provides the external interface to send and receive RESTful HTTP requests. Since shipping in 4.4, the infrastructure is now used by WordPress Core for oEmbed responses, and by plugins like WooCommerce and Jetpack, enabling anyone to create their own REST API endpoints.

    The team has also been hard at work on the API endpoints. This has included core changes to WordPress to support the API, including deeper changes to both settings and meta.

    Today the REST API team is proposing the inclusion of a collection of endpoints that we term the “Content API” into WordPress Core.

    Proposals for Merge

    Content Endpoints

    For WordPress 4.7 the API team proposes to merge API endpoints for WordPress content types. These endpoints provide machine-readable external access to your WordPress site with a clear, standards-driven interface, allowing new and innovative apps for interacting with your site. These endpoints support all of the following:

    • Content:
      • Posts: Read and write access to all post data, for all types of post-based data, including pages and media.
      • Comments: Read and write access to all comment data. This includes pingbacks and trackbacks.
      • Terms: Read and write access to all term data.
      • Users: Read and write access to all user data. This includes public access to some data for post authors.
      • Meta: Read and write access to metadata for posts, comments, terms, and users, on an opt-in basis from plugins.
    • Management:
      • Settings: Read and write access to settings, on an opt-in basis from plugins and core. This enables API management of key site content values that are technically stored in options, such as site title and byline.

    This merge proposal represents a complete and functional Content API, providing the necessary endpoints for mobile apps and frontends, and lays the groundwork for future releases focused on providing a Management API interface for full site administration.

    Content API endpoints support both public and authenticated access. Authenticated access allows both read and write access to anything your user has access to, including post meta and settings. Public access is available for any already-public data, such as posts, terms, and limited user data for published post authors. To avoid potential privacy issues we’ve taken pains to ensure that everything we’re exposing is already public, and the API uses WordPress’ capability system extensively to ensure that all data is properly secured.

    Just like the rest of WordPress, the Content API is fully extensible, supporting custom post meta, as well as allowing more complex data to be added via register_rest_field. The API is built around standard parts of WordPress, including the capability system and filters, so extending the API in plugins should feel as familiar to developers as extending any other part of WordPress.

    This Content API is targeted at a few primary use cases, including enhancing themes with interactivity, creating powerful plugin interfaces, building mobile and desktop applications, and providing alternative authoring experiences. We’ve been working on first-party examples of these, including a mobile app using React Native and a liveblogging web app, as well as getting feedback from others, including WIRED, the New York Times, and The Times of London. Based on experience building on the API, we’ve polished the endpoints and expanded to support settings endpoints, which are included as the first part of the Management API.

    Authentication

    The API Infrastructure already in WordPress core includes support for regular cookie-based authentication. This is useful for plugins and themes that want to use the API, but requires access to cookies and nonces, and is hence only useful for internal usage.

    To complement the Content Endpoints, for WordPress 4.7 the API team also proposes merging the REST API OAuth 1 server plugin into WordPress Core. This plugin provides remote authentication via the OAuth 1 protocol, allowing remote servers and applications to interact securely with the WordPress API.

    OAuth is a standardised system for delegated authorisation. With OAuth, rather than providing your password to a third-party app, you can authorise it to operate on your behalf. Apps are also required to be registered with the site beforehand, which gives site administrators control over third-party access. Access to these apps can be revoked by the user if they are no longer using the app, or by a site administrator. This also allows apps with known vulnerabilities to have compromised credentials revoked to protect users.

    We’ve chosen OAuth 1 over the newer OAuth 2 protocol because OAuth 1 includes a complex system for request signing to ensure credentials remain secure even over unsecured HTTP, while OAuth 2 requires HTTPS with a modern version of TLS. While it is strongly encouraged for sites to use HTTPS whenever possible (Let’s Encrypt makes it easier than ever to do so), WordPress itself does not require HTTPS and we do not believe WordPress should make HTTPS a requirement for using the API. The additional complexity that OAuth 1 adds can be easily supported by a library, and many such libraries already exist in most programming languages. OAuth 1 remains supported around the web, including for the Twitter API, and we also provide extensive documentation on using it.

    Authentication Beyond 4.7

    One issue with OAuth over direct username and password authentication is that it requires applications to be registered on the site. For centralized OAuth servers this wouldn’t be a problem, but the distributed nature of WordPress installations makes this tough to handle: your application must be independently registered with every WordPress site it connects to. If you’ve ever had to create a Twitter or Facebook app just to use an existing plugin on your site, you’ll know this can be a less-than-optimal experience for users.

    To solve this distribution problem, we’ve created a solution called brokered authentication. This allows a centralised server (called the “broker”) to handle app registration and to vouch for these apps to individual sites. It simplifies app registration by allowing app developers to register once for all sites, and improves security by allowing the broker to vet applications and revoke them across the entire network. The system is designed to allow multiple brokers; while the main broker is run at apps.wp-api.org, organisations can run their own broker for internal usage, and developers can run a broker locally for testing.

    While the broker system has been running live at apps.wp-api.org for months, we want to stay conservative in our approach to the API, especially where security is concerned. We are therefore proposing brokered authentication for WordPress 4.8 to ensure we have further time to continue testing and refining the broker system. In addition, this will require an installation of the broker on a centralised server to act as the canonical broker for out-of-the-box WordPress. While apps.wp-api.org is currently acting in this role, this is currently hosted by a third-party (Human Made) on behalf of the API team. For long-term usage the broker should instead be hosted on WordPress.org, alongside the existing plugin and theme repositories. This migration will take time but we remain committed to continuing to develop and support the broker.

    After Merge

    After merging the REST API, the team plans to continue developing the API as before. We expect that integrating the REST API into WordPress core will bring additional feedback, and we plan on incorporating this feedback through the rest of the 4.7 cycle.

    During the remaining parts of this release cycle and through into the 4.8 cycle, additional work will go into other parts of the API. This includes further work and refinement on the broker authentication system, including work on WordPress.org infrastructure. Additionally, we plan to continue working on the Management API endpoints, including theme and appearance endpoints to support the Customiser team. Both of these components will be maintained as separate feature projects on GitHub until they’re ready for merge into core.

    The team remains committed to supporting the API in core, and the Content API will switch from GitHub to Trac for project management and contributions. This same process occurred for the API Infrastructure in WordPress 4.4.

    Reviews and Feedback

    With this merge proposal, we’re looking for feedback and review of the project. In particular, we’re focussing on feedback on the security of the API and OAuth projects, and are also reaching out to specific people for reviews. (We take the security of the API seriously, and bug reports are welcomed on HackerOne at any time.) Design and accessibility reviews for the OAuth authorisation UI are also welcomed to ensure we maintain the high standards of WordPress core.

    Both the REST API plugin and the OAuth plugin are available on WordPress.org, and issues can be reported to the GitHub tracker for the API and the OAuth plugin respectively. We have released a final beta (Beta 15 “International Drainage Commission”) which includes the meta and settings endpoints.

    With Love from Us

    As always, this is a merge proposal, and is not final until 4.7 is released. We’re eager to hear your thoughts and feedback; the comments below are a perfect place for that, or you can pop along to one of our regular meetings. We’re also always available in the #core-restapi room on Slack.

    We’d like to thank every single one of our contributors, including 88 contributors to the main repository and 23 contributors to the OAuth repository. Particular thanks goes to my (@rmccue) wonderful co-lead Rachel Baker (@rachelbaker), our 2.0 release leads Daniel Bachhuber (@danielbachuber) and Joe Hoyle (@joehoyle), and our key contributors for the 4.7 cycle: Adam Silverstein (@adamsilverstein), Brian Krogsgard (@krogsgard), David Remer (@websupporter), Edwin Cromley (@chopinbach), and K. Adam White (@kadamwhite). Thanks also to the core committers helping us out through the 4.7 cycle, including Aaron D. Campbell (@aaroncampbell) and Aaron Jorbin (@aaronjorbin), and to the fantastic release lead, Helen Hou-Sandí (@helen).

    Thanks also to everyone who has used the REST API, and to you for reading this. We built the REST API for you, and we hope you like it.

    With love, The REST API Team

     
    • George Stephanis 12:17 pm on October 8, 2016 Permalink | Log in to Reply

      Regarding Authentication, as nice as OAuth 1.0a may be in some respects, I feel that we’re missing some rather obvious problems here.

      We’re expressing such concern about securing the REST API endpoints to work on HTTP — that we’re missing the fact that for sites that don’t support HTTP, normal wp-login requests or cookies could just as easily be sniffed.

      It just feels to me like we’re spending a lot of time reinforcing the back door against attackers, when the front door isn’t even locked.

      The concept of a third-party broker feels very antithetical to WordPress Core. To have to ping the third-party server for every login to check for invalidations of their applications, let alone the initial confirmation of an application … for me, it doesn’t pass the gut check.

      I’d much rather see something akin to the Application Password system we’ve devised. It has unique per-application passwords, with 142 bits of entropy, usage logging (date and ip last used), and trivial invalidation, as well as a proposed simple flow for applications to request passwords and get the generated passwords passed back.. And, as an added bonus, it works with the legacy XML-RPC API.

      Compared to that, making someone hoping to do something for API access to a single site register for a cloud broker, and then reauth with the individual site .. the UX doesn’t pass muster for me. :\

      Authentication is probably the most important key to getting the REST API correct, and it’s necessary (imho) to ship. We need to get it right.

      • marsjaninzmarsa 7:25 am on October 9, 2016 Permalink | Log in to Reply

        To have to ping the third-party server for every login to check for invalidations of their applications, let alone the initial confirmation of an application … for me, it doesn’t pass the gut check.

        Nope, you’re missing the point, third party will be pinged only on first use of new app on particular site, and next every few hours or so for invalidation (same as with checking for security updates).

      • Dion Hulse 10:40 am on October 9, 2016 Permalink | Log in to Reply

        Core. To have to ping the third-party server for every login to check for invalidations of their applications, let alone the initial confirmation of an application … for me, it doesn’t pass the gut check.

        I tend to agree here.

        I’d much rather see something akin to the Application Password system we’ve devised

        However, I feel that Application Passwords are actually a far worse solution to the problem than the various oAuth options out there, to the point that I think Application Passwords are an anti-pattern which core should never directly support. The user experience of Application Passwords are not user friendly at all, they’re a hacky solution to avoid using a proper modern application authentication mechanism.

        I could ramble for quite some time on the UX of these, but at the end of the day moving towards oAuth is going to provide a far better developer and user experience for API clients.
        Unfortunately though with all options here there’s the downside that Applications need to be registered/known/considered safe and also be able to invalidate their credentials in the event the applications key store is leaked (For example, Plugin X which relies upon a service has it’s keystore hacked, the application would have no way of informing those sites to distrust it’s previous authenticated sessions).

        In an ideal world, a central provider wouldn’t be needed, but we don’t have a decentralised platform for WordPress yet, so there’s no other mechanism for WordPresses out there to be told the sort of information they need to know.

      • Ryan McCue 8:40 pm on October 9, 2016 Permalink | Log in to Reply

        At its core, OAuth is just a standardised system for issuing app tokens. The primary things that it builds on top of this are specifically for security over HTTP, so I would be extremely reluctant to move backwards from those to a more simple token-based system.

        Regular WordPress logins are protected by two main factors: nonces and session tokens. While it is possible to sniff a raw username/password over the initial login, subsequent requests are protected, which means automated attacks are much harder. The nature of an external API means neither WP nonces nor session tokens (which are both intentionally server-only secrets) can be used to protect authentication, so we need a replacement system.

        OAuth incorporates a combination of nonce and timestamp to replace these in a similar manner, which are then combined with the secret, which we need since it’s no longer server-only. (WP nonces and session tokens have an internal secret with NONCE_SALT, the only difference is that we share them with the client for OAuth.)

        The broker system exists specifically because dynamic registration (either with OAuth or your plugin) has a number of key problems, primarily that it makes revocation useless. If the app is revoked, it can simply register again, which subverts both the site admin and W.org team if it were intentionally revoked. We looked at dynamic registration and rejected it specifically because of the issues with it.

        While the system might seem conceptually complex, it’s pretty simple to actually implement, because the broker is just regular OAuth under the hood. The entirety of the flow can be written in 200 lines of JavaScript. From the app’s perspective, it primarily Just Works, with most of the complexity hidden inside the broker implementation instead.

        The OAuth 1.0a specification is rigorously tested by security researchers and in production on huge web apps. The broker system builds on top of this, but avoids reimplementing the wheel, and instead just uses OAuth for some of the heavy lifting. Application Passwords is at its core HTTP Basic Authentication, which in its own specification 17 years ago recommended against actually using it.

        OAuth 1 isn’t perfect, but every thing in it is there for a reason. Is it perfect? No. But it provides a lot of benefit over Basic Auth for a relatively low cost.

    • Jon Brown 1:09 pm on October 8, 2016 Permalink | Log in to Reply

      Much love back at you all. This looks fabulously well thought out and complete.

    • Josh Pollock 2:42 pm on October 8, 2016 Permalink | Log in to Reply

      5 Stars!

    • fgilio 3:09 pm on October 8, 2016 Permalink | Log in to Reply

      Thanks to all of you!

    • Ahmad Awais 4:07 pm on October 8, 2016 Permalink | Log in to Reply

      I’m all in. Let’s do it this time. BTW great read Ryan.

    • Omaar Osmaan 5:55 pm on October 8, 2016 Permalink | Log in to Reply

      Thanks so much for all the hard work from the team- eager to see it get merged on core!

    • Noel Tock 7:56 pm on October 8, 2016 Permalink | Log in to Reply

      :+1:

    • Sergio Santos 1:45 pm on October 9, 2016 Permalink | Log in to Reply

      Thanks to all the team behind this outstanding work!

    • Matthew Eppelsheimer 9:43 pm on October 9, 2016 Permalink | Log in to Reply

      Thumbs up!

    • Weston Ruter 12:12 am on October 10, 2016 Permalink | Log in to Reply

      Additionally, we plan to continue working on the Management API endpoints, including theme and appearance endpoints to support the Customiser team. Both of these components will be maintained as separate feature projects on GitHub until they’re ready for merge into core.

      I’d like to note that customizer changesets (#30937, formerly “transactions”) allows for REST API responses to have customizations applied when the request includes a customize_changeset_uuid query param which identifies a customize_changeset post. This allows the customizer to be used with headless sites and mobile apps.

      A feature plugin needs to be started shortly that allows for these changeset posts to be CRUD’ed via the REST API as well, allowing for new customizer administrative applications to be built on top of the REST API without any need to go to customize.php.

    • Tammie Lister 8:08 pm on October 10, 2016 Permalink | Log in to Reply

      As requested in the design Slack channel, here is a design review. I took the OAuth plugin for a spin today and only focused on the design elements.

      I first of all had discoverability issues, but that was mainly due to not using this. I sort of imagine if someone is going to use this they will be doing so knowing more than I did – so that’s ok.

      The first screen is minimal but as expected when empty. It seemed to all fit the existing WP patterns. Thanks for taking the time and doing that. Should there be select all boxes though – I don’t see any actions for all.

      On the ‘add’ screen, I tried adding nothing in the fields. I was surprised when got a green message. I would expect this should be red over the success green.

      https://cldup.com/JMW8wRzxx4.png

      The term ‘Add Application’ but then the action button being ‘Save Consumer’, this threw me. Perhaps this is my lack of knowledge over terminology, but shouldn’t they both be the same?

      The page gets cluttered fast, I sort of want a break here visually, just a simple line would do:

      https://cldup.com/3BZcACH2u9.png

      Regenerating the secret success message I felt should be by the secret. It was odd as the message appeared above my eye view. I click to regenerate lower and then this message pops up the top, feels like it should be close to add context.

      https://cldup.com/BF3C3iuVeF.png

      This may be a bug but when I searched for applications it tried to search users and I got the following:

      https://cldup.com/UjY8mgctGd.gif

    • Matt Mullenweg 8:26 pm on October 10, 2016 Permalink | Log in to Reply

      1. Given the hurdles of authentication I don’t think that bringing this into core provides benefits for WP beyond what the community gets from the plugin. I don’t believe in its current state the benefit outweighs the cost, and we should err on the side of simplicity.

      2. I am not interested in hosting the centralized brokered authentication server on WordPress.org in the 4.8 timeframe, and hesitant about the implications it has for WP more broadly. I do appreciate the thought that has been put into solving this tricky problem.

      • K.Adam White 9:39 pm on October 11, 2016 Permalink | Log in to Reply

        @matt, thanks for the comment. Can you clarify whether with (1) you mean the authentication solution, or the merge proposal for the content endpoints more broadly? There was discussion today in slack where we weren’t sure which way to interpret this point.

    • Dominik Schilling (ocean90) 10:01 pm on October 10, 2016 Permalink | Log in to Reply

      I gave the OAuth 1 plugin a try and here’s some feedback:

      • https://github.com/WP-API/OAuth1/issues/161 makes me wonder how we can integrate something with may not work on “a lot of sites”.
      • Adding Applications as a sub menu of Users doesn’t feel right to me. I just can’t imagine that 80% of our users really need this there. Twitter and Facebook have it both in the settings.
      • The UI: https://cloudup.com/c1emHXcHP4g Reusing existing elements is fine, but that looks a bit to simple and not fully developed. I’m sure that this can made better and doesn’t require a table. See Twitter/Facebook.
      • The plugin is using closures so it’s not compatible with the minimum requirements of WordPress.
      • I got a “500 Internal Server Error” error when the callback URL was invalid.
      • A few DocBlocks don’t follow the documentation standards.

      For some reasons I can’t get a successful `oauth1/access` request, I’ll try this again tomorrow…

    • Aaron D. Campbell 7:30 pm on October 11, 2016 Permalink | Log in to Reply

      The API endpoints themselves seem to be in a really good place, but I’m not sure the oAuth plugin is. Would it be reasonable to separate these into different proposals?

    • Mark Howells-Mead 2:32 pm on October 12, 2016 Permalink | Log in to Reply

      Issues aside, I’m strongly in favour of the REST API becoming a core feature as soon as it is stable.

    • Chris Smith 3:13 pm on October 12, 2016 Permalink | Log in to Reply

      +1 here as well and thanks to the team for their hard and thoughtful work.

      Based on the comments here, it does seem like it would make sense to split the proposal into the Content API and oAuth pieces for 4.7 so they can be dealt with/commented on independently as needed.

      @kadamwhite, what were the team’s thoughts on that in yesterday’s discussion?

    • Nilambar Sharma 5:32 pm on October 12, 2016 Permalink | Log in to Reply

      Really waiting for this. Lets make WordPress more awesome. It would be a great step merging new endpoints to core.

    • brad989 5:33 pm on October 12, 2016 Permalink | Log in to Reply

      Been looking forward to this for a long time. The content endpoints are an essential addition to WordPress core.

    • Chuck Reynolds 6:52 am on October 14, 2016 Permalink | Log in to Reply

      full api integration into core needs to happen eventually… API endpoints are at/near a good place. re: oath tho… meh..
      needs full support of CPT’s, which theoretically it would but… lots to test there.

    • forbze 7:16 am on October 14, 2016 Permalink | Log in to Reply

      I really want this! I’ve had to use hacky solutions in the past to repurpose content for mobile apps (I didn’t want to use web views / Mobile ui plugins).

      WordPress’s admin interface would make it really simple for me to give clients content control for their app content – rather than me having to build a custom editor UI on top of Parse / Firebase.

      I think oauth is the right solution for auth.

    • pwaring 9:23 am on October 14, 2016 Permalink | Log in to Reply

      I’m only in favour of this if the API can be disabled (ideally by default). I don’t need or want this functionality and it sounds like another remote attack vector.

      “we do not believe WordPress should make HTTPS a requirement for using the API”

      I *strongly* disagree with this. TLS uptake is increasing all the time and some browsers (e.g. Chrome) are starting to show stronger warnings for plain HTTP. Plus, if a popular application like WordPress requires HTTPS for its API, that will act as a significant nudge to hosting providers to provide HTTPS by default (a bit like moving from PHP 4 to 5).

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

        It’s super easy to disable the REST API via the `rest_enabled` filter (just return false), and there’s already a plugin for it. 🙂

        • pwaring 8:10 am on October 15, 2016 Permalink | Log in to Reply

          Whilst I’m capable of changing the code to add a filter, I don’t think that counts as ‘super easy’. It really should be a tick box somewhere in the admin settings.

          Installing a plugin to disable optional behaviour in core also seems unnecessarily complicated, plus it introduces another dependency and there’s no guarantee that the plugin author will keep it up to date.

          • Dave McHale 1:59 pm on October 18, 2016 Permalink | Log in to Reply

            I understand your concern, pwaring, but we already don’t have the ability to disable XML-RPC in core (ever since they enabled it by default in 3.5) – and since the REST API is “the same but different” I believe that’s why the new feature is following the same model. “Decisions, not options” and all that 🙂

            It’s also why I’m the author of the plugin Ryan linked to above. I think the REST API is great, and can’t wait to start using it myself *and* also see what other people build with it. But it’s not going to be for everyone, and I thought that people may want the easy ability to turn it off if they had a reason to.

            Since the plugin uses the root-level filters provided by the REST API there should very, VERY little need for actual plugin updates moving forward into the future (though I do keep an eye on the project, in case an update is needed). The only time I’ve needed to make a real functional change was when the filters themselves changed from version 1.x to 2.x of the API, before it was even merged into core. New features like the content endpoints won’t change the use of the plugin, because the REST API is still entirely disabled if you’re using the filters.

  • Nick Halsey 1:27 am on October 3, 2016 Permalink |
    Tags: ,   

    Customize Update 2016-10-02 

    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.

    Weekly Customize Meeting Summary

    On Monday we held our weekly 4.7 customize component meeting in #core-customize on Slack [logs]. Participants: @celloexpressions, @voldemortensen, @westonruter, @karmatosed, @folletto, @aaroncampbell. This summary also contains a few notes on action since the meeting.

    4.7 Projects

    • Customize changesets (transactions) – #30937 – @westonruter
      • @westonruter has completed an initial patch, merging previous work with major updates
      • Transactions are now known as “changesets”, with a customize_changeset post type and customize_changeset_uuid query param.
      • @aaroncampbell is interested in helping here.
      • Please apply the patch from the GitHub pull request and test for any regressions and that it fixes the myriad of issues that it is supposed to fix: grunt patch:https://github.com/xwp/wordpress-develop/pull/161
      • Latest patch improves theme preview experience so that pending changes made during a theme preview aren’t lost when switching to another theme (see #36485).
    • Create pages within live preview during site setup – #37914#37915, #37916, #38002, #38013, #38164 – @celloexpressions
      • #38164 has been created for creating pages from the static front page section. This functionality can be extracted from the customize posts plugin, but we need design ideas here.
      • We still need UX feedback on providing a path to edit newly-created pages, #38002.
      • @westonruter punted #37916 to a future release.
    • A new experience for themes in the customizer – #37661 –@celloexpressions
      • There was a special meeting to iterate on the design approach, and @folletto and @karmatosed agreed on a new design that was implemented in a revised patch at the end of the week.
      • A feature proposal is ready to be published on make/core pending final review.
      • The revised mobile flow was posted in a visual record on make/flow.
      • The deadline for feedback from other teams is October 12th, leaving a week for final code review and commit.
    • Code-editing gateways, via CSS – #35395 – @johnregan3
      • This was discussed at length during the core dev chat. The consensus was that the feature is appropriate for core as proposed (pending approval of the formal proposal).
      • For security, because there is limited-to-no ability to actually sanitize CSS, a new meta capability, unfiltered_css, will be introduced. By default, this will map to unfiltered_html, but plugins can change this as needed, for example on multisite, where site admins don’t have unfiltered_html and custom CSS is particularly useful.
      • Neither CSSTidy nor CodeMirror will be used for now, as CSSTidy doesn’t actually provide CSS sanitization, and CodeMirror is a nice-to-have for syntax highlighting. There will be some primitive validation that provides user feedback for common syntax errors.
      • @folletto has volunteered to assist with the design/UX aspects here, taking inspiration from the similar feature on WordPress.com.
      • We’re schedule to post a feature proposal next week, and need to complete an updated patch soon to make 4.7.
    • Customizer browser history#28536 – @westonruter
      • Parts of this might be blocked by changesets (transactions), which is higher priority for now.
      • If it’s okay with @helen, we may want to pursue this in the week before beta, after the major feature deadline, since it’s a smaller feature.
      • During customizer themes user testing, this came up as expected behavior.
    • Improving sliding panels UI – #34391, #34343, #29158 – @delawski
      • An initial commit is in trunk, dev note published, and only a few minor bugs have come up so far.
      • #34343 is now in progress. @folletto pointed out that we might want to do #35186 instead, or in addition at some point.
      • #29158 needs design ideas for the back arrows and close button focus styles, with the possibility of eliminating the autofocusing of (pending accessibility feedback).
    • Twenty Seventeen
      • Tracking a couple of possible customizer-heavy features.

    Additional Tickets Needing Attention

    • Customizer notifications – #35210 – needs UX feedback and a patch
      • @westonruter will work on this after changesets (transactions) unless anyone else is willing to work on turning the latest proposal into a patch.
      • This ticket is holding up some of the other tickets on the 4.7 milestone, such as #22037 and #29932, as well as aspects of changesets (transactions).

    Ticket Scrub

    • #21627: Filter for custom-background CSS selector
      • Needs unit tests, looks like @peterwilsoncc is the best person to own this.
    • #30738: JS content templates for base WP_Customize_Control
      • Not critical for 4.7, but there is code in customize posts that could be adapted for this.
    • #33085: Customizer: controls description inside labels are not real labels nor descriptions
      • This is fixed with the code for #30738.
    • #37269: Introduce removed event for wp.customize.Values collection
      • Punted pending a (good-first) patch.
    • #36582: Export main query from Customizer preview
      • Punted, as it can be implemented in plugins such as customize posts for now.
    • #22857: ‘Header Image’ state isn’t removed from images previously used as header image
      • This may be more appropriate under the media component based on the direction it’s taking.
    • #38080: Focusing a customizer control from the preview should show the controls on mobile
      • Patch should be too difficults, this is a follow up to another change in 4.7, although there is no UI exposed for this functionality on mobile currently.

    Recent Customize Commits

    Here are the customize-related commits for the past week:

    • [38648]: Customize: Re-architect and harden panel/section UI logic.
    • [38649]: Customize: Opt to disable IE8 support via conditional comments instead of unreliable feature detection.
    • [38668]: Customize: Fix focusing on controls for widgets and nav menu items after [38648].

    Big thanks to those who contributed to patches committed this week: @westonruter, @delawski, @celloexpressions, @ryankienstra.

    We’re always looking for more contributors; check out the open customize tickets and swing by #core-customize in Slack to get involved. Fun fact: we’re 7 commits away from the 1000th commit that references customize.

    Agenda for 2016-10-03 Meeting

    Our next regularly-scheduled meeting is Monday, October 3rd, 17:00 UTC. Agenda:

    4.7 Projects

    Additional Tickets Needing Attention

    • Customizer notifications – #35210 – needs UX feedback and a patch
    • Customizer UI Contrast/Focus Styles – #29158 – needs UI ideas for focus styles on back buttons

    Ticket Scrub

    • 4.7 Customize non-bugs without owners. We’ll assign these all to an owner or punt to a future release. Beta 1 is three weeks away.
    • We’ll pick a different query to triage each week. For example, bugs awaiting review (need verification).

    We’ll see you next week!

     
  • Aaron Jorbin 6:09 am on September 27, 2016 Permalink |
    Tags: ,   

    Bug Scrubs This Week 

    There are a few upcoming bug scrubs in addition to the regular component ones that you should plan on attending. Both of these scrubs will be taking place in the #core slack room.

    Additionally, thanks to @desrosj for running a 4.7 focused scrub on Monday.

    Want to run a bug scrub? Learn about running your own.

     
    • Aaron D. Campbell 5:57 pm on September 27, 2016 Permalink | Log in to Reply

      Unfortunately, something has come up and I had to reschedule my bug scrub. I updated the time in the post. Sorry to anyone this is less convenient for.

  • Jeff Paul 8:06 pm on September 22, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: September 21 (4.7 week 5) 

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

    Reminders

    • Schedule: As of this meeting, we are 4 weeks from the final chance to merge in major features. This includes Twenty Seventeen.

    Bug Scrubs

    Components & Features

    • Twenty Seventeen (@davidakennedy, @melchoyce)
      • Announcement post, latest update
      • Maintainers are out travelling today, but #core-themes is active and they will be holding a meeting on Friday at 18:00 UTC
    • REST API (@krogsgard, @kadamwhite )
      • Latest update
      • API discussion is at 7 am Pacific on Mondays
      • Settings endpoints and meta support both have first-passes on them, which need internal review and some more testing before we ship
      • We have a path forward for passworded posts (password in the query string, eww, but only viable option), there really isn’t a way we can see to avoid sending them as a query param
      • Meeting tomorrow in #core-restapi at 21:00 UTC to go through open issues around non-trivial, conceptual issues in WordPress. REST API team will prepare summary of issues for component maintainers and/or lead devs to review, question, and help guide discussion towards consensus.
    • Media (@mikeschroder, @joemcgill)
      • Latest update
      • Moving our weekly meetings up to Fridays at 17:00 UTC starting this week
      • Unexpected change to media title behavior in WP 4.6.1 (#37989) – The main issue here was resolved, but there seems to still be some odd behavior affecting words being chopped off filenames with international characters. Could use extra eyes from anyone (along with @sergey) more versed in i18n. Regression on the attachment titles that we generate on upload all became URL encoded instead of reading like a normal title.
      • Media search doesn’t include file name (#22744) – Committed earlier this week. Please report any issues that come as a result.
      • Next step in improving the organization of the media library is to assess both the infrastructure and UI improvements that need to be made here. Prefer to include #design early in this process, rather than asking for UI feedback on development driven decisions, hope to be part of the #design chat agenda tomorrow
    • Customize (@westonruter, @celloexpressions)
      • Latest update
      • In this week’s meeting we developed a schedule for publishing make/core feature proposals/dev notes for the remaining primary 4.7 customize projects, working backward from anticipated time to commit after the proposal and current readiness:
        • Week of 9/19: Improving sliding panels UI (34391, @delawski)
        • Week of 9/26: A new experience for themes in the customizer (37661, @celloexpressions). Please review soon for any requested changes in direction or design.
          • Summary: The existing themes section in the customizer is replaced with a full-screen theme browser and installer… The UI is nearly identical to wp-admin/theme-install.php… The .org-based theme-install previewer is not accessible here because it is likely to cause confusion with its customizer-like interface and the resulting need to switch contexts back and forth… An overarching goal is to avoid switching in and out of the admin/frontend/customize contexts during theme installation and previewing, instead staying in the hybrid customizer context that provides a combination of frontend plus controls… On the technical side, this heavily leverages JS-templated customizer controls and scales nicely to hundreds of themes.
          • Visual:
          • Please comment on the ticket with your feedback as soon as possible, preferably with specific concerns/ideas and reasons.
          • @celloexpressions to check in with @karmatosed on user testing ahead of posting final feature proposal
        • Week of 9/26: Customize transactions (30937, @westonruter evaluating this week and might punt again)
        • Week of 10/3: Code-editing gateways, via CSS (35395, @johnregan3/@celloexpressions). Awaiting approval/feedback on the acceptability/ability to bundle the two proposed libraries in core, with feedback particularly needed from committers and anyone familiar with the Jetpack fork of CSSTidy.
        • Week of 10/10: Customizer browser history (28536, @westonruter)
    • I18n (@swissspidy)
      • User Admin Language (#29783) – almost ready, another review this week and will commit if no blocker pops up
      • Introduce a locale-switching function (#26511) – @ocean90 to do some benchmarking
      • Introduce some JavaScript i18n functions (#20491) – GlotPress side has a solid plugin for exporting translations as JSON files (assistance on testing would be helpful). Still tinkering with the WordPress side and would love to get some additional feedback there.
    • Editor (@azaozz, @iseulde)
      • No updates, but would love to figure out a way to get more user feedback that helps us set direction for the editor. Will look to add some Core questions to annual survey on WordPress.org. Otherwise will start with something in the beta tester plugin, biased audience but it’s one that exists, is more likely to opt-in, and will be more flexible.
    • HTTPS (@johnbillion)

    Open Floor

    • @pbearne on Add filters to wp_new_user_notification and wp_password_change_notification (#38068) – added a set of filters to allow us to override email messages send by the wp_new_user_notification and wp_password_change_notification functions. @johnbillion to review as it relates to work on notifications.
    • @danieliser checking for interest for core in a set of reusable templates, models & functionality for forms, tabs & modals
    • @ericlewis on Bulk actions: Reactivate bulk actions hook + add hander hook for all admin screens (#16031) – could use a review of the latest patch, looking to commit sometime in the next week
    • @dshanske still working through the Pings and Trackbacks component
     
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