[wp-trac] [WordPress Trac] #41333: Implement `wp_initialize_site()` and `wp_uninitialize_site()`

WordPress Trac noreply at wordpress.org
Mon Sep 24 15:08:35 UTC 2018


#41333: Implement `wp_initialize_site()` and `wp_uninitialize_site()`
-------------------------------------------------+-------------------------
 Reporter:  flixos90                             |       Owner:  flixos90
     Type:  enhancement                          |      Status:  closed
 Priority:  normal                               |   Milestone:  5.0
Component:  Networks and Sites                   |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  ms-roadmap has-patch needs-dev-note  |     Focuses:  multisite
  has-unit-tests                                 |
-------------------------------------------------+-------------------------
Changes (by flixos90):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"43654" 43654]:
 {{{
 #!CommitTicketReference repository="" revision="43654"
 Multisite: Introduce a site initialization and uninitialization API.

 This changeset makes the new CRUD API for sites introduced in [43548]
 usable for real-world sites. A new function `wp_initialize_site()`, which
 takes care of creating a site's database tables and populating them with
 initial values, is hooked into the site insertion process that is
 initiated when calling `wp_insert_site()`. Similarly, a new function
 `wp_uninitialize_site()`, which takes care of dropping a site's database
 tables, is hooked into the site deletion process that is initiated when
 calling `wp_delete_site()`.

 A new function `wp_is_site_initialized()` completes the API, allowing to
 check whether a site is initialized. Since this function always makes a
 database request in its default behavior, it should be called with
 caution. Plugins that would like to use site initialization in special
 ways can leverage a `pre_wp_is_site_initialized` filter to alter that
 default behavior.

 The separate handling of the site's row in the `wp_blogs` database table
 and the actual site setup allows for more flexibility in controlling
 whether or how a site's data is set up. For example, a unit test that only
 checks data from the site's database table row can unhook the site
 initialization process to improve performance. At the same time,
 developers consuming the new sites API only need to know about the CRUD
 functions, since the initialization and uninitialization processes happen
 internally.

 With this changeset, the foundation for a sites REST API endpoint is fully
 available. The previously recommended functions `wpmu_create_blog()` and
 `wpmu_delete_blog()` now call the new respective function internally.
 Further follow-up work to this includes replacing calls to
 `wpmu_create_blog()` with `wp_insert_site()`, `update_blog_details()` with
 `wp_update_site()` and `wpmu_delete_blog()` with `wp_delete_blog()`
 throughout the codebase.

 As a side-effect of this work, the `wpmu_new_blog`, `delete_blog`, and
 `deleted_blog` actions and the `install_blog()` function have been
 deprecated.

 Fixes #41333. See #40364.
 }}}

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


More information about the wp-trac mailing list