Kun ohjelmoijat puhuvat kokonaisuuksista, he yleensä puhuvat konseptista tai jostakin, joka on olemassa järjestelmässä. Joskus se on luokka, joskus kirjasto tai riippuvuus, tai se voi olla jotain WordPress-viestityyppiä.
Jos WordPressiä on pidettävä sovellusperustana (verrattuna kehykseen), on tärkeää ajatella tiettyjä ominaisuuksia tavoilla, joita voidaan käsitellä kokonaisuuksina. Yllä olevassa esimerkissä viestityyppi on juuri sellainen.
Kun mukautetut viestityypit otettiin käyttöön, se antoi meille tavan tuoda sovellukseen jotain muutakin kuin sivuja ja viestejä. Nyt voimme toteuttaa minkä tahansa konseptin – kuten tapahtuman – ja käsitellä sitä omana kokonaisuutenaan järjestelmässä.
Mutta kun kaikki on sanottu ja tehty, se kaikki tallennetaan viestitaulukkoon. Ja se on hienoa, koska ohjelmistokehityksessä on kyse abstraktiosta. Kun otamme käyttöön WordPress-viestityyppejä, toteutamme abstraktin viesti-idean päälle.
WordPress-viestityypit
Viimeisessä viestissä kävin läpi sellaisen käyttäjän luomisprosessin, joka lopulta liitetään johonkin WordPress-sovelluksen kokonaisuuteen.
- Ehkä hän on viestin kirjoittaja,
- Ehkä hän on tuotteen myyjä,
- Ehkä hän on tarinan kertoja,
- Tai mitä muuta voit kuvitella.
Mahdollisuudet ovat rajattomat. Mutta ennen kuin puhumme yhteyden luomisesta kahden entiteetin – eli käyttäjän ja WordPress-viestityypin – välille, meidän on puhuttava kokonaisuuden tai mukautetun viestityypin toteuttamisesta ohjelmallisesti.
Tästä on paljon dokumentaatiota, ja tästä on saatavilla paljon opetusohjelmia, joten en aio käsitellä asiaa. Sen sijaan yritän pitää tämän mahdollisimman paljaana. Muista, että tämän koko sarjan tavoitteena on lopulta päästä pisteeseen, jossa yhdistämme entiteettejä metatietojen avulla.
Mutta ennen kuin teemme sen, meidän on luotava kokonaisuudet. Meillä on siis käyttäjä, joten tehdään se.
Oletetaan esimerkiksi, että edellisessä viestissä luomamme käyttäjä Meghan on kirjan kirjoittaja. Ja jonkun muun hallinnoimassa WordPress-asennuksessa on mukautettu postaustyyppi kirjoille, joilla jokaisella on muutama attribuutti:
- otsikko,
- kuvaus,
- julkaisupäivämäärä,
- ISBN,
- alkuperäisten myytyjen kappaleiden määrä,
- mistä sen voi ostaa,
- ja niin edelleen.
Voit lisätä toteutukseen enemmän tai vähemmän. Itse asiassa saatat myydä sähköisiä kirjoja, ja kirjan URL-osoite ostettavaksi on yksi ominaisuuksista. Oli miten oli, ymmärrät idean.
Näin ollen voimme ottaa käyttöön yksinkertaisen mukautetun viestityypin "kirjoille" ohjelmallisesti.
Viestityypin käyttöönotto
Ja se näyttää tältä :
<?php
add_action( 'init', 'acme_create_book_post_type' );
/**
* Creates a new custom post type called 'Book' using the smallest number of arguments
* to prepare the post type.
*/
function acme_create_book_post_type() {
$args = array(
'labels' => array(
'name' => 'Books',
'singular_name' => 'Book',
),
'public' => true,
);
register_post_type( 'acme_book', $args );
}Jos luet mukautettujen viestityyppien luomista koskevat ohjeet, tässä ei ole mitään epänormaalia. Sen pitäisi näyttää juuri sellaiselta kuin odotit.
Se, missä luot tämän, riippuu projektisi luonteesta. On monia ihmisiä, jotka puolustavat sitä, että se on laajennuksessa tai että se tehdään teemaksi. Tämä ei ole oikea paikka keskustella asiasta. Riittää, kun sanon, että tarkoituksiini oletetaan, että se kaikki on osa samaa laajennusta edellisestä opetusohjelmasta.
Lisäksi en poikkea mukautetuista taksonomioista, kommenteista tai muista mukautetuista tiedoista, jotka voidaan yhdistää mukautettuun viestityyppiin.
Sen jälkeen katsomme, miltä tämä näyttää WordPressin hallinta-alueella sekä miltä tämä näyttää tietokannassa.
Katso verhon taakse
Ensinnäkin, tältä se näyttää (tai sen pitäisi näyttää) WordPressin hallinta-alueella:
Ja jos katsot tietokantaa merkinnän luomisen jälkeen, näet jotain tällaista:
Ilmeisesti olen rajoittanut tietokannan käyttöliittymässä palautettuja tietueita suodattamalla tulokset, jotta kuvakaappausta olisi helpompi seurata.
Kirjoissa
Ja siinä se, todella. Tarkoitan, että kaikkein perustavimmalla tasolla näin luot mukautetun viestityypin WordPressissä. Tiedän, että se ei ole mitään uutta, mutta jos voisin esittää hieman vahvemman perustelun tällaiselle postaukselle, se sisältäisi seuraavat kaksi kohtaa.
1 Kyse on abstraktioista
Jos haluat perehtyä verkkosovellusten rakentamiseen WordPressin avulla, on tärkeää lopettaa asioiden ajatteleminen perinteisillä termeillä, kuten postauksilla, sivuilla, kommenteilla ja luokilla, ja alkaa ajatella niitä yleisempinä abstraktioina.
Entiteetit, kuten artikkelissa aiemmin mainittiin. Kun teet niin, sinulla on muutos henkisessä mallissa, joka ohjaa kykyäsi ajatella ja toteuttaa ratkaisu.
2 Kyse on ihmissuhteista
Vaikka ajattelemme usein asioita niiden yksittäisissä osissa, kuten julkaisuissa ja sivuissa, tiedämme luonnostaan, että viesteissä voi olla kommentteja, kommenteissa voi olla vastauksia, sivuilla voi olla malleja ja niin edelleen.
Kaikkien näiden yksittäisten asioiden välillä on suhteita, jotka ovat osa järjestelmää. Ja kun alat ajatella, että suhteet ovat jotain, jonka avulla voimme tehdä enemmän, alat nähdä, kuinka voimakas jokin voi olla. Se on kokonaisuus "kokonaisuus on suurempi kuin osiensa summa".
Joten kun sinulla on yksittäisiä kokonaisuuksia paikoillaan ja kun alat nähdä, kuinka ne voivat liittyä toisiinsa, otat askeleen eteenpäin luomalla jotain, joka ratkaisee hieman monimutkaisemman ongelman näennäisesti yksinkertaisista osista.
Ja sinne lähdetään seuraavaksi.
Entä metadata?
Tämän sarjan koko tarkoitus on käydä läpi, kuinka luoda assosiaatio entiteettien välille, eikö niin? Tarkemmin sanottuna pyrimme luomaan yhteyden käyttäjän ja julkaisun tai tarkemmin sanottuna kirjailijan ja kirjan välille.
WordPress tarjoaa perustan tälle, ja tässä lisäpöytien ja koukkujen voimat voivat tulla esiin. Seuraavassa postauksessa aion puhua siitä, kuinka tämä yhteys luodaan, mihin suuntaan yhdistykset voivat mennä ja kuinka näiden tietojen kanssa työskennellä, jos esimerkiksi käyttäjä poistetaan sovelluksesta.