Acabo de terminar una funci\u00f3n para un proyecto que utiliza una combinaci\u00f3n de tipos de publicaciones personalizadas, importaciones de datos y actualizaci\u00f3n de publicaciones existentes al eliminar un usuario (o un conjunto de usuarios).<\/p>\n
Sin embargo, hay un problema:<\/p>\n
Digamos que tiene una publicaci\u00f3n que est\u00e1 publicada actualmente (es decir, su ‘post_status’ est\u00e1 configurado en ‘publicar’) pero, cuando actualiza la publicaci\u00f3n a trav\u00e9s de wp_update_post, su atributo post_status est\u00e1 configurado en ‘futuro’.<\/p>\n
En otras palabras, cada vez que actualiza una publicaci\u00f3n mediante programaci\u00f3n, el estado de la publicaci\u00f3n se establece en ‘Programada’ (seg\u00fan la interfaz de usuario) y ‘futuro’ (seg\u00fan la columna de la base de datos).<\/p>\n
Entonces, \u00bfqu\u00e9 da?<\/p>\n
En t\u00e9rminos generales, no soy fan\u00e1tico de hacer que algo funcione, descubrir que funciona y pasar a la siguiente tarea a menos que comprenda exactamente por qu\u00e9 no funcion\u00f3 [como se esperaba] en primer lugar.<\/p>\n
Esto no quiere decir que no haya momentos en los que las restricciones hayan provocado que esto suceda (al menos durante las horas de trabajo). Pero si es medianoche, soluciono un error y luego no estoy totalmente seguro de entender por qu\u00e9 aparentemente se rompi\u00f3 en primer lugar, tambi\u00e9n podr\u00eda quedarme despierto y resolverlo, \u00bfno?<\/p>\n
Es como la versi\u00f3n del programador del sesgo del costo irrecuperable<\/a>.<\/p>\n De todos modos, como se describe anteriormente, aqu\u00ed est\u00e1 la esencia del problema:<\/p>\n Todo funciona muy bien, excepto que hay un problema: cada vez que la publicaci\u00f3n se actualiza mediante programaci\u00f3n, marca el estado de la publicaci\u00f3n como "futuro" en la base de datos y, en \u00faltima instancia, configura la l\u00ednea de pedido de la publicaci\u00f3n en la\u00a0 vista Todas<\/strong> las publicaciones como "Programada".<\/p>\n Hay dos formas de solucionar este problema:<\/p>\n Si opta por la primera soluci\u00f3n, aseg\u00farese de usar la funci\u00f3n de preparaci\u00f3n y aseg\u00farese de ejecutar la consulta despu\u00e9s de que se devuelva la funci\u00f3n de actualizaci\u00f3n<\/a>.<\/p>\n Si opta por la segunda soluci\u00f3n, actualice expl\u00edcitamente las propiedades del objeto de publicaci\u00f3n antes de pasarlo a la funci\u00f3n de actualizaci\u00f3n<\/a>.<\/p>\n No soy de los que dicen que no hay lugar para ninguna de estas soluciones cuando se trabaja en un proyecto, pero la pregunta sigue siendo:<\/p>\n \u00bfPor qu\u00e9 WordPress marca una publicaci\u00f3n programada para el futuro cuando la publicaci\u00f3n, antes de pasar por el procedimiento de actualizaci\u00f3n, estaba configurada para publicarse?<\/p>\n Y si no est\u00e1 familiarizado con el resto de los argumentos que se pasan a WordPress al actualizar una publicaci\u00f3n, le llevar\u00e1 alg\u00fan tiempo localizarlo.<\/p>\n En aras de evitar escribir una consulta directa a la base de datos, opt\u00e9 por la segunda soluci\u00f3n porque es m\u00e1s limpia (aunque no la hace menos confusa).<\/p>\n Para averiguar por qu\u00e9 ocurre este comportamiento, puede preguntarle a otro desarrollador o depurar el c\u00f3digo. Dado que estaba trabajando en esto a altas horas de la noche, opt\u00e9 por lo \u00faltimo.<\/p>\n Ejecutando el depurador y rastreando el c\u00f3digo a trav\u00e9s de post.php.<\/p>\n No voy a hablar sobre todos los puntos de interrupci\u00f3n y relojes que configur\u00e9, as\u00ed que intentar\u00e9 que esto sea lo m\u00e1s conciso posible.<\/p>\n Primero, cuando el c\u00f3digo se ejecuta a trav\u00e9s de la funci\u00f3n wp_update_post<\/a>, encontrar\u00e1 este bloque de c\u00f3digo<\/a> :<\/p>\n Tenga en cuenta que dentro del condicional, no estamos trabajando con un archivo adjunto y estamos trabajando con un estado de publicaci\u00f3n de ‘publicar’. As\u00ed que vamos a tocar el primer condicional dentro del condicional externo (un poco confuso, \u00bfno?).<\/p>\n Ahora hay una variable, $post_status, que mantiene un valor de publicaci\u00f3n pero no est\u00e1 asignada a ninguna propiedad particular de la publicaci\u00f3n actual. Si contin\u00faa rastreando el c\u00f3digo, encontrar\u00e1 la siguiente l\u00ednea<\/a> :<\/p>\n Aqu\u00ed, ver\u00e1 que funciona con un conjunto de claves de matriz que est\u00e1n contenidas en la variable $postarr. Esta variable se usa anteriormente en el c\u00f3digo (v\u00e9ala aqu\u00ed<\/a> en Trac). Y si observa detenidamente, ver\u00e1 que primero verifica si la propiedad post_date_gmt est\u00e1 vac\u00eda o si est\u00e1 en cero.<\/p>\n Y como no lo es, usar\u00e1 el valor que especificamos en la propiedad cuando inicialmente llamamos a la funci\u00f3n<\/a> :<\/p>\n Esperar.<\/p>\n \u00bfPor qu\u00e9 volver a la funci\u00f3n cuando el c\u00f3digo ya pas\u00f3? Esa es la naturaleza de la depuraci\u00f3n. A veces ves variables y no piensas en ellas solo para ver que se usan, configuran, manipulan, combinan o cualquier otra cosa m\u00e1s adelante en el c\u00f3digo.<\/p>\n Esa es la realidad.<\/p>\n Pero de todos modos, debido a eso, la propiedad mantendr\u00e1 el valor que proporcionamos antes de llamar a la funci\u00f3n de actualizaci\u00f3n. Por lo general, este ser\u00e1 el mismo valor que cuando se inici\u00f3 la funci\u00f3n, pero puede haber ocasiones en las que desee, por ejemplo, descartar una publicaci\u00f3n.<\/p>\n Y eso es motivo para usar wp_delete_post<\/a>. Pero tiene sus advertencias, especialmente en torno a los tipos de publicaciones personalizadas.<\/p>\n Sin embargo, eso pasa a otra publicaci\u00f3n.<\/p>\n\n
dos soluciones<\/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>\nComprender el 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