Eu tenho uma função que define um campo personalizado em um tipo de postagem. Digamos que o campo seja "subtítulo".
Quando a postagem é salva, desejo validar a entrada e exibir uma mensagem de erro na tela de edição da postagem, se necessário. Algo como:
// Handle post updating
function wpse_update_post_custom_values($post_id, $post) {
// Do some checking...
if($_POST['subhead'] != 'value i expect') {
// Add an error here
$errors->add('oops', 'There was an error.');
}
return $errors;
}
add_action('save_post','wpse_update_post_custom_values',1,2);
Estou tentando vincular isso à ação save_post, mas não consigo descobrir como lidar com erros. Não parece haver um objeto de erro passado para a função e, se eu criar meu próprio objeto WP_Error e o devolver, ele não será respeitado por qualquer mecanismo que solte erros na página de pós-edição.
Atualmente, tenho uma mensagem de erro na página dentro da minha caixa de meta personalizada, mas isso é menos do que o ideal - eu prefiro ter um grande erro vermelho, alto, como o WP normalmente exibe.
Alguma ideia?
ATUALIZAR:
Com base na resposta de @Denis, tentei algumas coisas diferentes. O armazenamento de erros como global não funcionou, porque o Wordpress faz um redirecionamento durante o processo save_post, que mata o global antes que você possa exibi-lo.
Acabei armazenando-os em um meta-campo. O problema é que você precisa limpá-las ou elas não desaparecerão quando você navegar para outra página, então tive que adicionar outra função anexada ao admin_footer que apenas apaga os erros.
Eu não esperava que o tratamento de erros para algo tão comum (atualizando postagens) fosse tão desajeitado. Estou perdendo algo óbvio ou essa é a melhor abordagem?
// Handle post updating
function wpse_5102_update_post_custom_values($post_id, $post) {
// To keep the errors in
$errors = false;
// Do some validation...
if($_POST['subhead'] != 'value i expect') {
// Add an error here
$errors .= 'whoops...there was an error.';
}
update_option('my_admin_errors', $errors);
return;
}
add_action('save_post','wpse_5102_update_post_custom_values',1,2);
// Display any errors
function wpse_5102_admin_notice_handler() {
$errors = get_option('my_admin_errors');
if($errors) {
echo '<div class="error"><p>' . $errors . '</p></div>';
}
}
add_action( 'admin_notices', 'wpse_5102_admin_notice_handler' );
// Clear any errors
function wpse_5102__clear_errors() {
update_option('my_admin_errors', false);
}
add_action( 'admin_footer', 'wpse_5102_clear_errors' );
fonte
admin_footer
gancho se limpar os erros no final da função do manipulador de avisos. Simplifica as coisas um pouco.update_option('my_admin_errors', false);
imediatamente após a instrução if no final dewpse_5102_admin_notice_handler()
?Respostas:
Armazene erros em sua classe ou como global, possivelmente em um transitório ou meta, e exiba-os em avisos de administrador em solicitações POST. O WP não possui nenhum manipulador de mensagens flash.
fonte
Sugiro usar sessões, pois isso não criará efeitos estranhos quando dois usuários editarem ao mesmo tempo. Então é isso que eu faço:
As sessões não são iniciadas pelo wordpress. Então você precisa iniciar uma sessão no seu plugin, functions.php ou mesmo wp-config.php:
Ao salvar a postagem, anexe erros e avisos à sessão:
Imprima avisos e erros e limpe as mensagens na sessão:
fonte
Baseado em pospi 's sugestão para uso transientes , eu vim com o seguinte. O único problema é que não há gancho para colocar a mensagem abaixo de
h2
onde outras mensagens vão, então eu tive que fazer um hack do jQuery para chegar lá.Primeiro, salve a mensagem de erro durante o manipulador
save_post
(ou similar). Eu concedo um tempo de vida curto de 60 segundos, portanto, existe apenas o tempo suficiente para o redirecionamento acontecer.Em seguida, basta recuperar a mensagem de erro na próxima página carregada e exibi-la. Também o apago para que não seja exibido duas vezes.
Como é
admin_notices
acionado antes que o conteúdo da página principal seja gerado, o aviso não é para onde as outras mensagens de pós-edição vão, então eu tive que usar esse jQuery para movê-lo para lá:Como o ID da postagem faz parte do nome transitório, isso deve funcionar na maioria dos ambientes multiusuário, exceto quando vários usuários estão editando simultaneamente a mesma postagem.
fonte
acme_plugin_error_msg_POSTID
. Você pode apenas adicionar o ID do usuário a esse gostoacme_plugin_error_msg_POSTID_USERID
.Quando
save_post
executado, ele já salvou a postagem no banco de dados.Analisando o código principal do WordPress, mais especificamente no
wp-includes/post.php
'supdate_post()
função, não há built-in maneira de interceptar um pedido antes de ser salvo no banco de dados.No entanto, podemos conectar
pre_post_update
e usarheader()
eget_post_edit_link()
impedir que a postagem seja salva.Se você notificar o usuário sobre o erro, verifique esta lista: https://gist.github.com/Luc45/09f2f9d0c0e574c0285051b288a0f935
fonte
Por que você não valida seu campo com a ajuda de algum Javascript? Eu acho que essa seria a melhor abordagem para isso.
fonte
Tentando usar o script acima, encontrei um problema estranho. Duas mensagens são mostradas na tela de edição, após a atualização posterior. Um está mostrando o estado do conteúdo do salvamento anterior e outro do atual. Por exemplo, se eu salvar a postagem corretamente e depois cometer um erro, a primeira é "erro" e a segunda é "ok" - embora elas sejam geradas ao mesmo tempo. Se eu alterar o script e anexar apenas uma mensagem (por exemplo, "erro"), inicie uma atualização com "erro" e depois outra com "ok", a mensagem "erro" permanece (é exibida pela segunda vez). Devo salvar com "ok" mais uma vez para me livrar dele. Realmente não sei o que há de errado, testei-o em três servidores locais diferentes e há o mesmo problema em cada um deles.
fonte
Eu escrevi um plug-in que adiciona um tratamento de erro em flash às telas de pós-edição e evita a publicação de postagens até que os campos obrigatórios sejam preenchidos:
https://github.com/interconnectit/required-fields
Ele permite a obrigatoriedade de qualquer campo de postagem, mas você pode usar a API fornecida para tornar os campos personalizados necessários também com uma mensagem de erro personalizável e uma função de validação. O padrão é verificar se o campo está vazio ou não.
fonte