Dev Chat Summary: February 14th (4.9.5 week 2)

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

4.9.5 planning

  • We’re looking for nominations for people to lead this minor release, self-nominations are very much welcome. Please reach out to @jbpaul17 (@jeffpaulon Slack) or comment on this post with nominations.
  • No timeline set for 4.9.5, but minor releases tend to run 6-8 weeks so we’ll go with what fits with the release leads’ schedule
  • Potential focus for 4.9.5 could be support of foundational work needed to support Gutenberg

Updates from focus leads and component maintainers

  • The PHP team shared a recap from their recent meeting, thanks again to them for documenting that discussion
  • The GDPR compliance team met earlier today, so if you missed the meeting but have interest in the topic you can follow along in the #gdpr-compliance channel.
  • The New Contributor meeting has resumed, thanks to @desrosj for getting that going again

“good-first-bug” claiming process

  • Topic primer from @drewapicture: Gardeners have (mostly) been updating patch-related keywords on `good-first-bug` tickets, but not assigning the tickets which is what actually moves a `good-first-bug` ticket from the unclaimed to the claimed list. I just went through and assigned maybe 40 tickets, which puts the unclaimed list at a much more realistic 4 tickets. It might be worth a discussion about whether we should change the “claiming” behavior to trigger off of adding the `has-patch` keyword vs being assigned. It’s one thing to ask people to just do what needs to be done in the current workflow, but that doesn’t seem to be working, so maybe the better option is to just change how it works so it can be more automagical.
  • Agreement that adding a patch equates to claiming a ticket, conceptually auto-claiming could work
  • Meta#3459 created to track this work

General announcements

Next meeting

The next meeting will take place on February 21, 2018 at 21:00 UTC / February 21, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-5, #core, #dev-chat, #summary

Dev Chat Summary: November 22nd (4.9.1 week 1)

This post summarizes the dev chat meeting from November 22nd (agenda, Slack archive).

4.9 feedback + 4.9.1 planning

  • WordPress 4.9 was released last week, and so far 3 pressing issues have arisen that needs to be addressed in a timely manner:
    • #42573 (template file caching), #42574 (MEJS breaking things for some languages), and #42609 (file editing broken on Windows).
    • As we have a short timeline for this release, focusing on these 3 major issues for now, and planning a future point release for any other regressions appear to be the ideal way forward.
    • @johnbillion has volunteered to run the 4.9.1 release, backed by @sergeybiryukov, we're aiming to have 4.9.1-RC1 on Monday November 27th, with a tentative release date set for Tuesday November 28th.

Request for devchat lead next week

  • @sergeybiryukov has graciously volunteered to help with runnign next weeks Dev Chat, as many of us will be in transit for WordCamp US

Props to @clorith for helping lead devchat and write this summary. 🙌

#4-9-1, #core, #dev-chat, #summary

Dev Chat Summary: October 25th (4.9 week 13)

This post summarizes the dev chat meeting from October 25th (agendaSlack archive).

4.9 schedule

  • Beta 4 dropped late last night / early this morning, please do help test. RC is scheduled to go out on Monday, October 30th and that entails soft string freeze.
  • For all @committers, please let @melchoyce @westonruter know if you are able to help with commits during RC as we’ll need two committers to approve a patch before merging.
  • Bug Scrubs are scheduled on Monday’s and Thursday’s. If you have availability to help run a scrub, please let @jbpau17 know. Any help would be greatly appreciated, thanks!
  • Currently nine tickets that show as needs-dev-note
  • Three Dev Notes coming from @westonruter and one from @rafa8626 (#39686); all could use proofreading
  • If anyone can help draft the Field Guide, please let @jbpaul17 know especially for things around New Action Hooks, New Filter Hooks, Modified Filter Hooks, and External Library Updates.
  • If anyone can help populating the “Developer Happiness” section of the About page, please let @melchoyce know or add notes to #42087

Editor / Gutenberg update

  • Gutenberg v1.5 includes metabox support and likely has advanced cases where the plugin will benefit from feedback and iteration.
  • You can report via GitHub, the feedback form within the Gutenberg plugin, or in #core-editor.

General announcements

  • @johnbillion: The last PHP 7.2 issue, #41526, needs some eyes and can still make it into 4.9 if another patch comes along. The original patch causes some warnings.
  • @paaljoachim: looking for comments on #42324

#4-9, #core, #dev-chat, #summary

Multisite Recap for the week of October 9th

Office Hours Recap

The agenda for this office hours meeting was to review 4.9 bug and task tickets that still need to be finished and merged within Beta, particularly continuing from where the ticket scrub meeting stopped.

The meeting’s chat log

Attendees: @earnjam, @flixos90, @jeremyfelt, @jjj, @johnbillion, @josheby, @spacedmonkey, @stevenkword

Chat Summary:

  • #41936: It was decided that the new filter pre_get_main_site_id should not actually set the WP_Network::$blog_id property when used and only override the return value when accessing it, as it could otherwise have unexpected consequences if a hook set for it was (temporarily) removed. The latest patch had one issue where a variable had not been correctly renamed after moving the code from the function to the class method. It was furthermore discussed how verbose and strict casting the value returned by a filter should be. It was decided to only return the filter value if 0 < (int) $value. Both issues have since been fixed in the latest patch.
  • #38570 and #41652: @sergey is taking care of these i18n tickets.
  • #41789: @johnbillion will provide feedback.
  • As there is now a 5.0 milestone on Trac, the priority tickets that were previously flagged with “Future Release” and “early” are now being moved into the actual milestone.
  • #40364: @flixos90 asked for feedback for this rather complex ticket, as it should preferably get ready early in the 5.0 cycle. That ticket should be discussed in detail in one of the next few weeks, once the multisite work for 4.9 has wrapped up.

Next meeting

The next office hours will take place on October 17th, 2017, 16:00 UTC. Its agenda will be to continue discussing 4.9 tickets and the dev-note for the Networks & Sites component.

Ticket Scrub Recap

The agenda for this ticket scrub was to review 4.9 bug and task tickets that still need to be finished and merged within Beta, similar to the office hours meeting agenda this week (see above).

The meeting’s chat log

Attendees: @afercia, @flixos90, @jeremyfelt, @jjj, @paaljoachim, @spacedmonkey

Chat Summary:

  • #41936: It was decided that moving the logic that is currently in get_main_site_id() is okay to be moved to WP_Network:get_main_site_id(), since that data is very specific to each individual network. It must furthermore be ensured that all values are properly typecast into the expected type (WP_Network::$blog_id is a string, WP_Network::$site_id is an integer and WP_Network::get_main_site_id() should always return an integer). Minor tweaks suggested were returning get_current_blog_id() instead of a hardcoded value of 1 in get_main_site_id() for non-multisite environments and using an internal variable for the cache key used. @spacedmonkey and @flixos90 will make sure this gets ready.
  • #42093: @jeremyfelt has been working on providing an easy way to run unit tests for a subdomain install. This ticket is currently a task scheduled for 4.9, but may as well be punted to 5.0 in case it does not get ready in time.
  • #39419: It was agreed on that the doc block for the globals should indicate replacements to use for those that are deprecated. @jeremyfelt has since updated the patch. It is still being considered whether globals such as $table_prefix, which are used there, but not actually set up there initially should be listed as well.
  • #41789: It was briefly discussed how to be most precise about the documentation of the get_sites() (and related WP_Site_Query method) return value, without making the description overly complex. @jeremyfelt added the final idea as a comment on the ticket and is now waiting for feedback. It was also mentioned that documentation for the other query classes should probably be changed in a similar way, however the ticket for now should only deal with sites and networks.

Next meeting

The next ticket scrub will take place on October 16th, 2017, 17:00 UTC. Its agenda will be to continue discussing 4.9 tickets, particularly the issue that came up with #40228.

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

Dev Chat Summary: September 27th (4.9 week 9)

This post summarizes the dev chat meeting from September 20th (agendaSlack archive).

4.9 schedule

  • Today is the feature project merge deadline
  • Bulk of the code editor improvements already merged into core, along with the Gallery widget
  • Theme browsing in the Customizer and drafting & scheduling in the Customizer to be merged tonight or tomorrow at the latest
  • Beta 1 in next Wednesday, enhancement tickets due by then
  • Bug scrubs scheduled over next week
  • @joemcgill: Anyone wanting to rubber duck #21819 over approaches in the media meeting tomorrow would be good
    • trying to solve a UX issue with a broadly defined outcome and different possibilities include varying levels of tech complexity
  • @danieltj: recommend putting version info into At A Glance metabox #35554
    • @melchoyce: let's get feedback on this and work to a decision in the next couple days

General announcements

  • @azaozz: removal of SWFUpload #41752 needs more testing in the affected plugins
    • would be great to see how the fallback works in all of them, so please help test
  • @kadamwhite: The REST API team is having a bug scrub on Friday at 15:00 UTC, and likely another the start of next week (time TBD). We’ve got a lot of tickets sitting with patches that are pretty close, so if you’ve got outstanding REST patches to discuss hope to see y’all then in #core-restapi!
  • @johnbillion: if anyone is running PHP 7.2 (currently in beta) it'd be great to test trunk. Some fixes will be going in shortly to remove deprecated notices, apart from that it should be bug free.
  • @obenland: Since [41594], orphaned widgets will get merged into the inactive widgets sidebar on theme switch, instead of becoming orphaned. what your opinions are on removing the concept of orphaned widgets entirely, and just have them be part of the inactive sidebar?
    • pre-41594 they would be shown in separate Orphaned Widgets sidebars above inactive widgets
    • @melchoyce: Looking for someone to take screenshots or a video of this in action on 4.8 and on trunk, so we can compare them visually

#4-9, #core, #dev-chat, #summary

Multisite Recap for the Week of August 28th

Office Hours Recap

The agenda for this office hours meeting was to take a look at progress on the multisite roadmap and to continue discussing the best approach to checking for the existence of a wp_blogmeta database table (See #37923).

The meeting’s chat log

Attendees: @flixos90, @desrosj, @stephdau, @dac, @johnbillion, @spacedmonkey, @jeremyfelt

Chat Summary:

  • During the core dev chat, everyone was open to the roadmap being published at make.wordpress.org/core/roadmaps/multisite. The REST API team is also interested in posting a roadmap under that structure.
  • Quite a bit of progress has been made by @flixos90 so far on the multisite roadmap document.
  • A good way to contribute to the roadmap now is to read through critically and make comments/suggestions on the direction and content.
  • Everyone is free to make changes/comments. Ping @jeremyfelt if you would like access.
  • @johnbillion is going to add some items related to multisite administration.
  • More needs to be built out around multisite’s bootstrap and the future of “global context” above the level of network.
  • There was some discussion on what an objective on the roadmap for multisite’s bootstrap may be. Everyone seems to agree that “increasing stability and testability” of the bootstrap is a good objective.
  • There should be a general section at the end that covers some things that don’t necessarily fit as part of the main roadmap at this time. That can be considered “a summary to encourage discussion/contribution even if what you want isn’t on the roadmap.”
  • Quite a bit of ground was covered on #37923 as to whether the existence of a wp_blogmeta table (after upgrade) should be stored as a main network option, as an option on every network, or in a new place entirely.
  • @spacedmonkey brought up concerns about the performance issues of loading an option from a different network. During multisite’s bootstrap, all of the current network’s options are loaded into memory. Storing in a single place would result in an extra DB query/cache lookup.
  • @flixos90 and @jeremyfelt prefer (so far) storing the data as an option on the main network. The idea that a global setting storage may exist one day makes it tempting to treat this data as global now.
  • A next step is to lookup more possible “global context” data that could be stored. @spacedmonkey brought up global terms and ms-files as two immediate options. Brainstorming should continue via chat and on the ticket (#37923).

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 review 4.9 ticket progress.

The meeting’s chat log

Attendees: @flixos90, @desrosj, @sergey, @paaljoachim, @jeremyfelt, @spacedmonkey

Chat Summary:

  • #29684 – Had a lengthy discussion on the possibilities of this ticket. Chatted through whether a networks main site ID should be stored as a network option. For the time being, let’s stick with not storing the data anywhere.

There will be no ticket scrub Monday 17:00 UTC. A schedule and agenda for the next ticket scrub will be posted next week.

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, #network-sites, #summary

Multisite Recap for the week of August 21st

Office Hours Recap

The agenda for this office hours meeting was to brainstorm about finding a solid way to check for the existence of the blogmeta database table for site meta (see #37923).

The meeting’s chat log

Attendees: @dac, @flixos90, @jeremyfelt, @johnbillion, @pmbaldha, @spacedmonkey, @vizkr

Chat Summary:

  • There is no global storage in WordPress, but the blogmeta table exists in global context, therefore we can’t reliably check whether the table exists based on the db_version setting of the current network. We need to find a way to cache this value somewhat globally and work around the limitation.
  • A network option site_meta_supported should be used to store the result of the direct database check. It should only be available on the main network to simulate the one central access point as if the setting was global.
  • A dedicated function is_site_meta_supported() should be developed to check whether the blogmeta table exists in global context or not.
  • The option site_meta_supported should not be set on every network, to prevent unnecessary clutter and to make possible future migration easy.
  • The function is_site_meta_supported() should check a specific filter first. If the filter returns something other than null, the function should return that result immediately. Otherwise it should check the main network’s site_meta_supported option. If that is not set yet, the function should run a direct database query to check for the table existence and populate the main network option accordingly.
  • The upgrade_network() function should set the main network option based on a direct database check.
  • The site meta ticket is getting closer to commit. It should be ready once the suggested changes are in place (see #37923).

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 look at the tickets #40764 and #41344.

The meeting’s chat log

Attendees: @afragen, @desrosj, @ina2n, @pmbaldha

Chat Summary:

  • In multisite, theme updates do not show the new version number. The patch to fix this bug is looking good. There was only some coding standard error (see #40764).
  • Secure Email Integration with SMTP: It was decided that the ticket is plugin territory due to the huge variety of mechanisms and services for sending mail (see #41344).

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

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

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, #core, #dev-chat, #summary

Multisite Recap for the week of July 31st

Office Hours Recap

The agenda for this office hours meeting included the discussion of a “global” state for multisite.

The meeting’s chat log

Attendees: @desrosj, @flixos90, @paaljoachim, @johnbillion, @feshin, @spacedmonkey, @stephdau, @jeremyfelt

Chat Summary:

  • In the multisite context, “global” is the hierarchy level above networks. A global installation of WordPress has one or more networks. Each of these networks has one or more sites.
  • Users are global in that wp_users provides the same set of users used across all sites on all networks. There is no concept of a global role other than super admin. Another level could be created so that a global admin controls all networks and network admins control individual networks.
  • Two important pieces of this discussion are global storage, data about the configuration of the whole, and global roles, data about global users’ relationships with sites.
  • Items that fit under global storage could be a total user count, a total site count, a network count, globally active plugins, globally enabled themes, update checks.
  • @jeremyfelt showed a custom UI for activating and deactivating global plugins. @flixos90 mentioned his global admin plugin as a UI example. It seems like these are good examples of how core can provide APIs to make interfaces easier to build. We should not necessarily be focused on trying to build the UI.
  • There are two options for storing global data — as network ID 0 in wp_sitemeta or as a new global table. After some discussion it seems that using network ID 0 is the best answer. As part of an effort to use the meta API for managing network meta (see #37181), the API will need to be updated to support an object ID of 0. It may be that this is only necessary for network meta, but it’s possible other components could find it useful.
  • The current plan is to implement global multisite storage in wp_sitemeta with a network ID of 0. This is relatively low priority compared to other efforts, but implementation itself will not be too involved. A lot of testing for breakage must be done. As @stephdau mentions, “we all know how much room there is for error with 0 values in data”. 🙂

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 continue reviewing multisite tickets assigned to the 4.9 milestone.

The meeting’s chat log

Attendees: @desrosj, @drewapicture, @flixos90, @florian-tiar, @jmdodd, @sergey, @spacedmonkey

Chat Summary:

  • A third opinion would be appreciated regarding the discussion around #29684 about whether to store the main site of a network in a network option. @spacedmonkey argues that it would provide an easier lookup, while @flixos90 argues that it would be redundant and unreliable because of existing sites not having it and the new get_main_site_id() would be just as easy-to-use.
  • @sergey is going to review #41285 to come to a conclusion whether removing the unused $site_id and $public globals in the multisite bootstrap process would have any bad side effects.
  • #38645 and #36961 are closely related as they both deal with switching context, the first for roles, the latter for user capabilities. Their methods and properties used for that should be similar, for a better DUX. @spacedmonkey pointed out that eventually the new blogmeta table would be helpful with this, however that shouldn’t be the focus of these tickets. At the point of this writing, @flixos90 has updated patches on these that require a review.

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