[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:  5.0
Component:  Networks and Sites                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  ms-roadmap has-patch has-unit-tests  |     Focuses:  multisite
-------------------------------------------------+------------------------

Comment (by flixos90):

 Replying to [comment:50 spacedmonkey]:

 Thanks a lot for the review!

 > Change this action to a filter `do_action( 'wp_validate_site_data',
 $validity, $data, null );` to a filter. It the conversion in WordPress, if
 you are going change a value, developers use filters. They wouldn't think
 to use an action. I think developers will find it weird.
 Technically, it doesn't make sense for this to be a filter since objects
 (i.e. `$validity`) are passed by reference in PHP. If though, the general
 opinion is that this should be a filter for how WordPress developers are
 used to do it, I'm not entirely opposed to changing it. I'd like to have a
 third opinion here.

 > - If you pass an id into `wp_insert_site`, it should pass to
 `wp_update_site` to bring it into line with other crud functions. If it
 doesn't do this, at least handle this as error.
 That `wp_insert_post()` and `wp_update_post()` behave like this is very
 unexpected as it is not explicit at all. Because these here are new APIs
 for which we try to make things better, I vote for not doing this solely
 for the sake of compatibility with those two functions (especially since
 not all WordPress object CRUD functions behave like the latter either).

 > - The following lines need to be changed as they are filter not actions.
 > `add_action( 'wp_normalize_site_data', 'wp_normalize_site_data', 10, 1
 );` -> `apply_filters( 'wp_normalize_site_data', 'wp_normalize_site_data',
 10, 1 );`
 > `add_action( 'wp_validate_site_data', 'wp_validate_site_data', 10, 3 );`
 ->   `apply_filters( 'wp_validate_site_data', 'wp_validate_site_data', 10,
 3 );`
 Good catch, I'll implement this soon!

 > - Should the actions `do_action( 'delete_blog', $blog_id, $drop );` and
 `do_action( 'deleted_blog', $blog_id, $drop );` be moved to the
 `wp_delete_site`? I know that the drop tables param doesn't really map,
 but I am wondering if they will be breakage without these actions.
 It's helpful that you bring this up, I haven't considered it before. I
 think we should deal with this in #41333 as it goes more into the flow of
 uninstalling the site and in the current state of the patch works fully
 backward-compatible.

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