[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 flixos90):

 Replying to [comment:19 jeremyfelt]:
 > 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?

 In [attachment:40364.4.diff] the value falls back to the one previously
 set. This is indeed only useful when someone passes a falsy network ID
 value to `wp_update_site()`.

 > My gut says that we can probably deprecate it, but I'm not completely
 sure.

 Regarding deprecation, I'd like to add to this ticket what we discussed a
 few weeks ago: Let's only deprecate `insert_blog()` for now. The
 `*_blog_details()` functions can be considered at a later point, when this
 ticket (for `update_blog_details()`, #40180 and #40228 (for
 `get_blog_details()`) and #40201 (for `refresh_blog_details()`) have all
 been merged.

 > 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?

 I think this all ends up being dev-education. As discussed, the functions
 part of this ticket are very low-level. The actual function to create a
 new site will be `wp_create_site()`, which will wrap `wp_insert_site()`
 and a future `wp_install_site()` and will be the de-facto replacement for
 `wpmu_create_blog()`.

 > 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?

 I was following the examples in `wp_insert_post()` or
 `wp_insert_comment()` which use present tense, but I'm not opposed to
 another name. I don't like having only the past tense versions there - if
 they're the only filter, I'd rather use the function name. For other
 examples of how it's been done before, we might wanna look at
 `wp_insert_term()`: That one has to hooks, if we were going with that way,
 it would be `insert_site` and `inserted_site` - not sure how much sense
 that makes. I think I prefer the function name for the filter name,
 alongside with the docblock, which states that it is run ''after'' the
 process.

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