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
*/
2020-02-06 01:33:11 -05:00
require_once ABSPATH . WPINC . '/ms-site.php' ;
require_once ABSPATH . WPINC . '/ms-network.php' ;
2019-01-08 04:15:49 -05:00
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
/**
2020-06-28 10:09:04 -04:00
* Get a full blog URL , given a blog ID .
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
*
2019-08-11 12:18:57 -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
/**
2022-08-11 10:11:08 -04:00
* Retrieves a site ' s 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
}
2020-05-16 14:42:12 -04:00
if ( 'www.' === substr ( $fields [ 'domain' ], 0 , 4 ) ) {
2017-10-16 18:29:48 -04:00
$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
}
2020-05-16 14:42:12 -04:00
if ( 'www.' === substr ( $fields [ 'domain' ], 0 , 4 ) ) {
2017-10-16 18:29:48 -04:00
$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
}
2020-06-15 08:31:11 -04:00
$switched_blog = false ;
if ( get_current_blog_id () !== $blog_id ) {
switch_to_blog ( $blog_id );
$switched_blog = true ;
}
2019-01-08 04:15:49 -05:00
$details -> blogname = get_option ( 'blogname' );
$details -> siteurl = get_option ( 'siteurl' );
$details -> post_count = get_option ( 'post_count' );
$details -> home = get_option ( 'home' );
2020-06-15 08:31:11 -04:00
if ( $switched_blog ) {
restore_current_blog ();
}
2019-01-08 04:15:49 -05:00
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-11-09 08:05:02 -05:00
* @ deprecated 4.7 . 0 Use { @ see 'site_details' } instead .
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
*
2020-10-17 12:05:09 -04:00
* @ param WP_Site $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
}
/**
2020-06-28 10:09:04 -04: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-08-11 12:18:57 -04:00
* @ param int $blog_id Blog ID .
2019-01-08 04:15:49 -05:00
* @ 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
*
Code Modernization: Rename parameters that use reserved keywords in `wp-includes/ms-blogs.php`.
While using reserved PHP keywords as parameter name labels is allowed, in the context of function calls using named parameters in PHP 8.0+, this will easily lead to confusion. To avoid that, it is recommended not to use reserved keywords as function parameter names.
This commit renames the `$default` parameter to `$default_value` in `get_blog_option()`.
Follow-up to [52946], [52996], [52997], [52998], [53003], [53014], [53029], [53039], [53116], [53117], [53137], [53174], [53184], [53185], [53192], [53193], [53198], [53203], [53207], [53215], [53216], [53220], [53230], [53232], [53236], [53239], [53240], [53242], [53243], [53245], [53246], [53257], [53269], [53270], [53271], [53272], [53273], [53274], [53275], [53276], [53277], [53281], [53283], [53284], [53285], [53287], [53364], [53365], [54927], [54929], [54930], [54931], [54932], [54933], [54938], [54943], [54944].
Props jrf, aristath, poena, justinahinon, SergeyBiryukov.
See #56788.
Built from https://develop.svn.wordpress.org/trunk@54945
git-svn-id: http://core.svn.wordpress.org/trunk@54497 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-12-06 17:16:13 -05: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_value 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 .
*/
Code Modernization: Rename parameters that use reserved keywords in `wp-includes/ms-blogs.php`.
While using reserved PHP keywords as parameter name labels is allowed, in the context of function calls using named parameters in PHP 8.0+, this will easily lead to confusion. To avoid that, it is recommended not to use reserved keywords as function parameter names.
This commit renames the `$default` parameter to `$default_value` in `get_blog_option()`.
Follow-up to [52946], [52996], [52997], [52998], [53003], [53014], [53029], [53039], [53116], [53117], [53137], [53174], [53184], [53185], [53192], [53193], [53198], [53203], [53207], [53215], [53216], [53220], [53230], [53232], [53236], [53239], [53240], [53242], [53243], [53245], [53246], [53257], [53269], [53270], [53271], [53272], [53273], [53274], [53275], [53276], [53277], [53281], [53283], [53284], [53285], [53287], [53364], [53365], [54927], [54929], [54930], [54931], [54932], [54933], [54938], [54943], [54944].
Props jrf, aristath, poena, justinahinon, SergeyBiryukov.
See #56788.
Built from https://develop.svn.wordpress.org/trunk@54945
git-svn-id: http://core.svn.wordpress.org/trunk@54497 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-12-06 17:16:13 -05:00
function get_blog_option ( $id , $option , $default_value = false ) {
2012-08-08 13:11:15 -04:00
$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 ) {
Code Modernization: Rename parameters that use reserved keywords in `wp-includes/ms-blogs.php`.
While using reserved PHP keywords as parameter name labels is allowed, in the context of function calls using named parameters in PHP 8.0+, this will easily lead to confusion. To avoid that, it is recommended not to use reserved keywords as function parameter names.
This commit renames the `$default` parameter to `$default_value` in `get_blog_option()`.
Follow-up to [52946], [52996], [52997], [52998], [53003], [53014], [53029], [53039], [53116], [53117], [53137], [53174], [53184], [53185], [53192], [53193], [53198], [53203], [53207], [53215], [53216], [53220], [53230], [53232], [53236], [53239], [53240], [53242], [53243], [53245], [53246], [53257], [53269], [53270], [53271], [53272], [53273], [53274], [53275], [53276], [53277], [53281], [53283], [53284], [53285], [53287], [53364], [53365], [54927], [54929], [54930], [54931], [54932], [54933], [54938], [54943], [54944].
Props jrf, aristath, poena, justinahinon, SergeyBiryukov.
See #56788.
Built from https://develop.svn.wordpress.org/trunk@54945
git-svn-id: http://core.svn.wordpress.org/trunk@54497 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-12-06 17:16:13 -05:00
return get_option ( $option , $default_value );
2017-11-30 18:11:00 -05:00
}
2012-08-08 13:11:15 -04:00
switch_to_blog ( $id );
Code Modernization: Rename parameters that use reserved keywords in `wp-includes/ms-blogs.php`.
While using reserved PHP keywords as parameter name labels is allowed, in the context of function calls using named parameters in PHP 8.0+, this will easily lead to confusion. To avoid that, it is recommended not to use reserved keywords as function parameter names.
This commit renames the `$default` parameter to `$default_value` in `get_blog_option()`.
Follow-up to [52946], [52996], [52997], [52998], [53003], [53014], [53029], [53039], [53116], [53117], [53137], [53174], [53184], [53185], [53192], [53193], [53198], [53203], [53207], [53215], [53216], [53220], [53230], [53232], [53236], [53239], [53240], [53242], [53243], [53245], [53246], [53257], [53269], [53270], [53271], [53272], [53273], [53274], [53275], [53276], [53277], [53281], [53283], [53284], [53285], [53287], [53364], [53365], [54927], [54929], [54930], [54931], [54932], [54933], [54938], [54943], [54944].
Props jrf, aristath, poena, justinahinon, SergeyBiryukov.
See #56788.
Built from https://develop.svn.wordpress.org/trunk@54945
git-svn-id: http://core.svn.wordpress.org/trunk@54497 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-12-06 17:16:13 -05:00
$value = get_option ( $option , $default_value );
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
}
/**
2020-06-28 10:09:04 -04:00
* Add a new option for a given blog ID .
2012-08-08 13:11:15 -04:00
*
* 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 .
2020-07-05 10:46:03 -04:00
* @ return bool True if the option was added , false otherwise .
2012-08-08 13:11:15 -04:00
*/
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 ;
}
/**
2020-06-28 10:09:04 -04:00
* Removes option by name for a given blog ID . Prevents removal of protected WordPress options .
2012-08-08 13:11:15 -04:00
*
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 .
2020-07-05 10:46:03 -04:00
* @ return bool True if the option was deleted , false otherwise .
2012-08-08 13:11:15 -04:00
*/
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
*
2020-06-28 10:09:04 -04:00
* @ param int $id The blog ID .
2016-01-08 20:45:26 -05:00
* @ param string $option The option key .
* @ param mixed $value The option value .
* @ param mixed $deprecated Not used .
2020-07-05 10:46:03 -04:00
* @ return bool True if the value was updated , false otherwise .
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
*
2019-08-03 21:12:56 -04:00
* @ global wpdb $wpdb WordPress database abstraction object .
2015-05-26 17:51:31 -04:00
* @ global int $blog_id
* @ global array $_wp_switched_stack
* @ global bool $switched
* @ global string $table_prefix
* @ global WP_Object_Cache $wp_object_cache
*
2019-08-14 10:29:56 -04:00
* @ param int $new_blog_id The ID of the blog to switch to . Default : current blog .
* @ param bool $deprecated Not used .
* @ return true Always returns true .
2010-09-30 21:32:31 -04:00
*/
2019-08-14 10:29:56 -04:00
function switch_to_blog ( $new_blog_id , $deprecated = null ) {
2017-09-27 17:44:44 -04:00
global $wpdb ;
2010-02-13 17:35:11 -05:00
2019-08-14 10:29:56 -04:00
$prev_blog_id = get_current_blog_id ();
if ( empty ( $new_blog_id ) ) {
$new_blog_id = $prev_blog_id ;
2016-08-31 00:55:54 -04:00
}
2010-02-13 17:35:11 -05:00
2019-08-14 10:29:56 -04:00
$GLOBALS [ '_wp_switched_stack' ][] = $prev_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
*/
2019-08-14 10:29:56 -04:00
if ( $new_blog_id == $prev_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 )
2020-01-22 15:53:05 -05:00
* @ since 5.4 . 0 The `$context` parameter was added .
2013-12-01 12:32:10 -05:00
*
2020-01-22 15:53:05 -05:00
* @ param int $new_blog_id New blog ID .
* @ param int $prev_blog_id Previous blog ID .
* @ param string $context Additional context . Accepts 'switch' when called from switch_to_blog ()
* or 'restore' when called from restore_current_blog () .
2013-12-01 12:32:10 -05:00
*/
2020-01-22 15:53:05 -05:00
do_action ( 'switch_blog' , $new_blog_id , $prev_blog_id , 'switch' );
2020-06-15 08:31:11 -04:00
2012-08-21 23:34:00 -04:00
$GLOBALS [ 'switched' ] = true ;
2020-06-15 08:31:11 -04:00
2010-02-13 17:35:11 -05:00
return true ;
}
2019-08-14 10:29:56 -04:00
$wpdb -> set_blog_id ( $new_blog_id );
2013-09-24 19:41:10 -04:00
$GLOBALS [ 'table_prefix' ] = $wpdb -> get_blog_prefix ();
2019-08-14 10:29:56 -04:00
$GLOBALS [ 'blog_id' ] = $new_blog_id ;
2010-10-19 03:48:22 -04:00
2012-08-02 14:31:14 -04:00
if ( function_exists ( 'wp_cache_switch_to_blog' ) ) {
2019-08-14 10:29:56 -04:00
wp_cache_switch_to_blog ( $new_blog_id );
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
}
2020-06-15 08:31:11 -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 {
Coding Standards: Wrap long lines with global cache groups for better readability.
Follow-up to [946/tests], [1060/tests], [https://mu.trac.wordpress.org/changeset/1784 mu1784], [https://mu.trac.wordpress.org/changeset/2032 mu2032] [https://mu.trac.wordpress.org/changeset/2029 mu2029], [7986], [12128], [12603], [12688], [12732], [12755], [13125], [14009], [15482], [21403], [22092], [31347], [31348], [36258], [36393], [36413], [37918], [40343], [40347], [42836].
See #55647.
Built from https://develop.svn.wordpress.org/trunk@53823
git-svn-id: http://core.svn.wordpress.org/trunk@53382 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-08-04 09:33:12 -04:00
wp_cache_add_global_groups (
array (
'blog-details' ,
'blog-id-cache' ,
2022-08-04 12:29:10 -04:00
'blog-lookup' ,
'blog_meta' ,
'global-posts' ,
Coding Standards: Wrap long lines with global cache groups for better readability.
Follow-up to [946/tests], [1060/tests], [https://mu.trac.wordpress.org/changeset/1784 mu1784], [https://mu.trac.wordpress.org/changeset/2032 mu2032] [https://mu.trac.wordpress.org/changeset/2029 mu2029], [7986], [12128], [12603], [12688], [12732], [12755], [13125], [14009], [15482], [21403], [22092], [31347], [31348], [36258], [36393], [36413], [37918], [40343], [40347], [42836].
See #55647.
Built from https://develop.svn.wordpress.org/trunk@53823
git-svn-id: http://core.svn.wordpress.org/trunk@53382 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-08-04 09:33:12 -04:00
'networks' ,
'sites' ,
'site-details' ,
2022-08-04 12:29:10 -04:00
'site-options' ,
'site-transient' ,
'rss' ,
'users' ,
'useremail' ,
'userlogins' ,
'usermeta' ,
'user_meta' ,
'userslugs' ,
Coding Standards: Wrap long lines with global cache groups for better readability.
Follow-up to [946/tests], [1060/tests], [https://mu.trac.wordpress.org/changeset/1784 mu1784], [https://mu.trac.wordpress.org/changeset/2032 mu2032] [https://mu.trac.wordpress.org/changeset/2029 mu2029], [7986], [12128], [12603], [12688], [12732], [12755], [13125], [14009], [15482], [21403], [22092], [31347], [31348], [36258], [36393], [36413], [37918], [40343], [40347], [42836].
See #55647.
Built from https://develop.svn.wordpress.org/trunk@53823
git-svn-id: http://core.svn.wordpress.org/trunk@53382 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-08-04 09:33:12 -04:00
)
);
2015-02-05 22:24:23 -05:00
}
2020-06-15 08:31:11 -04: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 */
2020-01-22 15:53:05 -05:00
do_action ( 'switch_blog' , $new_blog_id , $prev_blog_id , 'switch' );
2020-06-15 08:31:11 -04:00
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
/**
2019-08-14 10:29:56 -04:00
* Restore the current blog , after calling switch_to_blog () .
2010-09-30 21:32:31 -04:00
*
* @ 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
*
2019-08-03 21:12:56 -04:00
* @ global wpdb $wpdb WordPress database abstraction object .
2015-05-26 17:51:31 -04:00
* @ global array $_wp_switched_stack
* @ global int $blog_id
* @ global bool $switched
* @ global string $table_prefix
* @ global WP_Object_Cache $wp_object_cache
*
2019-08-14 10:29:56 -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
2019-08-14 10:29:56 -04:00
$new_blog_id = array_pop ( $GLOBALS [ '_wp_switched_stack' ] );
$prev_blog_id = get_current_blog_id ();
2010-02-13 17:35:11 -05:00
2019-08-14 10:29:56 -04:00
if ( $new_blog_id == $prev_blog_id ) {
2013-12-01 12:32:10 -05:00
/** This filter is documented in wp-includes/ms-blogs.php */
2020-01-22 15:53:05 -05:00
do_action ( 'switch_blog' , $new_blog_id , $prev_blog_id , 'restore' );
2020-06-15 08:31:11 -04:00
2020-01-28 19:45:18 -05: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' ] );
2020-06-15 08:31:11 -04:00
2010-02-13 17:35:11 -05:00
return true ;
}
2019-08-14 10:29:56 -04:00
$wpdb -> set_blog_id ( $new_blog_id );
$GLOBALS [ 'blog_id' ] = $new_blog_id ;
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' ) ) {
2019-08-14 10:29:56 -04:00
wp_cache_switch_to_blog ( $new_blog_id );
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 {
Coding Standards: Wrap long lines with global cache groups for better readability.
Follow-up to [946/tests], [1060/tests], [https://mu.trac.wordpress.org/changeset/1784 mu1784], [https://mu.trac.wordpress.org/changeset/2032 mu2032] [https://mu.trac.wordpress.org/changeset/2029 mu2029], [7986], [12128], [12603], [12688], [12732], [12755], [13125], [14009], [15482], [21403], [22092], [31347], [31348], [36258], [36393], [36413], [37918], [40343], [40347], [42836].
See #55647.
Built from https://develop.svn.wordpress.org/trunk@53823
git-svn-id: http://core.svn.wordpress.org/trunk@53382 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-08-04 09:33:12 -04:00
wp_cache_add_global_groups (
array (
'blog-details' ,
'blog-id-cache' ,
2022-08-04 12:29:10 -04:00
'blog-lookup' ,
'blog_meta' ,
'global-posts' ,
Coding Standards: Wrap long lines with global cache groups for better readability.
Follow-up to [946/tests], [1060/tests], [https://mu.trac.wordpress.org/changeset/1784 mu1784], [https://mu.trac.wordpress.org/changeset/2032 mu2032] [https://mu.trac.wordpress.org/changeset/2029 mu2029], [7986], [12128], [12603], [12688], [12732], [12755], [13125], [14009], [15482], [21403], [22092], [31347], [31348], [36258], [36393], [36413], [37918], [40343], [40347], [42836].
See #55647.
Built from https://develop.svn.wordpress.org/trunk@53823
git-svn-id: http://core.svn.wordpress.org/trunk@53382 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-08-04 09:33:12 -04:00
'networks' ,
'sites' ,
'site-details' ,
2022-08-04 12:29:10 -04:00
'site-options' ,
'site-transient' ,
'rss' ,
'users' ,
'useremail' ,
'userlogins' ,
'usermeta' ,
'user_meta' ,
'userslugs' ,
Coding Standards: Wrap long lines with global cache groups for better readability.
Follow-up to [946/tests], [1060/tests], [https://mu.trac.wordpress.org/changeset/1784 mu1784], [https://mu.trac.wordpress.org/changeset/2032 mu2032] [https://mu.trac.wordpress.org/changeset/2029 mu2029], [7986], [12128], [12603], [12688], [12732], [12755], [13125], [14009], [15482], [21403], [22092], [31347], [31348], [36258], [36393], [36413], [37918], [40343], [40347], [42836].
See #55647.
Built from https://develop.svn.wordpress.org/trunk@53823
git-svn-id: http://core.svn.wordpress.org/trunk@53382 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-08-04 09:33:12 -04:00
)
);
2015-02-05 22:24:23 -05:00
}
2020-06-15 08:31:11 -04: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 */
2020-01-22 15:53:05 -05:00
do_action ( 'switch_blog' , $new_blog_id , $prev_blog_id , 'restore' );
2012-08-09 12:28:15 -04:00
2020-01-28 19:45:18 -05: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 ;
}
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
*
2019-08-11 12:18:57 -04:00
* @ param int $id Blog ID .
* @ 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
*
2019-08-11 12:18:57 -04:00
* @ param int $id Blog ID .
* @ param string $archived The new status .
2010-09-30 21:32:31 -04:00
* @ 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
*
2019-08-11 12:18:57 -04:00
* @ param int $blog_id Blog ID .
* @ param string $pref Field name .
* @ param string $value Field value .
* @ param null $deprecated Not used .
2015-05-26 17:51:31 -04:00
* @ 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
General: Remove “whitelist” and “blacklist” in favor of more clear and inclusive language.
“The WordPress open source community cares about diversity. We strive to maintain a welcoming environment where everyone can feel included.”
With this commit, all occurrences of “whitelist” and “blacklist” (with the single exception of the `$new_whitelist_options` global variable) are removed. A new ticket has been opened to explore renaming the `$new_whitelist_options` variable (#50434).
Changing to more specific names or rewording sentences containing these terms not only makes the code more inclusive, but also helps provide clarity. These terms are often ambiguous. What is being blocked or allowed is not always immediately clear. This can make it more difficult for non-native English speakers to read through the codebase.
Words matter. If one contributor feels more welcome because these terms are removed, this was worth the effort.
Props strangerstudios, jorbin, desrosj, joemcgill, timothyblynjacobs, ocean90, ayeshrajans, davidbaumwald, earnjam.
See #48900, #50434.
Fixes #50413.
Built from https://develop.svn.wordpress.org/trunk@48121
git-svn-id: http://core.svn.wordpress.org/trunk@47890 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2020-06-22 13:26:13 -04:00
$allowed_field_names = array ( 'site_id' , 'domain' , 'path' , 'registered' , 'last_updated' , 'public' , 'archived' , 'mature' , 'spam' , 'deleted' , 'lang_id' );
2020-04-04 23:02:11 -04:00
General: Remove “whitelist” and “blacklist” in favor of more clear and inclusive language.
“The WordPress open source community cares about diversity. We strive to maintain a welcoming environment where everyone can feel included.”
With this commit, all occurrences of “whitelist” and “blacklist” (with the single exception of the `$new_whitelist_options` global variable) are removed. A new ticket has been opened to explore renaming the `$new_whitelist_options` variable (#50434).
Changing to more specific names or rewording sentences containing these terms not only makes the code more inclusive, but also helps provide clarity. These terms are often ambiguous. What is being blocked or allowed is not always immediately clear. This can make it more difficult for non-native English speakers to read through the codebase.
Words matter. If one contributor feels more welcome because these terms are removed, this was worth the effort.
Props strangerstudios, jorbin, desrosj, joemcgill, timothyblynjacobs, ocean90, ayeshrajans, davidbaumwald, earnjam.
See #48900, #50434.
Fixes #50413.
Built from https://develop.svn.wordpress.org/trunk@48121
git-svn-id: http://core.svn.wordpress.org/trunk@47890 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2020-06-22 13:26:13 -04:00
if ( ! in_array ( $pref , $allowed_field_names , true ) ) {
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
*
2019-08-11 12:18:57 -04:00
* @ param int $id Blog ID .
* @ param string $pref 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
*
2019-08-11 12:18:57 -04:00
* @ param mixed $deprecated Not used .
* @ param int $start Optional . Number of blogs to offset the query . Used to build LIMIT clause .
* Can be used for pagination . Default 0.
* @ param int $quantity Optional . The maximum number of blogs to retrieve . Default 40.
* @ return array The list of blogs .
2010-09-30 21:32:31 -04:00
*/
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 ) ) {
2020-01-28 19:45:18 -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
*
2019-12-06 17:43:04 -05:00
* @ param string $new_status The new post status .
* @ param string $old_status The old post status .
* @ param WP_Post $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
2020-05-16 14:42:12 -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
2020-05-16 14:42:12 -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 ();
}
2019-09-23 13:35:59 -04:00
/**
* Count number of sites grouped by site status .
*
* @ since 5.3 . 0
*
2019-11-05 16:23:02 -05:00
* @ param int $network_id Optional . The network to get counts for . Default is the current network ID .
* @ return int [] {
* Numbers of sites grouped by site status .
*
* @ type int $all The total number of sites .
* @ type int $public The number of public sites .
* @ type int $archived The number of archived sites .
* @ type int $mature The number of mature sites .
* @ type int $spam The number of spam sites .
* @ type int $deleted The number of deleted sites .
* }
2019-09-23 13:35:59 -04:00
*/
function wp_count_sites ( $network_id = null ) {
if ( empty ( $network_id ) ) {
$network_id = get_current_network_id ();
}
$counts = array ();
$args = array (
'network_id' => $network_id ,
'number' => 1 ,
'fields' => 'ids' ,
'no_found_rows' => false ,
);
$q = new WP_Site_Query ( $args );
$counts [ 'all' ] = $q -> found_sites ;
$_args = $args ;
$statuses = array ( 'public' , 'archived' , 'mature' , 'spam' , 'deleted' );
foreach ( $statuses as $status ) {
$_args = $args ;
$_args [ $status ] = 1 ;
$q = new WP_Site_Query ( $_args );
$counts [ $status ] = $q -> found_sites ;
}
return $counts ;
}