Вход на сайт

Просмотр новости

Найдите то, что Вас интересует

Comment on wp_insert_post by Rodrigo Vieira Eufrasio da Silva

Дата публикации: 14-08-2026 17:17:59

wp_insert_post() runs post_content (and a few other fields) through wp_filter_kses() unless the current user has the 'unfiltered_html' capability. On a single-site install, Administrators have this cap by default — but there's a context most people don't think about: when there is NO logged-in user at all.
If you call wp_insert_post() from WP-CLI, a wp-cron event, a REST request with no authenticated user, or a standalone script that loads wp-load.php directly, get_current_user_id() returns 0. In that case current_user_can( 'unfiltered_html' ) is false — even if you're the site owner and would normally have full access — and your content gets silently passed through kses. Script tags, iframes, and various HTML attributes get stripped with NO warning, NO error, and no WP_Error returned; wp_insert_post() just succeeds with the sanitized content.
This is one of the most common causes of "why did my import/cron job strip HTML from my post_content" — the code works fine when triggered manually from the browser (where you're logged in as admin) but breaks silently when the exact same code runs via cron or WP-CLI.
Fix: explicitly set a user context with sufficient capability before inserting, and restore it afterward if needed:
$original_user = get_current_user_id();
wp_set_current_user( 1 ); // or any user ID with 'unfiltered_html'
$post_id = wp_insert_post( array(
'post_title' => 'Imported post',
'post_content' => $html_with_iframes_and_scripts,
'post_status' => 'publish',
) );
wp_set_current_user( $original_user ); // restore previous context
Also worth knowing: on Multisite, even a logged-in site Administrator does NOT have 'unfiltered_html' by default — only Super Admins do (see wp-includes/capabilities.php, WP_User::has_cap() / map_meta_cap()). So the same silent-stripping behavior also affects regular multisite admins running this function normally, not just CLI/cron contexts.

Основное содержимое страницы с новостью.

Fires once a post has been saved.

Parameters
$post_idint

Post ID.

$postWP_Post

Post object.

$updatebool

Whether this is an existing post being updated.

More Information

The wp_insert_post action fires once a post has been saved. You have the ability to set it to only fire on new posts or on all save actions using the parameters. Please see Plugin_API/Action_Reference/save_post for more information. Keep in mind that this action is called both for actions in the admin as well as anytime the wp_insert_post() function is invoked.

This action can be replicated by creating a conditional in a save_post action that excludes certain post statuses.

An important distinction of wp_insert_post action is that it is fired after update_post_meta has been called.

Source
do_action( 'wp_insert_post', $post_id, $post, $update );

View all references View on Trac View on GitHub

Changelog
VersionDescription
2.0.0Introduced.

Схожие новости

#Наименование новостиТональностьИнформативностьДата публикации
1 Comment on load_script_textdomain_relative_path by Rodrigo Vieira Eufrasio da Silva 08.6914-08-2026
2 Comment on wp_deregister_script() by Rodrigo Vieira Eufrasio da Silva 029.5314-08-2026
3JS Error0727-06-2026
4 Comment on WP_REST_Request::get_param() by Rodrigo Vieira Eufrasio da Silva 012.6414-08-2026
5 Comment on WP_Icons_Registry by Rodrigo Vieira Eufrasio da Silva 09.3814-08-2026
6Untitled Snippet012.4713-01-2026
7Reply To: remove admin email012.8409-08-2026
8Reply To: widgets not showing on page edit018.5615-07-2026
9Parameter display conditions (hide element when empty)0510-07-2026

Классификация: . Схожих патентов: 0. Схожих новостей: 9. Тональность: 0. Информативность: 13.12. Источник: developer.wordpress.org.