Acabei de terminar um recurso para um projeto que usa uma combina\u00e7\u00e3o de tipos de postagem personalizados, importa\u00e7\u00f5es de dados e atualiza\u00e7\u00e3o de postagens existentes ao excluir um usu\u00e1rio (ou conjunto de usu\u00e1rios).<\/p>\n
H\u00e1 um problema, por\u00e9m:<\/p>\n
Digamos que voc\u00ea tenha uma postagem publicada no momento (ou seja, seu ‘post_status’ est\u00e1 definido como ‘publicar’), mas, quando voc\u00ea atualiza a postagem via wp_update_post, seu atributo post_status \u00e9 definido como ‘futuro’.<\/p>\n
Em outras palavras, sempre que voc\u00ea atualiza programaticamente uma postagem, o status da postagem \u00e9 definido como ‘Agendado’ (de acordo com a interface do usu\u00e1rio) e ‘futuro’ (de acordo com a coluna do banco de dados).<\/p>\n
Ent\u00e3o o que d\u00e1?<\/p>\n
De um modo geral, n\u00e3o sou f\u00e3 de fazer algo funcionar, descobrir que funciona e passar para a pr\u00f3xima tarefa, a menos que entenda exatamente por que n\u00e3o funcionou [como esperado] em primeiro lugar.<\/p>\n
Isso n\u00e3o quer dizer que n\u00e3o haja momentos em que as restri\u00e7\u00f5es tenham causado isso (pelo menos durante o hor\u00e1rio de trabalho). Mas se \u00e9 meia-noite, eu conserto um bug e n\u00e3o tenho certeza se entendi por que aparentemente estava quebrado em primeiro lugar, \u00e9 melhor ficar acordado e descobrir, certo?<\/p>\n
\u00c9 como a vers\u00e3o do programador do vi\u00e9s de custo afundado<\/a>.<\/p>\n De qualquer forma, conforme descrito acima, aqui est\u00e1 a ess\u00eancia do problema:<\/p>\n Tudo funciona muito bem, exceto que h\u00e1 um problema: sempre que a postagem \u00e9 atualizada programaticamente, ela marca o status da postagem como ‘futuro’ no banco de dados, definindo o item de linha da postagem na\u00a0 visualiza\u00e7\u00e3o Todas as postagens<\/strong> como "Agendado".<\/p>\n Existem duas maneiras de corrigir esse problema:<\/p>\n Se voc\u00ea optar pela primeira solu\u00e7\u00e3o, certifique-se de usar a fun\u00e7\u00e3o prepare e certifique-se de executar a consulta depois que a fun\u00e7\u00e3o de atualiza\u00e7\u00e3o for retornada<\/a>.<\/p>\n Se voc\u00ea optar pela segunda solu\u00e7\u00e3o, atualize explicitamente as propriedades do objeto post antes de pass\u00e1-lo para a fun\u00e7\u00e3o de atualiza\u00e7\u00e3o<\/a>.<\/p>\n N\u00e3o sou de dizer que n\u00e3o h\u00e1 lugar para nenhuma dessas solu\u00e7\u00f5es ao trabalhar em um projeto, mas a pergunta permanece:<\/p>\n Por que o WordPress est\u00e1 marcando uma postagem agendada para o futuro quando a postagem, antes de passar pelo procedimento de atualiza\u00e7\u00e3o, foi definida para publica\u00e7\u00e3o?<\/p>\n E se voc\u00ea n\u00e3o estiver familiarizado com o restante dos argumentos que s\u00e3o passados \u200b\u200bao WordPress ao atualizar um post, levar\u00e1 algum tempo para rastre\u00e1-lo.<\/p>\n Para evitar escrever uma consulta direta ao banco de dados, opto pela segunda solu\u00e7\u00e3o porque \u00e9 mais limpa (embora n\u00e3o a torne menos confusa).<\/p>\n Para descobrir por que esse comportamento acontece, voc\u00ea pode perguntar a outro desenvolvedor ou depurar o c\u00f3digo. Dado que eu estava trabalhando nisso tarde da noite, optei pelo \u00faltimo.<\/p>\n Executando o depurador e o c\u00f3digo de rastreamento atrav\u00e9s de post.php.<\/p>\n N\u00e3o vou falar sobre todos os pontos de interrup\u00e7\u00e3o e rel\u00f3gios que defini, ent\u00e3o tentarei ser o mais conciso poss\u00edvel.<\/p>\n Primeiro, quando o c\u00f3digo for executado pela fun\u00e7\u00e3o wp_update_post<\/a>, ele encontrar\u00e1 este bloco de c\u00f3digo<\/a> :<\/p>\n Observe que dentro da condicional, n\u00e3o estamos trabalhando com um anexo e estamos trabalhando com um status de postagem de ‘publicar’. Ent\u00e3o, vamos acertar a primeira condicional dentro da condicional externa (um pouco confuso, n\u00e3o \u00e9?).<\/p>\n Agora h\u00e1 uma vari\u00e1vel, $post_status, mantendo um valor de publica\u00e7\u00e3o, mas n\u00e3o \u00e9 atribu\u00edda a nenhuma propriedade espec\u00edfica da postagem atual. Se voc\u00ea continuar rastreando o c\u00f3digo, voc\u00ea encontrar\u00e1 a pr\u00f3xima linha<\/a> :<\/p>\n Aqui, voc\u00ea ver\u00e1 que est\u00e1 trabalhando com um conjunto de chaves de matriz contidas na vari\u00e1vel $postarr. Esta vari\u00e1vel \u00e9 usada anteriormente no c\u00f3digo (veja aqui<\/a> no Trac). E se voc\u00ea olhar de perto, ver\u00e1 que primeiro verifica se a propriedade post_date_gmt est\u00e1 vazia ou se est\u00e1 tudo zerado.<\/p>\n E como n\u00e3o \u00e9, ele usar\u00e1 o valor que especificamos na propriedade quando inicialmente chamamos a fun\u00e7\u00e3o<\/a> :<\/p>\n Espere.<\/p>\n Por que voltar para a fun\u00e7\u00e3o quando o c\u00f3digo j\u00e1 passou por isso? Essa \u00e9 a natureza da depura\u00e7\u00e3o. \u00c0s vezes voc\u00ea v\u00ea vari\u00e1veis \u200b\u200be n\u00e3o pensa nada sobre elas apenas para ver que s\u00e3o usadas, configuradas, manipuladas, combinadas ou qualquer outra coisa posteriormente no c\u00f3digo.<\/p>\n Essa \u00e9 a realidade disso.<\/p>\n Mas de qualquer forma, por causa disso, a propriedade manter\u00e1 o valor que fornecemos antes de chamar a fun\u00e7\u00e3o de atualiza\u00e7\u00e3o. Normalmente, este ser\u00e1 o mesmo valor de quando a fun\u00e7\u00e3o foi iniciada, mas pode haver momentos em que voc\u00ea queira, digamos, descartar uma postagem.<\/p>\n E isso \u00e9 motivo para usar wp_delete_post<\/a>. Mas tem suas ressalvas, especialmente em torno dos tipos de postagem personalizados.<\/p>\n Isso fica em outro post, no entanto.<\/p>\n\n
Duas solu\u00e7\u00f5es<\/h3>\n
\n
<?php\n\n\/\/ First, update the post using the available WordPress API.\nwp_update_post( $post );\n\n\/**\n * If the post status attribute of the post that was just updated\n * maintains the 'publish' post setatus, then manually update the \n * database column.\n *\/\nif ('publish' === $post->post_status) {\n\n global $wpdb;\n $wpdb->query(\n $wpdb->prepare(\n \"\n UPDATE $wpdb->posts\n SET post_status = '%s'\n WHERE ID = %d\n \",\n 'publish',\n $post->ID) );\n}\n<\/code><\/pre>\n<?php\n\n$event_post->post_date_gmt = gmdate( 'Y-m-d H:i:s', $event_post->post_date_gmt );\nwp_update_post( $event_post );\n<\/code><\/pre>\nEntendendo o problema<\/h2>\n
<?php\n\nif ('attachment' !== $post_type) {\n if ('publish' == $post_status) {\n $now = gmdate('Y-m-d H:i:59');\n if (mysql2date('U', $post_date_gmt, false) > mysql2date('U', $now, false)) {\n $post_status = 'future';\n }\n } elseif ('future' == $post_status) {\n $now = gmdate('Y-m-d H:i:59');\n if (mysql2date('U', $post_date_gmt, false) <= mysql2date('U', $now, false)) {\n $post_status = 'publish';\n }\n }\n}\n<\/code><\/pre>\n<?php\n\n$post_parent = apply_filters( 'wp_insert_post_parent', $post_parent, $post_ID, compact( array_keys( $postarr) ), $postarr );\n<\/code><\/pre>\n<?php\n\nif (empty( $postarr['post_date_gmt']) || '0000-00-00 00:00:00' == $postarr['post_date_gmt']) {\n if (! in_array( $post_status, array( 'draft', 'pending', 'auto-draft') )) {\n $post_date_gmt = get_gmt_from_date( $post_date );\n } else {\n $post_date_gmt = '0000-00-00 00:00:00';\n }\n } else {\n $post_date_gmt = $postarr['post_date_gmt'];\n }\n<\/code><\/pre>\n