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, #gutenberg, #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, #bug-scrub, #core, #dev-chat, #media-widgets, #php7, #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, #components, #core-customize, #core-multisite, #core-restapi, #dev-chat, #roadmaps, #security, #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

New Contributors Meeting Recap – August 2nd

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 @asalce @azerial @chetan200891 @circlecube @clorith @desrosj @dipeshkakadiya @dnavarrojr @e_baker @helen @jdmensing @johnbillion @jorbin @josiahsprague @joyously @kelseyfecho @linsoftware @luckyankit @milindmore22 @mte90 @nabil_kadimi @proscriptsell @punit5658 @stevenkword @t-rave @welcher @zakkath

Discussion Highlights

Before Creating Tickets

  • Before creating a ticket, there are a few things you should do:
    • Ensure you are running the latest version of WordPress (if reporting a bug).
    • Search Trac to make sure a ticket for your bug or enhancement.
  • Creating a duplicate ticket is ok, as long as you did your best to find a pre-existing ticket.

Writing a Title

  • A good ticket title should accurately summarize the problem the ticket addresses.
  • Someone should be able to see the title and get the general idea of what the ticket is trying to solve, not the solution.

Writing a Description

  • A ticket description should include:
    • A description of the behavior you expect and why
    • A description of the behavior you are seeing
    • Steps to reproduce the behavior so other contributors can see it for themselves and track down the source.
    • If an enhancement ticket, describe what it improves upon and why this is beneficial.
  • If it involves something else (like a specific browser, or server type), make sure to detail that as well.
  • If applicable, screenshots are also very helpful.
    • Screenshots are best uploaded directly to Trac. This prevents images from becoming dead links when removed from external image sources.
  • Always try to focus on the problems being solved, even if it’s an enhancement, you are trying to solve a problem of some sort.

Examples of tickets with good titles and descriptions: #41525, #37013.

What is the difference between Core and Meta Trac?

Core Trac is meant for tickets relating to the WordPress software you install and run (including unit tests). Meta Trac is meant for a bunch of other things, but mainly things that are WordPress.org related. There is a full list at the top of the Meta Trac home page.

Security Vulnerabilities

It is very important that any issues with security implications be reported through responsible disclosure privately. For more information on reporting security vulnerabilities, see the WordPress Handbook.

What is considered “enough testing”?

  • This will vary based on the ticket and what problem is being solved.
  • Testing may span multiple releases for complex problems.
  • It also is up to the committer that chooses to take ownership of the ticket. They need to be completely comfortable with the change, and confident that there is little to no potential for issues.
  • Once committed, the testing does not end. Testing continues by using trunk.
  • After that, the alpha, beta, and RC releases are in place to catch anything that might have been missed.

Is there a protocol for old tickets that have become stagnant?

  • Check that the problem or enhancement in the ticket is still relevant.
  • Test any patches on the ticket to ensure they still apply cleanly.
  • Test that the patch still solves the issue.
  • Add the needs-refresh tag if not.
  • Stagnant tickets can be frustrating, but remember, no one is purposefully ignoring your efforts. Most (if not all) of the folks here are volunteers working in their free time.

Tickets discussed

  • #39535 – Canonical redirects disallow tag named comments
  • #37057 – Creation of an esc_html functions for _n(), _nx(), _ex(), and number_format_i18n()
  • #41521 – Menu list with dropdown icon alignment bug in responsive.
  • #41497 – Menu has style problem in listing on admin menu page

Next Week’s Meeting

The next meeting will take place in the #core slack channel on Wednesday, August 9, 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.

#new-contributors, #summary

Multisite Recap for the week of July 23rd

Office Hours Recap

There was no agenda post this week. This week’s chat was a continuation of last week’s. The conclusion last week was: more discussion around specific items that will be in the roadmap is needed in order to construct an effective roadmap.

The first item to be discussed (and the topic for this week’s office hours) was network meta.

Meeting’s chat log

Attendees: @desrosj, @flixos90, @jeremyfelt, @johnbillion, @maximeculea, @mista-flo, @spacedmonkey, @stevenkword

Chat Summary:

Discussed in the meeting were current pain points and limitations in network options that network meta (the replacement) would help address:

  • Autoloading network options is very poor. Only a predefined list of core options are autoloaded and cached properly. Any other code utilizing network options without object caching causes additional queries.
  • Network options are a siloed area of Core that only multisite developers utilize. This prevents growth, and sometimes allows long lasting bugs.

Also discussed were other benefits of introducing network meta:

  • The Meta API is used by many other areas of Core and has many more developers using it. It is a very solid foundation. Using it means network meta will receive any improvements to the Meta API with a trivial amount to no effort.
  • Allows networks to be queried with a meta_query(see #38025).
  • Allows *_network_options to utilize the metadata API (see #37181).
  • WP-CLI already uses the Meta API for network options.
  • Converting network options to meta makes everything much cleaner and easier to maintain.
  • Network meta opens the door for networks in the REST API, allowing them to be consistent with other meta endpoints.

Some things to keep in mind:

  • A good list of goals that summarizes previous discussions.
  • If network and network meta REST API endpoints are merged into utilized by Core, they should give developers the tools needed to manage networks, but be un-opinionated (custom plugins and code like WP Multi Network are for opinionated).
  • There are likely not many people utilizing *_network_option(). Of those uses, it’s more likely that it’s to manage core network options. If they use it to manage custom network options, then it should be single only.
  • Meta query is closely connected to meta and should be rather trivial to implement.

The suggested workflow moving forward:

  • Reopen #37181 (for network meta API inside of the network options API).
  • Open a ticket for a networks endpoint.
  • Open a ticket for a network meta endpoint.
  • Add site meta endpoint to #40365 (to be discussed in a future office hours meeting).
  • Add all of these tickets to the ms-roadmap keyword.
  • The first thing needed would be #25344Introduce *_network_meta() functions

Problems that were solved and other important thoughts:

  • Network options are always $key => $value while network meta would be $key => $values (multiple ones). So there could be conflicts if people misuse it. However this was considered a negligible issue that can easily be prevented by properly educating developers about the changes in a dev-note. The internal usage of the Meta API in the *_network_option() functions will be implemented in a way that prevents this.
  • When/if network meta is implemented, it should be clarified that existing core options will always be treated as single.
  • get_network_option() should always return the first value, if multiple values exist for it (which should not happen per the above).
  • Migrating network options should be the last step (#37181 – Use metadata api in *_network_options will be reopened for keeping those concerns separate).

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 tickets targeted during this ticket scrub were tickets in the 4.9 milestone with multisite focus or the Networks and Sites component.

The meeting’s chat log

Attendees: @earnjam, @euthelup, @flixos90, @jeremyfelt, @sergey, @spacedmonkey,

Chat Summary:

  • The meeting ended up being a discussion entirely dedicated to #29684 and the get_main_site_id() function it will introduce.
  • There are two patches on it both of which have advantages and disadvantages. A combination of both will be best (see below).
  • The function should rely on the multisite constants if they are set.
  • Instead of relying on the cache, a network option main_site should be introduced for this data. This will allow relying on that option and only run the more complex query logic in case it is not set. Furthermore, it allows more custom things by letting developers filter the option. When creating a new network, the option should be set from the beginning on, while for existing networks it should be set as needed.
  • The function should only use the domain and path-based comparison if no main site value has been stored and no such constants are set.
  • The existing cache key, although not necessary any longer, should probably be preserved for backward-compatibility.
  • @flixos90 is going to create a new patch which @jeremyfelt will then 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