Para executar uma ação quando uma publicação muda de rascunho para publicada, use o hook transition_post_status e verifique os estados anterior e novo. O WordPress também oferece o hook dinâmico publish_post, mas entender a transição ajuda a evitar que uma integração repita o efeito quando um post publicado é apenas atualizado.
Detecte a primeira transição para publicado
Um exemplo mínimo para posts padrão é:
add_action( 'transition_post_status', 'hipersite_ao_publicar_post', 10, 3 );
function hipersite_ao_publicar_post( $novo_status, $status_anterior, $post ) {
if ( 'publish' !== $novo_status || 'publish' === $status_anterior ) {
return;
}
if ( 'post' !== $post->post_type ) {
return;
}
}Substitua o corpo vazio por uma ação pequena que possa ser testada, como enfileirar um trabalho interno; não faça uma requisição externa lenta durante o salvamento do post.
O filtro exclui estados em que o conteúdo não ficou público e atualizações de posts que já estavam publicados. Se você também precisa tratar páginas ou um tipo personalizado, ajuste o teste post_type de forma intencional. Publicações agendadas podem fazer a transição para publish quando chegar a hora; teste esse cenário no ambiente usado.
Escolha o hook conforme o evento
transition_post_status fornece o novo status, o anterior e o objeto do post. publish_post é uma ação dinâmica do tipo {$new_status}_{$post->post_type} e recebe ID, objeto e status anterior. Confira a referência oficial e os argumentos do hook antes de copiar código: usar um nome semelhante com ordem de parâmetros diferente pode causar erros.
Se a ação chama um serviço externo, projete-a para ser idempotente ou registre que o evento já foi processado. Uma repetição após timeout, reenvio ou recuperação não deve enviar duas notificações, criar cópias duplicadas ou cobrar novamente. Não coloque chaves secretas no navegador nem faça uma integração lenta bloquear o salvamento do post.
Teste antes de ativar no site público
Use staging e um post fictício. Teste rascunho → publicado, agendado → publicado, atualização de um post já publicado, mudança para rascunho e tipos de conteúdo que não devem disparar a ação. Confira logs sem registrar dados pessoais desnecessários e tenha como desativar a personalização.
Para código que precisa sobreviver à troca do tema, mantenha a lógica num plugin próprio ou solução de implantação versionada, em vez de colar o trecho no tema pai. Se não administra PHP/WordPress, encaminhe os requisitos e testes esperados a quem mantém a instalação.
Fontes oficiais: WordPress Developer Reference — wp_transition_post_status e referência de ações do WordPress.