Viestin tilan säilyttäminen WordPress-viestiä päivitettäessä

Viimeisin päivitys marras 9, 2022

Sisältö

Sain juuri valmiiksi ominaisuuden projektille, joka käyttää yhdistelmää mukautettuja viestityyppejä, tietojen tuontia ja olemassa olevien viestien päivittämistä käyttäjän (tai käyttäjäjoukon) poistamisen yhteydessä.

Yksi ongelma kuitenkin on:

Oletetaan, että sinulla on tällä hetkellä julkaistu viesti (eli sen post_status-asetuksena on julkaista), mutta kun päivität viestin wp_update_post-sovelluksella, sen post_status-attribuutti on asetettu tulevaisuuteen.

Toisin sanoen, aina kun päivität julkaisun ohjelmallisesti, viestin tilaksi asetetaan "Scheduled" (käyttöliittymän mukaan) ja "tulevaisuus" (tietokantararakkeen mukaan).

Mitä siis antaa?

Viestin tila päivitettäessä

Yleisesti ottaen en ole fani siitä, että saa jotain toimimaan, saa selville, että se toimii, ja siirry seuraavaan tehtävään, ellen ymmärrä tarkalleen, miksi se ei toiminut [odotusti] alun perin.

Tämä ei tarkoita sitä, etteikö rajoitteet olisivat saaneet tämän tapahtumaan (ainakaan työaikana). Mutta jos on keskiyö, korjaan virheen, ja sitten en ole täysin varma, ymmärränkö, miksi se ilmeisesti alun perin meni rikki. Voisin yhtä hyvin pysyä hereillä ja selvittää sen oikein?

Se on kuin ohjelmoijan versio uponneiden kustannusten biasista.

Joka tapauksessa, kuten edellä on kuvattu, tässä on ongelman ydin:

Tietty viesti on olemassa WordPressissä.
Kun käyttäjä poistetaan, järjestelmä tarkistaa, onko tietyssä viestissä tiettyä sisältöä, ja jos on, poistaa sen.
Viesti päivitetään sitten WordPress API -toiminnolla.

Kaikki toimii hyvin, paitsi että siinä on ongelma: Aina kun viestiä päivitetään ohjelmallisesti, se merkitsee viestin tilaksi "tulevaisuus" tietokannassa ja asettaa lopulta viestin rivikohdan Kaikki viestit -näkymässä "Ajoitettu".

Kaksi Ratkaisua

On kaksi tapaa korjata tämä ongelma:

Korjaa ongelma suorittamalla nopea kysely suoraan tietokannasta.
Päivitä viestin argumentit käyttämään oikeaa aikaa GMT:ssä (käsittelen tätä lisää hetken kuluttua).

Jos valitset ensimmäisen ratkaisun, varmista, että käytät valmistelutoimintoa ja suoritat kyselyn sen jälkeen, kun päivitystoiminto on palautettu.

<?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) );
}

Jos valitset toisen ratkaisun, päivitä post-objektin ominaisuudet nimenomaisesti ennen sen välittämistä päivitystoimintoon.

<?php

$event_post->post_date_gmt = gmdate( 'Y-m-d H:i:s', $event_post->post_date_gmt );
wp_update_post( $event_post );

En ole sellainen, joka väittää, ettei kummallekaan näistä ratkaisuista olisi sijaa projektin parissa, mutta kysymys kuuluu:

Miksi WordPress merkitsee postauksen ajoitetuksi tulevaisuutta varten, kun postaus asetettiin julkaistavaksi ennen päivitysprosessia?

Ja jos et tunne muita argumentteja, jotka välitetään WordPressille julkaisua päivitettäessä, sen jäljittäminen kestää jonkin aikaa.

Ongelman ymmärtäminen

Suoran tietokantakyselyn kirjoittamisen välttämiseksi päätän valita toisen ratkaisun, koska se on puhtaampi (vaikka se ei tee siitä yhtään vähemmän hämmentävää).

Voit selvittää tämän toiminnan syyn kysymällä toiselta kehittäjältä tai tarkistamalla koodin. Koska työskentelin tämän parissa myöhään illalla, valitsin jälkimmäisen.

Debuggerin suorittaminen ja seurantakoodi post.php:n kautta.

En aio puhua läpi kaikista asettamistani keskeytyspisteistä ja kelloista, joten yritän tehdä tämän mahdollisimman ytimekkäästi.

Ensinnäkin, kun koodi suoritetaan wp_update_post- funktion läpi, se kohtaa tämän koodilohkon :

<?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';
        }
    }
}

Huomaa, että ehdollisen ehdon sisällä emme työskentele liitteen kanssa ja työskentelemme julkaisun tilan "julkaise" kanssa. Joten aiomme lyödä ensimmäistä ehdollista ulomman ehdon sisällä (hieman hämmentävää, eikö?).

Nyt on muuttuja, $post_status, joka säilyttää julkaisun arvon, mutta sitä ei ole liitetty mihinkään tiettyyn nykyisen viestin ominaisuuteen. Jos jatkat koodin jäljittämistä, kohtaat seuraavan rivin :

<?php

$post_parent = apply_filters( 'wp_insert_post_parent', $post_parent, $post_ID, compact( array_keys( $postarr) ), $postarr );

Tässä näet, että se toimii $postarr-muuttujan sisältämien taulukkoavainten kanssa. Tätä muuttujaa on käytetty aiemmin koodissa (katso se täältä Tracista). Ja jos katsot tarkasti, huomaat, että se tarkistaa ensin, onko post_date_gmt-ominaisuus tyhjä vai onko se kaikki nollattu.

Ja koska se ei ole, se käyttää arvoa, jonka määritimme ominaisuudelle, kun kutsuimme funktiota alun perin :

<?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'];
    }

Odota.

Miksi palata funktioon, kun koodi on jo ajettu tämän ohi? Se on virheenkorjauksen luonne. Joskus näet muuttujia, etkä ajattele niistä mitään vain nähdäksesi, että niitä käytetään, asetetaan, manipuloidaan, yhdistetään tai mitä tahansa muuta myöhemmin koodissa.

Se on sen todellisuus.

Mutta joka tapauksessa, tästä syystä ominaisuus säilyttää arvon, jonka toimitimme ennen päivitystoiminnon kutsumista. Yleensä tämä on sama arvo kuin funktion käynnistyshetkellä, mutta joskus haluat esimerkiksi siirtää viestin roskakoriin.

Ja tämä on syy käyttää wp_delete_post -tiedostoa. Mutta sillä on varoituksensa, myös varsinkin mukautettujen viestityyppien suhteen.

Se menee kuitenkin toiseen postaukseen.

: tommcfarlin.com