2010-02-13 17:35:11 -05:00
< ? php
/**
* Site / blog functions that work with the blogs table and related data .
*
* @ package WordPress
2010-02-14 20:08:23 -05:00
* @ subpackage Multisite
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2010-02-13 17:35:11 -05:00
*/
2019-01-08 04:15:49 -05:00
require_once ( ABSPATH . WPINC . '/ms-site.php' );
require_once ( ABSPATH . WPINC . '/ms-network.php' );
2010-09-30 21:32:31 -04:00
/**
2016-01-27 22:35:27 -05:00
* Update the last_updated field for the current site .
2010-09-30 21:32:31 -04:00
*
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2010-09-30 21:32:31 -04:00
*/
2010-02-13 17:35:11 -05:00
function wpmu_update_blogs_date () {
2017-10-01 21:44:47 -04:00
$site_id = get_current_blog_id ();
2010-02-13 17:35:11 -05:00
2017-10-01 21:44:47 -04:00
update_blog_details ( $site_id , array ( 'last_updated' => current_time ( 'mysql' , true ) ) );
2013-12-01 12:32:10 -05:00
/**
* Fires after the blog details are updated .
*
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2013-12-01 12:32:10 -05:00
*
2016-01-27 22:35:27 -05:00
* @ param int $blog_id Site ID .
2013-12-01 12:32:10 -05:00
*/
2017-10-01 21:44:47 -04:00
do_action ( 'wpmu_blog_updated' , $site_id );
2010-02-13 17:35:11 -05:00
}
2010-09-30 21:32:31 -04:00
/**
* Get a full blog URL , given a blog id .
*
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2010-09-30 21:32:31 -04:00
*
* @ param int $blog_id Blog ID
2015-01-11 21:24:22 -05:00
* @ return string Full URL of the blog if found . Empty string if not .
2010-09-30 21:32:31 -04:00
*/
2010-12-16 14:48:00 -05:00
function get_blogaddress_by_id ( $blog_id ) {
2016-10-25 14:50:30 -04:00
$bloginfo = get_site ( ( int ) $blog_id );
2015-10-29 22:02:24 -04:00
if ( empty ( $bloginfo ) ) {
return '' ;
}
$scheme = parse_url ( $bloginfo -> home , PHP_URL_SCHEME );
$scheme = empty ( $scheme ) ? 'http' : $scheme ;
return esc_url ( $scheme . '://' . $bloginfo -> domain . $bloginfo -> path );
2010-02-13 17:35:11 -05:00
}
2010-09-30 21:32:31 -04:00
/**
* Get a full blog URL , given a blog name .
*
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2010-09-30 21:32:31 -04:00
*
* @ param string $blogname The ( subdomain or directory ) name
* @ return string
*/
2010-02-13 17:35:11 -05:00
function get_blogaddress_by_name ( $blogname ) {
if ( is_subdomain_install () ) {
2018-09-24 11:22:24 -04:00
if ( 'main' === $blogname ) {
2010-02-13 17:35:11 -05:00
$blogname = 'www' ;
2017-11-30 18:11:00 -05:00
}
2010-05-16 18:21:06 -04:00
$url = rtrim ( network_home_url (), '/' );
2017-11-30 18:11:00 -05:00
if ( ! empty ( $blogname ) ) {
$url = preg_replace ( '|^([^\.]+://)|' , '${1}' . $blogname . '.' , $url );
}
2010-02-13 17:35:11 -05:00
} else {
2010-05-16 18:21:06 -04:00
$url = network_home_url ( $blogname );
2010-02-13 17:35:11 -05:00
}
2010-05-16 18:21:06 -04:00
return esc_url ( $url . '/' );
2010-02-13 17:35:11 -05:00
}
2010-09-30 21:32:31 -04:00
/**
2017-10-16 18:35:47 -04:00
* Retrieves a sites ID given its ( subdomain or directory ) slug .
2010-09-30 21:32:31 -04:00
*
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2018-02-09 11:55:31 -05:00
* @ since 4.7 . 0 Converted to use `get_sites()` .
2010-09-30 21:32:31 -04:00
*
2016-09-27 14:18:28 -04:00
* @ param string $slug A site ' s slug .
* @ return int | null The site ID , or null if no site is found for the given slug .
2010-09-30 21:32:31 -04:00
*/
2012-09-24 15:31:37 -04:00
function get_id_from_blogname ( $slug ) {
2017-10-16 18:35:47 -04:00
$current_network = get_network ();
2017-11-30 18:11:00 -05:00
$slug = trim ( $slug , '/' );
2012-09-24 15:31:37 -04:00
2017-10-16 18:35:47 -04:00
if ( is_subdomain_install () ) {
$domain = $slug . '.' . preg_replace ( '|^www\.|' , '' , $current_network -> domain );
2017-11-30 18:11:00 -05:00
$path = $current_network -> path ;
2017-10-16 18:35:47 -04:00
} else {
$domain = $current_network -> domain ;
2017-11-30 18:11:00 -05:00
$path = $current_network -> path . $slug . '/' ;
2017-10-16 18:35:47 -04:00
}
2017-11-30 18:11:00 -05:00
$site_ids = get_sites (
array (
2019-03-18 11:56:51 -04:00
'number' => 1 ,
'fields' => 'ids' ,
'domain' => $domain ,
'path' => $path ,
'update_site_meta_cache' => false ,
2017-11-30 18:11:00 -05:00
)
);
2017-10-16 18:35:47 -04:00
if ( empty ( $site_ids ) ) {
2016-09-27 14:18:28 -04:00
return null ;
}
2017-10-16 18:35:47 -04:00
return array_shift ( $site_ids );
2010-02-13 17:35:11 -05:00
}
/**
* Retrieve the details for a blog from the blogs table and blog options .
*
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2017-10-16 18:29:48 -04:00
*
* @ global wpdb $wpdb WordPress database abstraction object .
2015-05-26 17:51:31 -04:00
*
* @ param int | string | array $fields Optional . A blog ID , a blog slug , or an array of fields to query against .
* If not specified the current blog ID is used .
* @ param bool $get_all Whether to retrieve all details or only the details in the blogs table .
* Default is true .
2016-03-09 02:42:26 -05:00
* @ return WP_Site | false Blog details on success . False on failure .
2010-02-13 17:35:11 -05:00
*/
2012-10-04 08:40:09 -04:00
function get_blog_details ( $fields = null , $get_all = true ) {
2017-10-16 18:29:48 -04:00
global $wpdb ;
2017-11-30 18:11:00 -05:00
if ( is_array ( $fields ) ) {
if ( isset ( $fields [ 'blog_id' ] ) ) {
2017-10-16 18:29:48 -04:00
$blog_id = $fields [ 'blog_id' ];
2017-11-30 18:11:00 -05:00
} elseif ( isset ( $fields [ 'domain' ] ) && isset ( $fields [ 'path' ] ) ) {
$key = md5 ( $fields [ 'domain' ] . $fields [ 'path' ] );
$blog = wp_cache_get ( $key , 'blog-lookup' );
if ( false !== $blog ) {
2017-10-16 18:29:48 -04:00
return $blog ;
2017-11-30 18:11:00 -05:00
}
2017-10-16 18:29:48 -04:00
if ( substr ( $fields [ 'domain' ], 0 , 4 ) == 'www.' ) {
$nowww = substr ( $fields [ 'domain' ], 4 );
2017-11-30 18:11:00 -05:00
$blog = $wpdb -> get_row ( $wpdb -> prepare ( " SELECT * FROM $wpdb->blogs WHERE domain IN (%s,%s) AND path = %s ORDER BY CHAR_LENGTH(domain) DESC " , $nowww , $fields [ 'domain' ], $fields [ 'path' ] ) );
2017-10-16 18:29:48 -04:00
} else {
$blog = $wpdb -> get_row ( $wpdb -> prepare ( " SELECT * FROM $wpdb->blogs WHERE domain = %s AND path = %s " , $fields [ 'domain' ], $fields [ 'path' ] ) );
}
if ( $blog ) {
2017-11-30 18:11:00 -05:00
wp_cache_set ( $blog -> blog_id . 'short' , $blog , 'blog-details' );
2017-10-16 18:29:48 -04:00
$blog_id = $blog -> blog_id ;
} else {
return false ;
}
2017-11-30 18:11:00 -05:00
} elseif ( isset ( $fields [ 'domain' ] ) && is_subdomain_install () ) {
$key = md5 ( $fields [ 'domain' ] );
$blog = wp_cache_get ( $key , 'blog-lookup' );
if ( false !== $blog ) {
2017-10-16 18:29:48 -04:00
return $blog ;
2017-11-30 18:11:00 -05:00
}
2017-10-16 18:29:48 -04:00
if ( substr ( $fields [ 'domain' ], 0 , 4 ) == 'www.' ) {
$nowww = substr ( $fields [ 'domain' ], 4 );
2017-11-30 18:11:00 -05:00
$blog = $wpdb -> get_row ( $wpdb -> prepare ( " SELECT * FROM $wpdb->blogs WHERE domain IN (%s,%s) ORDER BY CHAR_LENGTH(domain) DESC " , $nowww , $fields [ 'domain' ] ) );
2017-10-16 18:29:48 -04:00
} else {
$blog = $wpdb -> get_row ( $wpdb -> prepare ( " SELECT * FROM $wpdb->blogs WHERE domain = %s " , $fields [ 'domain' ] ) );
}
if ( $blog ) {
2017-11-30 18:11:00 -05:00
wp_cache_set ( $blog -> blog_id . 'short' , $blog , 'blog-details' );
2017-10-16 18:29:48 -04:00
$blog_id = $blog -> blog_id ;
} else {
return false ;
}
2010-02-13 18:09:54 -05:00
} else {
return false ;
}
} else {
2017-11-30 18:11:00 -05:00
if ( ! $fields ) {
2017-10-16 18:29:48 -04:00
$blog_id = get_current_blog_id ();
2017-11-30 18:11:00 -05:00
} elseif ( ! is_numeric ( $fields ) ) {
2017-10-16 18:29:48 -04:00
$blog_id = get_id_from_blogname ( $fields );
2017-11-30 18:11:00 -05:00
} else {
2017-10-16 18:29:48 -04:00
$blog_id = $fields ;
2017-11-30 18:11:00 -05:00
}
2010-02-13 17:35:11 -05:00
}
2017-10-16 18:29:48 -04:00
$blog_id = ( int ) $blog_id ;
2010-02-13 18:09:54 -05:00
2018-09-24 11:22:24 -04:00
$all = $get_all ? '' : 'short' ;
2017-10-16 18:29:48 -04:00
$details = wp_cache_get ( $blog_id . $all , 'blog-details' );
if ( $details ) {
if ( ! is_object ( $details ) ) {
2018-09-24 11:22:24 -04:00
if ( - 1 == $details ) {
2017-10-16 18:29:48 -04:00
return false ;
} else {
// Clear old pre-serialized objects. Cache clients do better with that.
wp_cache_delete ( $blog_id . $all , 'blog-details' );
2017-11-30 18:11:00 -05:00
unset ( $details );
2017-10-16 18:29:48 -04:00
}
} else {
return $details ;
}
2016-01-25 16:51:26 -05:00
}
2017-10-16 18:29:48 -04:00
// Try the other cache.
2017-10-03 15:40:46 -04:00
if ( $get_all ) {
2017-10-16 18:29:48 -04:00
$details = wp_cache_get ( $blog_id . 'short' , 'blog-details' );
} else {
$details = wp_cache_get ( $blog_id , 'blog-details' );
// If short was requested and full cache is set, we can return.
if ( $details ) {
if ( ! is_object ( $details ) ) {
2018-09-24 11:22:24 -04:00
if ( - 1 == $details ) {
2017-10-16 18:29:48 -04:00
return false ;
} else {
// Clear old pre-serialized objects. Cache clients do better with that.
wp_cache_delete ( $blog_id , 'blog-details' );
2017-11-30 18:11:00 -05:00
unset ( $details );
2017-10-16 18:29:48 -04:00
}
} else {
return $details ;
}
2017-10-03 15:40:46 -04:00
}
2010-02-13 17:35:11 -05:00
}
2017-11-30 18:11:00 -05:00
if ( empty ( $details ) ) {
2017-10-16 18:29:48 -04:00
$details = WP_Site :: get_instance ( $blog_id );
if ( ! $details ) {
// Set the full cache.
wp_cache_set ( $blog_id , - 1 , 'blog-details' );
return false ;
}
}
if ( ! $details instanceof WP_Site ) {
2019-01-08 04:15:49 -05:00
$details = new WP_Site ( $details );
}
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
2019-01-08 04:15:49 -05:00
if ( ! $get_all ) {
wp_cache_set ( $blog_id . $all , $details , 'blog-details' );
return $details ;
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
}
2019-01-08 04:15:49 -05:00
switch_to_blog ( $blog_id );
$details -> blogname = get_option ( 'blogname' );
$details -> siteurl = get_option ( 'siteurl' );
$details -> post_count = get_option ( 'post_count' );
$details -> home = get_option ( 'home' );
restore_current_blog ();
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
/**
2019-01-08 04:15:49 -05:00
* Filters a blog ' s details .
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
*
* @ since MU ( 3.0 . 0 )
2019-01-08 04:15:49 -05:00
* @ deprecated 4.7 . 0 Use site_details
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
*
2019-01-08 04:15:49 -05:00
* @ param object $details The blog details .
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
*/
2019-01-08 04:15:49 -05:00
$details = apply_filters_deprecated ( 'blog_details' , array ( $details ), '4.7.0' , 'site_details' );
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
2019-01-08 04:15:49 -05:00
wp_cache_set ( $blog_id . $all , $details , 'blog-details' );
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
2019-01-08 04:15:49 -05:00
$key = md5 ( $details -> domain . $details -> path );
wp_cache_set ( $key , $details , 'blog-lookup' );
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
2019-01-08 04:15:49 -05:00
return $details ;
}
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
2019-01-08 04:15:49 -05:00
/**
* Clear the blog details cache .
*
* @ since MU ( 3.0 . 0 )
*
* @ param int $blog_id Optional . Blog ID . Defaults to current blog .
*/
function refresh_blog_details ( $blog_id = 0 ) {
$blog_id = ( int ) $blog_id ;
if ( ! $blog_id ) {
$blog_id = get_current_blog_id ();
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
}
2019-01-08 04:15:49 -05:00
clean_blog_cache ( $blog_id );
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
}
/**
2019-01-08 04:15:49 -05:00
* Update the details for a blog . Updates the blogs table for a given blog id .
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
*
2019-01-08 04:15:49 -05:00
* @ since MU ( 3.0 . 0 )
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
*
* @ global wpdb $wpdb WordPress database abstraction object .
*
2019-01-08 04:15:49 -05:00
* @ param int $blog_id Blog ID
* @ param array $details Array of details keyed by blogs table field names .
* @ return bool True if update succeeds , false otherwise .
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
*/
2019-01-08 04:15:49 -05:00
function update_blog_details ( $blog_id , $details = array () ) {
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
global $wpdb ;
2019-01-08 04:15:49 -05:00
if ( empty ( $details ) ) {
return false ;
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
}
2019-01-08 04:15:49 -05:00
if ( is_object ( $details ) ) {
$details = get_object_vars ( $details );
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
}
2019-01-08 04:15:49 -05:00
$site = wp_update_site ( $blog_id , $details );
if ( is_wp_error ( $site ) ) {
return false ;
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
}
2019-01-08 04:15:49 -05:00
return true ;
}
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
2019-01-08 04:15:49 -05:00
/**
* Cleans the site details cache for a site .
*
* @ since 4.7 . 4
*
* @ param int $site_id Optional . Site ID . Default is the current site ID .
*/
function clean_site_details_cache ( $site_id = 0 ) {
$site_id = ( int ) $site_id ;
if ( ! $site_id ) {
$site_id = get_current_blog_id ();
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
}
2019-01-08 04:15:49 -05:00
wp_cache_delete ( $site_id , 'site-details' );
wp_cache_delete ( $site_id , 'blog-details' );
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.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-09-24 11:09:26 -04:00
}
2012-08-08 13:11:15 -04:00
/**
* Retrieve option value for a given blog id based on name of option .
*
* If the option does not exist or does not have a value , then the return value
* will be false . This is useful to check whether you need to install an option
* and is commonly used during installation of plugin options and to test
* whether upgrading is required .
*
* If the option was serialized then it will be unserialized when it is returned .
*
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2012-08-08 13:11:15 -04:00
*
2015-05-26 17:51:31 -04:00
* @ param int $id A blog ID . Can be null to refer to the current blog .
* @ param string $option Name of option to retrieve . Expected to not be SQL - escaped .
* @ param mixed $default Optional . Default value to return if the option does not exist .
2012-08-08 13:11:15 -04:00
* @ return mixed Value set for the option .
*/
function get_blog_option ( $id , $option , $default = false ) {
$id = ( int ) $id ;
2017-11-30 18:11:00 -05:00
if ( empty ( $id ) ) {
2012-08-08 13:11:15 -04:00
$id = get_current_blog_id ();
2017-11-30 18:11:00 -05:00
}
2012-08-08 13:11:15 -04:00
2017-11-30 18:11:00 -05:00
if ( get_current_blog_id () == $id ) {
2012-08-08 13:11:15 -04:00
return get_option ( $option , $default );
2017-11-30 18:11:00 -05:00
}
2012-08-08 13:11:15 -04:00
switch_to_blog ( $id );
2012-08-23 12:04:39 -04:00
$value = get_option ( $option , $default );
2012-08-08 13:11:15 -04:00
restore_current_blog ();
2013-12-01 12:32:10 -05:00
/**
2016-05-22 14:50:28 -04:00
* Filters a blog option value .
2013-12-01 12:32:10 -05:00
*
2014-11-30 07:10:23 -05:00
* The dynamic portion of the hook name , `$option` , refers to the blog option name .
2013-12-01 12:32:10 -05:00
*
* @ since 3.5 . 0
*
* @ param string $value The option value .
* @ param int $id Blog ID .
*/
return apply_filters ( " blog_option_ { $option } " , $value , $id );
2012-08-08 13:11:15 -04:00
}
/**
* Add a new option for a given blog id .
*
* You do not need to serialize values . If the value needs to be serialized , then
* it will be serialized before it is inserted into the database . Remember ,
* resources can not be serialized or added as an option .
*
* You can create options without values and then update the values later .
* Existing options will not be updated and checks are performed to ensure that you
* aren ' t adding a protected WordPress option . Care should be taken to not name
* options the same as the ones which are protected .
*
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2012-08-08 13:11:15 -04:00
*
2015-05-26 17:51:31 -04:00
* @ param int $id A blog ID . Can be null to refer to the current blog .
2012-08-08 13:11:15 -04:00
* @ param string $option Name of option to add . Expected to not be SQL - escaped .
2015-05-26 17:51:31 -04:00
* @ param mixed $value Optional . Option value , can be anything . Expected to not be SQL - escaped .
2012-08-08 13:11:15 -04:00
* @ return bool False if option was not added and true if option was added .
*/
function add_blog_option ( $id , $option , $value ) {
$id = ( int ) $id ;
2017-11-30 18:11:00 -05:00
if ( empty ( $id ) ) {
2012-08-08 13:11:15 -04:00
$id = get_current_blog_id ();
2017-11-30 18:11:00 -05:00
}
2012-08-08 13:11:15 -04:00
2017-11-30 18:11:00 -05:00
if ( get_current_blog_id () == $id ) {
2012-08-08 13:11:15 -04:00
return add_option ( $option , $value );
2017-11-30 18:11:00 -05:00
}
2012-08-08 13:11:15 -04:00
switch_to_blog ( $id );
$return = add_option ( $option , $value );
restore_current_blog ();
return $return ;
}
/**
* Removes option by name for a given blog id . Prevents removal of protected WordPress options .
*
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2012-08-08 13:11:15 -04:00
*
2015-05-26 17:51:31 -04:00
* @ param int $id A blog ID . Can be null to refer to the current blog .
2012-08-08 13:11:15 -04:00
* @ param string $option Name of option to remove . Expected to not be SQL - escaped .
* @ return bool True , if option is successfully deleted . False on failure .
*/
function delete_blog_option ( $id , $option ) {
$id = ( int ) $id ;
2017-11-30 18:11:00 -05:00
if ( empty ( $id ) ) {
2012-08-08 13:11:15 -04:00
$id = get_current_blog_id ();
2017-11-30 18:11:00 -05:00
}
2012-08-08 13:11:15 -04:00
2017-11-30 18:11:00 -05:00
if ( get_current_blog_id () == $id ) {
2012-08-08 13:11:15 -04:00
return delete_option ( $option );
2017-11-30 18:11:00 -05:00
}
2012-08-08 13:11:15 -04:00
switch_to_blog ( $id );
$return = delete_option ( $option );
restore_current_blog ();
return $return ;
}
/**
* Update an option for a particular blog .
*
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2012-08-08 13:11:15 -04:00
*
2016-01-08 20:45:26 -05:00
* @ param int $id The blog id .
* @ param string $option The option key .
* @ param mixed $value The option value .
* @ param mixed $deprecated Not used .
2013-04-29 08:49:33 -04:00
* @ return bool True on success , false on failure .
2012-08-08 13:11:15 -04:00
*/
function update_blog_option ( $id , $option , $value , $deprecated = null ) {
$id = ( int ) $id ;
2017-11-30 18:11:00 -05:00
if ( null !== $deprecated ) {
2016-07-06 08:40:29 -04:00
_deprecated_argument ( __FUNCTION__ , '3.1.0' );
2017-11-30 18:11:00 -05:00
}
2012-08-08 13:11:15 -04:00
2017-11-30 18:11:00 -05:00
if ( get_current_blog_id () == $id ) {
2012-08-08 13:11:15 -04:00
return update_option ( $option , $value );
2017-11-30 18:11:00 -05:00
}
2012-08-08 13:11:15 -04:00
switch_to_blog ( $id );
$return = update_option ( $option , $value );
restore_current_blog ();
return $return ;
}
2010-09-30 21:32:31 -04:00
/**
* Switch the current blog .
*
* This function is useful if you need to pull posts , or other information ,
* from other blogs . You can switch back afterwards using restore_current_blog () .
*
* Things that aren ' t switched :
* - plugins . See #14941
*
* @ see restore_current_blog ()
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2010-09-30 21:32:31 -04:00
*
2015-05-26 17:51:31 -04:00
* @ global wpdb $wpdb
* @ global int $blog_id
* @ global array $_wp_switched_stack
* @ global bool $switched
* @ global string $table_prefix
* @ global WP_Object_Cache $wp_object_cache
*
* @ param int $new_blog The id of the blog you want to switch to . Default : current blog
2012-08-15 11:56:14 -04:00
* @ param bool $deprecated Deprecated argument
2015-05-26 17:51:31 -04:00
* @ return true Always returns True .
2010-09-30 21:32:31 -04:00
*/
2012-08-09 12:28:15 -04:00
function switch_to_blog ( $new_blog , $deprecated = null ) {
2017-09-27 17:44:44 -04:00
global $wpdb ;
2010-02-13 17:35:11 -05:00
2016-08-31 00:55:54 -04:00
$blog_id = get_current_blog_id ();
if ( empty ( $new_blog ) ) {
$new_blog = $blog_id ;
}
2010-02-13 17:35:11 -05:00
2016-08-31 00:55:54 -04:00
$GLOBALS [ '_wp_switched_stack' ][] = $blog_id ;
2010-02-13 17:35:11 -05:00
2013-12-01 12:32:10 -05:00
/*
* If we 're switching to the same blog id that we' re on ,
* set the right vars , do the associated actions , but skip
* the extra unnecessary work
*/
2016-08-31 00:55:54 -04:00
if ( $new_blog == $blog_id ) {
2013-12-01 12:32:10 -05:00
/**
* Fires when the blog is switched .
*
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2013-12-01 12:32:10 -05:00
*
* @ param int $new_blog New blog ID .
* @ param int $new_blog Blog ID .
*/
2012-08-09 12:28:15 -04:00
do_action ( 'switch_blog' , $new_blog , $new_blog );
2012-08-21 23:34:00 -04:00
$GLOBALS [ 'switched' ] = true ;
2010-02-13 17:35:11 -05:00
return true ;
}
2012-08-09 12:28:15 -04:00
$wpdb -> set_blog_id ( $new_blog );
2013-09-24 19:41:10 -04:00
$GLOBALS [ 'table_prefix' ] = $wpdb -> get_blog_prefix ();
2017-11-30 18:11:00 -05:00
$prev_blog_id = $blog_id ;
$GLOBALS [ 'blog_id' ] = $new_blog ;
2010-10-19 03:48:22 -04:00
2012-08-02 14:31:14 -04:00
if ( function_exists ( 'wp_cache_switch_to_blog' ) ) {
2012-08-09 12:28:15 -04:00
wp_cache_switch_to_blog ( $new_blog );
2012-08-02 14:31:14 -04:00
} else {
2012-08-09 12:28:15 -04:00
global $wp_object_cache ;
2016-08-31 00:55:54 -04:00
if ( is_object ( $wp_object_cache ) && isset ( $wp_object_cache -> global_groups ) ) {
2012-08-02 14:31:14 -04:00
$global_groups = $wp_object_cache -> global_groups ;
2016-08-31 00:55:54 -04:00
} else {
2012-08-02 14:31:14 -04:00
$global_groups = false ;
2016-08-31 00:55:54 -04:00
}
2012-08-02 14:31:14 -04:00
wp_cache_init ();
2012-08-09 12:28:15 -04:00
if ( function_exists ( 'wp_cache_add_global_groups' ) ) {
2015-02-05 22:24:23 -05:00
if ( is_array ( $global_groups ) ) {
2012-08-02 14:31:14 -04:00
wp_cache_add_global_groups ( $global_groups );
2015-02-05 22:24:23 -05:00
} else {
2018-03-15 22:15:31 -04:00
wp_cache_add_global_groups ( array ( 'users' , 'userlogins' , 'usermeta' , 'user_meta' , 'useremail' , 'userslugs' , 'site-transient' , 'site-options' , 'blog-lookup' , 'blog-details' , 'rss' , 'global-posts' , 'blog-id-cache' , 'networks' , 'sites' , 'site-details' , 'blog_meta' ) );
2015-02-05 22:24:23 -05:00
}
2016-06-01 17:26:27 -04:00
wp_cache_add_non_persistent_groups ( array ( 'counts' , 'plugins' ) );
2012-08-02 14:31:14 -04:00
}
2010-02-13 17:35:11 -05:00
}
2013-12-01 12:32:10 -05:00
/** This filter is documented in wp-includes/ms-blogs.php */
2012-08-09 12:28:15 -04:00
do_action ( 'switch_blog' , $new_blog , $prev_blog_id );
2012-08-21 23:34:00 -04:00
$GLOBALS [ 'switched' ] = true ;
2012-08-09 12:28:15 -04:00
2010-02-13 17:35:11 -05:00
return true ;
}
2010-09-30 21:32:31 -04:00
/**
* Restore the current blog , after calling switch_to_blog ()
*
* @ see switch_to_blog ()
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2010-09-30 21:32:31 -04:00
*
2015-05-26 17:51:31 -04:00
* @ global wpdb $wpdb
* @ global array $_wp_switched_stack
* @ global int $blog_id
* @ global bool $switched
* @ global string $table_prefix
* @ global WP_Object_Cache $wp_object_cache
*
2012-08-15 11:56:14 -04:00
* @ return bool True on success , false if we ' re already on the current blog
2010-09-30 21:32:31 -04:00
*/
2010-02-13 17:35:11 -05:00
function restore_current_blog () {
2017-09-27 17:44:44 -04:00
global $wpdb ;
2010-02-13 17:35:11 -05:00
2016-08-31 00:55:54 -04:00
if ( empty ( $GLOBALS [ '_wp_switched_stack' ] ) ) {
2010-02-13 17:35:11 -05:00
return false ;
2016-08-31 00:55:54 -04:00
}
2010-02-13 17:35:11 -05:00
2017-11-30 18:11:00 -05:00
$blog = array_pop ( $GLOBALS [ '_wp_switched_stack' ] );
2016-08-31 00:55:54 -04:00
$blog_id = get_current_blog_id ();
2010-02-13 17:35:11 -05:00
2016-08-31 00:55:54 -04:00
if ( $blog_id == $blog ) {
2013-12-01 12:32:10 -05:00
/** This filter is documented in wp-includes/ms-blogs.php */
2010-02-13 17:35:11 -05:00
do_action ( 'switch_blog' , $blog , $blog );
2012-08-09 12:28:15 -04:00
// If we still have items in the switched stack, consider ourselves still 'switched'
2012-08-21 23:34:00 -04:00
$GLOBALS [ 'switched' ] = ! empty ( $GLOBALS [ '_wp_switched_stack' ] );
2010-02-13 17:35:11 -05:00
return true ;
}
2012-08-09 12:28:15 -04:00
$wpdb -> set_blog_id ( $blog );
2017-11-30 18:11:00 -05:00
$prev_blog_id = $blog_id ;
$GLOBALS [ 'blog_id' ] = $blog ;
2013-09-24 19:41:10 -04:00
$GLOBALS [ 'table_prefix' ] = $wpdb -> get_blog_prefix ();
2010-02-13 17:35:11 -05:00
2012-08-02 14:31:14 -04:00
if ( function_exists ( 'wp_cache_switch_to_blog' ) ) {
2012-08-09 12:28:15 -04:00
wp_cache_switch_to_blog ( $blog );
2012-08-02 14:31:14 -04:00
} else {
2012-08-09 12:28:15 -04:00
global $wp_object_cache ;
2016-08-31 00:55:54 -04:00
if ( is_object ( $wp_object_cache ) && isset ( $wp_object_cache -> global_groups ) ) {
2012-08-02 14:31:14 -04:00
$global_groups = $wp_object_cache -> global_groups ;
2016-08-31 00:55:54 -04:00
} else {
2012-08-02 14:31:14 -04:00
$global_groups = false ;
2016-08-31 00:55:54 -04:00
}
2012-11-17 10:11:29 -05:00
2012-08-02 14:31:14 -04:00
wp_cache_init ();
2012-08-09 12:28:15 -04:00
if ( function_exists ( 'wp_cache_add_global_groups' ) ) {
2015-02-05 22:24:23 -05:00
if ( is_array ( $global_groups ) ) {
2012-08-02 14:31:14 -04:00
wp_cache_add_global_groups ( $global_groups );
2015-02-05 22:24:23 -05:00
} else {
2018-03-15 22:15:31 -04:00
wp_cache_add_global_groups ( array ( 'users' , 'userlogins' , 'usermeta' , 'user_meta' , 'useremail' , 'userslugs' , 'site-transient' , 'site-options' , 'blog-lookup' , 'blog-details' , 'rss' , 'global-posts' , 'blog-id-cache' , 'networks' , 'sites' , 'site-details' , 'blog_meta' ) );
2015-02-05 22:24:23 -05:00
}
2016-06-01 17:26:27 -04:00
wp_cache_add_non_persistent_groups ( array ( 'counts' , 'plugins' ) );
2012-08-02 14:31:14 -04:00
}
2010-02-13 17:35:11 -05:00
}
2013-12-01 12:32:10 -05:00
/** This filter is documented in wp-includes/ms-blogs.php */
2012-08-09 12:28:15 -04:00
do_action ( 'switch_blog' , $blog , $prev_blog_id );
// If we still have items in the switched stack, consider ourselves still 'switched'
2012-08-21 23:34:00 -04:00
$GLOBALS [ 'switched' ] = ! empty ( $GLOBALS [ '_wp_switched_stack' ] );
2010-02-13 17:35:11 -05:00
return true ;
}
2017-09-27 17:44:44 -04:00
/**
* Switches the initialized roles and current user capabilities to another site .
*
* @ since 4.9 . 0
*
* @ param int $new_site_id New site ID .
* @ param int $old_site_id Old site ID .
*/
function wp_switch_roles_and_user ( $new_site_id , $old_site_id ) {
if ( $new_site_id == $old_site_id ) {
return ;
}
if ( ! did_action ( 'init' ) ) {
return ;
}
wp_roles () -> for_site ( $new_site_id );
wp_get_current_user () -> for_site ( $new_site_id );
}
2012-08-20 16:48:35 -04:00
/**
* Determines if switch_to_blog () is in effect
*
* @ since 3.5 . 0
*
2015-05-26 17:51:31 -04:00
* @ global array $_wp_switched_stack
*
2012-08-20 16:48:35 -04:00
* @ return bool True if switched , false otherwise .
*/
2012-08-20 16:56:34 -04:00
function ms_is_switched () {
2012-09-26 13:02:44 -04:00
return ! empty ( $GLOBALS [ '_wp_switched_stack' ] );
2012-08-20 16:48:35 -04:00
}
2010-09-30 21:32:31 -04:00
/**
* Check if a particular blog is archived .
*
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2010-09-30 21:32:31 -04:00
*
* @ param int $id The blog id
2010-10-07 22:35:06 -04:00
* @ return string Whether the blog is archived or not
2010-09-30 21:32:31 -04:00
*/
2010-02-13 17:35:11 -05:00
function is_archived ( $id ) {
2017-11-30 18:11:00 -05:00
return get_blog_status ( $id , 'archived' );
2010-02-13 17:35:11 -05:00
}
2010-09-30 21:32:31 -04:00
/**
* Update the 'archived' status of a particular blog .
*
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2010-09-30 21:32:31 -04:00
*
2015-05-26 17:51:31 -04:00
* @ param int $id The blog id
2010-09-30 21:32:31 -04:00
* @ param string $archived The new status
* @ return string $archived
*/
2010-02-13 17:35:11 -05:00
function update_archived ( $id , $archived ) {
2017-11-30 18:11:00 -05:00
update_blog_status ( $id , 'archived' , $archived );
2010-02-13 17:35:11 -05:00
return $archived ;
}
/**
* Update a blog details field .
*
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2019-01-08 03:58:49 -05:00
* @ since 5.1 . 0 Use wp_update_site () internally .
2010-02-13 17:35:11 -05:00
*
2015-10-14 19:44:25 -04:00
* @ global wpdb $wpdb WordPress database abstraction object .
2015-05-26 17:51:31 -04:00
*
* @ param int $blog_id BLog ID
* @ param string $pref A field name
* @ param string $value Value for $pref
* @ param null $deprecated
* @ return string | false $value
2010-02-13 17:35:11 -05:00
*/
2010-12-01 17:12:09 -05:00
function update_blog_status ( $blog_id , $pref , $value , $deprecated = null ) {
2010-02-13 17:35:11 -05:00
global $wpdb ;
2017-11-30 18:11:00 -05:00
if ( null !== $deprecated ) {
2016-07-06 08:40:29 -04:00
_deprecated_argument ( __FUNCTION__ , '3.1.0' );
2017-11-30 18:11:00 -05:00
}
2010-12-01 17:12:09 -05:00
2017-11-30 18:11:00 -05:00
if ( ! in_array ( $pref , array ( 'site_id' , 'domain' , 'path' , 'registered' , 'last_updated' , 'public' , 'archived' , 'mature' , 'spam' , 'deleted' , 'lang_id' ) ) ) {
2010-02-13 17:35:11 -05:00
return $value ;
2017-11-30 18:11:00 -05:00
}
2010-02-13 17:35:11 -05:00
2018-08-16 21:51:36 -04:00
$result = wp_update_site (
$blog_id ,
array (
$pref => $value ,
)
);
2010-02-13 17:35:11 -05:00
Multisite: Complete the new CRUD API for managing sites.
New functions `wp_insert_site( $data )`, `wp_update_site( $id, $data )` and `wp_delete_site( $id )` are introduced to manage site rows in the `wp_blogs` table, forming the new CRUD API together with the existing `get_site()` / `get_sites()`. The new API provides various benefits over the previously existing API, fixing several cache invalidation issues and being hook-driven so that normalization and validation of the passed data can be fully customized.
New hooks introduced as part of this are the actions `wp_insert_site`, `wp_update_site`, `wp_delete_site`, `wp_validate_site_data` and the filter `wp_normalize_site_data`.
At this point, `wp_insert_site()` does not handle setting up the site's database tables, and `wp_delete_site()` does not handle dropping the site's database tables, so the two can not yet be used directly as full replacements of `wpmu_create_blog()` and `wpmu_delete_blog()`. Managing the site's database tables will be added via hooks as part of the follow-up ticket #41333.
The existing functions `wpmu_create_blog()`, `update_blog_details()`, and `wpmu_delete_blog()` make use of the respective new counterpart and will be obsolete once #41333 has been completed.
Props flixos90, jeremyfelt, spacedmonkey.
Fixes #40364.
Built from https://develop.svn.wordpress.org/trunk@43548
git-svn-id: http://core.svn.wordpress.org/trunk@43377 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2018-08-01 09:06:26 -04:00
if ( is_wp_error ( $result ) ) {
2012-10-11 08:37:46 -04:00
return false ;
2017-11-30 18:11:00 -05:00
}
2012-10-11 08:37:46 -04:00
2010-02-13 17:35:11 -05:00
return $value ;
}
2010-09-30 21:32:31 -04:00
/**
* Get a blog details field .
*
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2010-09-30 21:32:31 -04:00
*
2015-10-14 19:44:25 -04:00
* @ global wpdb $wpdb WordPress database abstraction object .
2015-05-26 17:51:31 -04:00
*
* @ param int $id The blog id
2010-09-30 21:32:31 -04:00
* @ param string $pref A field name
2015-05-26 17:51:31 -04:00
* @ return bool | string | null $value
2010-09-30 21:32:31 -04:00
*/
2010-02-13 17:35:11 -05:00
function get_blog_status ( $id , $pref ) {
global $wpdb ;
2016-10-25 14:50:30 -04:00
$details = get_site ( $id );
2017-11-30 18:11:00 -05:00
if ( $details ) {
2010-02-13 17:35:11 -05:00
return $details -> $pref ;
2017-11-30 18:11:00 -05:00
}
2010-02-13 17:35:11 -05:00
2017-11-30 18:11:00 -05:00
return $wpdb -> get_var ( $wpdb -> prepare ( " SELECT %s FROM { $wpdb -> blogs } WHERE blog_id = %d " , $pref , $id ) );
2010-02-13 17:35:11 -05:00
}
2010-09-30 21:32:31 -04:00
/**
* Get a list of most recently updated blogs .
*
2017-08-01 16:44:43 -04:00
* @ since MU ( 3.0 . 0 )
2010-10-19 03:48:22 -04:00
*
2015-10-14 19:44:25 -04:00
* @ global wpdb $wpdb WordPress database abstraction object .
2015-05-26 17:51:31 -04:00
*
2010-11-18 14:12:48 -05:00
* @ param mixed $deprecated Not used
2015-05-26 17:51:31 -04:00
* @ param int $start The offset
* @ param int $quantity The maximum number of blogs to retrieve . Default is 40.
2010-09-30 21:32:31 -04:00
* @ return array The list of blogs
*/
2010-02-13 17:35:11 -05:00
function get_last_updated ( $deprecated = '' , $start = 0 , $quantity = 40 ) {
global $wpdb ;
2010-12-13 16:21:50 -05:00
2017-11-30 18:11:00 -05:00
if ( ! empty ( $deprecated ) ) {
2010-11-18 14:12:48 -05:00
_deprecated_argument ( __FUNCTION__ , 'MU' ); // never used
2017-11-30 18:11:00 -05:00
}
2010-12-13 16:21:50 -05:00
2017-08-12 09:11:43 -04:00
return $wpdb -> get_results ( $wpdb -> prepare ( " SELECT blog_id, domain, path FROM $wpdb->blogs WHERE site_id = %d AND public = '1' AND archived = '0' AND mature = '0' AND spam = '0' AND deleted = '0' AND last_updated != '0000-00-00 00:00:00' ORDER BY last_updated DESC limit %d, %d " , get_current_network_id (), $start , $quantity ), ARRAY_A );
2010-02-13 17:35:11 -05:00
}
2011-11-03 13:06:45 -04:00
/**
2017-10-01 23:20:47 -04:00
* Handler for updating the site ' s last updated date when a post is published or
* an already published post is changed .
2011-11-03 13:06:45 -04:00
*
* @ since 3.3 . 0
*
* @ param string $new_status The new post status
* @ param string $old_status The old post status
2015-05-26 17:51:31 -04:00
* @ param object $post Post object
2011-11-03 13:06:45 -04:00
*/
function _update_blog_date_on_post_publish ( $new_status , $old_status , $post ) {
$post_type_obj = get_post_type_object ( $post -> post_type );
2014-07-28 20:51:17 -04:00
if ( ! $post_type_obj || ! $post_type_obj -> public ) {
2011-11-03 13:06:45 -04:00
return ;
2014-07-28 20:51:17 -04:00
}
2011-11-03 13:06:45 -04:00
2014-07-28 20:51:17 -04:00
if ( 'publish' != $new_status && 'publish' != $old_status ) {
2011-11-03 13:06:45 -04:00
return ;
2014-07-28 20:51:17 -04:00
}
2011-11-03 13:06:45 -04:00
// Post was freshly published, published post was saved, or published post was unpublished.
wpmu_update_blogs_date ();
}
2012-04-13 13:30:37 -04:00
/**
2017-10-01 23:20:47 -04:00
* Handler for updating the current site ' s last updated date when a published
* post is deleted .
2012-04-13 13:30:37 -04:00
*
* @ since 3.4 . 0
*
* @ param int $post_id Post ID
*/
function _update_blog_date_on_post_delete ( $post_id ) {
$post = get_post ( $post_id );
$post_type_obj = get_post_type_object ( $post -> post_type );
2014-07-28 20:51:17 -04:00
if ( ! $post_type_obj || ! $post_type_obj -> public ) {
2012-04-13 13:30:37 -04:00
return ;
2014-07-28 20:51:17 -04:00
}
2012-04-13 13:30:37 -04:00
2014-07-28 20:51:17 -04:00
if ( 'publish' != $post -> post_status ) {
2012-04-13 13:30:37 -04:00
return ;
2014-07-28 20:51:17 -04:00
}
2012-04-13 13:30:37 -04:00
wpmu_update_blogs_date ();
}
2014-06-25 20:53:15 -04:00
/**
2017-10-01 23:20:47 -04:00
* Handler for updating the current site ' s posts count when a post is deleted .
2014-06-25 20:53:15 -04:00
*
2014-07-28 20:59:16 -04:00
* @ since 4.0 . 0
2014-06-25 20:53:15 -04:00
*
2014-07-13 21:02:15 -04:00
* @ param int $post_id Post ID .
2014-06-25 20:53:15 -04:00
*/
function _update_posts_count_on_delete ( $post_id ) {
2014-09-02 03:17:17 -04:00
$post = get_post ( $post_id );
2017-10-01 23:09:44 -04:00
if ( ! $post || 'publish' !== $post -> post_status || 'post' !== $post -> post_type ) {
2014-06-25 20:53:15 -04:00
return ;
}
2014-06-28 00:07:16 -04:00
2014-06-25 20:53:15 -04:00
update_posts_count ();
}
/**
2017-10-01 23:20:47 -04:00
* Handler for updating the current site ' s posts count when a post status changes .
2014-06-25 20:53:15 -04:00
*
2014-07-28 20:59:16 -04:00
* @ since 4.0 . 0
2017-10-01 23:09:44 -04:00
* @ since 4.9 . 0 Added the `$post` parameter .
2014-06-25 20:53:15 -04:00
*
2017-10-01 23:09:44 -04:00
* @ param string $new_status The status the post is changing to .
* @ param string $old_status The status the post is changing from .
* @ param WP_Post $post Post object
2014-06-25 20:53:15 -04:00
*/
2017-10-01 23:09:44 -04:00
function _update_posts_count_on_transition_post_status ( $new_status , $old_status , $post = null ) {
2014-06-25 20:53:15 -04:00
if ( $new_status === $old_status ) {
return ;
}
2017-10-01 23:09:44 -04:00
if ( 'post' !== get_post_type ( $post ) ) {
return ;
}
2014-06-25 20:53:15 -04:00
if ( 'publish' !== $new_status && 'publish' !== $old_status ) {
return ;
}
update_posts_count ();
}