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_idintPost ID.
$postWP_PostPost object.
$updateboolWhether this is an existing post being updated.
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.
do_action( 'wp_insert_post', $post_id, $post, $update );
View all references View on Trac View on GitHub
Changelog| Version | Description |
|---|---|
| 2.0.0 | Introduced. |
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | Comment on load_script_textdomain_relative_path by Rodrigo Vieira Eufrasio da Silva | 0 | 8.69 | 14-08-2026 |
| 2 | Comment on wp_deregister_script() by Rodrigo Vieira Eufrasio da Silva | 0 | 29.53 | 14-08-2026 |
| 3 | JS Error | 0 | 7 | 27-06-2026 |
| 4 | Comment on WP_REST_Request::get_param() by Rodrigo Vieira Eufrasio da Silva | 0 | 12.64 | 14-08-2026 |
| 5 | Comment on WP_Icons_Registry by Rodrigo Vieira Eufrasio da Silva | 0 | 9.38 | 14-08-2026 |
| 6 | Untitled Snippet | 0 | 12.47 | 13-01-2026 |
| 7 | Reply To: remove admin email | 0 | 12.84 | 09-08-2026 |
| 8 | Reply To: widgets not showing on page edit | 0 | 18.56 | 15-07-2026 |
| 9 | Parameter display conditions (hide element when empty) | 0 | 5 | 10-07-2026 |