[wp-trac] [WordPress Trac] #40364: Improve site creation in multisite

[WordPress Trac]

#40364: Improve site creation in multisite
-------------------------------------------------+------------------------
 Reporter:  jeremyfelt                           |       Owner:  flixos90
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  4.9
Component:  Networks and Sites                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  ms-roadmap has-patch has-unit-tests  |     Focuses:  multisite
-------------------------------------------------+------------------------

Comment (by jeremyfelt):

 This is looking good, thanks @flixos90! I added a slightly tweaked patch.
 Some comments/thoughts:

 > Should wp_insert_site() and wp_update_site() contain any additional
 restrictions?

 * It's tempting, but it's never happened at this low level before
 (`insert_blog()`, `update_blog_details()`), and I think we can avoid it.
 It's probably worth thinking about some more before we implement. Domain
 and path validation would specifically be interesting if it fit.
 * I did update the patch to trim the domain before checking emptiness.

 > When no site_id (network ID) is passed, the main network ID is used. Is
 that desired or should it rather use the current network ID?

 * I think we should use the current network ID if one is not specified. I
 would probably specify it every time myself, but I can imagine being
 confused in a multi network environment if the site ended up on another
 network when I didn't.
 * Related: In `wp_update_site()`, what case would lead to `site_id` being
 empty? It should already have one from the old site object. Are we
 protecting against `false` or `0` being passed to `wp_update_site()`? If
 so, maybe it should fall back to the old site's value instead of the
 main/current network?

 > update_blog_details() has now just become a simple wrapper for
 wp_update_site(). I generally would say that it should be deprecated, but
 since it is so widely used, I'm not sure that's a good step. What are the
 thoughts here?

 * How widely used is it outside of core? My gut says that we can probably
 deprecate it, but I'm not completely sure.

 And the remaining:

 * This isn't a new problem, and could be another ticket, but should we
 think about adding a check for the new site's options table in `WP_Site`'s
 `get_details()`? If I do `wp_insert_site( $args )` and then immediately
 look for `get_site( 2 )->home`, I'll get an error because `wp_2_options`
 doesn't exist. Should I know enough as a dev to avoid that myself without
 a kinder warning?
 * Updated patch to remove a now unused `$wpdb` in `update_blog_details()`
 * The action names `wp_insert_site`, `wp_update_site`, and
 `wp_delete_site` don't necessarily clarify on their own (to me) that the
 action is fired after the function has performed its main task. What about
 `wp_site_inserted`, `wp_site_updated`, and `wp_site_deleted`? Or something
 else?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/40364#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform