Ho appena terminato una funzionalit\u00e0 per un progetto che utilizza una combinazione di tipi di post personalizzati, importazione di dati e aggiornamento di post esistenti quando si elimina un utente (o un insieme di utenti).<\/p>\n
C’\u00e8 un problema, per\u00f2:<\/p>\n
Supponiamo che tu abbia un post attualmente pubblicato (ovvero, "post_status" \u00e8 impostato su "pubblica") ma, quando aggiorni il post tramite wp_update_post, il suo attributo post_status \u00e8 impostato su "futuro".<\/p>\n
In altre parole, ogni volta che aggiorni un post a livello di codice, lo stato del post \u00e8 impostato su "Programmato" (secondo l’interfaccia utente) e "futuro" (secondo la colonna del database).<\/p>\n
Allora cosa d\u00e0?<\/p>\n
In generale, non sono un fan di far funzionare qualcosa, scoprire che funziona e passare all’attivit\u00e0 successiva a meno che non capisca esattamente perch\u00e9 non ha funzionato [come previsto] in primo luogo.<\/p>\n
Questo non vuol dire che non ci siano momenti in cui i vincoli hanno causato ci\u00f2 (almeno durante l’orario di lavoro). Ma se \u00e8 mezzanotte, risolvo un bug e poi non sono del tutto sicuro di capire perch\u00e9 apparentemente era rotto in primo luogo, potrei anche stare sveglio e capirlo, giusto?<\/p>\n
\u00c8 come la versione del programmatore della distorsione dei costi irrecuperabili<\/a>.<\/p>\n Ad ogni modo, come descritto sopra, ecco l’essenza del problema:<\/p>\n Tutto funziona alla grande tranne che c’\u00e8 un problema: ogni volta che il post viene aggiornato a livello di codice, contrassegna lo stato del post come "futuro" nel database, impostando infine l’elemento pubblicitario del post nella\u00a0 visualizzazione Tutti i post<\/strong> come "Programmato".<\/p>\n Esistono due modi per risolvere questo problema:<\/p>\n Se si opta per la prima soluzione, assicurarsi di utilizzare la funzione di preparazione e assicurarsi di eseguire la query dopo la restituzione della funzione di aggiornamento<\/a>.<\/p>\n Se opti per la seconda soluzione, aggiorna in modo esplicito le propriet\u00e0 dell’oggetto post prima di passarlo alla funzione di aggiornamento<\/a>.<\/p>\n Non sono uno che dice che non c’\u00e8 posto per nessuna di queste soluzioni quando si lavora su un progetto, ma la domanda rimane:<\/p>\n Perch\u00e9 WordPress contrassegna un post programmato per il futuro quando il post, prima di passare alla procedura di aggiornamento, era impostato per la pubblicazione?<\/p>\n E se non hai familiarit\u00e0 con il resto degli argomenti che vengono passati a WordPress durante l’aggiornamento di un post, ci vorr\u00e0 del tempo per rintracciarlo.<\/p>\n Per evitare di scrivere una query diretta sul database, scelgo di scegliere la seconda soluzione perch\u00e9 \u00e8 pi\u00f9 pulita (anche se non la rende meno confusa).<\/p>\n Per capire perch\u00e9 si verifica questo comportamento, puoi chiedere a un altro sviluppatore o eseguire il debug del codice. Dato che ci stavo lavorando a tarda notte, ho optato per quest’ultimo.<\/p>\n Eseguire il debugger e tracciare il codice tramite post.php.<\/p>\n Non parler\u00f2 di tutti i breakpoint e gli orologi che ho impostato, quindi cercher\u00f2 di renderlo il pi\u00f9 conciso possibile.<\/p>\n Innanzitutto, quando il codice viene eseguito tramite la funzione wp_update_post<\/a>, incontrer\u00e0 questo blocco di codice<\/a> :<\/p>\n Nota che all’interno del condizionale, non stiamo lavorando con un allegato e stiamo lavorando con uno stato del post di "pubblica". Quindi raggiungeremo il primo condizionale all’interno del condizionale esterno (un po’ confuso non \u00e8 vero?).<\/p>\n Ora c’\u00e8 una variabile, $post_status, che mantiene un valore di pubblicazione ma non \u00e8 assegnata a nessuna propriet\u00e0 particolare del post corrente. Se continui a tracciare il codice, ti imbatterai nella riga successiva<\/a> :<\/p>\n Qui vedrai che funziona con un insieme di chiavi di array che sono contenute nella variabile $postarr. Questa variabile \u00e8 usata in precedenza nel codice (vedi qui<\/a> su Trac). E se guardi da vicino, vedrai che prima controlla se la propriet\u00e0 post_date_gmt \u00e8 vuota o se \u00e8 tutto azzerato.<\/p>\n E poich\u00e9 non lo \u00e8, utilizzer\u00e0 il valore che abbiamo specificato nella propriet\u00e0 quando inizialmente abbiamo chiamato la funzione<\/a> :<\/p>\n Attesa.<\/p>\n Perch\u00e9 tornare nella funzione quando il codice \u00e8 gi\u00e0 stato eseguito oltre? Questa \u00e8 la natura del debug. A volte vedi variabili e non pensi a niente solo per vedere che sono usate, impostate, manipolate, combinate o qualsiasi altra cosa pi\u00f9 avanti nel codice.<\/p>\n Questa \u00e8 la realt\u00e0.<\/p>\n Ma comunque, per questo motivo, la propriet\u00e0 manterr\u00e0 il valore che abbiamo fornito prima di chiamare la funzione di aggiornamento. Di solito, questo sar\u00e0 lo stesso valore di quando la funzione \u00e8 stata avviata, ma a volte potresti voler eliminare un post.<\/p>\n E questo \u00e8 il motivo per usare wp_delete_post<\/a>. Ma ha anche i suoi avvertimenti, specialmente sui tipi di post personalizzati.<\/p>\n Questo entra in un altro post, per\u00f2.<\/p>\n\n
Due soluzioni<\/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>\nCapire il 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