Je viens de terminer une fonctionnalit\u00e9 pour un projet qui utilise une combinaison de types de publication personnalis\u00e9s, d’importations de donn\u00e9es et de mise \u00e0 jour des publications existantes lors de la suppression d’un utilisateur (ou d’un ensemble d’utilisateurs).<\/p>\n
Il y a cependant un probl\u00e8me :<\/p>\n
Disons que vous avez un message qui est actuellement publi\u00e9 (c’est-\u00e0-dire que ‘post_status’ est d\u00e9fini sur ‘publish’) mais, lorsque vous mettez \u00e0 jour le message via wp_update_post, son attribut post_status est d\u00e9fini sur ‘future’.<\/p>\n
En d’autres termes, chaque fois que vous mettez \u00e0 jour une publication par programme, le statut de la publication est d\u00e9fini sur "Planifi\u00e9" (selon l’interface utilisateur) et "futur" (selon la colonne de la base de donn\u00e9es).<\/p>\n
Alors qu’est-ce qui donne ?<\/p>\n
D’une mani\u00e8re g\u00e9n\u00e9rale, je ne suis pas fan de faire fonctionner quelque chose, de d\u00e9couvrir que c’est le cas et de passer \u00e0 la t\u00e2che suivante \u00e0 moins que je ne comprenne exactement pourquoi cela n’a pas fonctionn\u00e9 [comme pr\u00e9vu] en premier lieu.<\/p>\n
Cela ne veut pas dire qu’il n’y a pas de moments o\u00f9 des contraintes ont provoqu\u00e9 cela (au moins pendant les heures de travail). Mais s’il est minuit, je corrige un bug, et je ne suis pas tout \u00e0 fait s\u00fbr de comprendre pourquoi il a apparemment \u00e9t\u00e9 cass\u00e9 en premier lieu, autant rester \u00e9veill\u00e9 et comprendre, n’est-ce pas\u00a0?<\/p>\n
C’est comme la version du programmeur du biais de co\u00fbt irr\u00e9cup\u00e9rable<\/a>.<\/p>\n Quoi qu’il en soit, comme indiqu\u00e9 ci-dessus, voici l’essentiel du probl\u00e8me:<\/p>\n Tout fonctionne tr\u00e8s bien sauf qu’il y a un probl\u00e8me\u00a0: chaque fois que la publication est mise \u00e0 jour par programme, elle marque le statut de la publication comme "futur" dans la base de donn\u00e9es, d\u00e9finissant finalement l’\u00e9l\u00e9ment de campagne de la publication dans la\u00a0 vue Toutes<\/strong> les publications comme "Planifi\u00e9".<\/p>\n Il existe deux fa\u00e7ons de r\u00e9soudre ce probl\u00e8me\u00a0:<\/p>\n Si vous optez pour la premi\u00e8re solution, assurez-vous d’utiliser la fonction prepare et assurez-vous d’ex\u00e9cuter la requ\u00eate apr\u00e8s le retour de la fonction update<\/a>.<\/p>\n Si vous optez pour la seconde solution, mettez alors explicitement \u00e0 jour les propri\u00e9t\u00e9s de l’objet post avant de le passer \u00e0 la fonction update<\/a>.<\/p>\n Je ne suis pas du genre \u00e0 dire qu’il n’y a pas de place pour l’une ou l’autre de ces solutions lorsque vous travaillez sur un projet, mais la question demeure\u00a0:<\/p>\n Pourquoi WordPress marque-t-il une publication pr\u00e9vue pour le futur alors que la publication, avant de passer par la proc\u00e9dure de mise \u00e0 jour, \u00e9tait configur\u00e9e pour \u00eatre publi\u00e9e ?<\/p>\n Et si vous n’\u00eates pas familier avec le reste des arguments qui sont transmis \u00e0 WordPress lors de la mise \u00e0 jour d’un article, il faudra un certain temps pour le retrouver.<\/p>\n Afin d’\u00e9viter d’\u00e9crire une requ\u00eate directe \u00e0 la base de donn\u00e9es, j’opte pour la deuxi\u00e8me solution car elle est plus propre (bien que cela ne la rende pas moins d\u00e9routante).<\/p>\n Pour comprendre pourquoi ce comportement se produit, vous pouvez demander \u00e0 un autre d\u00e9veloppeur ou d\u00e9boguer le code. \u00c9tant donn\u00e9 que je travaillais dessus tard dans la nuit, j’ai opt\u00e9 pour ce dernier.<\/p>\n Ex\u00e9cution du d\u00e9bogueur et du code de tra\u00e7age via post.php.<\/p>\n Je ne vais pas parler de tous les points d’arr\u00eat et de toutes les montres que j’ai d\u00e9finis, je vais donc essayer de le rendre aussi concis que possible.<\/p>\n Tout d’abord, lorsque le code passe par la fonction wp_update_post<\/a>, il rencontre ce bloc de code<\/a> :<\/p>\n Notez que dans le conditionnel, nous ne travaillons pas avec une pi\u00e8ce jointe et nous travaillons avec un statut de publication de "publier". Nous allons donc frapper le premier conditionnel dans le conditionnel externe (un peu d\u00e9routant, n’est-ce pas\u00a0?).<\/p>\n Maintenant, il y a une variable, $ post_status, conservant une valeur de publication mais elle n’est affect\u00e9e \u00e0 aucune propri\u00e9t\u00e9 particuli\u00e8re du message actuel. Si vous continuez \u00e0 tracer le code, vous tomberez sur la ligne suivante<\/a>\u00a0:<\/p>\n Ici, vous verrez qu’il fonctionne avec un ensemble de cl\u00e9s de tableau contenues dans la variable $postarr. Cette variable est utilis\u00e9e plus t\u00f4t dans le code (voir ici<\/a> sur Trac). Et si vous regardez attentivement, vous verrez qu’il v\u00e9rifie d’abord si la propri\u00e9t\u00e9 post_date_gmt est vide ou si tout est mis \u00e0 z\u00e9ro.<\/p>\n Et puisque ce n’est pas le cas, il utilisera la valeur que nous avons sp\u00e9cifi\u00e9e sur la propri\u00e9t\u00e9 lorsque nous avons initialement appel\u00e9 la fonction<\/a> :<\/p>\n Attendre.<\/p>\n Pourquoi remonter dans la fonction alors que le code a d\u00e9j\u00e0 d\u00e9pass\u00e9 cela? C’est la nature du d\u00e9bogage. Parfois, vous voyez des variables et ne pensez \u00e0 rien d’elles uniquement pour voir qu’elles sont utilis\u00e9es, d\u00e9finies, manipul\u00e9es, combin\u00e9es ou quoi que ce soit d’autre plus tard dans le code.<\/p>\n C’est la r\u00e9alit\u00e9.<\/p>\n Mais de toute fa\u00e7on, \u00e0 cause de cela, la propri\u00e9t\u00e9 conservera la valeur que nous avons fournie avant d’appeler la fonction de mise \u00e0 jour. Habituellement, ce sera la m\u00eame valeur que lorsque la fonction a d\u00e9marr\u00e9, mais il peut arriver que vous souhaitiez, par exemple, supprimer un message.<\/p>\n Et c’est une raison pour utiliser wp_delete_post<\/a>. Mais il a ses mises en garde, en particulier autour des types de publication personnalis\u00e9s.<\/p>\n Cela entre dans un autre poste, cependant.<\/p>\n\n
Deux solutions<\/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>\nComprendre le probl\u00e8me<\/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