WordPress как на ладони
wordpress jino

before_delete_post хук-событие . WP 3.2

Срабатывает до того как запись (пост) будет удалена, в самом начале функции wp_delete_post().

Это событие срабатывает до того как, будут произведены какие либо действия над очисткой базы данных от поста: удаление метаданных, изменение родителя у вложений удаляемого поста

Этот хук-событие срабатывает только в том случае, если запись удаляется из корзины или если корзина отключена, т.е. когда запись удаляется безвозвратно.

Заметка

Хук не срабатывает, если удаляется вложение (прикрепленный файл, файл медиатеки). Чтобы производить действие при удалении вложения используйте хук delete_post - срабатывает прямо перед тем как сама запись будет удалена из базы данных. Если нужно что-то сделать после того, как запись удалена и удалены все её связи и метаданные, используйте хук deleted_post, но имейте ввиду что на этот момент записи в БД уже нет и данные удаленного поста можно получить только через хук, а не через get_post().

Использование

add_action( 'before_delete_post', 'action_function_name_11' );
function action_function_name_11( $postid ) {
	// Действие...
}
$postid(число)
ID поста, который передается в функцию прикрепленную к событию.

Примеры

#1 Действие при удалении поста

Предположим мы пишем плагин и нам нужно что-то сделать в тот момент, когда удаляется произвольный тип записи "my_post_type":

add_action( 'before_delete_post', 'my_func' );
function my_func( $postid ){
	// Проверяем наш ли это тип записи удаляется

	$post = get_post( $postid );

	// если нет, выходим.
	if( ! $post || $post->post_type !== 'my_custom_post_type' ) 
		return;

	// Код который будет делать что нам нужно при удалении
}

Где используется хук

wp_delete_post() остальные хуки:

Код хука-события before_delete_post

Фрагмент из: wp-includes/post.php VER 4.9.2
...
	 */
	$check = apply_filters( 'pre_delete_post', null, $post, $force_delete );
	if ( null !== $check ) {
		return $check;
	}

	/**
	 * Fires before a post is deleted, at the start of wp_delete_post().
	 *
	 * @since 3.2.0
	 *
	 * @see wp_delete_post()
	 *
	 * @param int $postid Post ID.
	 */
	do_action( 'before_delete_post', $postid );

	delete_post_meta($postid,'_wp_trash_meta_status');
	delete_post_meta($postid,'_wp_trash_meta_time');

	wp_delete_object_term_relationships($postid, get_object_taxonomies($post->post_type));

	$parent_data = array( 'post_parent' => $post->post_parent );
	$parent_where = array( 'post_parent' => $postid );

	if ( is_post_type_hierarchical( $post->post_type ) ) {
		// Point children of this page to its parent, also clean the cache of affected children.
		$children_query = $wpdb->prepare( "SELECT * FROM $wpdb->posts WHERE post_parent = %d AND post_type = %s", $postid, $post->post_type );
		$children = $wpdb->get_results( $children_query );
		if ( $children ) {
			$wpdb->update( $wpdb->posts, $parent_data, $parent_where + array( 'post_type' => $post->post_type ) );
...
before_delete_post 2 комментария
  • Дмитрий

    Здравствуйте. А могли бы Вы дополнить пост или в комментариях, что $post_id, в данном случае, это id поста который удаляется, не совсем понятно, что при выполнения add_action, id передается именно хуком, а не нам самим нужно его указывать. И откуда берется global $post_type;? Я так и не разобрался, если это глобальная переменная Wp_Query, то global $category_name - оказалась NULL, проясните, этот момент, пожалуйста

    Ответитьмесяц назад #
    • Kama4711

      События (хуки) всегда передают данные какие-то - это базовое поведение.

      Про global $post_type вы правы, поправил пример, было не очень правильно и универсально.

      Ответитьмесяц назад #

Здравствуйте, !

Ваш комментарий
Предпросмотр