Lõpetasin just projekti funktsiooni, mis kasutab kasutaja (või kasutajate komplekti) kustutamisel kohandatud postitustüüpide, andmete importimise ja olemasolevate postituste värskendamise kombinatsiooni.
Siiski on üks probleem:
Oletagem, et teil on praegu avaldatud postitus (st selle "post_status" väärtuseks on seatud "avaldamine"), kuid kui värskendate postitust saidi wp_update_post kaudu, on selle atribuudi post_status väärtuseks "tulevik".
Kui värskendate postitust programmiliselt, määratakse postituse olekuks "Ajastatud" (vastavalt kasutajaliidesele) ja "tulevik" (vastavalt andmebaasi veerule).
Mis siis annab?
Postituse olek värskendamisel
Üldiselt ma ei fänna seda, et miski tööle hakkaks, teada saada, et see toimib, ja liikuda edasi järgmise ülesande juurde, välja arvatud juhul, kui ma mõistan täpselt, miks see [oletatult] üldse ei toiminud.
See ei tähenda, et piirangud ei oleks seda põhjustanud (vähemalt tööajal). Aga kui on kesköö, parandan vea ja siis ma pole täiesti kindel, et saan aru, miks see ilmselt katki läks, võin sama hästi üleval olla ja selle välja mõelda, eks?
See on nagu programmeerija versioon pöördumiskulude kallutatusest.
Igatahes, nagu ülalpool kirjeldatud, on probleemi põhiolemus siin:
- Antud postitus on WordPressis olemas.
- Kui kasutaja kustutatakse, vaatab süsteem, kas antud postituses on teatud sisu, ja kui jah, siis eemaldab selle.
- Seejärel värskendatakse postitust WordPressi API funktsiooni abil.
Kõik töötab suurepäraselt, välja arvatud probleem: kui postitust programmiliselt värskendatakse, märgib see andmebaasis postituse olekuks „tulevik", määrates lõpuks vaates Kõik postitused postituse reaüksuseks „Ajastatud”.
Kaks Lahendust
Selle probleemi lahendamiseks on kaks võimalust.
- Käivitage probleemi lahendamiseks kiirpäring otse andmebaasi vastu.
- Värskendage postituse argumente, et kasutada õiget aega GMT-s (räägin sellest lähemalt hetke pärast).
Kui valite esimese lahenduse, kasutage kindlasti ettevalmistamise funktsiooni ja veenduge, et täidaksite päringu pärast värskendusfunktsiooni tagastamist.
<?php
// First, update the post using the available WordPress API.
wp_update_post( $post );
/**
* If the post status attribute of the post that was just updated
* maintains the 'publish' post setatus, then manually update the
* database column.
*/
if ('publish' === $post->post_status) {
global $wpdb;
$wpdb->query(
$wpdb->prepare(
"
UPDATE $wpdb->posts
SET post_status = '%s'
WHERE ID = %d
",
'publish',
$post->ID) );
}
Kui valite teise lahenduse, värskendage enne selle värskendamisfunktsioonile edastamist postitusobjekti atribuute .
<?php
$event_post->post_date_gmt = gmdate( 'Y-m-d H:i:s', $event_post->post_date_gmt );
wp_update_post( $event_post );
Ma ei ole see, kes ütleks, et projektiga töötades pole kummalegi neist lahendustest kohta, kuid küsimus jääb alles:
Miks märgib WordPress postituse edaspidiseks, kui postitus oli enne värskendusprotseduuri läbimist seatud avaldama?
Ja kui te pole kursis ülejäänud argumentidega, mis postituse värskendamisel WordPressile edastatakse, kulub sellele jälile jõudmiseks veidi aega.
Probleemi mõistmine
Otsese andmebaasipäringu kirjutamise vältimiseks valin teise lahenduse, kuna see on puhtam (kuigi see ei muuda seda vähem segaseks).
Sellise käitumise põhjuste väljaselgitamiseks võite küsida mõnelt teiselt arendajalt või koodi siluda. Arvestades, et töötasin selle kallal hilisõhtul, valisin viimase.
Siluri käitamine ja jälgimiskoodi otsimine läbi post.php.
Ma ei räägi kõigist seatud murdepunktidest ja kelladest, seega püüan seda teha võimalikult lühidalt.
Esiteks, kui kood töötab läbi funktsiooni wp_update_post, puutub see kokku järgmise koodiplokiga :
<?php
if ('attachment' !== $post_type) {
if ('publish' == $post_status) {
$now = gmdate('Y-m-d H:i:59');
if (mysql2date('U', $post_date_gmt, false) > mysql2date('U', $now, false)) {
$post_status = 'future';
}
} elseif ('future' == $post_status) {
$now = gmdate('Y-m-d H:i:59');
if (mysql2date('U', $post_date_gmt, false) <= mysql2date('U', $now, false)) {
$post_status = 'publish';
}
}
}
Pange tähele, et tingimuse piires ei tööta me manusega ja töötame postituse olekuga „avalda”. Nii et me tabame esimest tingimuslauset välise tingimuslause sees (natuke segane, kas pole?).
Nüüd on muutuja $post_status, mis säilitab publitseerimise väärtuse, kuid seda ei ole määratud praeguse postituse ühelegi konkreetsele atribuudile. Kui jätkate koodi jälgimist, näete järgmist rida :
<?php
$post_parent = apply_filters( 'wp_insert_post_parent', $post_parent, $post_ID, compact( array_keys( $postarr) ), $postarr );
Siin näete, et see töötab massiivivõtmete komplektiga, mis sisalduvad muutujas $postarr. Seda muutujat on koodis varem kasutatud (vaata seda siin Tracis). Ja kui te vaatate tähelepanelikult, näete, et see kontrollib esmalt, kas atribuut post_date_gmt on tühi või on see kõik nullitud.
Ja kuna see pole nii, kasutab see väärtust, mille määrasime atribuudil, kui funktsiooni algselt kutsusime :
<?php
if (empty( $postarr['post_date_gmt']) || '0000-00-00 00:00:00' == $postarr['post_date_gmt']) {
if (! in_array( $post_status, array( 'draft', 'pending', 'auto-draft') )) {
$post_date_gmt = get_gmt_from_date( $post_date );
} else {
$post_date_gmt = '0000-00-00 00:00:00';
}
} else {
$post_date_gmt = $postarr['post_date_gmt'];
}
Oota.
Miks minna tagasi funktsiooni juurde, kui kood on sellest juba möödas? See on silumise olemus. Mõnikord näete muutujaid ja ei mõtle neist midagi ainult selleks, et näha, kuidas neid hiljem koodis kasutatakse, seadistatakse, manipuleeritakse, kombineeritakse või mida iganes muud.
See on selle tegelikkus.
Kuid igal juhul säilitab atribuut selle väärtuse, mille andsime enne värskendusfunktsiooni kutsumist. Tavaliselt on see sama väärtus, mis funktsiooni käivitamisel, kuid võib juhtuda, et soovite postituse prügikasti visata.
Ja see on põhjus wp_delete_post kasutamiseks. Kuid sellel on ka oma hoiatused, eriti kohandatud postitustüüpide puhul.
See läheb aga teise postitusse.