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.
Below is a basic example that will send an email every time a post or page is created or updated on your website. (copied from codex)
function my_project_updated_send_email( $post_id, $post, $update ) {
// If this is a revision, don't send the email.
if ( wp_is_post_revision( $post_id ) )
return;
$post_url = get_permalink( $post_id );
$subject = 'A post has been updated';
$message = "A post has been updated on your website:\n\n";
$message .= $post->post_title . ": " . $post_url;
// Send email to admin.
wp_mail( 'admin@example.com', $subject, $message );
}
add_action( 'wp_insert_post', 'my_project_updated_send_email', 10, 3 );
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’
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.
You must log in before being able to contribute a note or feedback.
Below is a basic example that will send an email every time a post or page is created or updated on your website. (copied from codex)
It’s not reliable to check first publication.
$updatewill betruein first time post is published if you are using dashboard because it creates revisions.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.