Make WordPress Core

Updates from October, 2016 Toggle Comment Threads | Keyboard Shortcuts

  • 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?
  • Jeff Paul 3:59 am on October 20, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: October 12 (4.7 week 8) 

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


    Feature Proposals for 4.7

    • REST API: Content API (@kadamwhite)
      • REST API Team Update
      • Content API endpoints have been stable for some time and now have the missing functionality established at the start of this development cycle
      • We pitched merging in the OAuth 1 server alongside those content endpoints, to simplify the process of authenticating from remote applications
      • The auth method in core right now is cookie/nonce-based, so it’s available to any code running within the same domain as the main WordPress install and leverages the existing login cookie
      • plugins and themes that utilize JS to enhance the editing experience within their admin UI have full read/write access, restricted to the capabilities of the authenticated user
      • External applications, e.g. a mobile app, desktop app or external server, would have read-only access
      • readers, aggregators, etc are possible without authentication, and more complex read-write apps can be written by installing one of the available authentication plugins, of which OAuth is but one
      • Reference for options and when/how to use
      • 90 contributors for the rest-api plugin
      • automated test coverage currently at 90.44%
      • 37 more open tickets
      • weekly meeting on Monday at 1400UTC in #core-restapi
    • Discovering and installing themes in the customizer (@celloexpressions)
      • Related Make/Design and Make/Flow posts, but best to post all feedback to the Make/Core feature proposal
      • Working through the accessibility feedback, but it’s a bit unclear what’s specific to this feature versus the customizer in general, and which issues are also present in the admin theme installer
      • Haven’t heard anything from polyglots, security (unlikely to have any issues), or docs
      • There is one known i18n concern where we’ll need a compromise until we have JS i18n in core
      • @celloexpressions to do a final iteration to pick up any remaining feedback on Thursday, then pass to @westonruter for the code review process
    • Custom CSS with live previews (@celloexpressions)
      • seems to have decent support as a feature, with the biggest question in the comments being how to store and output the CSS
      • CSS is output from the db via a style tag, use of `style` tag is key for targeting for `postMessage` live preview
      • Post-based storage allows for revisions built in (ensuring that there are hooks for a plugin that wants to write a file would alleviate many concerns)
      • CSS is theme-specific in the proposal for this, with a post object for each theme that has CSS
      • Scheduling a meeting to go through these concerns and make a decision, coordination to occur in #core-customize
    • Customize Changesets (née Transactions) (@westonruter)
      • Technical Post (audience is developers who have extended the customizer significantly, as there may be impacts to any heavy customizer integrations since changesets touches some very low-level stuff in the customizer)
      • Users will be able to bookmark a customizer session since the changeset UUID will be part of the URL
      • Theme switches will no longer result in changes being lost (no more AYS dialog)
      • a few other open questions and issues that have been noted


  • Joe McGill 9:36 pm on October 19, 2016 Permalink |
    Tags: ,   

    Media Weekly Update (Oct 14) 

    This post serves to jump-start discussion before the weekly check in, which takes place in #core-media on Slack. The next meeting is Friday, October 21 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 14 at 17:00 UTC. You can read the entire chat log in the #core-media channel on Slack.

    Attendees: @mikeschroder, @karmatosed@adamsilverstein@paaljoachim, @mapk, @flixos90, and @azaozz.

    • Media organization improvements:
      • Last week, we chatted about starting up design for Media organization improvements. @paaljoachim and @flixos90 started sketching flows in GitHub.
      • @karmatosed mentioned focussing on documenting the current flows this week.
    • Add new core media widget (#32417) – No progress was made this week and it’s now too late for 4.7, but work should continue so it’s ready for a future release.
    • Rotate Full Size Images on Upload (#14459) – @mikeschroder planned to do additional profiling re: complete resize+rotate times for upload vs editing.
    • Better PDF Upload Management (#31050) – @mikeschroder is putting more attention on trying to get this in this release after chatting with @helen.
    • Drag/Drop Ordering of Media Does Not Work in Chrome on touch enabled devices (#31652) – @adamsilverstein noted that the patch to enable sortable on touch devices was ready to commit, which was handled in [38793] this week. Additional discussion about reducing reliance on `wp_is_mobile()` is happening on #33704.
    • Accents in attachment filenames should be sanitized (#22363) – @gitlost has been working on updates for this ticket, which is now closely related to fixing #24661 (`remove_accents()` is not removing combining accents”).
    • Usage of `image_size_names_choose` breaks JS attachment model attributes (#34981)@azaozz suggests using srcset in the media library to make sure full size images aren’t used if a smaller image is available (as described in the ticket description).
    • Responsive images (srcset) can include images larger than the full size (#36477) – The latest patch, which utilized `Imagick::getImageColors` adds a significant performance concerns. @mikeschroder punted this out of the current milestone for 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-media channel.

  • David A. Kennedy 9:56 pm on October 18, 2016 Permalink |
    Tags: , ,   

    Twenty Seventeen: Merge Proposal for 4.7 

    A note from @helen: Before we get into the proposal itself, I’d like to officially introduce its author, @davidakennedy, as a committer for bundled themes. We really should have done this ages ago, but now he’ll get to make a big splash with Twenty Seventeen. Congrats, David! 🎉


    The team behind Twenty Seventeen has reached that point that we’re ready to propose Twenty Seventeen as the new default theme for WordPress in 4.7. It’s an ambitious theme that focuses on a creative home page and an easy site setup experience for users.

    Like last year, with Twenty Sixteen, the development process happened on GitHub. The theme will be merged into WordPress from the beta period on, and development will move to Trac. Some remaining tickets will move over to Trac at that time.

    Features of Twenty Seventeen

    Created with the feedback on previous default themes in mind, and the desire to reach a new audience, Twenty Seventeen was designed for business websites. It offers:

    • multiple sections on the front page, selected in the Customizer.
    • a striking asymmetrical grid.
    • custom color schemes, built on top of a monochromatic foundation, and adjustable via a hue picker.
    • different headline placement for pages, changeable in the Customizer, via theme options.
    • a great experience in many languages, thanks to language-specific font stacks.
    • SVG icons (a first for a default theme).
    • support for custom logo, custom header image and many post formats.
    • the use of new functions in Core for making child theming easier.


    As usual, a default theme couldn’t happen without the community. This year, Twenty Seventeen has benefited from 57 amazing contributors so far (up from 38 at this point last year). They have helped with:

    • triaging issues.
    • providing code reviews.
    • testing and recommending language specific font stacks.
    • improving the theme’s accessibility.
    • browser and device testing.
    • numerous bug fixes, code tidying and countless improvements.

    Testing, Feedback and Next Steps

    While contributors have tested Twenty Seventeen on various devices and browsers throughout the development process, edge cases still exist. Please test Twenty Seventeen in as many different environments as you can.

    Until the merge deadline, contributors to Twenty Seventeen will work on the Core Merge milestone in GitHub, knocking out as many issues as possible.

    A big thank you to everyone that has helped make Twenty Seventeen come to life.

    • hiddenpearls 10:28 pm on October 18, 2016 Permalink | Log in to Reply

      is very happy to take part in making this awesome theme ready for such a big audience.
      Congrats Theminator @davidakennedy

    • Mark Root-Wiley 11:13 pm on October 18, 2016 Permalink | Log in to Reply

      This is very exciting! Is there a public live beta version of this site available for easy front-end testing (especially on mobile devices?)

    • Tara 12:39 am on October 19, 2016 Permalink | Log in to Reply

      How about creating the next theme designed ONLY for blogging websites (NOT business)!

      • Aaron Jorbin 3:22 pm on October 19, 2016 Permalink | Log in to Reply

        There are a number of default themes that have blogging as a main goal. Twenty Fifteen and Twenty Thirteen are two that I really like.

      • Knut Sparhell 5:07 pm on October 19, 2016 Permalink | Log in to Reply

        Most of the Twenty* themes are for excellent for blogging. Twenty Seventeen is the first one I personally see as a not-so-good-for-simple-blogging Twenty-theme. I would recommend both Twentu Fifteen and Sixteen as a simple, light-weight and modern themes for blogging. Twenty Ten and Eleven are technically a bit old, and old fashioned today, so forget them, if not for “retro” look.

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

  • Nick Halsey 5:36 pm on October 11, 2016 Permalink |
    Tags: , , , ,   

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

    When people ask “why WordPress?”, some of the most common answers center around flexibility for users of all kinds, whether they’re building their sites primarily through code or UI. Let’s take the story of a user who does a little of both – we’ll call her Becky.

    Becky is a pretty savvy user. She knows that you’re supposed to make child themes instead of hacking on a theme directly, because updates can wipe out your changes. She found that out the hard way when she first started using WordPress – she hardly knew what CSS or PHP were, but she knew there was a theme editor in the admin and that she could make tweaks to colors or remove the author byline pretty easily without having to figure out this FTP stuff. Later on, most colors could be changed with the customizer so having a child theme just to remove an author byline seemed like overkill, but it was certainly better than having it reappear every time her site updated, especially with auto updates turned on.

    After a couple years with the same theme on her personal site, Becky felt it was time to change things up. She was pleasantly surprised to find some new features that made getting a theme set up a lot easier, especially when live previewing them. Still, though, that pesky author byline remained, and since her last child theme copied a template to get rid of the byline, she would have to set up a whole new one to do it again. Then Becky found an “Edit CSS” option and realized she could hide things using CSS without having to go through the entire child theme process. Now, it turns out that those CSS tweaks didn’t come with live previewing, and that functionality was provided by a certain plugin, but Becky got what she needed to get done a lot faster than she would have otherwise, and ended up with the site she wanted.

    This isn’t one specific story, but it is a combination of user stories many have heard, witnessed, or even personally experienced. You could replace Becky with @helen and it would be 100% accurate. The theme editor is a dangerous but useful entry point to more deeply customizing your site – rather than outright removing it and cutting off that introduction not just to WordPress code but to the concept of web development at large, why not provide a far safer and more user-friendly alternative? This post will explain why custom CSS with live previewing is valuable for WordPress and propose an implementation for inclusion in 4.7.

    Proposed solution: Custom CSS with live preview

    When bridging the gap between advanced user and beginning developer, desired changes are typically visual tweaks, such as changing a font size or hiding something, that are theme-specific. These sorts of changes should not require that users take risks editing live files that might white screen their sites or jump immediately into developer-facing tasks such as using FTP. Therefore, the scope of this feature has been defined as a custom CSS editor that leverages the customizer for a user-friendly live preview experience. This live preview allows for users to try various tweaks to a theme before saving and setting their changes live.

    There are hundreds of thousands (if not millions) of users making use of custom CSS plugins or other themes/plugins that have custom CSS capabilities, and the frequent suggestion of CSS fixes in support forums justify a core need for this functionality. When plugins and themes interact in unexpected ways, CSS snippets are often an efficient solution to fixing the particular problem on particular sites.

    The CSS editor takes inspiration from the many plugins offering similar solutions, but with an updated approach that offers instant live previewing in the customizer. The proposal for 4.7 looks like this:


    Notably, previewing CSS in the customizer allows the site to be navigated and previewed on different sized devices by leveraging existing core features, allowing users to visualize the impact of their changes across their site. Error messages are shown for common syntax mistakes to help users ensure that their CSS is formatted properly before saving.

    In future releases, the interface can be iterated on to further improve usability. The long-term design vision provides functionality such as revisions, syntax highlighting, and in-preview selector helpers, and can be implemented iteratively over time (click through for the full version):


    CSS would be stored in a custom post type (without admin UI), with a post stored for each theme. The editor would be used to supplement and override theme styles rather than editing them directly, as users have long been advised that directly editing files may lead to lost changes during updates. Instead, custom CSS safely stays available through updating and switching themes, starting fresh for each new theme. Projects such as customize changesets (#30937) and revisions for customizer settings (#31089) would bring future enhancements to this feature and further leverage the opportunities that come with storing the data in post objects.

    This is proposed as core functionality rather than remaining as plugin territory because it is designed as the first step toward a next generation of the existing theme editor in core, with a more refined feature set and safer, more user-oriented focus. The theme editor is not proposed to be removed at this time, though with the introduction of this feature it likely makes sense to introduce more friction before accessing the editor (#31779).


    To improve the user experience further, it is critical that a link to documentation and resources for learning CSS be included with useful help text. This could initially be the “CSS” codex page but would ideally live on a user or developer handbook of some sort eventually (perhaps the theme developer handbook?). This help text must be much more succinct than the help tab on the existing theme editor, conveying what CSS is, where to learn about specific rules, and explaining that it’s specific to each theme in only a few lines.

    Help is needed to create a resource for using custom CSS in WordPress, and locate it on WordPress.org. There are some related resources on make/training and WordPress.com has a good introductory page that they may be willing to contribute. Translated versions will eventually be needed as well. If anyone is interested in improving this aspect of the feature, which will presumably live on WordPress.org, please comment on this post.

    Security, Capabilities, and Multisite

    While the proposal includes basic validation, it is not possible to fully sanitize CSS. For this reason, a new meta capability will be introduced for managing css, unfiltered_css. By default, this is mapped to the unfiltered_html capability.

    Site administrators on multisite networks do not have the unfiltered_html capability by default. A plugin that remaps unfiltered_css to a different capability can be created to provide this access on multisite, where custom CSS is especially useful given the need to restrict the number of themes and child themes in the network. This is an area of potential evolution over time.

    Related Customize API Improvements

    There are a couple of customizer API improvements introduced as part of the implementation of custom CSS in the customizer. A new “Code Editor” customizer control (WP_Customize_Code_Editor_Control) is used for the CSS editor and can also be utilized in plugins and elsewhere in the future. It currently handles line numbers and basic code styling, and will eventually add enhancements such as syntax highlighting.

    Additionally, the WP_Customize_Section class has a new “description_hidden” parameter, which locates the section description in the section header behind the help icon toggle (“?”), functioning in the same manner as the customizer panel descriptions.


    @johnregan3 is leading development of this project, based on initial work by myself (@celloexpressions). @folletto is leading design efforts, with a focus on the long-term growth of the feature for maximum usability.

    The implementation takes inspiration from many of the numerous plugins and services that implement custom CSS, specifically including:

    • Simple Custom CSS (@johnregan3)
    • Modular Custom CSS (@celloexpressions)
    • WordPress.com Custom CSS in the design upgrade (Automattic)
    • Jetpack (Automattic)

    Testing, Feedback, and Next Steps

    Your help is needed in giving feedback on this proposal and testing the feature! To test, please apply the patch either via Trac or the PR (helpful reminder: grunt patch handles both) and try some custom CSS in the customizer using various themes.

    Pending approval of this proposal, the next steps will be to finalize and commit the patch on #35395. Code review is ongoing in the GitHub PR linked on the ticket. Feedback on the feature in general and the specific implementation is encouraged via the comments on this post, with any more technical implementation discussion happening on the Trac ticket or GitHub PR.

    • FolioVision 5:46 pm on October 11, 2016 Permalink | Log in to Reply

      I appreciate all the thought you’ve put into this Nick. A simpler way to customise a child theme is a bold and welcome proposal.

      Still I’d rather see a tool for CSS customisation (a browser extension or an app) than add all this code to core WordPress. This much javascript and CSS in a single webpage is a house of cards and equally fragile.

      A simple way to save in custom CSS after using an external tool would be useful.

      PS. It pains me every day to see complex caching solutions and top heavy security plugins. Core issues (caching and security) would be a better place to start with heavy duty new features than adding more fragility and complexity to a an already fragile and complex system.

      • Helen Hou-Sandi 7:07 pm on October 11, 2016 Permalink | Log in to Reply

        Volunteer effort is not symmetrical – people work on things they have expertise in and passion for. “X is suffering because you are working on Y” is a fallacy.

      • Nick Halsey 11:30 pm on October 11, 2016 Permalink | Log in to Reply

        This feature doesn’t introduce a significant amount of code and in fact, most of the core code is PHP, not JS or CSS. Because it uses the customizer API, which is a framework for live-previewing changes to sites, the implementation of the particular feature is not complex. The proposed solution will work well in a workflow where you write CSS elsewhere and paste it in as well.

    • Jon Brown 6:33 pm on October 11, 2016 Permalink | Log in to Reply

      The general outline of this proposal sounds good to me and I’d certainly love to see all the custom css plugins die a fiery death. The primary reason for that though is that I’ve seen them all hurt performance with slow queries on each page load. My mantra has long been that CSS doesn’t belong in the database.

      I suspect storing the data in a CPT (instead of _options) is going to be more performant, but I’m still very considered about it based on past experience. Wouldn’t be possible to store it as a static file while still having a similar UI to this proposal for editing that file’s content?

      Either way, is there a way it could be tied into the enqueuing system so it could be easily manipulated by themes and picked up by plugins that concatenate enqueued stylesheets?

    • Luke Cavanagh 8:11 pm on October 11, 2016 Permalink | Log in to Reply

      Not sure what the performance will be like for rendering out CSS from postmeta.

      • Nick Halsey 11:27 pm on October 11, 2016 Permalink | Log in to Reply

        Noting that it’ll use post objects directly, not postmeta. This is how Jetpack and WordPress.com do it, so I don’t believe there aren’t major performance issues with that, although I can’t speak to specifics there.

    • Tom J Nowell 9:39 pm on October 11, 2016 Permalink | Log in to Reply

      I’d just like to note that loading this post on a mobile is painful, I’m sure we can cut down a fullscreen 6MB GIF to perhaps a 640×480 view of a reduced size screen a quarter of the length, especially given that when roaming that GIF could cost a lot of money to load. I know my former carrier charges £6 per MB in the US and Canada, that’s £36 or $43 USD

    • vherring 10:09 pm on October 11, 2016 Permalink | Log in to Reply

      The feed back here is from developers the real benefactors of this kind of change is not developers, it in some ways threatens developers because if we get sophisticated in this feature a significant proportion peoples frustration with themes would go away. Like others I do feel storing in a database is too heavy for the feature at present and maintaining a method similar to existing mechanisms provides the flexibility in using the feature in the short term. Perhaps migrating to a different permanent storage method in the future as we become familiar with it and it is functionality is extended.

    • simonrcodrington 10:54 pm on October 11, 2016 Permalink | Log in to Reply

      Pretty excited by this. I think it’s a great idea to offer a more core centric solution to styles and the customizer is the perfect place for it. Having the ability to control styling in an easy to preview way will really help some of our more tech savvy users without giving me the stress of having to let them loose editing the child them.

      In addition to helping site admins, I can see this being really useful as it gives me the ability to quickly preview style charges without affecting live sites.

    • Ahmad Awais 12:17 am on October 12, 2016 Permalink | Log in to Reply

      Good one, Nick! +1 for Aditional CSS. I am just not so sure about the versioning part of it. While it is going to be an incredibly important part of this addition, at the same time it might confuse a beginner. What are your thoughts about that?

      • Nick Halsey 2:24 am on October 12, 2016 Permalink | Log in to Reply

        Versioning/revisions isn’t part of the initial proposal for 4.7. We’ll explore all of the considerations there in a future release, and your input/any ideas you have for improving the usability would be appreciated there.

    • Ipstenu (Mika Epstein) 1:18 am on October 12, 2016 Permalink | Log in to Reply

      CSS would be stored in a custom post type (without admin UI), with a post stored for each theme.

      One small thought… Sometimes users make changes that are not theme-specific. Like your example, Betty/Helen wanting to hide the author byline via CSS, if she changed from TwentyFifteen to the Magical Jumbotron theme, she should be able to grab the CSS from before. Otherwise she has to go back to her old theme and copy pasta.

      Right now, JetPack lets you restore by clicking from your older, saved revisions so stealing that would help 🙂

      • Nick Halsey 2:22 am on October 12, 2016 Permalink | Log in to Reply

        I explored this with the Modular Custom CSS plugin, which stores CSS intended for themes and plugins separately. In practice, I found that the vast majority of tweaks were specific to a particular theme since so much of the way the markup is structured depends on the theme. For the byline example, it would work on other themes using similar markup, but it’s hard to say how consistent themes would be there.

        That being said, there is definitely room for core to improve the cross-theme experience here over time.

        • Ipstenu (Mika Epstein) 5:31 pm on October 13, 2016 Permalink | Log in to Reply

          Yes but… consider that I may change my theme and keep my plugins. This may be intended to be theme specific, but (part of) the reason Jetpack CSS is so popular is that it’s outside my theme, so I can keep plugin css tweaks between themes 🙂

          • Knut Sparhell 1:33 am on October 14, 2016 Permalink | Log in to Reply

            Does Jetpack really keep custom CSS between themes? It says in a notice at the top of the editor that the CSS will be reset when changing theme.

            • Ipstenu (Mika Epstein) 11:54 pm on October 14, 2016 Permalink

              It does and it doesn’t. What it does is lets me click on the link to see the older versions, with the name of the theme. So I can go back and grab the old one. I’m not saying KEEP them as the active CSS, I’m saying make it easy for me to go back, get my old css, and restore it 🙂

              IIRC it’s via post revisions, but I could be wrong (and I’m currently not using it because I needed SVG stuff they don’t support).

    • David C 1:34 am on October 12, 2016 Permalink | Log in to Reply

      Fantastic idea and proof of concept, Nick! We get customers all the time asking how to “tweak” certain css elements without having to build a child theme. This feature would certainly fill that gap. BTW, nice animated gifs. What software did you use to create them?

    • James Collins 2:20 am on October 12, 2016 Permalink | Log in to Reply

      This is a great idea.

      We always need to write custom css rules when creating WordPress sites for clients. We’ve used our own Custom CSS plugin for many years, which helps us avoid the need to create a child theme just to override some CSS.

      We also have clients who want to tweak CSS rules themselves, so they appreciate being able to do so via the WordPress admin.

      Having this operate via the customizer with live preview would be a real time saver!

      In our custom CSS plugin, we save the CSS rules to the database, and also out to a .css file in wp-content/uploads/ , and reference that inside . So when the website is viewed, the .css file is loaded via a CSS link rather than being embedded directly in each and every page.

      I would have thought serving the static .css file from the uploads directory would be more performant than embedding the CSS in each and every page?

      We also use CodeMirror for the actual textarea/editor interface, which works well.

    • Kishores 5:14 am on October 12, 2016 Permalink | Log in to Reply

      +1 for Aditional CSS.

    • Hapiuc Robert 6:34 am on October 12, 2016 Permalink | Log in to Reply

      Really great idea, for small use of the feature storing the data in a CPT doesn’t sound so bad, but we all know how users act and things can escalade quickly.

      How the CSS will be embedded on the page?

    • Primoz Cigler 6:36 am on October 12, 2016 Permalink | Log in to Reply

      Excellent proposal Nick, I can see lots of positive feedback here and I can only add to it.

      One question: will there be another blogpost here in Make Core going more in details about implementation? With the introduction of Additional CSS in 4.7 we will be deprecating our custom CSS field from customizer and we want do to do in a safely manner by automatically migrating the existing custom CSS for our users.

      > How the CSS will be embedded on the page?


      • Nick Halsey 2:04 pm on October 12, 2016 Permalink | Log in to Reply

        That’s a good point, hopefully @johnregan3 can put together some boilerplate functionality for importing existing CSS data into the new core post type, and we can write a dev note for that during beta.

    • Hugo Ashmore 8:57 am on October 12, 2016 Permalink | Log in to Reply

      While I appreciate the sentiments here in the proposal I also have great worries when WP attempts to pursue the user focussed simplicity path as we are in danger of going too far and of encouraging bad code and broken sites and where those users tweaking wouldn’t especially realise something was amiss.

      CSS is not – as often it feels like it’s suggested – a simple language, yes it’s a simple declarative syntax but in reality a powerful tool for preparing the presentation of rendered code to devices, not simply a tool to make a link ‘green’, the cascade, the inheritance are hard aspects to grasp and the flow of rulesets important. CSS was never intended, really, to be worked as many separate disparate episodes provided by themes, child themes, plugins, core etc.. In many cases this results in sites that are problematic to say the least in maintaining with clashes in code that are largely unresolvable.

      I understand the issue though and that we are talking from the perspective of non coder/developers but from a developers perspective we have to understand that many – if from a Standards focussed background – would have a deep concern with the level of participation a client might have in that core site code, personally if a client came to me and expressed the desire for a major site build but also that they would tweak and play with the code as they saw fit I would decline the work as impossible or hard to maintain any sort of standard. implementing a proposal like this may worry developers and further isolate them from the WP sphere at worst (yes the functionality doesn’t have to exist ).

      The process for adding this custom CSS needs thought, embedding as often seen by plugins using wp_head is not a great idea filling the head element of a document isn’t good practise, never been so , embedded code isn’t cached as a linked file is, the page is weighed down, altogether not a good experience especially when perhaps many plugins drop their styles in. So preferably a method that somehow allows the writing of a file to be enqueued would be better although possibly with issues implementing.

      Regardless I do appreciate the intent in this proposal and the nature of WP is to be user focussed and friendly, with ease of use but we just need to think carefully how we implement improvements such as this.

      • Joy 2:59 pm on October 12, 2016 Permalink | Log in to Reply

        I agree that if you don’t really know CSS, you shouldn’t be using a feature like this. I think it could make it more difficult for support people to diagnose problems or clone a design.

        I already proposed the idea of treating the new CPT like an attachment, in that it would hold the file information of where the CSS is stored, and it would be embedded using a link tag, which means anything other than CSS in the file would be ignored.

        The problem I see with the way the interface is proposed is that the live preview should only come after the CSS is entered. Before that, there needs to be a way to toggle to see the source of the page so the proper selectors can be found. Basically, you need to have the browser’s Developer Tools there so you can see the existing selectors and the cascade and the autocomplete, etc.

      • FolioVision 4:13 pm on October 20, 2016 Permalink | Log in to Reply

        Thank you for articulating our shared concerns so well Hugo. A hidden custom CSS feature is a troubleshooting nightmare conceived to destroy developers lives. End users in the end won’t like it either when neither they nor their developer can make their site run right again without starting from scratch.

        The situation isn’t quite as bad as I’ve described above for very well organised developers (I imagine you fall into this class too Hugo). We’ll just add yet another nuisancy check to our checklists of what to do before we start work on a site.

        For our internal clients, we’ll be disabling the Customizer completely I believe as our clients don’t want a tool which could break their sites available to any site admin. It’s funny that developers all have to spend as much time fighting WordPress core these days as working with it.

        What we really need is rock solid caching in core and a built-in security solution and not more toys to break and slow websites. A CSS tweaker or theme builder should be standalone software or a web-based server. I don’t understand why we aren’t all working on such a tool together with Nick. Building a theme building into the core of your CMS is a very, very bad idea for performance, security and maintenance reasons.

        Complexity killed the cat.

    • laur3ntv 12:19 pm on October 12, 2016 Permalink | Log in to Reply

      What I generally do is that I try all the CSS changes in the Chrome Inspector and they apply them in a custom CSS plugin or file. It’s not user friendly and I have to go back and forth between the two.
      So I really love this feature proposal and give a huge upvote 🙂
      Thank you Nick!

    • Timothy Jacobs 7:08 pm on October 12, 2016 Permalink | Log in to Reply

      This is great! Fantastic work. Excited to see where this goes over the next few releases.

    • Weston Ruter 8:58 pm on October 12, 2016 Permalink | Log in to Reply

      Since the only feature provided in the WP_Customize_Code_Editor_Control is line numbers, I think we should skip including this in favor of just using a regular textarea control. In the future when we actually have a code editing control powered by a library like CodeMirror, then the textarea control can be replaced.

    • Daniel Bachhuber 9:01 pm on October 12, 2016 Permalink | Log in to Reply

      Echoing my comments made in Slack, I’m -1 on this proposal for a couple of reasons:

      1. A lot of my (and others) post_type != 'revision' code is going to potentially break. There’s historical precedent that revisions are the only “hidden” post type.
      2. I’m not sold on adding more IDE features to WordPress (that we’ll eventually need to replicate in the REST API)

      I’m opinionated towards having WordPress make decisions as to which elements of the page are configurable and how they can be configured (e.g. header color or background image), over recreating an IDE within the WordPress admin.

      • Aaron Jorbin 2:48 am on October 13, 2016 Permalink | Log in to Reply

        Assuming revisions are the only post type with no UI is far from a best practice. `nav_menu_item` for instance is another non-public nonstandard UI post type already in core.

    • idealien 11:25 pm on October 12, 2016 Permalink | Log in to Reply

      Question: Would this respect the DISALLOW_FILE_EDIT config variable?

    • Aaron Jorbin 2:50 am on October 13, 2016 Permalink | Log in to Reply

      After playing with this, I wonder if it would make sense to add an “Import from Theme” selector of some sort. That might give you a leg up when you switch themes. Was this tested at all?

    • davetgreen 7:17 am on October 13, 2016 Permalink | Log in to Reply

      I’d like to see a couple of filters introduced so that developers can:

      • Hide the CSS editor completely.
      • Prevent the use of `!important` by removing all instances on save etc.
      • Pass in an array of banned properties.
      • Insert a custom notice/advisory directly above the editor.
    • justnorris 9:01 am on October 13, 2016 Permalink | Log in to Reply

      Why not keep this as a plugin ? Why add more bloat to the core? I don’t see the argument for killing CSS Plugins just because they’re popular.

      All plugins solve some problem that the core has. There are 300’000 people using bbPress, I don’t see WordPress becoming a forum software in it’s core any time soon.

      Regenerate thumbnails has 1m+ installs, maybe merge that into core too – people obviously need it and it helps people after they switch themes or thumbnail sizes.

      The list goes on – “Disable Comments”, “Google Analytics”, “Loco Translate”, etc.

      Plugins extend the core. That’s what they’re made for, that’s why WordPress is awesome – everyone can customize the software to their own liking.

      Features that aren’t useful to most users should not be added to the core.

      This is going to clutter the interface, it’s going to add bloat to the core. If it ain’t broke, don’t fix it

      I get it. Custom CSS is rad, I make themes too, I get people asking for CSS modifications too. That’s why you have plugins like Custom CSS. There is just no need for this to become core.

    • treykane 4:06 pm on October 13, 2016 Permalink | Log in to Reply

      I’m a few days late to this debate, but I see a fundamental problem here…

      I have conflicted feelings on this feature as I know I’ve had many clients in the past that wanted this ability, and plenty of good plugins have provided exactly already. But, it seems WordPress is starting to diverge down two different paths, which is a much deeper problem than this proposal.

      1.) WordPress has been going for some time in the direction of becoming a CMS that supports data in a REST API. I think this is great, it puts WordPress in a position to become the backend for web applications of all kinds. Its user friendly, gives content editors a familiar place to go and work on their content, while still providing the developer with the flexibility to do whatever they need to on the front end.

      2.) WordPress keeps adding features like this one, that allow the user to customize the front end, and empowers the user to do whatever they want to do on the site. While this isn’t bad and is in-fact GREAT for a consumer centric product, its in contention with my first point.

      TL;DR –
      It feels like WordPress is trying to be two different products at once and at some point this is going to become a serious problem, on one end or the other. It feels like this proposal just continues to push the potential for identity crisis another step further.

    • Ximbalo 4:52 pm on October 14, 2016 Permalink | Log in to Reply

      This is a welcome topic that I have often wondered “How long before WP adds this feature?”
      I can see quite clearly how this would be a valuable and helpful feature for “simple customization” requirements.

      As long as it does not imply a gradual “phasing out” of the continued ability for more advanced and experienced developers to still create child-themes as needed.

      In my projects at least 50% of all child-theme edits are specific to and focused on the PHP of the parent theme and not just the CSS.

      Here is my input on the topic:

      1. Must Remain: PHP File Overrides:
      As a professional developer, I almost always cannot properly complete a project, nor apply ideal code-and-content top-down flow optimizations, without resorting to PHP template overrides. Suffice it to say, rarely does any given theme’s built-in page header or body structure suffice for my client customization requirements. The built-in CSS editor feature sounds great… as long as it does not lead to my eventually not being able to create child-theme PHP page template & include file overrides.

      2. Unwanted: Long Streams of Embedded Inline CSS
      To me, one of the *very worst* and sloppy coding bad habits of WP Theme developers in recent years, is that of “dumping” custom CSS directly into the code-flow as inline CSS — rather than at least allowing for the custom CSS to be compartmentalized into a single “custom.css.php” file.

      I have seen some themes that include a checkbox for this option – and I always admire that. If it does not exist, I will add my own PHP to remove the hundreds or thousands of lines of inline CSS that get dumped into my would-be “clean and optimized code”.

      Thus, when this new feature is added to WordPress, it would be good to include an option for all custom CSS to be written into a PHP generated include file. (Understood and acknowledged is the idea that this option is not compatible with DISALLOW_FILE_EDIT or Security Plugins that turn off back-end file edits.)

      3. SUMMARY: As a professional developer…
      A) I would use and benefit from this feature in cases of small, simple edits to a relatively simple site.
      B) I would use this feature to make clearly accessible certain “global styles” that I actually WANTED my client to be able to edit on their own ( i.e. global use of font styles, colors, & such )
      C) But only if an option was available to encapsulate the cusotm CSS into a single file (avoid dumping reams of inline CSS)
      D) I would NOT use this feature when hundreds of lines of advanced custom CSS are required
      E) This feature should really not be confused with no longer actually needing child themes due to the requirement of being able to override PHP template files.

      Thank You,


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

      As mentioned here -> https://core.trac.wordpress.org/ticket/35395#comment:71, I still feel like this type of tool is more “developer-centric” as 99% of my clients would never use this nor would I expect them to however I do see value in power users using something like this to tweak and fix very minor css.

      Ultimately, yes I do want this…but in core? Not so sure about that. I want to be able to turn this off and leave no dependency on loading the actual css from the db on the front end. The db stored css should only be used for revisions and live editing in the customizer and I feel the front end should still reference actual files that can be post-processed, cached and even off-hosted such as a CDN.

      If we can figure out a way of writing logical files that WP automatically loads based on file naming structure, similar to how themes do this now with the php file naming conventions, we would be golden and no one can complain about bloat, extra db cost etc. But again, do we need IDE features like this built into the core or should we amend the core only to allow for bettering our IDE plugins we use for development?

      Maybe we should consider requiring a constant in wp-config to enable IDE development features of wordpress, like this, like the current theme/plugin editors?

    • Sebastian Pisula 7:45 am on October 21, 2016 Permalink | Log in to Reply

      Why CPT? Why not theme_mods?

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


    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


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


      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:


      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.


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


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

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

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