Office Hours Recap
The agenda for this office hours meeting was to discuss whether a function to retrieve a site by specific details should be introduced as a successor to the legacy-bloated
The meeting’s chat log
Attendees: @desrosj, @drewapicture, @earnjam, @flixos90, @jeremyfelt, @jmdodd, @spacedmonkey, @stephdau, @stevenkword
- It was decided that the
get_site_by() function proposed in #40180 should be introduced. It might need to get a more suitable name though. While it can work similar as other existing functions like
get_term_by(), a significant difference is that it can also accept an array of multiple fields to query by, which makes the name a bit confusing.
- Some examples of how get_site_by() can be used:
get_site_by( 'id', 2 )
get_site_by( 'slug', 'subsite1' )
get_site_by( array( 'domain' => 'mainsite.com', 'path' => '/subsite1/' ) )
get_site_by( 'domain', 'subsite1.mainsite.com' ) (only works in a subdomain install)
- In addition to the above, a lookup by path only, when in a subdirectory network (versus site, blog), should be supported as well, but isn’t in the latest patch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing..
- In the documentation it should be clarified that, when multiple results are found which can theoretically happen, the first result will be returned.
get_blog_details() will wrap the new function, and apply some tweaks to remain backward-compatible.
- After the discussion, it was time for an open floor:
*_blog_details() functions were further discussed in regard of a possible deprecation. They are still widely used, so that should probably not happen any time soon. It was however decided that, once the changes in #40364, #40180, #40228 and #40201 have been completed, a new ticket Created for both bug reports and feature development on the bug tracker. should be opened to further discuss the path towards deprecating
refresh_blog_details(), all of which will be unnecessary at that point.
- The new site CRUD Create, read, update and delete, the four basic functions of storing data. (More on Wikipedia.) functions from #40364 should only be merged once the wrapping functions that handle both the
wp_blogs table as well as setting up the individual site tables are ready as well. It should be clarified that the CRUD functions do not actually set up the site’s database tables and should not be used on its own in most cases.
- @drewapicture brought up #25650, which deals with a rather critical bug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. that has been around for a while: When switching to another site in multisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site, the media base URLs still point to the original site. @flixos90 proposed a
get_content_url( $blog_id = null, $path = '' ) function that could help with this. @drewapicture will have a closer look at the ticket.
- All planned discussions for the multisite roadmap have been completed now, so @jeremyfelt and @flixos90 will be focussing on elaborating the results into a proper format over the next couple days and weeks.
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 finish reviewing multisite tickets assigned to the 4.9 milestone, and then have an open floor for further tickets.
The meeting’s chat log
Attendees: @desrosj, @flixos90, @jeremyfelt, @mista-flo, @sergey, @spacedmonkey, @vizkr
- A third opinion for #29684 was requested as the discussion there needs further input to proceed.
- #36961 (a bug where initializing user capabilities for another than the current site fails) and #38645 (which aims at improving role switching) need reviews. They are kind of related as they both deal with site switching. @flixos90 has patches up that revamp the switching process for both to bring them in line with each other and improve some unnecessary legacy bloat. While they do more than switching the original bug, without these changes the bug could only be fixed in a quite hacky way. @jeremyfelt will review these proposals.
- @spacedmonkey is working on patches for the site meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. related tickets #37923 and #40229. He has also worked on network meta code and will update all these tickets soon.
- @flixos90 has a patch up for #40364, which will provide the foundation for the planned
wp/v2/sites endpoint for the REST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. by implementing a full CRUD API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. for sites. A particular focus for the new functions was to only deal with the
wp_blogs table and have all connected functionality be handled by hooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.. @jeremyfelt has since reviewed the ticket and patch and left a comment.
- #40764 and #41538 are both being reviewed by @swissspidy.
- #41538 is a straightforward fix, but should wait until #39677 has been merged to account for the new capability.
- Open floor:
- @spacedmonkey brought up #41507 as part of a few tickets to improve the understanding of the multisite codebase. The ticket was milestoned and has since been committed.
- In relation to function replacements, @flixos90 brought up replacing the
*_network_option() calls once the
*_network_meta() functions are in core Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. In the discussion it was decided that the network meta functions cannot be a direct replacement for the network option functions, as meta functions have always required passing an ID and should continue to do so. They can still replace them in several areas, however a solution needs to be found for the hooks that the
*_network_option() functions trigger, but the
*_network_meta() functions wouldn’t.
- @jeremyfelt pointed out #41520 in the above discussion, as WordPress never removes deprecated functions. It would be helpful if a setup could take care of that manually by setting a specific constant preventing deprecated functions from being loaded.
- @spacedmonkey asked for feedback on #41510. The ticket has been milestoned and committed as of now.
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!