Dev Chat Agenda for August 23rd (4.9 week 4)

This is the agenda for the weekly dev meeting on August 23, 2017 at 20:00 UTC / August 23, 2017 at 20:00 UTC:

  • Review 4.9 “early” tickets
  • Gutenberg testing
  • Future support for ancient versions of WordPress
  • General announcements

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!

#4-9, #agenda, #dev-chat

Source: WordPress Development Updates

REST API Roadmap

If you’ve been following WordPress development this year, you may be wondering “what’s been happening with the REST API focus?” We’ve been a little under-the-radar for most of the year so far, so we thought publishing an update and roadmap might be a good idea.

For new contributors looking to get involved with the REST API focus or WordPress generally, there’s never been a better time, and we’d love to have your help on our projects. Read on to see what we’ve been doing, where we’re going, and how you can get involved.

Since 4.7

Since the REST API was merged into core in WordPress 4.7, development activity has unfortunately been light. The merge into core was a huge effort, and after shipping in 4.7 we saw a drop-off in contribution and overall momentum as many API contributors took a break to recover from the stress of the merge. These contributions have not returned to previous levels, and there’s a few factors behind this: the move to Trac, lack of a forward roadmap, and overall fatigue have hampered our ability to move forward quickly.

The core REST API focus goal is to utilise the REST API within the WordPress admin. Defining the scope of this project has involved auditing all admin-ajax calls, as well as the filters used inside these calls, and where they are used. In addition, we’ve been working on the low-level JavaScript utilities we need to offer conceptual compatibility: while we can deprecate and remove old PHP filters, we need to offer new JS-based filters to replace them.

The admin-ajax audit revealed that the majority of ajax requests can be grouped into four categories: Media, Themes, the Editor, and List Tables. The code for both Media and the Editor will gradually switch to the REST API moving forward with development around Gutenberg, and likewise endpoints for better managing Themes are expected to be incorporated into Customizer work.

Rather than simply refactor the existing code for the other actions in a piecemeal fashion, we’ve been working on prototyping bigger groups of related changes and features, starting with the New List Tables and Live Settings.

A significant portion of existing admin-ajax code is for handling list table actions. The existing JS code for these actions is particularly difficult to work with, and the existing list table actions user experience is frustratingly inconsistent (for example, deleting a comment happens inline, whereas deleting a post causes a page refresh). A reworking of the code has the potential to improve UX significantly. New List Tables allows us to explore ideas around how we can improve the content organisation and management experience in the admin. This is a prototyping plugin where we’ve been exploring backwards compatibility techniques, and thinking about how a theoretical new management interface would look.

The Live Settings prototype uses the REST API settings endpoints to add live saving to the Settings screens. This dovetails with the work underway by the Accessibility team to switch to the Settings API, and the two projects will be able to work together in the future.

In addition to these API team projects, work has continued on REST API-related pieces on other teams, notably the Customizer and Multisite teams, who are working on API endpoints in their respective components.

Renewing our focus

Moving forward with the REST API, there’s a few key items we’re going to be focussing on. These items will have their own dedicated subteams and development cycles, and will work in parallel. The two broad goals are to use the API in the admin, and to solve authentication for external applications.

API in the Admin

Getting the API used in the WordPress admin is our primary focus. While it is technically possible to directly switch from admin-ajax calls to REST API calls, this is essentially refactoring with no real user benefit. Instead, we want to focus on changes that can improve the user experience.

For the feature prototypes (New List Tables, and Live Settings), we’re engaging members of the Design team to lead these features from a UX perspective. So far, these prototypes have been primarily about proving out the features and ensuring it’s actually technically possible to migrate these features to use the REST API; with the initial success on the technical side, we need to switch focus to delivering compelling user experiences.

New List Tables will be working with the goal of prototyping improved content management, using the REST API. This includes unifying and standardising existing interactions, and improving the perceived performance. This is a React-based prototype, and uses the existing REST API endpoints.

Live Settings will be working with the goal of making settings changes seamless. We’ve seen huge strides forward with the Customizer for updating your site, and the backend settings deserve a better experience to match. Live Settings touches on similar areas as the Settings API Enhanced project spearheaded by the Accessibility team; we plan to continue working independently to avoid blocking each other, while keeping in touch about the respective projects.

Work on converting existing admin-ajax code to use the REST API will continue, however this won’t be a priority, as it generally doesn’t provide a strong benefit to end users. Most admin-ajax actions will naturally be deprecated as part of progress by other focuses, including Gutenberg and plans around the Media Library. We’ll continue working with other teams and focuses on their efforts here.

Authentication

External authentication is an unsolved problem, and one that’s crucial to API use outside of WordPress core itself, including the official WordPress apps.

There are two key problems to solve here: how do apps act on behalf of a user (authentication), and how do sites recognise valid apps (initial connection). We have existing solutions to both these problems (OAuth 1.0a and the Broker system respectively), however these are not the easiest solutions, and aren’t adequate for all use cases.

To date the most complete authentication solution maintained by the REST API team has been a plugin providing OAuth 1.0a authentication. Moving forward, we are switching authentication focus to OAuth 2. As Matt announced last year, we are going to begin shipping HTTPS-only features in WordPress: this allows us to switch to OAuth 2. Work started during the WordCamp Europe contributor day on a new official OAuth 2 provider plugin which is now under ongoing development.

Simplifying the initial connection is a much harder piece, and this is a long-term project. Eventually, this should be as simple as a “Connect to WordPress” button, requiring minimal effort for app developers and no effort for users. This is a complex problem to solve, and no similar software has to work on the same scale we have. In the meantime however, we’re going to investigate pre-configuring Core to recognize and permit authentication from certain default apps, including the official WordPress mobile applications. Whitelisting applications in core is a practical expedient but this solution is not sustainable in the long-term, and should be replaced with a better system as soon as feasible. Work on solving this issue will be in the mid-term, however, as we need to ensure we have solid basics first.

Help Us!

The toughest challenge facing the REST API team right now is resourcing. There are only a few people working on the API regularly, and we need help to build out our projects—which is hopefully where you come in. We need people of all skillsets to help on New List Tables, Live Settings, and OAuth 2. This includes regular contributors, JS developers, and designers. And all of this will need documentation, too: following a productive contributor day at WordCamp Europe we are making progress expanding and reorganizing the REST API developer handbook, and would gladly welcome any interested docs contributors.

Our plan is to release the first public beta of each of these projects within the next month, with regular releases from each project following that. New List Tables and Live Settings could be part of either a 4.9 or 5.0 release, while OAuth 2 will remain as a plugin until fully proven out, and would likely target a core release next year. This also requires coordination with the Mobile team, and finalising the approach to usage inside the apps.

If you’re interested in getting involved, we’d love to get your help. The API holds weekly meetings every Wednesday at 13:00 UTC (next meeting at Wednesday at 13:00 UTC), and we’re always happy to spend time helping people get started contributing.

#rest-api, #roadmap

Source: WordPress Development Updates

What’s new in Gutenberg? (18th August)

0.9.0 🐧

Other changes:

#core-editor, #editor, #gutenberg

Source: WordPress Development Updates

Multisite Agenda for the week of August 21st

Office Hours Agenda

This is the agenda for the weekly office hours meeting on Tuesday 16:00 UTC in #core-multisite.

  • Review progress on roadmap and related discussion.
  • Brainstorm about finding a solid way to check for the existence of the wp_blogs database table for site meta (see #37923).
  • Open floor regarding roadmap, related tickets and suggestions.

Ticket Scrub Agenda

This is the agenda for the weekly ticket scrub meeting on Monday 17:00 UTC in #core-multisite. Note that neither @jeremyfelt nor @flixos90 are available for that meeting, so we are looking for someone to host this one. Please ping one of us on Slack if you’re interested, help is much appreciated. If you want to attend the meeting, please check #core-multisite on Monday to see whether the meeting will take place or has been cancelled. Here is the planned agenda:

  • Review and discuss #41344.
  • Review and discuss #40764.
  • Open floor for any multisite-related bugs and small enhancements.

Please join the chat if you’re interested in one of the topics. In case you cannot make the respective meeting, we will be working on publishing a recap post afterwards. If you have some thoughts beforehand or would like something related to be part of the agenda, feel free to share your ideas in the comments for this post. See you in the chat!

#4-9, #agenda, #multisite, #networks-sites

Source: WordPress Development Updates

New Contributors Meeting Recap – August 16th

Yesterday, the new weekly contributor meeting was held in the #core Slack room. Here is a recap of the meeting. A full chat log is also available.

Participants: @adamsilverstein @brainfork @clorith @davidmosterd @desrosj @dipeshkakadiya @drewapicture @flixos90 @geoffreyshilling @jnylen0 @johnbillion @joyously @justpeace @mikeschroder @milindmore22 @morganestes @mte90 @mrahmadawais @nabil_kadimi @sergey @stevenkword @zakkath

Discussion Highlights

Documentation on core unit test suite

  • There’s currently no documentation on the core unit testing suite in the handbook.
  • The current and best method for learning is to read some of the existing tests and see how they do it. With specific questions, @boone and @johnbillion are always good people to go to.
  • Several developers indicated their interest in working on an introduction or documentation for it. Any results will be published in a future meeting.

Documentation on contributing with Git

  • Documentation on Git contributions is still lacking. Most typical handbook pages with patch instructions only reference SVN commands and don’t have Git examples. @morganestes will start working on consolidating pages and instructions and would love to have some guidance on contributing tests as part of that.
  • @jnylen0 shared a handbook page specific to contributing with Git.

Documentation on getting started with contributing

  • There’s not a very good “Getting Started” documentation in the handbook. It throws several things at you in different pages. You can learn how things technically work, but not really how to get started from a workflow/mindest point of view.
  • @adamsilverstein shared what is probably the best “Getting Started” page for core contributing.
  • However where you start, to a large extent depends on your preferences. It’s important to find one or two areas of core in which you’re most interested in and concentrate on those first.
  • To get a feeling for what is being worked on and how these processes work, participating or even just lurking in meetings can help a lot. Show up to some dev chats, and other component meetings you’re interested in.
  • If you don’t need to do it remotely and have the possibility to attend a WordCamp, probably the best way to start is attending a contributor day. The in-person communication has huge benefits, especially for the beginning.

Moving tickets forward

  • Persistence is generally key in keeping your patches moving on trac. Knowing who to ping and how often can take you a long way. Start with the component maintainers and work out to the core developers. Ask for feedback at a dev chat, or if you don’t want to jump in yourself ask whomever is running dev chats to toss out the ticket for public discussion.
  • Ping specific people, don’t worry about being annoying or anything. It can happen that someone is short on time and does not respond immediately, and that may feel like a bummer. But every core developer is trying to help, so do not hesitate being persistent. Actually, component maintainters and core devs expect to get pinged and try to make core contributing as welcome as possible.
  • The easiest way to get in touch is commonly in a component meeting if there is one. But if there is none, pinging a maintainer is the way to go.

Changing workflow keywords on tickets

  • Everyone can and should properly apply and modify workflow keywords on a ticket. Here are some examples:
    • If you add a patch, add the has-patch keyword if it isn’t set yet.
    • If you provide tests, add the has-unit-tests keyword if it isn’t set yet.
    • If you feel a patch is rather complex, feel free to add dev-feedback.
  • If you aren’t sure that your patch addresses the issue, or if you don’t feel that you understand the issue well, it’s best to let someone else look and change the keywords appropriately. But also no worries, if you accidentally or mistakenly set a “wrong” keyword.

Next Week’s Meeting

The next meeting will take place in the #core slack channel on Wednesday, August 23, 19:00 UTC. Please feel free to drop in with any questions or tickets you’d like to discuss!

Thanks to everyone that attended! As always, please feel free to leave a comment below or reach out to any of the moderators (@adamsilverstein, @desrosj, @stevenkword, @welcher) with questions on Slack. Or, as mentioned above, to any core developer or component maintainer with questions specific to certain core areas.

#new-contributors, #summary

Source: WordPress Development Updates

PHP Meeting Recap – August 14th

This recap is a summary of this week’s PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

The meeting’s chat log.

Attendees: @afragen @desrosj @dimadin @drewapicture @flixos90 @jdgrimes @mikeschroder @nerrad @pross @schlessera @sergey @spacedmonkey @stevenkword @tfrommen

Chat Summary

The agenda for this week’s meeting to continue our efforts for the planned .org page to educate and convine mainly non-technical users about the benefits and necessity of PHP upgrades. Here are the highlights from the discussion:

  • There is now a new GitHub organization for the core PHP team, and a repository as a central location for the work towards the new page, which now lives under the temporary codename “servehappy”.
  • There’s furthermore an additional repository as a collection of third-party resources on the topic, such as articles or hosting-/tool-specific upgrade tutorials. Some of those will be good references and inspiration for our own version.
  • Everyone is welcome to contribute to both of those.
    • The primary task for the “servehappy” repository will be to open issues for the benefits we’ve come up with over the past few weeks, and discuss them one by one, whether they qualify for the page and how they can be framed in the most convincing way. A project board exists to get a quick overview about where each of those benefits stands in terms of workflow.
    • Any useful resource found about the topic should be added to the resources repository. This can happen in a very intuitive way, as you don’t even have to fork the repository to enhance it. Simply use one of the file editing buttons to make your changes, and create a pull-request from it. Enhancing the resources list is much appreciated too.
  • @nerrad suggested to also have issues for the different sections planned for the page (see last week’s recap for the proposed outline). A project view for these has been created since, which is a work in progress.
  • While we call the first section “What we want from you”, this title should only be used for ourselves to remind us what we’re using the page for and that this should be conveyed in the first section. However, that should be phrased in a way so that the site visitor does not feel put under pressure. It should go more into a direction like “Once you’ve read this page, you will want this too”.
  • The section “What should you need to know before doing an update?” must not unnecessarily make the user worry. Let’s highlight possible issues, but not overestimate them. People should see upgrading as a good thing, and we should point them at how they can determine whether their sites are ready.
  • Users should briefly be educated about the natural requirement of software updates, and that PHP is just the same. Phrases like “Now you need to do this every … months” must not be used, but a more general way that highlights the benefits of staying up to date and that, in order to do so, upgrades are occasionally required. If site owners are not made aware of this, the next upgrade request will be just as painful as this one.
  • An important goal of the page is to improve the distribution of the PHP versions as collected by the installation/update stats of WordPress.org.
  • At the end of the chat, we talked about PHP versions a bit, and which jumps were more critical or problematic than others.@mikeschroder highlighted that the jump from 5.2 to 5.3 was actually one of the hardest, while 5.6 to 7.0 was quite smooth. @schlessera added that 7.1 is a bit more problematic than 7.0 because of some of the changes involved.@mikeschroder will try to see if they still have data at DreamHost about the 5.2->5.3 jump that they could share. He furthermore reminded ask to ask more of these questions in the #hosting-community channel.

The takeaway of this week was that we should finally get in touch with the marketing team. Let’s work on adding a brief one or two sentences for each of the sections that were proposed in last week’s meeting to give them more context, to provide a better foundation for the #marketing team. This can happen via GitHub. More benefits should be added as issues on GitHub as well.

Next week’s meeting

The next meeting will take place on Monday 18:00 UTC, as always in #core-php, and its agenda will be to continue discussing the page outline, benefits and further coordination. If you have suggestions but cannot make the meeting, please leave a comment on this post so that we can take them into account. See you next week!

#core-php, #php, #summary

Source: WordPress Development Updates

Dev Chat Summary: August 16th (4.9 week 3)

This post summarizes the dev chat meeting from August 16th (agendaSlack archive).

Feedback on 4.9 goals

  • @johnbillion: as part of ongoing Security focus, planning on several user account security related changes, for example bringing some of the Multisite confirmation emails when you change your email address into single site
  • @flixos90: Multisite team is working on REST API endpoints for the multisite objects, like sites and networks, plus improvements to the users endpoint that make it compatible with multisite
  • @westonruter: just published 0.2.0 of the codemirror-wp plugin which adds an a11y option to the user profile screen to opt-out of syntax highlighting in the same way that a user can opt-out of the visual editor
  • @westonruter: feedback and help welcomed via the CodeMirror repo
  • @westonruter: Customizer drafting and scheduling (essentially porting the features from the Customize Snapshots plugin) is currently working through designs with @joshuawold, once that’s set this will move to implementation

Component roadmaps

  • @desrosj: Multisite team using weekly meetings to re-organize the Network & Sites component’s roadmap to align with Core’s current focuses and the component’s short and long term goals
  • @desrosj: We propose using make.wordpress.org/core/roadmap/ as a location for components to house their roadmaps (multisite living at `make.wordpress.org/core/roadmap/multisite`) as roadmap posts on the Make/Core blog slowly get pushed away as new posts are published
  • @desrosj: The roadmap outline (brief descriptions of each item, a timeline, some tickets to focus on immediately) would live on these roadmap pages, and link out to make blog posts with specific details about each item.
  • Agreement to proceed with this with Multisite and assess how its working before pushing other components to do the same

General announcements

  • @koenhuybrechts: looking for update on #17268
  • @mte90: looking for update on #12955
    • @drewapicture: concern with potential performance hit due to the sheer number of times it’s called on a given page load; will leave a comment on the ticket
  • @mte90: looking for an update on #13657
    • No one around related to the Database component, will continue to look for updates via the ticket
  • @mte90: looking for an update on #40542 as well as my other patches

#4-9, #components, #core-customize, #core-multisite, #core-restapi, #dev-chat, #roadmaps, #security, #summary

Source: WordPress Development Updates

Multisite Recap for the week of August 14th

Office Hours Recap

The agenda for this office hours meeting was to discuss the format of the multisite roadmap that will be compiled from many of our recent conversations.

The meeting’s chat log

Attendees: @desrosj, @flixos90, @spacedmonkey, @vizkr, @jeremyfelt

Chat Summary:

  • An initial multisite roadmap document has been started. If anyone would like access to edit, please ping @jeremyfelt on Slack.
  • The previous multisite roadmap (2013) was verbose. @jeremyfelt mentioned that it provided the thought process behind a lot of things that were going to become decisions at some point.
  • That the previous roadmap was posted on make/core and then lost in the timeline makes discoverability difficult.
  • There should be a specific URL where the roadmap can be published and evolve over time. Additional (verbose) updates on progress or new initiatives can be posted as posts on make/core and then linked from the roadmap as needed.
  • During the weekly core dev chat, we’ll propose a make.wordpress.org/core/roadmap/ structure under which make.wordpress.org/core/roadmap/multisite/ can exist as well as pages for other components or focuses.
  • It’s also possible we can follow the customizer component’s lead and publish under https://make.wordpress.org/core/components/networks-sites/. Note that this only covers one component rather than the focus.
  • A ticket should be created for everything we plan so that people can help when available.
  • @flixos90 is going to spend some time working on the roadmap document some more to get it closer to the format that we’ve been discussing.

The next office hours will take place on Tuesday 16:00 UTC. An agenda for it will be posted in advance.

Ticket Scrub Recap

The agenda for this ticket scrub was to discuss approaches for better clarifying site statuses, and then have an open floor for further tickets.

The meeting’s chat log

Attendees: @flixos90, @sergey, @ina2n, @afragen, @pmbaldha, @paaljoachim, @desrosj, @spacedmonkey, @jeremyfelt

Chat Summary:

  • #17164 – More elegant handling of site ‘archive’ options for Multisite
  • #39158 – Unify site deactivation process
  • #15801 – Network Admin: Deactivated / Deleted inconsistency
  • These 3 tickets are all related in some way, though deal with different issues around site statuses.
  • The checkboxes at wp-admin/network/site-info.php don’t convey any real information about their meaning or a workflow.
  • Different terms are used in the MS sites list table for network admins (deactivate) and in the site admin (delete).
  • Different error messages are displayed on the front end when a site is archived or deactivated. There should be better documentation for what these mean in the screen help.
  • @flixos90 – “Deactivating should be called deactivating everywhere”, “we should only use the term Delete when it really is delete”
  • It seems that #39158 is a ticket about workflow and unification of deactivate/delete. #15801 is a ticket about terminology.
  • Priorities via @flixos90:
    • change Deleted to Deactivated where it’s not actually Deleted
    • Figure out what all these actions do exactly.
    • Document what these actions do
  • We need to support these workflows in the sites endpoint.
  • #40736 – Ensure that get_blog_count() and get_user_count() return an integer. Specifically—Can the return type be safely changed without issue and/or should we deprecate get_blog_count() in favor of get_site_count(). We aren’t too worried about changing the return type as this function doesn’t appear to be used much outside of core.
  • #41344 – Secure Email Integration. We agreed to look at this ticket next week.
  • #40764 – Multisite theme update not showing new version number. This ticket came up right at the end and can be covered next week.

The next ticket scrub will take place on Monday 17:00 UTC. An agenda for it will be posted in advance.

If you were unable to attend one of these meetings but have feedback, please share your thoughts in the comments on this post. In case there’s a need for further discussion we will ensure to make time for it in one of next week’s chats. See you next week!

#4-9, #multisite, #networks-sites, #summary

Source: WordPress Development Updates

Dev Chat Agenda for August 16th (4.9 week 3)

This is the agenda for the weekly dev meeting on August 16, 2017 at 20:00 UTC / August 16, 2017 at 20:00 UTC:

  • Feedback on 4.9 goals
  • Component roadmaps
  • General announcements

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!

#4-9, #agenda, #dev-chat

Source: WordPress Development Updates

X-post: Community Conduct Project – Kick off meeting scheduled for 17:00 UTC on the 5th September 2017

X-Post from +make.wordpress.org/updates: Community Conduct Project – Kick off meeting scheduled for 17:00 UTC on the 5th September 2017

Source: WordPress Development Updates