Make WordPress Core

Updates from Aaron Jorbin Toggle Comment Threads | Keyboard Shortcuts

  • Aaron Jorbin 7:32 pm on December 8, 2016 Permalink |
    Tags: , retrospective   

    4.7 Retrospective 

    A retrospective meeting on the WordPress 4.7  release will be held during the week of December 19th. In order to properly prepare for that retrospective and make the time as productive as possible, I would like to encourage everyone to comment below with things they would like to bring up. To help, here are three good questions to ask yourself:

    • What should WordPress start doing as a part of the development process?
    • What should WordPress stop doing as a part of the development process?
    • What should WordPress continue doing as a part of the development process?

    Please remember when commenting to keep the discussion professional and focused on ways the process of creating WordPress is either already working great or can be improved.

    • Aaron Jorbin 7:35 pm on December 8, 2016 Permalink | Log in to Reply

      We failed at getting the field guide and email to plugin dev out early enough. We have aimed to have that out around beta 2 and usually end up getting it out around RC the last few releases. This time it came out the day before (field guide) and day after the release (email)

    • Darren Ethier (nerrad) 7:41 pm on December 8, 2016 Permalink | Log in to Reply

      I’m curious as to how the announcement by Matt about changes to the development process is going to affect this retrospective process. It might be beneficial if there was some clarity surrounding that change brought up at the meeting perhaps? It may be hard to talk about improvements that can be when there’s some ambiguity about what developing WordPress core will look like in 2017.

      • Aaron Jorbin 8:03 pm on December 8, 2016 Permalink | Log in to Reply

        I can’t speak for @matt, but I imagine that the feedback generated will help inform the process in 2017 and going forward.

      • Jeffrey Paul 8:32 pm on December 8, 2016 Permalink | Log in to Reply

        I’d prefer we frame this Retrospective with the current state of core development in mind. Let’s identify the start/stop/continue doing items based on the current approach and as @jorbin says I’m certain it will help inform any changes in the process next year.

    • J.D. Grimes 9:02 pm on December 8, 2016 Permalink | Log in to Reply

      The posts explaining new features and changes are helpful, but I think that we need more of them. I follow the trac feed, and sometimes I know that as a plugin developer a particular ticket is important for me to take note of, but it can be difficult to unravel exactly what the final decision was just based on the changesets. An example of something that is going on right now is the a11y team’s work on removing excessive content from headings on admin screens. Often API changes get documented and UI changes don’t, but I’m a perfectionist and I like to stay up to date on the latest design/a11y evolutions as well. I can usually figure out what changes I might want to make in my plugins based on the changes in core, but I’m sure that often most plugin developers don’t even know that there was a change, if they don’t read every ticket.

      I also think that continuing to plan releases for particular dates and stick by those deadlines is helpful for me as a plugin developer. It helps me to plan plugin releases, because I can coordinate them with WordPress’s release cycle. By coordinating the release cycle of my plugins with WordPress, I can test any extensions against the new versions of both the plugin and WordPress at once, instead of having to duplicate effort in that regard.

    • Nick Halsey 2:49 am on December 9, 2016 Permalink | Log in to Reply

      We need to collectively review the “feature plugin merge guidelines” listed here: https://make.wordpress.org/core/handbook/about/release-cycle/features-as-plugins/#feature-plugin-merge-criteria

      While development in plugins has become less prominent, most of the bigger projects merging into core in 4.7 (I would exclude the REST API since that’s less user-facing) skipped many of the steps here. A lot of the points don’t apply to most projects – to the point that the checklist is often forgotten entirely. But there remains a need for better quality control and an updated checklist or recommended merge considerations for larger projects should be created accordingly. These written guidelines can better inform merge decisions and assess readiness.

      Only one feature posted a visual record on make/flow during 4.7. Prior to beta, that was also the only feature to publish any user testing on make blogs. There should have been far more of that happening, especially given the large number of significant user-oriented features in 4.7. I don’t think any frontend user testing of Twenty Seventeen was ever published either, which would have been a good way to identify potential usability issues.

      On a related note, clearer procedures about backing out merged features are needed. Particularly if a feature goes through an extensive process to demonstrate readiness and is approved for merge, input on removing the feature during beta/RC should be solicited publicly via make/core posts and scheduled meetings, similarly to the initial merge decision. Otherwise, the decision to remove a feature can seem to ignore the value of the opinions that went into making the decision initially and may not be fully informed about the broader implications with respect to related aspects of a component. If work on a feature seems to stagnate as bugs accumulate during beta and a lead is considering pulling it due to lack of attention, contributors working on the feature should be notified so that they can address the issues or recommend removing the feature based on availability. Perhaps putting more trust in the feature teams and component maintainers that are most intimately familiar with a given project could help ensure that decisions are more broadly considered.

    • petj 12:27 pm on December 16, 2016 Permalink | Log in to Reply

      What should WordPress start doing as a part of the development process?

      • make it more clear *how* to contribute with code. Where and how to upload. That kind of information. I know this is a total beginner issue, but it was a major challenge for me to figure out how-to. I think you’d get more code from contributors in that way.

      What should WordPress continue doing as a part of the development process?

      • The combination of a Git startup phase and Slack is excellent. At least for the Twenty Seventeen theme.
    • Weston Ruter 10:28 pm on December 20, 2016 Permalink | Log in to Reply


      • Increase user testing base for new features, particularly to include people who specialize in QA being part of the ticket lifecycle.
      • Add automated acceptance testing for the user flows. If we add these for new features added, we can ensure they work across browsers. And in future releases, these tests can ensure that we don’t break existing flows. Run tests on BrowserStack. See #34693.
      • Integrate PHP_CodeSniffer into our build/test tools, allow patches to be checked against coding standards. See #34694.


      • Weekly design meetings.
      • Steven Word 9:12 pm on December 21, 2016 Permalink | Log in to Reply

        I like these ideas. I was talking to a few people at WCUS about the idea of CI for patches in Trac. It would be really nice to see if patches still apply / lint in the patch dev process.

    • Joe McGill 6:44 pm on December 21, 2016 Permalink | Log in to Reply

      I share @celloexpressions concerns about new features being merged without going through the level of scrutiny we’ve previously set for ourselves. While it is not possible/practical for every new feature to go through a plugin development cycle, many of the items in the feature plugin checklist are still applicable. The risk of rushing features is even greater during cycles where we’re trying to ship a new default theme that depends on new features. Video headers and panels are examples of such features from this cycle, even though only one (video headers) ended up in Core.

      Besides having clear criteria and processes for merge decisions of new features, I would also recommend that new features be identified early in release cycles and that we make sure there is at least one core committer responsible for giving oversight (at minimum) to new features during the cycle. This should help us keep a closer eye on the progress being made on new features, and removes confusion about who will be responsible for merging the feature once it is ready. In my previous experience as a contributor to the responsive image feature project in 4.4 (before I had commit access), having @azaozz be part of the process was invaluable and helped us avoid roadblocks when it came to code review and getting code merged into core.

      On the upside, having clear deadlines for when enhancements need to be merged into core is very helpful for prioritizing time and focussing resources. I hope we will continue some form product calendar in the spirit of “deadlines aren’t arbitrary,” even if they take a different rhythm.

    • Andrea Fercia 7:08 pm on December 21, 2016 Permalink | Log in to Reply

      > Integrate PHP_CodeSniffer into our build/test tools, allow patches to be checked against coding standards.
      This would be great and should apply to JavaScript too, especially considering the relevant part JavaScript will probably play in the next future. While there are JavaScript standards for both coding and documentation, I’ve noticed there’s room for improvements even in files or sections of code that were recently committed.

      Start doing: more focus on Trac and tickets, every committer should try to follow Trac on a daily basis. Not to know 100% of the details of each ticket but at least to get a sense of what’s going on. Also, the number of tickets on Trac is increasing more and more, there’s the need of some serious “Trac Gardening” 🙂

      Continue doing: increase the effort to involve different teams in collaborating on features development, where different skills and knowledge are needed, of course.

      Stop doing: ignoring Trac 😉

    • mattyrob 9:35 pm on December 21, 2016 Permalink | Log in to Reply

      I think the good and bad can be summed up in a single word – Communication.

      Things have improved but could still be loads and loads better.

      • Trac is practically ignored or so it seems with many takes years old.
      • Coders are encouraged to contribute code but tickets or patches can lie dormant for long periods of time before being closed as ‘wontfix’ without any apparent consideration of the individual who opened the ticket or created the patch (declaration of conflict – this has happened to me more than once).
      • New features for developers should have a field guide issued as soon as the code is committed, not when a new version is released. The field guide should be a working document and it’s fine if it changes, but more notice of new features and core changes is needed – not RC and ideally before beta even.

      In order to improve communication:
      Perhaps there should be some consideration the core leads spend an equal amount of time on documentation as the core code to get that side of things on the same pace as the core code.
      Perhaps development teams should be consider – small fluid groups with a core lead who can act as a mentor to those keen to contribute but new to this.
      Limit the number of new ‘features’ in any release. WordPress is very mature as a product now, adding new stuff may seem like the way to improve but let’s make sure everything that’s already done is being done as well as it can be.
      Stop releasing a new theme with core each year, or at least break it out and away from the core development. It’d would certainly take a lot of traffic out of the Trac.
      Targetting getting the number of tickets in Trac reduced – the current number simply cannot be managed and it’s getting to the stage where duplicates are frequent and overlap is common.

      I think that’s enough for now 😉

  • Aaron Jorbin 9:05 pm on December 5, 2016 Permalink |
    Tags: , ,   

    WordPress 4.7 Field Guide 

    WordPress 4.7 is shaping up to be the best WordPress yet!  Users will receive new and refined features that make it easier to “Make your site, YOUR site”, and developers will be able to take advantage of 173 enhancements and feature requests added.  Let’s look at the many improvements coming in 4.7…

    RESTing, RESTing: 1, 2, 3

    The foundation for RESTful APIs has been in core since 4.4, and 4.7 sees the addition of Content Endpoints after a healthy discussion. We’ve defined four success metrics as part of the merge discussion and you can help by building themes and plugins on top of the API, using the API in custom development projects, and utilizing the API for a feature project, core features, or patches. So, dive in, start playing around, and let us know what you build!

    REST API Merge Proposal, Part 2: Content API


    It don’t mean a thing, if you ain’t got a theme

    No matter if you are building themes for public consumption, as a bespoke project for a major public company, or anything in between WordPress 4.7 has something to help you.

    Theming with Twenty Seventeen

    Video Headers in 4.7

    Starter content for themes in 4.7

    Visible Edit Shortcuts in the Customizer Preview

    Whitespace changes in navigation for 4.7

    Post Type Templates in 4.7

    New Post Type Labels in 4.7

    New Functions, Hooks, and Behaviour for Theme Developers in WordPress 4.7

    The Voyages of USS Media

    Two notable changes, enhanced PDF support in the media library and changes to the default fallbacks for image alt attributes, are explained in separate posts.

    Enhanced PDF Support in WordPress 4.7

    Improving accessibility of image alternative text in 4.7

    Media also received other exciting enhancements and bug fixes you should check out.

    Around the World

    The way users understand the words on WordPress are important and now users will be able to select their personal preferred language.

    User Admin Languages and Locale Switching in 4.7


    For Whom Customization Tolls

    The customize component will now support the ability to create pages within live preview during site setup; will have a faster, smoother, and more accessible navigation; will automatically persist your changes in the background while you browse your site and switch themes; and will let you fine-tune your site with custom CSS.

    Customizer Improvements in 4.7

    Customize Changesets Technical Design Decisions

    Changes to Customizer Sliding Panels/Sections in WordPress 4.7

    Extending the Custom CSS editor


    Reading, Writing and Teriffic

    Whether you’re creating content in the WordPress Admin or concerned about comment moderation, we’ve got updates that will be sure to please you.

    Editor changes in 4.7

    Comment “allowed” checks in WordPress 4.7


    The Foundation of WordPress

    For those who like to get “under the hood” of WordPress, we’ve got some improvements that will hopefully make your life easier.

    Changed loading order for current user in 4.7

    Multisite Focused Changes in 4.7

    Attributes for Resource Hints in 4.7

    wp_list_sort() and WP_List_Util in 4.7

    WP_Taxonomy in 4.7

    Fine grained capabilities for taxonomy terms in 4.7

    WP_Hook: Next Generation Actions and Filters

    Registering your settings in WordPress 4.7


    But Wait, There is More!

    Over 447 bugs, 165 enhancements, 8 feature requests, and 15 blessed tasks have been marked as fixed in WordPress 4.7. Some additional ones to highlight include:

    • Make media library searchable by file name (#22744)
    • Improved Custom Background Properties UI (#22058)
    • Hue-only Color Picker (#38263)
    • Fix Sections that .cannot-expand (#37980)
    • Allow Plugins to do Comprehensive Late Validation of Settings (#37638)

    Please, test your code. Fixing issues now, before 4.7 is released, helps you and helps millions of WordPress sites.

  • Aaron Jorbin 6:56 pm on November 2, 2016 Permalink |
    Tags: , ,   

    Dev Chat Agenda for November 1 (4.7 week 11) 

    This is the agenda for the weekly dev meeting on November 1, 2016 at 20:00 UTC:

    • Schedule reminder:  The Chat remains at 20:00 UTC.  Day Light Savings Time means that 20:00 UTC may be a different time for you already, or it may be a different time soon.
    • Schedule reminder: Today is the target for Beta 2! That leaves us one week until the final scheduled beta, where the list of tickets should be at zero. It is currently at 74.
    • Ticket reminder: For any tickets you’ve moved into the milestone, please make sure these are active tickets, with some kind of activity in the last 7 days.
    • Call For Bug Scrubs:  Can you run a scrub to help ensure tickets move forward?
    • Dev Notes:  These should all be published this week this week
    • Beta 2:  What needs to be done to get this out the door?
    • 4.6 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!

  • Aaron Jorbin 4:31 am on October 3, 2016 Permalink |
    Tags: ,   

    Bug Scrubs for the week of October 3 

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

    There are only 3 weeks remaining until the first beta for 4.7. To hit this target, there must be no remaining enhancements or feature requests. As of today, there are 72 open tickets that must be closed or punted before October 26.

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

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

    Bug Scrubs This Week 

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

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

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

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

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

  • Aaron Jorbin 3:30 am on September 21, 2016 Permalink
    Tags: , ,   

    Dev Chat Agenda for September 21 (4.7 week 5) 

    This is the agenda for the weekly dev meeting on September 21, 2016 at 20:00 UTC:

    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!

  • Aaron Jorbin 2:40 pm on September 15, 2016 Permalink
    Tags: , ,   

    Dev Chat Summary: September 14 (4.7 week 4) 

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


    As of this meeting, we are 5 weeks from the final deadline to merge major features.
    There are a lot of tickets in the milestone and owners / people who milestoned them need to make sure they are active and moving, or else punt. You can use this report see tickets in the milestone grouped by who moved it there:https://core.trac.wordpress.org/report/61.

    Components and features

    Twenty Seventeen (@davidakennedy, @melchoyce)

    Make sure to checkout both the Announcement post and the latest update. There is no formal meeting this week. Development has started on GitHub. Like many feature projects, it will live on GitHub until it is ready to come into SVN (within the next 5 weeks).

    REST API (@krogsgard, @kadamwhite, @joehoyle, @rmccue)

    Core patches, documentation, and reducing the issue backlog have been the primary focuses. There is a settings registry up (https://github.com/WP-API/wp-api-site-endpoints/pull/13) with a corresponding core patch (https://core.trac.wordpress.org/ticket/37885).

    Feedback is needed on #37885.  Please take a look.

    #38056 is needed for password posts. (update: it has landed).

    The next dev chat is Monday September 19 1400 UTC.

    Media (@mikeschroder, @joemcgill)

    • Still looking for feedback/testing on #22744, but planning to commit soon.
      • If you have a large media library, your help in testing would be particularly helpful.
    • @paaljoachim continued researching UI flows in other platforms and posted a bunch of screenshots in #core-images.
    • Joe shared an outline of what we’re trying to accomplish longer term here in#core-images and would like to talk more about it design side of things during the #design meeting tomorrow, if possible.
    • Still waiting to hear back from folks who were involved in starting up the Core Media Widget #32417 work, but travel has been an issue. Hopefully we’ll have a better update there next week.

    Customize (@westonruter, @celloexpressions)

    • @boone is thinking about/investigating ⁠⁠⁠⁠term_status⁠⁠⁠⁠ for #38015. We have some time to think about it, and could potentially use shadow/draft taxonomies as a workaround for #38014 in 4.7 if needed.
    • tracking the ability to add page stubs or create pages directly from the static front page controls along with this project to facilitate creating pages for initial site setup within the customizer. @westonruter is leading the way on #38013.
    • #34391 is a significant refactoring of code that themes and plugins are encouraged to extend. A corresponding make/core post will follow soon after.
      • Already working with some plugin, theme, and framework authors to minimize breakage.
    • We need some feedback now on #35395 – Custom CSS – @johnregan3 is making great progress.  Please check out the ticket.

    i18n (@swissspidy)

    • #29783 (User Admin Language): in good shape, but not much testing happening so far. We could do much more when #26511 is in core though…
    • #26511 (switch_to_locale()): needs some much needed performance testing. If anyone runs a large WordPress site, I could use your help!
      Also since there are some similarities with switch_to_blog(), I’ll open a new ticket to suggest adding a WP_State interface for such switching functions. Think WP_Site_State, WP_Locale_State, WP_Post_State (see #19572), etc. Not a blocker, but worth keeping in mind for future compatibility.
    • #20491 (JS i18n): I documented the current state in the tasks with responsibilities etc. As of tomorrow I’ll have more time to work on it (mainly on the GlotPress side of things). Also have been thinking about a switch_to_locale() function in JS via Ajax…

    Editor (@azaozz, @iseulde)

    • Post your wishlist items for the editor.

    HTTPS (@johnbillion)

    • Plan of attack for HTTPS work will be published on Make/Core.

    Open floor for tickets and any lingering 4.7 ideas.

    Please review and comment on these tickets:

  • Aaron Jorbin 3:27 pm on September 12, 2016 Permalink
    Tags: ,   

    The Upcoming Week in 4.7: 12 September – 18 September 

    This is the jump-start post for the third week of the WordPress 4.7 release cycle. This release is off to a 🚀 start, and there are 5 weeks remaining for feature projects to be merged. 

    Priorities this week:

    #17817: do_action/apply_filters/etc. recursion on same filter kills underlying call landed recently.  Please make sure to read the associated post and test.

    42 tickets currently milestoned for 4.7 need a patch or unit tests.

    A Media Widget is a commonly requested feature; get involved with #32417 if you would like to make it a reality.

    Core meetings this week:

    All meetings in the WordPress Slack #core channel unless specified otherwise.

    Things to do this week:

    • Nick Halsey 4:09 pm on September 12, 2016 Permalink | Log in to Reply

      Don’t forget about the weekly customize meetings on Mondays at 17:00 UTC in #core-customize (for 4.7). It’s on make/meetings, but missing from the sidebar and these posts.

  • Aaron Jorbin 12:16 pm on August 30, 2016 Permalink
    Tags: ,   

    The Upcoming Week in 4.7: August 30 – September 4 

    This is the jump-start post for the first week of the WordPress 4.7 release cycle. Many projects are still putting together pinkprints for success, so this week is all about getting 4.7 off to a flying start. 🛫

    Priority tickets this week:

    There are currently 3 tickets that require very early consideration.  Please follow them, give feedback, and help test where applicable.

    • #17817: do_action/apply_filters/etc. recursion on same filter kills underlying call
    • #37699: Death to Globals Episode #1: A Registry, A Pattern
    • #36335: Next generation: core autoloader proposal

    Core meetings this week:

    All meetings in the WordPress Slack #core channel unless specified otherwise.

    Things to do this week:

    • Meander through the wishlist comments and give feedback where you feel comfortable
    • Working on a project that you would like to target for 4.7?  Make sure to talk to @helen.
    • Schedule a bug scrub.
  • Aaron Jorbin 8:02 pm on August 25, 2016 Permalink
    Tags: ,   

    Bug Scrubs for 4.7 

    Ensuring tickets move towards a resolution is one of the most important things we can work on as a project. Bug Scrubs serve as one of the ways to make this happen. For 4.7, I would like to invite you to run a WordPress bug scrub. Bug Scrubs can have a general focus, focus on a specific component, or focus on a specific report (such as ancient tickets). Want to learn more? Here is a list of “Potentially Asked Questions”. Have an unanswered question? Ask it in the comments.

    (More …)

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