WordPress.org

Make WordPress Core

Welcome to the official blog of the core development team for the WordPress open source project.

Here, we make WordPress core. Follow our progress with general updates, status reports, and the occasional code debate.

We’d love for you to help out.

Looking to file a bug?

It’s easy to create a ticket on our bug tracker.

Want to contribute?

Get started quickly. We have some tickets marked as good first bugs for new contributors. There’s more on our reports page, like patches needing testing.

We also have a detailed handbook for contributors, complete with tutorials.

Weekly meetings

We use Slack for real-time communication. As contributors live all over the world, there are discussions happening at all hours of the day.

We have a project meeting every Wednesday at 20:00 UTC in the #core channel on Slack. (Find out more about Slack.)

You can find meeting agendas on this blog. You’re welcome to join us or listen in.

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Jeffrey Paul 5:37 am on January 10, 2017 Permalink |
    Tags: , , ,   

    Dev Chat Agenda for January 11 (4.7.1 week 5) 

    This is the agenda for the weekly dev meeting on January 11, 2017 at 15:00 CST:

    • Schedule reminder: 4.7.1 scheduled to launch at January 11, 2017 at 15:00 UTC
    • 2017 releases: 4.7.1 will NOT be last in the 4.7 branch, so it’s best to start on anything that needs to go in 4.7.2 immediately
    • General announcements: bring your bullhorn, step up on the soapbox, and shout for all to hear

    If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

     

  • Ryan McCue 4:03 am on January 10, 2017 Permalink |  

    API Chat Summary: January 9th (4.8 kickoff) 

    We’ve had an early kickoff meeting for the REST API for 4.8 (Slack archive) to establish some of the new workflows and structure for the team heading into 4.8.

    Development Process for 4.8

    • There are three big areas for the API moving forward: usage in core, usage in apps, and general expansion
    • Focus for 4.8 core development will be on usage in core
    • Other areas will continue development in Feature Projects where they need to, but won’t be the focus of the core API team
    • Feature Projects for the API:
      • Two additional requirements:
        1. Project must have a reviewer, who needs to be a core committer
        2. Project must have a design doc with a few specifics
      • Exactly what is required in the design doc will be laid out in the future, will include detailed merging plan
      • These changes based on our own experiences being a feature project
    • Project Organisation (including feature projects and core projects)
      • Overview and tracking of features will use Trello (mainly for our own internal usage)
      • Projects will have their own teams with a point-person to organise
      • Projects can have their own meetings, and will report their progress in the main API meeting
      • Our first core project is the Multisite API, @jnylen0 has been volunteered for point-person 😉

    4.8 Focus: Admin

    • Attacking the problem from multiple fronts: lots of JS work, backend/new endpoints also required
    • New endpoints
      • “Appearance” menu is largest area lacking API support
      • Will work with the Customiser team closely here, including work on Widgets and Menus
    • Frontend work
      • Press This is great candidate, and work is already underway in #38343
      • Large amount of work around List Tables required
      • Work here can start with Quick Edit and Quick Delete
      • These will act as smaller areas to help establish process, including dealing with backwards compatibility

    Documentation and Support

    As noted, we’re trying out some new things with API development for this cycle. Those may stick, or they may not, and we’ll be continuing to improve and refine the process as we go.

     

  • Jeremy Felt 8:04 pm on January 9, 2017 Permalink |
    Tags: , , ,   

    Improving the REST API users endpoint in multisite 

    One of the objectives for multisite is sorting how users are managed with the REST API. This was one of the agenda items for last week’s #core-multisite office hours and generated some good discussion. Here’s a wrap-up of the ideas and thoughts from that discussion.

    Chat log in #core-multisite

    Attendees: @iamfriendly, @johnjamesjacoby, @nerrad, @florian-tiar, @mikelking, @earnjam, @jeremyfelt

    Users in multisite exist globally and are shared among sites on one or more networks. Users are associated with sites in the user meta table with a wp_#_capabilities key.

    The current state of the wp-json/wp/v2/users endpoint for multisite is:

    • A POST request for a new global user to the main site creates the user and associates them with the main site only.
    • A POST request for a new global user to a sub site creates the user and associates them with the sub site only.
    • A POST request for an existing global user results in an error.
    • A PUT request for an existing global user to a sub site updates the user’s meta with a capability for that sub site.
    • A DELETE request on multisite is invalid and results in an error. See #38962.

    It is not possible to remove a user from an individual site or to delete the user from the network.

    Previous tickets: #38526, #39155, #38962, #39000

    The following are a few thoughts expressed separately from the above summary.

    • The right way to associate existing objects over the REST API is with a PUT request.
    • The right way to disassociate existing objects is with a PUT request.
    • Linked previous discussion – “Deleting an item should always delete an item“
    • We already have functions like remove_user_from_blog() and add_user_to_blog() available to us.
    • Does “add” invite or literally add? This can probably be included as data in the PUT request.
    • What happens if an API client is built for single site and then that site gets switched to multisite?
    • Handling bulk actions on an endpoint would be nice. (e.g. Add a user to multiple sites) No endpoint has implemented batch handling yet though.

    Initial tasks:

    • It should be possible to remove a user from a site with a PUT request to the wp-json/wp/v2/users/# endpoint.
    • It should be possible to delete a global user with a DELETE request to the wp-json/wp/v2/users/# endpoint once all sites have been disassociated.

    New tickets will be created soon for these tasks. Please leave any initial feedback in the comments on this post covering the assumptions and conclusions made above. There will be another round of discussion during tomorrow’s #core-multisite office hours at Tuesday 17:00 UTC.

    /cc @rmccue and @kadamwhite

     

    • James Nylen 8:12 pm on January 9, 2017 Permalink | Log in to Reply

      I am assuming that “`PUT` request” is being used as a shorthand to refer to any of `POST/PUT/PATCH` to an existing user. These should be treated equivalently via the `WP_REST_Server::EDITABLE` constant.

    • John James Jacoby 8:22 pm on January 9, 2017 Permalink | Log in to Reply

      👍

    • Darren Ethier (nerrad) 8:33 pm on January 9, 2017 Permalink | Log in to Reply

      One thing that may have been brought up elsewhere, but I don’t think was brought up in the meeting (likely because its something that will happen on further implementation) is whether the schema response for the users endpoint would change in a multisite environment vs single site. For instance, does the `user` resource in a multisite environment include the sites the user belongs to? Is that something that should be exposed? If so, then its something that would need to go into the schema as well.

      • John James Jacoby 12:11 am on January 10, 2017 Permalink | Log in to Reply

        You’re right that this is an implementation detail. My hunch is not as part of the default user response (which probably has higher value as something that doesn’t have too many variants) but it would be useful to have a dedicated endpoint to get the sites of a User – that way the response can more easily be setup behind its own capability check.

    • Brainy 12:30 am on January 10, 2017 Permalink | Log in to Reply

      I may miss something (the wp-api.org documentation doesn’t tell me at least), but I think it would be great if there would be a way to list users sites via rest api as well since the current way of looping get_blogs_of_users is very, very slow.

    • Knut Sparhell 1:55 am on January 10, 2017 Permalink | Log in to Reply

      I think there should be a network level (endpoint) where users of a multisite may be removed from all sites in a network, or actually deleted if only one network. Then a top (installation) level endpoint for actually deleting users in a multi-network. When a removed or deleted user is the only/last user of it’s primary site, then maybe also mark the site as deleted.

    • Ryan McCue 2:28 am on January 10, 2017 Permalink | Log in to Reply

      Definitely want to see better API support for multisite. To that effect, @jnylen0 has volunteered to be the multisite API coordinator, so you’ll have a permanent point of contact. Obviously, the rest of the team is also always around. 🙂

      • James Nylen 2:30 am on January 10, 2017 Permalink | Log in to Reply

        s/volunteered/been volunteered/ 😉

        I’m happy to help, though, and it makes a lot of sense for me to be involved with this: I’m also responsible for the WP REST API integration on WordPress.com, the largest multisite installation in the world.

  • Jeffrey Paul 5:40 pm on January 9, 2017 Permalink |
    Tags: , , ,   

    Dev Chat Summary: January 4th (4.7.1 week 4) 

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

    Schedule

    2017 Release Schedule

    • no update on the “new release schedule”, so for now it will be process as usual
     

  • Matt Mullenweg 5:32 pm on January 9, 2017 Permalink |
    Tags:   

    Aaron Campbell Leading Security 

    @aaroncampbell is now the new lead of security triage and resolution for the WordPress project, also known as the Security Czar. Many thanks to Nikolay Bachiyski for kicking this role off and getting a lot of the infrastructure we use in place. This is also a good time to thank the dozens of volunteers who participate in the security group, and the researchers and reporters who bring issues to our attention.

     

  • voldemortensen 10:37 pm on January 6, 2017 Permalink |
    Tags: , , , ,   

    4.7.1 Release Candidate 

    A Release Candidate for WordPress 4.7.1 is now available. This security and maintenance release fixes 62 issues reported against 4.7 and is scheduled for final release on Wednesday, January 11, 2017. Note this does not address a number of other issues, which are slated for a 4.7.2 release.

    Thus far WordPress 4.7 has been downloaded over 9 million times since its release on December 6, 2016. Please help us by testing this release candidate to ensure 4.7.1 fixes the reported issues and doesn’t introduce any new ones. As always, the entire WordPress project is grateful to security reporters for practicing responsible disclosure.

    PHPMailer Update

    Last month a security vulnerability (CVE 20016-10033) in the PHPMailer library was made public. WordPress uses this library as the basis for its email functionality. The Security Team has spent some time analysing this vulnerability, and how it applies to WordPress. This vulnerability does not appear to be directly exploitable in WordPress Core, or any major plugins in the plugin directory. The wp_mail() function, which WordPress Core and most plugins use for sending email, blocks this vulnerability from being exploited.

    All Changes

    Here’s a list of all closed tickets, sorted by component:

    Bootstrap/Load

    • #39132 – WP 4.7, object-cache.php breaks the site if APC is not enabled in php

    Build/Test Tools

    • #39327 – Database connection errors in unit tests on 4.7

    Bundled Theme

    • #39138 – wordpress 4.7 default theme does not get installed when upgrading
    • #39272 – Twenty Seventeen: Incorrect $content_width
    • #39302 – Twenty Seventeen: Featured image not displayed on single template
    • #39335 – Twenty Seventeen: customize-controls.js incorrectly assumes theme_options section is always present
    • #39109 – Twenty Seventeen: starter content array needs a filter
    • #39489 – Twenty Seventeen: Bump version and update changelog

    Charset

    • #37982 – 4.6.1 Breaks apostrophes in titles and utf-8 characters

    Comments

    • #39280 – comment permalink wrong in WordPress 4.7
    • #39380 – wp_update_comment can cause database error with new filter

    Customize

    • #39009 – Customizer: the preview UI language should be the user language
    • #39098 – Customize: Clicking on child elements of preview links fails to abort navigation to non-previewable links
    • #39100 – Customize: Edit shortcuts do not work if page hasn’t been saved and published
    • #39101 – Customize: edit shortcuts for custom menu widgets do not work
    • #39102 – Customize: Shift-click on placeholder nav menu items fails to focus on the nav menu item control
    • #39103 – Customize: menus aren’t deleted
    • #39104 – Customize: starter content home menu item needs to be a link, not a page
    • #39125 – Customize: Video Header YouTube field has issues when whitespace is inserted at beginning or end of URL
    • #39134 – Customize: custom CSS textarea is scrolled to top when pressing tab
    • #39145 – custom-background URL escaped
    • #39175 – Customizer assumes url is passed with replaceState and pushState
    • #39194 – Invalid parameters in Custom CSS and Changeset queries
    • #39198 – Customize: Apostrophes in custom CSS cause false positives for validation errors
    • #39227 – Changeset parameter not generated
    • #39259 – ‘custom_css_post_id’ theme mod of `-1` doesn’t prevent queries
    • #39270 – Use a higher priority on wp_head for inline custom CSS
    • #39349 – Customizer (mobile preview) site title extra padding
    • #39444 – Text Decoration Underline removes on hover in Customizer

    Editor

    • #39276 – Link Editor bug – target=”_blank” not removed
    • #39313 – Add New button not disappearing in Distraction-free Writing mode
    • #39368 – .page-template-default body class in editor doesn’t appear in initial post/page load.

    External Libraries

    • #37210 – Update PHPMailer to 5.2.21

    Feeds

    • #39066 – `fetch_feed()` changes REST API response `Content-Type`
    • #39141 – RSS feeds have incorrect lastBuildDate when using alternate languages

    General

    • #39148 – Correct concatenated dynamic hooks
    • #39433 – Update copyright year in license.txt

    HTTP API

    • #37839 – wp_remote_get sometimes mutilates the response body
    • #37991 – fsockopen logic bug
    • #37992 – fsockopen hard codes port 443 when http scheme used
    • #38070 – RegEx to remove double slashes affects query strings as well.
    • #38226 – “cURL error 23: Failed writing body” when updating plugins or themes
    • #38232 – Setting `sslverify` to false still validates the hostname

    Media

    • #39195 – Undefined index: extension in class-wp-image-editor-imagick.php on line 152
    • #39231 – Allow the pdf fallback_intermediate_image_sizes filter to process add_image_size() sizes.
    • #39250 – Undefinded Variable in Media-Modal

    Posts, Post Types

    • #39211 – is_page_template could return true on terms

    REST API

    • #38700 – REST API: Cannot send an empty or no-op comment update
    • #38977 – REST API: `password` is incorrectly included in arguments to get a media item
    • #39010 – REST API: Treat null and other falsy values like `false` in ‘rest_allow_anonymous_comments’
    • #39042 – REST API: Allow sanitization_callback to be set to null to bypass `rest_parse_request_arg()`
    • #39070 – WP-API JS client can’t use getCategories for models returned by collections
    • #39092 – REST API: Add support for filename search in media endpoint
    • #39150 – Empty JSON Payload Causes rest_invalid_json
    • #39293 – WordPress REST API warnings
    • #39300 – REST API Terms Controller Dynamic Filter Bug
    • #39314 – WP-API Backbone Client: buildModelGetter fails to reject deferred on fetch error

    Taxonomy

    • #39215 – Support for string $args in wp_get_object_terms() broken in 4.7
    • #39328 – Adding terms without AJAX strips “taxonomy” query arg

    Themes

    • #39246 – Theme deletion has a JS error that prevents multiple themes from being deleted.

    Upgrade/Install

    • #39047 – Installer tries to create nonce before options table exists
    • #39057 – FTP credentials form doesn’t display the SSH2 fields on the Updates screen

     

     

    • Angelika Reisiger 12:26 pm on January 7, 2017 Permalink | Log in to Reply

      Hi,
      thanks to the complete core team for this release and to you @voldemortensen for the detailed release announcement.
      One point to mention: a security release only for test purposes sounds odd.

      I know (or I believe to know), that the security fix concerns only the updated PHPMailer_library. So it is no “urgent” fix, since WP itself is not directly exploitable in WP Core and major plugins.

      However, a _security release for testing_ could confuse less informed WordPress users.
      Just my2Cents.

      Keep up the great work and have a nice weekend.

  • Andrew Rockwell 4:55 am on January 5, 2017 Permalink |
    Tags: ,   

    Week in Core, December 14th 2016 – January 3rd, 2017 

    Welcome back the latest issue issues (sorry) of Week in Core, covering changes [39599-39665]. Here are the highlights:

    • 67 commits
    • 56 contributors
    • 203 tickets created
    • 24 tickets reopened
    • 145 tickets closed

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

    Code Changes

    Bootstrap/Load

    • Bootstrap: Re-initialize any hooks added manually by object-cache.php.
      Prior to 3.1 if a object cache dropin wanted to add actions, they needed to use $wp_filter directly. [39605] #39132

    Build/Test Tools

    • Tests: Restore the database connection earlier when switching test groups. [39626-39627] #39327

    Bundled Theme

    • Twenty Seventeen: Fix incorrect $content_width value in theme. [39635], [39650] #39272
    • Twenty Seventeen: Hardens the logic for calling featured image in header.php [39624] #39302
    • Twenty Seventeen: Ensure functions in customize-controls.js don’t count on Customizer sections always being present [39623] #39335
    • Twenty Seventeen: Improves code readability and code standards in files [39618] #39152

    Comments

    • Ignore the ‘comment_order’ setting when determining comment pagination. [39663-39664] #31101, #39280
    • Fix placement of the wp_update_comment_data filter to safeguard filtered data from triggering a database error. [39640-39641] #39380

    Customize

    • Fix visible edit shortcuts for wp_nav_menu() instances using the menu arg (such as in the Custom Menu widget) instead of the theme_location arg. [39622], [39653] #27403, #39101
    • Bump wp_custom_css_cb from running at wp_head priority 11 to 101 to ensure Custom CSS overrides other CSS. [39616], [39651] #35395, #38672, #39270
    • Prevent edit shortcut from losing event handler after selective refresh. [39606] #27403, #39100

    Editor

    External Libraries

    Feeds

    • Replace the RSS2 lastBuildDate date field with the r date specifier. [39614] #39141
    • Do not translate the lastBuildDate field in RSS feeds. [39613] #39141

    Filesystem API

    • Filesystem: Add return statement to WP_Filesystem_ftpsockets->rmdir [39644] #39405

    General

    • Update copyright year to 2017 in license.txt. [39659], [39661] #39433
    • Docs: Misc corrections and additions to inline documentation. [39639] #39130
    • Use interpolation instead of concatenation for all dynamic hook names. [39600] #39148

    Mail

    • Ensure that any phpmailerException exceptions generated by setFrom() are caught to avoid PHP Fatal errors. [39655] #25239, #39360

    Media

    • Move a variable definition outside of conditionals to ensure it’s always available.
      This [39654] #39250
    • Allow PDF fallbacks filter to process custom sizes. [39617] #39231, #38594
    • This [39612] #39250
    • PDF Images: Avoid a PHP Warning when attempting to process a file without an extension. [39607] #39195

    Posts, Post Types

    • Taxonomy: Eliminate redundant and inaccurate dupe check when creating categories from post.php. [39637] #16567
    • Ensure is_page_template() can only return true when viewing a singular post query. [39599], [39608] #39211

    Query

    • Don’t double-escape terms payload in WP_Tax_Query::transform_query(). [39662] #39315
    • Improve documentation for orderby=relevance in WP_Query. [39636] #39336

    REST API

    • Add missing assertions to the view and embed context response data for the Users Controller. [39660] #39399
    • Add the supports property to the Post Type response object. [39647] #39033
    • Remove errant annotation from test_get_items_pagination_headers() method. [39643] #39398
    • Allow schema sanitization_callback to be set to null to bypass fallback sanitization functions. [39642] #38593, #39042
    • Docs: Add and correct @since docs for a variety of functions and methods. [39638] #39343, #39357, #39344, #39130
    • Allow sending an empty or no-op comment update. [39628] #38700
    • Improve the rest_*_collection_params filter docs and fix the terms filter. [39621] #39300
    • Fix PHP warnings when get_theme_support( 'post-formats' ) is not an array. [39620] #39293
    • Do not include the password argument when getting media items [39610] #38977
    • Do not error on empty JSON body [39609] #39150
    • WP-API: JavaScript client – fix setup of models used by wp.api.collections objects. [39603-39604] #39070
    • Add support for filename search in media endpoint. [39598] #39092

    Shortcodes

    • Clarify the docs for pre_do_shortcode_tag and do_shortcode_tag. [39665] #39294

    Taxonomy

    • Redirect to current taxonomy when adding a term without AJAX. [39649], [39652] #39328
    • REST API: Merge similiar error message strings in the Terms Controller. [39648] #39176
    • Ensure that mods to query vars in pre_term_query callbacks have an effect. [39625] #39354
    • Restore the ability to use string-based $args in wp_get_object_terms(). [39611] #39215

    Upgrade/Install

    • Updates: Show the Authentication key settings after selecting the SSH transport in both the modal, and also on the plugin/theme updates screen. [39657-39658] #39057
    • Updates: Remove a stray " from a tag. [39656] #39057

    Thanks to @adamsilverstein, @afercia, @bcworkz, @boonebgorges, @chandrapatel, @ChopinBach, @chris_de, @davidakennedy, @dd32, @dhanendran, @dl, @dlh, @dots, @dreamon11, @dshanske, @garyc40, @gitlost, @iseulde, @jblz, @jesseenterprises, @jfarthing84, @jnylen0, @joemcgill, @johnbillion, @jorbin, @JPry, @keesiemeije, @keesiemeijer, @kkoppenhaver, @kovshenin, @laurelfulford, @MattyRob, @MikeHansenMe, @natereist, @Nikschavan, @obenland, @ocean90, @pento, @peterwilsoncc, @rachelbaker, @ramiy, @sanket.parmar, @sebastian.pisula, @SergeyBiryukov, @sfpt, @shazahm1hotmailcom, @sirbrillig, @sstoqnov, @stevenkword, @szaqal21, @thepelkus, @timmydcrawford, @tymvie, @tyxla, @voldemortensen, and @westonruter for their contributions!

     

  • Jeffrey Paul 4:32 am on January 5, 2017 Permalink |
    Tags: , ,   

    4.7.1 Bug Scrub 

    Thursday, January 5th 12:30pm CST has been scheduled for a bug scrub.

    The bug scrub focus will be on tickets milestoned for 4.7.1 and the conversation will take place in #core. This will be the final bug scrub for 4.7.1 and any tickets remaining in the milestone after the bug scrub will be punted to 4.7.2 or a future release. Reminder that 4.7.1 is scheduled for release on Tuesday, January 10, 2017.

     

  • Matt Mullenweg 10:32 pm on January 4, 2017 Permalink |
    Tags: customizer, ,   

    Focus Tech and Design Leads 

    There are three main focuses this year: the REST API, the editor, and the customizer.

    For the REST API we’re going to work on getting first party wp-admin usage of the new endpoints, and hopefully replace all of the core places where we still use admin-ajax.

    The editor will endeavour to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery.

    The customizer will help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization “outside of the box” of post_content, including sidebars and possibly even an entire theme.

    Each focus will have a tech lead, and a design lead, and I’ll be working closely with each to make sure we’re aligned and moving diligently in the right direction even though we don’t have the normal release hooks. These starting leads will be:

    REST API: Ryan McCue and KAdam White.

    Editor: Matias Ventura and Joen Asmussen.

    Customizer: Weston Ruter and Mel Choyce.

    Given there is no set timeline for releases that would normally set a term, these leads are free to bow out at any time they feel they can’t contribute fully and we’ll find a replacement.

    You might be wondering what each lead is responsible for. The REST team gave some thought to this for their focus, and this is the list they came up with:

    Tech Lead responsibilities:

    • identify and ensure implementation of first-class REST API usage within WP-Admin,
    • replacing/refactoring admin-ajax use.
    • overall REST API architecture
    • infrastructure and endpoint performance
    • security at an infrastructure and endpoint (data-exposure) level
    • improving authentication options and documentation
    • working with the Design Lead to build new, or expand on existing, endpoints
    • working with the Design Lead to address usability feedback for the infrastructure and endpoints

    Design Lead responsibilities:

    • usability of endpoints for internal or external clients
    • usability of the infrastructure from the perspective of a API client
    • working with the Editor and Customizer focus teams to collect requirements and gather feedback
    • identifying ways to improve the overall experience for folks building clients or consuming endpoints (like documentation)
     

    • Jon Brown 10:38 pm on January 4, 2017 Permalink | Log in to Reply

      This all sounds awesome and I’m excited to see the fruits of this new paradigm.

      I do have one technical question I haven’t heard addressed… how are these being handled code/repo wise?

      Otto can come after me with a whip… but wouldn’t each of these major efforts be much easier managed as separate git branches than with SVN’s patching/branching system? I just can’t wrap my head around ever being able to merge the results of each of those efforts independently any other way.

      I’m not trying to start yet another svn/git war… just asking, what’s the plan for the fruits of this effort being merged into trunk someday?

      • Matt Mullenweg 10:41 pm on January 4, 2017 Permalink | Log in to Reply

        It is super tempting to also want to change all our tools and workflows at the same time, but we shouldn’t try to innovate in too many areas at once. So no SVN / Git war today. 🙂

        • Jon Brown 5:42 am on January 5, 2017 Permalink | Log in to Reply

          I guess my question wasn’t clear. What’s the plan?

          I totally understand the logic of not switching tools… The existing SVN patch paradigm seems unwieldly for anything this size. Is the plan to utilize SVN branches and merging? figured it out as we go?

      • Ryan McCue 1:33 am on January 5, 2017 Permalink | Log in to Reply

        As well as what @matt said, a lot of these pieces will (hopefully) tie in with each other quite heavily, and I expect we’ll all be working together a fair bit, so separate branches probably wouldn’t help. 🙂

    • Tammie Lister 10:39 pm on January 4, 2017 Permalink | Log in to Reply

      Congratulations everyone leading! Really looking forward to seeing the focuses evolve.

    • Luke Cavanagh 10:40 pm on January 4, 2017 Permalink | Log in to Reply

      Seems an interesting change of focus for WP core. Where will other features as plugins stand, if they do not fit within the three main focus areas?

    • Scott Kingsley Clark 10:47 pm on January 4, 2017 Permalink | Log in to Reply

      I’d like to get the Fields API into the Editor focus if the meta boxes and fields on the screen fits into your definition well enough. There may be a lot of crossover between what the Fields API could take on and the remarks you’ve made above about the Editor focus which would make a great pairing.

      • Matt Mullenweg 10:51 pm on January 4, 2017 Permalink | Log in to Reply

        Could look at it later in the year, I think the first half will be focused on more foundational things.

        • Scott Kingsley Clark 10:59 pm on January 4, 2017 Permalink | Log in to Reply

          OK, I’m just concerned as we add new methods for adding structures that Fields API has even more work to be done in order to unify them. But glad you’re not opposed to it. I can rest soundly now 🙂

      • Nick Halsey 12:13 am on January 5, 2017 Permalink | Log in to Reply

        On the other hand as the editor becomes integrated with the customize API via customize posts/broader live preview, the customize API could potentially be used directly for fields that manage any type of content throughout WordPress (this is already possible, but perhaps not obvious in terms of resulting usability). It’s probably best to wait and see where that heads before going too much further with a separate fields API.

      • Marcus 12:13 pm on January 5, 2017 Permalink | Log in to Reply

        I think Fields API is one of those things that is getting overlooked, yet would benefit the project so greatly by providing standards and consistency for developers working with WP.

        From the consistency/standardization point of view, I envisage similarities with how the introduction of Custom Post Types created a standard for content other than regular posts/pages.

        Whilst I don’t know much about the Customize API, I think Fields API make an awesome foundation for fields used in any other API or UI.

        • Scott Kingsley Clark 1:30 pm on January 5, 2017 Permalink | Log in to Reply

          I imagine that the Customizer API would ultimately fetch configurations from the Fields API to make use of them in its own context, but that Fields API would stretch across WordPress beyond things that need previewing.

          • Marcus 2:39 pm on January 6, 2017 Permalink | Log in to Reply

            Exactly! Everything on WP uses fields for gathering info; plugins, themes, customizer, core… yet each implementation handles it in its own way. A single API for this will help in so many ways.

      • Jon Brown 8:17 pm on January 6, 2017 Permalink | Log in to Reply

        +1 on getting the Fields API into the Editor focus. It seems to make sense that content blocks would use the Fields API and both would become available to the customizer.

    • Rachel Baker 11:01 pm on January 4, 2017 Permalink | Log in to Reply

      Congratulations to all the Focus Leads!
      Defining the responsibilities of the two roles was a valuable exercise for the REST API team. Thanks for sharing @matt.

    • Luke Cavanagh 11:10 pm on January 4, 2017 Permalink | Log in to Reply

      Final question I know performance was mentioned before, where will that focus fit? Thanks for the info.

      • Matt Mullenweg 2:18 am on January 5, 2017 Permalink | Log in to Reply

        What goes in a minor release will broaden a bit, which I know is something we have to approach carefully, but performance is very important and improvements will be something I will consider for being in a minor release.

    • Chuck Reynolds 11:37 pm on January 4, 2017 Permalink | Log in to Reply

      yay progress; very excite… let’s go!

    • Nick Halsey 1:29 am on January 5, 2017 Permalink | Log in to Reply

      Since I’m going to be generally much less available (and completely unavailable during US business hours) starting next week, I’m going to leave my thoughts on priorities and next steps for the customizer here.

      I’ve done some preliminary research on the process of making things in different industries. Preview, and live preview, is always a goal because it provides implementors with the best chance to understand what they’re making as they create it. In most cases a truly live preview is not possible due to physical constraints; for digital products and WordPress, though, live preview is possible and represents the best opportunity for improving user experience. See http://celloexpressions.com/blog/trust-wordpress-with-live-preview/ for details.

      The customizer will help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization “outside of the box” of post_content, including sidebars and possibly even an entire theme.

      Because unified live preview is critical to improved user experience and trust, the best approach is probably to implement the new editor experience within the customize API, thus creating it with contextual live preview as an integral part of the experience from the start. Improving the editor within an “admin” interface that lacks live preview doesn’t address the fundamental problems with the current content editing experience and creates something that still has to be entirely rebuilt and reimagined within a live preview context eventually.

      If the editor is built on the customize API first, rather than rethinking the editor and then bringing it into the live preview API, the customize and editor contributors would be able to join forces to focus on improving the content editing experience much more effectively. The customize component has been seeing a lot of contributors helping out (over 60 in 4.7) and their knowledge of the customize API would be a big help in tackling the technical and design challenges of rethinking the editor within the unified live preview context; the opposite is unlikely to happen.

      Either way, these are the next steps that I would prioritize in working toward an improved and unified live preview experience, which could encompass much of the editor focus and would then set the stage for improving the broader approaches to “customization” on top of what’s existing:

      • Implement a term status API so that terms can be previewed
      • Complete the new theme installation experience (proposed plan)
      • Develop a core customize inline editing/partials API within the customize preview
      • Iterate on Customize Posts and the front-end editor plugin to provide inline editing within the customize preview API (this would be the basis for new editor work)
      • Load the customizer directly from the front end, making it feel like a front-end edit mode rather than a mix between the admin and front end
      • Rework option navigation UX in the customize controls pane, UX of inline editing vs. editing in a separate pane, visible edit shortcut UX, and the way posts of any type are accessed to edit (perhaps integrating with menus?) – I know @folletto has thoughts here that would be valuable
      • Iterate on Customize Snapshots and changesets to provide UI for revisions, drafted changes, and scheduled changes unified across a site’s posts and options
      • Implement term editing within the customizer (unified live preview framework)
      • Merge Customize Posts, with refined UX (this would be a likely place for editor-contents work to happen as well)

      My general feeling is that we need to bring live preview to content editing before the editor and customizer goals above (in the post) can be effectively tackled, so that there’s a complete framework to build those; however, work on these goals can progress simultaneously if expectations are established appropriately at the beginning.

      I’m not sure how much time I’ll be able to contribute moving forward, but my priorities (as a user first) are to advance the proposed roadmap I listed above.

      • Andrew Ozz 4:07 am on January 5, 2017 Permalink | Log in to Reply

        Nice thoughts and ideas. I’ve also been thinking about this and agree with many of the above points.

        My general feeling is that we need to bring live preview to content editing

        Yes. Even not “live preview to content editing” but rather “inline content editing where no preview is necessary”. As far as preview is concerned, the best experience is to edit “the real thing”, i.e. some form of front-end editing directly into the theme.

        Because unified live preview is critical to improved user experience and trust, the best approach is probably to implement the new editor experience within the customize API, thus creating it with contextual live preview as an…

        I’m not sure what “unified” live preview and “contextual” live preview mean. The best “preview” is when something is edited inline. Unfortunately this is not available in the current customizer. The second best is when the editing UI is inline, right at the place that is affected by the edit. This also is not available in the current customizer.

        If the editor is built on the customize API first, rather than rethinking the editor and then bringing it into the live preview API…

        Don’t think this is good. As far as I see the current customizer UI will have to be redesigned together with the way it works. Don’t see a reason why the UI should be similar to a “frameset” site from the late 90’s. We can do a lot better than that 🙂

        Rework option navigation UX in the customize controls pane, UX of inline editing vs. editing in a separate pane, visible edit shortcut UX, and the way posts of any type are accessed to edit (perhaps integrating with menus?)

        Exactly (I read that as UI not UX). Further, the customization will happen from the theme/front-end, the “control” sidebar will go or be replaced with a proper navigation menu, everything will be 100% JavaScript and REST API driven, most controls will be inline or in some form of dialogs (with ample space/not overcrowded) that will have help or hints build right into them, etc.

        • Nick Halsey 7:17 am on January 5, 2017 Permalink | Log in to Reply

          Thanks for the reply. I should clarify some of the terminology I used:

          • Live preview and inline editing (can/should) mean the same thing. The basic idea is that you see the end product as you create it. Inline editing is a more specific form of live preview.
          • Expanding on that, most interactions should probably happen directly “on the site” (or in the preview). However, there are cases where that doesn’t make sense (for example, a theme’s color options or changing a post format) – that’s where some sort of sidebar, modal, popup, or other approach would be necessary, and this is where we need a lot of research and design work to find the best solution. A hybrid solution like this also makes theme compatibility and progressive enhancement with theme-support much more realistic.
          • “Unified” live preview is essentially being able to edit any part of a site within the same editing mode/workflow (without having to publish any changes).
          • “Contextual” live preview would be something like front-end editing, versus an editor that provides live previews of styling for the content area and media within it but is missing the context of the rest of the site, and may not be able to accurately reflect the way all content is displayed as a result.
          • In terms of API, the customize API is currently the core framework/API for live previewing anything. I might use customize API and live preview API somewhat interchangeably because I see this as the best path forward as a basis for building everything; @westonruter could probably discuss the advantages to that direction in more depth.
          • The customize API is 90% of the way to being able to fully manage live previewing any change to a site with controls to make changes happening either inline or in a separate place (the current customize “pane”). Specifically, once “Develop a core customize inline editing/partials API within the customize preview” is implemented on top of the base partials API currently in core, the customize API would support both approaches to making changes pretty robustly, as opposed to starting from scratch. That would also do a lot for the goal of unified live preview (and theme/back-compat) if content editing comes into the same framework that’s already used for many non-content options.

          So I think we’re largely in agreement about end goals, and should spend some time refining the direction on how to get there, both in terms of tech and design 🙂 The current “customizer” should certainly evolve in terms of usability but the internals are beginning to converge with long-standing feature plugins and the editor goals into something that could really take WordPress to the next level with unified live preview and inline editing as a central focus.

        • Weston Ruter 12:59 am on January 6, 2017 Permalink | Log in to Reply

          @azaozz:

          The best “preview” is when something is edited inline. Unfortunately this is not available in the current customizer. The second best is when the editing UI is inline, right at the place that is affected by the edit. This also is not available in the current customizer.

          Right, it isn’t available but as of 4.7 it is possible. With the introduction of changesets and with selective refresh it is now possible to live preview. Actually, it was possible even before this as was prototyped in Customize Inline Editing but now it is possible implement that concept without ever loading customize.php or enter into any iframe at all. I want to build on the new edit shortcuts to provide a UI to start inline editing an element while on the frontend.

          As far as I see the current customizer UI will have to be redesigned together with the way it works.

          Yes, the current customize.php app should fade away as we bootstrap the customizer into the frontend context. Controls should appear in the sidebar only when needed. Otherwise, controls can appear inline even with direct manipulation where possible.

          The benefit of using the Customize API is not only having a framework for previewing changes but also we get “for free” an system for batching together an arbitrary number of changes (menus, widgets, options, etc) and having them all go live together once a changeset is published (even after it is scheduled or going through an editorial review process).

          Also, I think that the more we can treat “the Editor” as a component rather than the admin screen the better. As with #35760 we should be able to instantiate a TinyMCE editor anywhere to manipulate content and content blocks, whether this be on the admin screen or in the customizer. For example since Shortcake integrates with the TinyMCE editor then the Post Elements interfaces it provides then (mostly) automatically become available to the TinyMCE editor embedded in the customizer via the Customize Posts plugin.

        • Weston Ruter 1:05 am on January 6, 2017 Permalink | Log in to Reply

          So the Editor component should be appear on the admin screen and on the frontend (with customizer bootstrapped). When you do “Preview” from the edit post screen this should take you to the frontend with the customizer bootstrapped so that not only can you preview the changes you made on the edit post screen but you can also continue to edit changes in that context and see the additional changes live. This is implemented today in Customize Posts.

    • Ryan McCue 1:35 am on January 5, 2017 Permalink | Log in to Reply

      Looking forward to working with you Matt, as well as all the other leads. Exciting times. 🙂

    • Julien 6:53 am on January 5, 2017 Permalink | Log in to Reply

      Great news, we’re definitely looking at Editor “blocks” features.

    • Ahmad Awais 9:21 am on January 5, 2017 Permalink | Log in to Reply

      Congratulations all the tech and design leads. I am excited to see what’s next.
      I think most of the time I contribute this year will go towards Customizer, looking forward to working with you @westonruter & @melchoyce!

      Moreover, I am very much interested in standardizing REST API authentication area as much as e can while keeping it flexible.

      @matt the concept of editor blocks sounds very much interesting to me. The only question rather a suggestion is that if we make the process more transparent, then it will help the theme developers in the long run. Right now, as a theme developer, I am not sure what to expect from WP 4.8’s editor. A more clear timeline will go a long way to help both WordPress and us (theme devs). For example…
      1. Setting the right expectation: What to expect from the final version of Editor.
      2. The concept of “Blocks” is exciting, expanding more on it, early on, will help us prepare our new themes accordingly.
      3. Transparency will lead to more and better comprehension, which in turns can bring more contributors to the WP core. I for one, plan to contribute my fair share to the editor this year, mostly because it has a direct impact on the revenue my company makes.
      4. If possible, the focus of editor could be supported by data/numbers; editing is BTW most important feature of WordPress, even a teeny tiny change to that component will impact more than 100 Million users? (A rough guess). It’s only fair, that what we change here is supported by feedback from the community and that we can comprehend how it impacts the future of writing/editing and theming in WordPress. It will not only help us make an informed decision but will help theme devs prepare for it in advance. WIN-WIN?!

      Having not set release cycle is something new, but setting the right expectations, that I think can help?
      What are your thoughts about this?

      • Weston Ruter 6:03 pm on January 6, 2017 Permalink | Log in to Reply

        @mrahmadawais My perspective is that WordPress already has the key pieces for content blocks in the form of widgets, shortcodes, and TinyMCE views. I think the gallery shortcode should be considered perhaps the proto content block. The Shortcake plugin has demonstrated content blocks in the editor and this plugin has a significant number of installs at 10,000+. I now have a proposal drafted for using widgets as the underlying construct for the shortcode UI and storage mechanism, while shortcodes and TinyMCE views would continue to be how the content blocks are embedded and visualized in the content editor. My opinion is that Shortcake combined with widgets will provide us with the key pieces for content blocks, where a content block an be used either in the post content editor or in a sidebar widget area.

        I’m waiting to publish my technical proposal until @matveb has has had a chance to review. I fully expect the process of designing and implementing content blocks to be done openly and transparently.

        • Ahmad Awais 7:10 am on January 7, 2017 Permalink | Log in to Reply

          @westonruter great, looking forward to it.

        • Weston Ruter 6:03 pm on January 9, 2017 Permalink | Log in to Reply

          I’ll also reiterate that this “Widgets as Content Blocks” proposal is just a proposal. I’m eager to get feedback on it and the JS Widgets feature plugin because I think it has a lot of promise for content blocks and also for widgets in general. But given this year being design-lead, the technical proposal post may wait to be published until design has first set the direction for the editor.

    • Davide 'Folletto' Casali 10:16 am on January 5, 2017 Permalink | Log in to Reply

      I couldn’t agree more on the combination of a design and a tech lead, as well as having explicit reference people for each project.

      I’m happy to see this direction, and specifically the people chosen there are probably the best choices I can think of. It’s going to be great. 🙂

    • Joen Asmussen 10:30 am on January 5, 2017 Permalink | Log in to Reply

      🎉

      Interesting times ahead. Can’t wait to see what cool stuff we’ll build together!

    • Mel Choyce 4:21 pm on January 5, 2017 Permalink | Log in to Reply

      Looking forward to working with all the other leads this year! 🙌

  • Jeffrey Paul 3:31 pm on January 4, 2017 Permalink |
    Tags: , , ,   

    Dev Chat Agenda for January 4 (4.7.1 week 4) 

    This is the agenda for the weekly dev meeting on January 4, 2017 at 15:00 CST:

    • Schedule reminder: We need to agree on a timing for a 4.7.1 RC. RC means the list of tickets should be at zero, as a release candidate is supposed to represent software you believe you can release. It is currently at 21. (50 have been closed so far.)
    • Ticket reminder: For any tickets you’ve moved into the milestone, please take action on these in the next week.
    • Getting ready for RC with a 4.7 open ticket scrub

    If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

     

    • Marius L. J. (Clorith) 5:31 pm on January 4, 2017 Permalink | Log in to Reply

      I’d like to see the dev chat address the new release schedule, and how this affects minor updates moving forward, there is way too much confusion without any official word as of yet, and it’s been a month since the reveal (even though it’s been a holiday, it’d be nice if this was released along with the reveal)

      The major concern (I believe) is that we are likely to be breaking a long standing expectation of what is included with a minor release, and why they are considered “safe” compared to a major update at this point (judging by ticket(s) with bugfixes not related to regressions in the latest 4.7 being pushed into the 4.7 branch as well as trunk)

      Somewhat lengthy discussion started at https://wordpress.slack.com/archives/core/p1483136776003730 for reference

      • Jeffrey Paul 8:57 pm on January 4, 2017 Permalink | Log in to Reply

        While clarity on the new release schedule would be nice, the focus today will be on 4.7.1 as I have no insight into “how things will be different in 2017”. I will continue to push to get clarity on the new release schedule and help to get that published as soon as it’s available.

    • Luke Cavanagh 5:48 pm on January 4, 2017 Permalink | Log in to Reply

      Hoping for some official clarity in relation to the new release schedule.

      • Jeffrey Paul 8:58 pm on January 4, 2017 Permalink | Log in to Reply

        Today’s focus will be on the 4.7.1 release and I’m unaware of additional details on the new release schedule. I do know that’s important to many people, so I’ll continue to push for more clarity on this topic. Thanks for the input!

← Older posts

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar