Make WordPress Core

Updates from July, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Konstantin Obenland 5:20 pm on July 7, 2015 Permalink |
    Tags: ,   

    Dev Chat Agenda for July 8 

    Here’s the agenda for tomorrow’s Dev Chat in the #core channel on Slack.

    Time/Date: July 8 2015 20:00 UTC:

    1. Beta Notes
    2. Feature Updates
      1. Admin UI – @helen
      2. Menu Customizer – @westonruter
      3. Passwords – @markjaquith
      4. Site Icon – @obenland
    3. Component Updates
    4. Open Floor

    Feature Leads: Let’s review last weeks goals and set new ones for next week.

  • Konstantin Obenland 1:15 pm on June 24, 2015 Permalink |
    Tags: ,   

    Dev Chat Agenda for June 24 

    Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

    Time/Date: June 24 2015 20:00 UTC:

    1. Feature Updates
      1. Admin UI – @helen
      2. Menu Customizer – @westonruter
      3. Passwords – @markjaquith
      4. Site Icon – @obenland
    2. Component Updates
    3. Open Floor

    Feature Leads: Let’s review last weeks goals and set new ones for next week.

  • Konstantin Obenland 8:56 am on June 17, 2015 Permalink |
    Tags: ,   

    Dev Chat Agenda for June 17 

    Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

    Time/Date: June 17 2015 20:00 UTC:

    1. Feature Updates
      1. Admin UI – @helen
      2. Menu Customizer – @westonruter
      3. Passwords – @markjaquith
      4. Site Icon – @obenland
    2. Component Updates
    3. Open Floor

    Feature Leads: Let’s review last weeks goals and set new ones for next week.

    [EDIT]: Please test https://wordpress.org/plugins/wporg-site-icon/ in preparation for today’s chat.

  • Jeremy Felt 9:20 pm on June 16, 2015 Permalink |

    Multisite Office Hours Recap (June 16, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite.

    Today’s chat log
    Overall 4.3 Release Objectives

    Last week’s objectives:

    • New tickets to address found issues in flow. These issues logged in the screen sweep spreadsheet.
    • Iterations on `WP_Site` and `WP_Network`. Discussion around iterations.
    • #22383 and #32503 committed.
    • Write post, generate discussion around HTTPS in multisite.

    Today’s meeting agenda:

    • Progress on capturing, observing, ticketing flows.
    • Next steps to combined domain/path UI – Add New site flow #31240
    • `WP_Network`, `WP_Site` progress – @jjj
    • Open floor for tickets, thoughts, etc…

    Topic Details:

    Progress on capturing, observing, ticket flows:

    Tickets #32647, #32645, #32643, #32644
    chat log

    • @earnjam added iPad flows.
    • @sharonaustin captured a bunch of flow data/notes and will be posting it to Make/Flow soon.
    • Some great progress was made over the weekend during the WCPHL contributor day. #32643 was opened and committed as an example of the process. #32644, #32645, #32646, and #32647 were also opened.
    • @earnjam is going to take the lead on getting #32647 and #32645 ready for next week as part of a My Sites overhaul.
    • The bugs from #32643, #32644, and #32646 are likely found in other places throughout core as well.
    • We should collaborate on a flow/design/admin ui/network admin ui contributor doc for WCEU with some basic “here’s what we need” guidelines. @helen @boren @sheri

    Objectives for next week: #32645, #32647 committed. More flow, more tickets, more observations. :)

    Next steps to combined domain/path UI

    Tickets: #31240, #22383, #32434, #32503
    chat log

    • #22383, #32434, #32503 are all committed and closed. 👍
    • Originally #31240 seemed kind of off the table for 4.3, but it seems very possible now. @jeremyfelt will take a shot at getting that prepped for next week.
    • Once these are both in, we should start having some validation questions pretty soon.

    Objective for next week: Patch and/or commit for #31240.

    Progress on `WP_Network`, `WP_Site`

    Tickets: #31985, #32450, #32504, #31148
    chat log

    • @earnjam is going to open a ticket to track `WP_Site_Query` and take a stab at that.
    • We need to iterate some more on the other existing patches.
    • Completely comfortable with progress on this continuing through 4.3 for a target of 4.4 early. It would also be nice just to get it in now. :)

    Objective for next week: Iterations, progress, discussion.

    Other items:

    • @jeremyfelt owes an HTTPS in multisite post still. Maybe by tomorrow?
    • No other items. A pretty quiet chat today.

    See you next week!

  • Konstantin Obenland 8:58 am on June 11, 2015 Permalink |
    Tags: ,   

    Dev Chat Summary, June 10 

    Agenda, Slack log.

    Menu Customizer Status Update (#)
    The a11y review did not unveil any blockers, although it wasn’t done on the feature branch the team is currently working on. Introduction of a blocker there was deemed unlikely however. A new plugin version can’t be released since it’s now dependent on some core patches being applied.

    For the rest of the requirements: The biggest blockers are almost complete, Customizer setting re-architecture and sub-menu drag & drop. The settings re-architecture has been integrated into JS for the nav menu items, allowing nav menus to be edited, added, removed all with 100% previewability and not making any changes to the DB. Once Save & Publish is done, any newly created nav menu items get inserted at that time. Same goes for nav menu deletion. The submenu drag & drop has been merged into the same branch and it is all working together now.

    The biggest outstanding pieces are:

    • adding back the ability to add/remove entire menus
    • updating keyboard-accessible reordering to work with new menu settings
    • more unit testing for PHP, and write tests for JS

    Estimated time of completion is June 11, which leaves 5 – 6 days to merge.

    Admin UI (#)
    Even more prep work has gone into list tables, now working on the responsive part on #32395. They have gotten some feedback so far, would love more even on the rough cuts. Helen will be at wordcamp philly’s contributor day this weekend, looking to knock through a bunch of the low hanging fruit on the screen sweep spreadsheet, and find takers for some make-flow tickets (#29906 in particular). She has some catch up to do with other contributors on visual regression testing and media-new, which will happen at tomorrow’s meeting.

    Network Admin UI (#)

    Objectives from last week:

    • #32434 is in. Jeremy is still poking at #22383 and #32503 with a target of this evening.
    • They had no additional iterations on WP_Network and WP_Network_Query, but @jjj is working on having something this week.
    • Did not yet generate discussion around HTTPS. Moving this objective along to this week.
    • They made quite a bit of progress with flows. @kraft added Nexus and @earnjam has iPad screencaptures he will be publishing shortly. Their next push is to start creating tickets. Jeremy wrote a post to try and drum up support – https://make.wordpress.org/core/2015/06/05/help-test-and-capture-the-network-admin-ui/ – and they had a handful of people hop in. Pretty optimistic that they’ll start making progress here, especially with a couple contributor days this weekend.

    Objectives for this week:

    • New tickets to address found issues in flow. These issues logged in the screen sweep spreadsheet.
    • Iterations on WP_Site and WP_Network. Discussion around iterations.
    • #22383 and #32503 committed.
    • Write post, generate discussion around HTTPS in multisite.

    Better Passwords (#)
    Mark turned the plugin into a patch for the new UI. After a cleanup, that can land, and we can iterate a bit, as well as tackle the new user password flow, which is different. The expiration of reset links (#32429) needs testing (human and unit), before that lands. And the “notify users of password and email changes” patch (#32430) needs a review on the hooks in it. I’m not sure we’re passing the right things along. Like, email instead of the whole user array.

    Favicons (Site Icon) (#)
    There’s been a status update on make/core. It’s looking like #29211 would be a better approach to a reusable control with image cropping functionality. So John is wondering whether we should aim for 29211 for 4.3 and site icon for 4.4. On the topic of using the Customizer or not: much of the image cropping control for the header image is also used on the old header image screen (it’s mostly media library and ajax functionality), so it’s not necessarily tied to being a customizer control.
    Let’s meet today June 11 2015, 20:00 UTC to discuss what a good approach could look like.

    Next chat will be on June 17 2015, 20:00 UTC

  • Konstantin Obenland 2:26 pm on June 10, 2015 Permalink |
    Tags: ,   

    Dev Chat Agenda for June 10 

    Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

    Time/Date: June 10 2015 20:00 UTC:

    1. Menu Customizer Status Review@westonruter
    2. Feature Updates
      1. Admin UI – @helen
      2. Multisite Admin UI – @jeremyfelt
      3. Passwords – @markjaquith
    3. Component Updates (if time permits)

    Feature Leads: Let’s review last weeks goals and set new ones for next week.

    Recommended reading: Trust, Live Preview, and Menus in the Customizer.

  • Ryan Boren 3:50 pm on June 9, 2015 Permalink |

    Trust, Live Preview, and Menus in the Customizer 

    One of the most important things in WordPress is users being able to feel confident as they make changes to their content and more generally to their sites. Being able to make non-destructive changes and preview them is an important component of building that trust. This is perhaps most noticeable in the “save and surprise” approach of the widgets admin screen – every time you add a new widget, modify its settings, or move one around, the changes are saved and appear live on your site, even if you’re not ready yet. The customizer is our framework for live previewing changes. We are committed to providing live preview for all aspects of site customization and making it usable on all devices from phones to large screens.

    The customizer is the result of a tremendous amount of work over many releases. It was first introduced in 3.4. In 3.9, it received its first big updates in the form of widgets support and improved header upload and cropping. 4.0 brought panels and contextual controls. Development really started to take off in 4.1 when JS-templated customizer controls and a JS api were introduced, making possible an ecosystem of live preview compatible plugins and themes. 4.2 followed that up with two important features, theme switching and mobile support.

    That brings us to today and the ongoing 4.3 development effort. Revamped navigation for the customizer is already in trunk and the nighty builds. The menu customizer feature plugin is a merge candidate for 4.3 and could land soon. These marquee features further our commitment to live preview and need all of the attention we can muster.

    The customizer has come a long way, but it still lacks some features and needs time to mature. We have many improvements planned and in-progress, including transactions, partial refresh, theme installation, speedier loading, scaling to large screens, and possibly even integration with front end editing. Our live preview framework offers many possibilities.

    Meanwhile, the Appearance screens will remain and will be maintained. Appearance > Menus recently received some attention in the form of a few fixes. More attention is needed and will be given. There are still differences in the flows each approach best enables, whether it’s new site/theme setup, small maintenance tasks, or dedicated content managers for heavy usage of widgets, menus, or other pieces of content that benefit from having a preview mechanism. We should gather quantifiable metrics when it comes to performance and time to completion for a given flow, as well as evaluating the less-objectively-quantifiable perceived performance. There may come a time where the worlds converge; however, that time is not now.

    The feature plugin merge window is currently scheduled for June 17th. We have 8 days to get the Menu Customizer plugin ready for merge. Feature plugins must meet several criteria to be considered for inclusion in a release. To meet this criteria, the flow team has started testing and documenting flow and visuals for the menu customizer as well as the recently landed navigation changes. Merge criteria include identifying flows through the customizer, creating visual records of those flows, and creating flow comparisons of existing flow through Appearance > Menus versus flow through the customizer. This is a great and necessary way to contribute that requires no coding. All you need to do is take screenshots and publish them as a captioned gallery using the tool we’re making together, WordPress. We endeavor to be an Alan Lomax of flow, capturing and cataloging real user scenarios. Please help us capture the flows through Appearance > Menus used by you and your clients. We need this information to ensure our new interfaces are mindful and aware of how WordPress is actually used. Information on how to test and contribute visual records is available on the 4.3 development tracking page.

    @ryan, @helen, @designsimply


    • codezag 3:59 pm on June 9, 2015 Permalink | Log in to Reply

      the database structure of the menus will be changed ?
      is there any chnages to the menu walkers & database ?


      • Fabien Quatravaux 7:49 am on June 11, 2015 Permalink | Log in to Reply

        As far as I know, this menu customizer will not introduce any change visible on the front-end side : no database structure change and no change to Menu Walkers. The only issue is about plugins or themes that added features to the Appearance > Menu admin page : those features may require some work to be available in the new menu customizer.

    • Frankie Jarrett 4:02 pm on June 9, 2015 Permalink | Log in to Reply

      Great to see that the core team is so committed to advancing the Customizer! I really believe it’s a glimpse into the future for a more JS-driven WordPress. Takes a bit of time to steer a ship of 75 million sites, but I know we’ll get there, and we’ll do it responsibly without leaving folks behind :-) /fives!

    • Shapeshifter 3 4:11 pm on June 9, 2015 Permalink | Log in to Reply


      A very thorough synopsis of the current plan.

      Thank you!

    • kevinwhoffman 4:49 pm on June 9, 2015 Permalink | Log in to Reply

      Ryan, thanks for the update. The parallel development of the Menu Customizer alongside maintenance of the existing Menus screen is a good strategy moving forward until the Customizer is better proven.

      I also appreciate the rationale behind the importance of live previewing in different use cases. The more guesswork we can take out of the editing process, the better.

    • Jon Brown 4:52 pm on June 9, 2015 Permalink | Log in to Reply

      Great summery Ryan. I think the backlash against the menu customizer would have been a lot tamer if the proposal hasn’t included removing the appearance/menu page and stating that “this was the solution” for all the long un-addressed bugs in the appearance/menu page.

      Personally I don’t like the UI/UX of the customizer. I think stuffing that much GUI in the side panel is a mistake and editing should happen directly “on the page”. I wouldn’t object strongly to menu editing being added to the customizer panel as on option though, especially since I can always disable it like many of the customizer controls my client base find cluttered and confusing.

    • Morten Rand-Hendriksen 5:14 pm on June 9, 2015 Permalink | Log in to Reply

      Ryan is a calm shore in a raging storm.

      • George Stephanis 6:45 pm on June 9, 2015 Permalink | Log in to Reply

        Yes, behold my lord Boren, the rock, the hard place, like a wind from Texas he sweeps by blown far from his homeland in search of glory and honor, we walk… in the garden of his turbulence!

        (as paraphrased from A Knight’s Tale)

    • Gabe Shackle 5:28 pm on June 9, 2015 Permalink | Log in to Reply

      It’s a great addition to WordPress but the release approach has been terrible. Virtually all the opposition to the Customizer could have been avoided if it didn’t seem like everyone was being forced to use it.

      Things like changing the Widgets link from the admin bar, requiring all settings being in the Customizer by the TRT, and then with this last push that included language to remove the menus admin completely from the dashboard, it’s no wonder people were fairly upset and wrote the entire system off.

      If it had simply been released like this:

      “Check out this great new way to manage menus and widgets.”

      Rather than:

      “Here is the new way to manage widgets and menus. We’re going to be removing the interface you’re familiar with because we feel this new method is better and we don’t have enough resources to maintain both.”

      There would have been almost no push back at all. If the Customizer is truly as great as its developers say, let it stand on it’s own and prove it.

      • Helen Hou-Sandi 5:48 pm on June 9, 2015 Permalink | Log in to Reply

        Let’s take a moment to reflect on reactions being similarly imperfect in language choices and emotive content, and the very real effects that has on attracting and retaining the contributors we need to be able to maintain and improve those interfaces. Continuing to snipe at each other about tone, semantics, and hypothetical “should”s as though everything is predictable is not particularly productive.

        • Gabe Shackle 5:52 pm on June 9, 2015 Permalink | Log in to Reply

          I was merely offering my perspective and a possible reason for the negative reaction. No sniping intended at all.

        • PeterRKnight 10:22 pm on June 9, 2015 Permalink | Log in to Reply

          I thought a lot of the (unfair) reactions were coming from a lack of understanding about why these changes are happening and the way they are coming about. It’s always painful to see folks talking like there’s some kind of powertrip happening amongst some illusory ruling elite.

          But I’m agreeing with Gabe here, I think better communication would have prevented some of the kneejerk reactions that can be demotivating toward the developers.

          Because Gabe is right in that some people are interpreting this as tools being taken away from them, instead of being excited about a new powerful way of managing menus.

        • dmccan 3:26 pm on June 12, 2015 Permalink | Log in to Reply

          This post is great. It communicates and helps people to understand the thinking, planning, work, and process.

          Compared to some feedback I’ve seen, the feedback to this post has mostly been positive and generally constructive. We are all human and learning along the way. It is important to encourage and acknowledge contributions as well as provide constructive feedback. In this case the constructive feedback is that more good communication, like this article, is helpful.

    • Weston Ruter 7:02 pm on June 9, 2015 Permalink | Log in to Reply

      Thank you for writing this, @boren.

    • Knut Sparhell 7:36 pm on June 9, 2015 Permalink | Log in to Reply

      It’s already said, but again: Thank you for writing this, @boren. Record the flows of common tasks, on every kind of device.

    • Jose Castaneda 7:52 pm on June 9, 2015 Permalink | Log in to Reply

      Great write-up! Thank you for this. :)

  • Konstantin Obenland 5:59 am on June 5, 2015 Permalink |
    Tags: ,   

    Dev Chat Summary, June 3 

    Agenda, Slack log.

    Menu Customizer Merge Proposal (#)
    @westonruter, @celloexpressions
    We went through the feature plugin checklist and discussed if the plugin was fit for core. It was approved for merge, pending the following conditions:

    Items that should be done before merge:

    • Complete a11y audit.
    • Address possible blockers.
    • Merge php tests.
    • Add JS tests.

    Then with/after merge:

    • Killswitch for plugin.
    • An outline for a fieldguide post.

    Better Passwords (#)
    New password UI on Profile screen, via GH plugin. Generates and shows by default. Lets the user hide, or click into the field and type (in show/hide modes). Also, the strength meter has been more closely integrated. The color wraps around the field, and it is integrated as one “unit” instead of being this button-like thing that floats below it. Mark would like to get the current state turned into a patch and merged, as he thinks it’s a fine inflection point, even if the next steps aren’t ready in time.

    Admin UI (#)
    Got a lot of a11y fixes in play for list tables. A fair number of small/low-hanging fruit issues being noted, which aren’t crucial to hit before beta, so they’ll keep focusing on the bigger items for now. They also started to sync up with #core-flow issues and getting those into the patch and review queue.

    Network Admin UI (#)
    Last week’s objectives and progress:

    • Wrap work on the edit site flow and MS sites list table and then take a look at the add site flow and validation in `update_blog_details()`. We made progress on the edit site flow and are nearing commit readiness for a few patches.
    • Continued progress on WP_Network, WP_Site, WP_Network_Query, and WP_Site_Query. We had quite a bit of discussion on the WP_Network ticket and in Slack. Not much ticket progress, but we’re doing good at continuing to pay attention.
    • More thoughts on tracking scheme in wp_blogs for sites. We discussed this in the meeting yesterday and need to do some more research on impact. There’s some info in the recap, but we’ll also have a call for info/thoughts soon.
    • More flows and network admin UI tickets from those flows. We have iPhone 5s flows from @ubernaut. We need to do more creating of tickets and generating of additional flows.

    Objectives for next week:

    • Have all 3 tickets related to the edit site flow closed and committed.
    • Additional iterations on WP_Network and WP_Network_Query. Please watch this.
    • Generate discussion around tracking site scheme. @jeremyfelt will gather a list of HTTPS related tickets and share.
    • Nexus (@kraft) and iPad (@earnjam) flows. Tickets created for bugs found in existing flows. Volunteers needed!

    And the recap has all the juicy details: https://make.wordpress.org/core/2015/06/03/multisite-office-hours-recap-june-2-2015/

    Favicons (#)
    Site Icon progress has been slow due to him being too busy, but he has a working implementation now which he will put up in a repo on GitHub tomorrow, then he’ll see about liaising with contributors to get feedback, and basically go from there.

    Next chat will be on June 10 2015, 20:00 UTC

  • Konstantin Obenland 6:21 am on June 3, 2015 Permalink |
    Tags: ,   

    Dev Chat Agenda for June 3 

    Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

    Time/Date: June 3 2015 20:00 UTC:

    1. Consider the Menu Customizer plugin for merge [Proposal] [Plugin]
      If you haven’t looked at either of the merge proposals yet, please spend some time today before the meeting. Please comment on the post if you haven’t already.
    2. Feature Updates
      1. Admin UI – @helen
      2. Multisite Admin UI – @jeremyfelt
      3. Passwords – @markjaquith
      4. Site Icon – @johnbillion
    3. Component Updates (if time permits)

    Feature Leads: Let’s review last weeks goals and set new ones for next week.

    Recommended reading: Features as Plugins.

  • Scott Kingsley Clark 10:12 pm on May 27, 2015 Permalink |
    Tags: , ,   

    Metadata API project reborn: The new Fields API project 

    Many of you will remember that a couple of years ago, @ericlewis and a group of us set out to start a project to make sense of all of the different APIs that arose from third party plugins and themes to build custom field solutions on top of WordPress. That project was nicknamed “Metamorphosis” and subsequently went by the “Metadata UI/API” project. As plugin authors dealing with and using custom fields and content types, we had been tackling the issues of developing for multiple object types in WordPress for years prior to getting together.

    Now, @helen and I are pleased to (re)introduce to you what we’re hoping to be the fruits of all of this labor: Meet the new Fields API project.

    function fields_api_example_post_field_register( $wp_fields ) {
       // 1. Define a new section (meta box) for fields to appear in
       $wp_fields->add_section( 'post_type', 'my_cpt', 'my_meta_box',
             // Visible title of section
             'title'       => __( 'My Meta Box', 'mytheme' ),
             // Determines what order this appears in
             'priority'    => 'high',
             // Determines what order this appears in
             'context'     => 'side',
             // Capability needed to tweak
             'capability'  => 'my_custom_capability'
       // 2. Register new fields
       $wp_fields->add_field( 'post_type', 'my_cpt', 'my_custom_field',
             // Default field/value to save
             'default'    => 'All about that post',
             // Optional. Special permissions for accessing this field.
             'capability' => 'my_custom_capability',
             // Optional. Add an associated control (otherwise it won't show up in the UI)
             'control' => array(
                // Don't set 'id' and it will automatically be generated for you as
                'id' => 'mysite_my_custom_field',
                // Admin-visible name of the control
                'label'   => __( 'My Custom Field', 'mytheme' ),
                // ID of the section this control should render in (can be one of yours, or a WordPress default section)
                'section' => 'my_meta_box',
                // Control type
                'type'    => 'text'
    add_action( 'fields_register', 'fields_api_example_post_field_register' );

    (Please note: The code above may not be the same as the final implementation, it will especially change over the next few weeks)

    First of all, we split off the UI side of the project to focus solely on the API. This way, we’re not held up by anything as we move towards implementation inside of core. We can tackle each UI separately and that helps us keep the project nimble and on track.

    The goals of this new API proposal will be to be implemented across WordPress objects as an API to register fields and sections for. We aim to cover these objects (not necessarily in this order):

    • Customizer (retrofitting it beneath the existing Customizer API)
    • User profile screen
    • Post editor
    • Settings screens (retrofitting it beneath the existing Settings API)
    • And other areas in the future (Comment editor, Network Settings screens [see #15691], Media modals, etc)

    This API offers a great deal of standardization across all of WordPress and code reusability. It’s paramount for third-party developers, who will be able to utilize these structures in their own plugins and themes, build apps and give access to other developers so they can contextually see what a site really contains. I see the biggest use-case being able to expose the entirety of WordPress to the REST API and giving apps like the WordPress iOS app access to meta boxes and custom fields to display real editor screens with field inputs based on the control types natively.

    Areas we need help currently:

    • Examples and use cases for Customizer, User profile screen, Post editor, and Settings screens (submit issues in GitHub with your ideas, coordinate with us to refine them if you want)
    • Unit tests for core
    • Testing Customizer implementation, you’ll find the core files to replace under the /implementations/ folder in the repo
    • Brainstorming implementation classes for other object types to implement in the UI, starting with User profile screen

    If you’re interested in joining our merry crew which includes @helen and a few of us, hop into Slack #core-fields and join our weekly meetings every Monday (Monday 20:00 UTC 2015). You can check out the Fields API and submit PRs on GitHub, or ping us in #core-fields throughout the week with questions or concerns.

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