[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:  Future
Component:  Networks and Sites                   |  Release
 Severity:  normal                               |     Version:
 Keywords:  ms-roadmap has-patch has-unit-tests  |  Resolution:
                                                 |     Focuses:  multisite
-------------------------------------------------+-------------------------
Changes (by flixos90):

 * keywords:  needs-unit-tests, needs-patch, ms-roadmap => ms-roadmap has-
     patch has-unit-tests


Comment:

 [attachment:40364.2.diff] is a patch for the new functions following the
 details that we recently discussed:

 * It introduces `wp_insert_site( $data )`, `wp_update_site( $site_id,
 $data )` and `wp_delete_site( $site_id )`. All of these have the sole
 purpose of interacting with the `wp_blogs` database table.
 * Each of the three functions introduces its individual action hook where
 the site object (or in the case of `wp_update_site()` the current and
 previous site object) is passed to the hook.
 * Everything that goes beyond handling the database row and the related
 cache is not part of the respective function, but instead hooked in via
 the aforementioned action hooks. This includes the updating network counts
 process (via a new `wp_maybe_update_network_site_counts_on_update()`
 function) and the site status transition triggers (via a new
 `wp_maybe_transition_site_statuses_on_update()` function).
 * The new `wp_maybe_transition_site_statuses_on_update()` fires the hooks
 that were previously part of `update_blog_details()`. Two new
 `make_public_blog` and `make_private_blog` hooks have been introduced to
 complete the rest of them.
 * It has always been the case that when the `public` status changes, the
 respective site's `blog_public` option is changed accordingly. Since this
 is an action that happens in site scope and not in network scope (like all
 the rest), it must not be tied in with the functionality. Therefore the
 new `make_public_blog` and `make_private_blog` actions are used to hook in
 the new functions `wp_make_blog_public_on_site_update()` and
 `wp_make_blog_private_on_site_update` in order to take care of that
 functionality. In cases where we only wanna test interaction with
 `wp_blogs` without actually creating the site's individual DB tables (in
 unit tests for example), those hooks can be temporarily removed to not
 cause any issues.
 * `insert_blog()` now wraps `wp_insert_site()` and has been deprecated.
 `wpmu_create_blog()` has been adjusted to use `wp_insert_site()`.
 * `update_blog_details()` now wraps `wp_update_site()`.
 * `wpmu_delete_blog()` now uses `wp_delete_site()` to delete the
 `wp_blogs` row.
 * I ran all existing related unit tests to verify the changes work in a
 backward-compatible fashion. In addition I introduced several tests for
 the three new main functions.

 Open questions (particularly important for the review):
 * Should `wp_insert_site()` and `wp_update_site()` contain any additional
 restrictions? At the moment, they do not check for example whether a
 domain and path combination doesn't already exist. I personally think
 that's fine as those are low-level functions and the `wp_create_site()`
 that we're going to introduce later will take care of these checks (that
 are currently handled in `wpmu_create_blog()` too and were not present in
 `insert_blog()`). The only check that is made in these functions is that a
 `domain` is always present. Furthermore if the `path` is empty, a simple
 slash is used.
 * 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?
 * `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? This is different to `insert_blog()` which is very
 rarely used.

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