WordPress-metadatayhdistys: liittyvät entiteetit
Tässä vaiheessa olemme käsitelleet, kuinka kokonaisuudet luodaan laajennuksen sisällä (joka, kuten olemme sanoneet, on vain hieno sana toiselle konkreettiselle idealle). Meillä on nimittäin käyttäjä ja mukautettu viestityyppi tai kirja. Ja tässä alamme ottaa kaksi erillistä kokonaisuutta ja yhdistää ja työskennellä sen kanssa, jota kutsumme WordPress-metatietoyhdistykseksi.
Mutta ennen kuin teet niin, on tärkeää ymmärtää kahdentyyppiset metatiedot, joiden kanssa työskentelemme, ja kaksi tapaa (tai kolme tapaa, riippuen siitä, miten katsot sitä), kuinka voimme yhdistää metatiedot.
Kuten muissakin sarjan postauksissa, tämän ei ole tarkoitus sukeltaa syvällisesti kunkin taulukon ymmärtämiseen tai syvällistä sukellusta kuhunkin API-toimintoon. Sen sijaan kartoitamme, mitä on saatavilla, käytämme niitä ja jätämme tarkempia tietoja tuleviin postauksiin (tai ehkä keskusteluihin kommentteihin).
WordPressin metatietoyhdistys
Metadata ei ole yksinomaan WordPressissä. Tiedät varmaan tämän. Ja se määritellään usein seuraavasti :
Tietoja tiedoista tai tietoja tiedoista.
Ja se on hyvä tapa ilmaista se. WordPress tarjoaa joitain erilaisia tietokantataulukoita, joiden avulla voimme tarjota tietoja tietyntyyppisistä WordPressin kokonaisuuksista. Aiomme käyttää paria näistä myöhemmin tässä viestissä, mutta riittää, kun sanon, että WordPress tarjoaa :
- kommentin metatiedot,
- lähetä metatiedot,
- termin metatiedot,
- ja käyttäjän metatiedot
Ja kaikki tämä on saatavilla suoraan pakkauksesta.
Yksi WordPressin metatietotaulukoista.
Jokaisen näiden sovellusliittymät ovat johdonmukaisia, mikä on myös mukavaa. Mutta jälleen kerran, käsittelemme vain muutamaa näistä tämän postauksen loppuosan ajan.
1 Metatietotaulukot
Esimerkissämme käytämme toista tai molempia seuraavista kahdesta taulukosta:
Myönnettäköön, että asennuksessasi niillä voi olla eri etuliite, mutta pääte on sama, ja ymmärrät idean.
Toiseksi käytämme niihin liittyviä API-toimintoja metatietojemme yhdistämiseen. Tarkastelemme näitä koodissa, kun yhdistämme tietoja käyttäjämme ja mukautetun viestityypin (tai kirjailijamme ja kirjojen, jos haluat käyttää tarkempaa terminologiaa) välillä.
Okei sitten. Tämä koko postauksen ensimmäinen osa luo vain pohjaa sille, mitä taustalla olevan WordPress-infrastruktuurin osia aiomme käyttää. Kun kaikki tämä on sanottu, katsotaanpa, kuinka voimme ohjelmallisesti muuttaa tämän asian joksikin hyödyllisemmäksi.
2 Metatietojen yhdistäminen
WordPressin metatietoyhdistyksen idea kuulostaa monimutkaisemmalta kuin se on. Ajattele asiaa näin:
- Kun otetaan huomioon kaksi taulukkoa, kuinka voimme jakaa tietoja kahden entiteetin välillä, jotka antavat toisen tietää toisesta?
Esimerkiksi, kuinka voimme kertoa käyttäjän metatiedoista julkaisujen metatiedoista, kun on kyse käyttäjästä. Tai miten voimme antaa postin metatiedon tietää mitään asiaan liittyvistä käyttäjien metatiedoista?
Korkealla tasolla todellakin teemme tätä: Annamme yhdelle entiteetille toisen olemassaolon ja suhteutamme sen toiseen. Tai se voi mennä toisinkin päin. Toteutuksestasi riippuen toinen voi olla hyödyllisempi kuin toinen.
1 Yksisuuntainen
Kun puhumme yksisuuntaisten WordPress-assosiaatioiden luomisesta, puhumme yleensä ajatuksesta, että vain yksi entiteetti on tietoinen toisesta. Tämä tarkoittaa, että käyttäjä voi olla tietoinen vain viestistä.
Voisimme määrittää sen jälkeen, kun viesti on luotu, kuten kyseinen käyttäjä on tietoinen juuri luodusta viestistä :
<?php
// Using post title as the value, but it's just an example.
add_user_meta( $user_id, $post_id, $post_title );Tai ehkä se tarkoittaa, että viesti on tietoinen käyttäjästä:
<?php
// User user email address a value but just an example.
add_post_meta( $post_id, $user_id, $email_address );Mutta katsoipa sitä miten tahansa, yhdistys kulkee vain yhteen suuntaan.
Ja vaikka suhde menee yhteen suuntaan, sen ei tarvitse olla niin. Eli molemmat olennot voivat olla tietoisia toisistaan.
2 Kaksisuuntainen
Koska metatietosovellusliittymien kanssa on niin helppoa ja johdonmukaista työskennellä, niiden kanssa työskentely ei ole vaikeaa. Jokainen niistä vaatii yleensä vähintään kaksi seuraavista:
- sen tyyppinen tunnus, johon metatiedot liittyvät,
- meta-avain, jota voidaan käyttää tietojen etsimiseen,
- arvo, joka tallentaa tunnukseen ja viestiin liittyvät tiedot.
Kuten olemme nähneet, valitsemasi tunnuksen ja avaimen valinta riippuu usein toteutuksestasi.
Tähän asti olemme pohtineet, kuinka luoda yksisuuntainen yhdistys. Kaksisuuntainen assosiaatio ei ole mikään erilainen. Sen sijaan, että teemme yhden kokonaisuuden tietoiseksi toisesta, teemme molemmat oliot tietoisiksi toisesta:
<?php
/**
* Using this association will give you the ability to query for information
* both on posts and users and then work with the data accordingly.
*/
add_user_meta( $user_id, $post_id, $post_title );
add_post_meta( $post_id, $user_id, $email_address );
Mutta tämä ei ole päätös, joka pitäisi tehdä vain sen vuoksi. Sen sijaan kannattaa pohtia joitakin syitä, miksi saatat haluta valita jommankumman.
Ongelman läpi ajattelu
Kun on kyse tällaisten ongelmien ratkaisemisesta, ei ole olemassa lopullista ratkaisua termillä "sinun pitäisi olla lopullinen [tämä tapa]", olipa se mikä tahansa tapa. Sen sijaan sinun on kysyttävä itseltäsi kysymyksiä, kuten "mikä tekee siitä helpoin tapa hallita näitä tietoja?"
Jos esimerkiksi olet ensisijaisesti kiinnostunut käyttäjien hallinnasta, tarvitset ehkä vain, että käyttäjän metatiedot ovat tietoisia siitä, mihin entiteeteihin ne liittyvät. Näin varmistat, että kun käyttäjä poistetaan, etsitään myös siihen liittyvät entiteetit käyttäjän metatietotaulukon kautta ja poistetaan myös ne.
Samoin ehkä sama toiminnallisuus toimisi molempiin suuntiin. Eli aivan kuten haluat varmistaa, että kun käyttäjä poistetaan, myös hänen viestinsä poistetaan, saatat haluta myös käyttäjän poistettavan (tai muokattavan) aina, kun jokin hänen julkaisuistaan poistetaan. Ja jos näin on, kaksisuuntainen assosiaatio mahdollistaa sen.
Koska sinulla on tietyn viestin tunnus ja tietyn käyttäjän tunnus sekä määrittämäsi metaavaimet, lähes minkä tahansa tyyppinen kysely, jonka voit kuvata joko WordPressin metadata API:n tai WP_Queryn tai jopa WP_User_Queryn kautta, on mahdollista. .
Loppu
Viime kädessä toivon, että tämä sarja on tarjonnut jonkinlaisen käsityksen siitä, kuinka WordPress-metatietoyhdistelmiä luodaan, mutta myös kuinka abstraktisti ajatellaan WordPressin käsitteitä, koska se liittyy korkeamman tason toteutusten luomiseen laajennuksissasi ja verkkosovelluksissasi.
Niille, jotka ovat kiinnostuneita, harkitsen tämän sarjan julkaisemista pienenä resurssina PDF-muodossa yhdessä toimivan laajennuksen kanssa tutkittavaksi. Jos olet kiinnostunut tästä, liity postituslistalle täällä, niin ilmoitan sinulle, kun se on valmis. Muussa tapauksessa käytä sarjan tietoja siirtyäksesi eteenpäin ja luodaksesi jotain arvokasta