Önálló tartalomtípust olyan ismétlődő entitáshoz hozzon létre, amelynek saját mezői, archívuma vagy kapcsolatai vannak. A taxonómiát közös rendezésre, a mezőt konkrét tulajdonságra, a hagyományos oldalt pedig egyszeri tartalomra használja. A modellt először valós rekordokon ellenőrizze, és csak ezután tervezzen sablonokat.
A WordPress adatmodellje határozza meg, hogyan tárolódnak, módosulnak, kapcsolódnak és jelennek meg az információk. Ha egy cég a szolgáltatásokat, a referenciákat és a munkatársak profiljait is szabad oldalakként viszi fel, az első verzió helyesnek tűnhet. Több tucat rekordnál azonban a szerkesztők másolgatják az elrendezést, a szűrők nem rendelkeznek megbízható adatokkal, és egyetlen szabály módosítása kézi javításokat igényel. A jól megtervezett modell elválasztja a tartalom jelentését annak aktuális megjelenésétől.
A WordPress oldalakat, bejegyzéseket, egyedi tartalomtípusokat, taxonómiákat és metaadatokat kínál. A választás nem technikai formalitás: hatással van az URL-ekre, az adminisztrációra, a belső hivatkozásokra, a keresésre és a jövőbeli migrációra is. A cél nem az, hogy minél több típust és mezőt hozzunk létre, hanem hogy megtaláljuk azt a legkisebb struktúrát, amely leképezi a valós entitásokat, és megakadályozza, hogy a szerkesztő ugyanazt az adatot több helyen adja meg.
Kezdje a valós entitások leltárával
Vegye elő a meglévő weboldalt, táblázatokat és anyagokat, és írja ki az ismétlődő főneveket: szolgáltatás, projekt, csapattag, fióktelep, esemény vagy dokumentum. Minden entitásnál jegyezze fel a rekordok számát, a tulajdonost, a közös tulajdonságokat és a kapcsolatokat. Nem minden főnévnek kell saját típus; az a döntő, hogy önállóan kezelik, szűrik, összekapcsolják vagy többféleképpen jelenítik-e meg.
Dolgozzon konkrét példákkal, a kivételeket is beleértve. Egy referenciához tartozhat ügyfél, iparág, igénybe vett szolgáltatások, galéria és évszám, de nem minden esetben szabad nyilvánosságra hozni az ügyfél nevét. A modellnek ezért opcionalitásra és világos szabályokra van szüksége. Ha az adatokat öt valós rekord esetében sem lehet megbízhatóan kitölteni, további technikai mezők inkább növelik a problémát, mintsem megoldanák.
- Az entitás neve és tulajdonosa
- Kötelező és opcionális tulajdonságok
- Kapcsolatok más tartalmakkal
- Kivételek a szokásos közzétételi forgatókönyv alól
Különböztesse meg a tartalomtípust, a taxonómiát és a mezőt
Az egyéni tartalomtípus akkor indokolt, ha a rekordnak saját adminisztrációs szekcióra, sablonra, URL-re vagy életciklusra van szüksége. Így a szolgáltatások és a referenciák a hagyományos oldalaktól függetlenül kezelhetők. Az egyszeri Rólunk oldalnak nincs szüksége saját típusra. Ne használjon tartalomtípust csak azért, hogy más színnel jelenjen meg a menüben; eltérő jelentést vagy működést kell képviselnie.
A taxonómia ismételhető besorolás szerint csoportosítja a bejegyzéseket, például iparág vagy téma alapján. A mező egyetlen bejegyzés tulajdonságát tárolja, például az időtartamot, egy külső azonosítót vagy telefonszámot. Ha az érték szerint rendszeresen böngésznek, és saját tartalmi oldala van, a taxonómia lehet ésszerű. Ha megjelenítendő vagy integrációs adatról van szó, általában pontosabb a validációval ellátott mező.
A mezőket jelentésük szerint tervezze meg, ne a dizájn alapján
A mezőt a hordozott tartalom alapján nevezze el, például „a szolgáltatás rövid haszna”, ne „szöveg a bal oldali szürke dobozban”. A megjelenés változhat, a jelentésnek meg kell maradnia. Határozza meg az adattípust, a kötelező jelleget, az alapértelmezett értéket, a megengedett formátumot és a szerkesztőnek szóló segédszöveget. A telefonszám, a dátum, az összeg és egy másik rekordra mutató kapcsolat ne legyen ellenőrzés nélküli, korlátlan szövegmező.
Ne hozzon létre minden mondathoz külön mezőt csak azért, hogy a sablon teljes mértékben kontrollálható legyen. A túlságosan felaprózott űrlap lassítja a szerkesztést, és nem teszi lehetővé a megfelelő hosszúságú tartalmat. Kombinálja a strukturált mezőket azokhoz az adatokhoz, amelyeket a rendszernek fel kell dolgoznia, a blokkos tartalommal a magyarázatokhoz. Az előnézetben mutassa meg, hogyan viselkedik egy hiányzó opcionális mező, hogy ne jöjjenek létre üres címsorok.
- Jelentést kifejező név
- Helyes adattípus és validáció
- Súgó példával
- Biztonságos állapot hiányzó érték esetén
A kapcsolatokat és az URL-eket együtt tervezze
Egy referencia egy vagy több szolgáltatásra hivatkozhat, a szolgáltatás pedig automatikusan megjelenítheti a kapcsolódó referenciákat. Az ilyen kapcsolatot a rekord azonosítójaként tárolja, ne kézzel beírt névként vagy másolt hivatkozásként. A cím módosításakor a kapcsolat megmarad. A kétirányú megjelenítés nem feltétlenül jelent duplikált tárolást; az egyik oldal a kanonikus kapcsolatból kiszámítható.
Döntse el, mely entitások kapnak nyilvános részletes oldalt, archívumot és indexelhető taxonómiát. Egy belső technikai rekordnak nem kell URL-t létrehoznia. A típus és a taxonómia slugját a tartalom feltöltése előtt válassza ki, és módosítás esetén készítsen átirányításokat. A morzsamenünek, a sitemapnak és a kanonikus hivatkozásoknak ugyanazt az architektúrát kell követniük, különben a rendszer ellentmondó jeleket küld.
Tesztelje a modellt, és dokumentálja a szerkesztőség számára
Stagingen hozzon létre egy kis, reprezentatív portfóliót: a legrövidebb és a leghosszabb rekordot, hiányzó képet, több kapcsolatot, régi dátumot és szokatlan értéket is. Tesztelje az adminisztrációs listát, a szűrőket, a gyorsszerkesztést, az importot, az exportot és a sablon kimenetét. Vonja be azt a személyt, aki a tartalmat ténylegesen rögzíteni fogja; a kérdései feltárják a homályos elnevezéseket és a felesleges mezőket.
A dokumentációnak röviden ki kell mondania, mikor kell az adott típust létrehozni, mely értékek kötelezők, hogyan kell a taxonómiákat használni, és mi történik archiválás után. A sémamódosításokat verziózza, és tömeges migráció előtt készítsen biztonsági mentést az adatokról. Új mező bevezetésekor határozza meg a régi rekordok kiegészítésének tervét is. Az egységes tartalom a jó modell, a súgó és a felelősség együtteséből jön létre.
Gyakori kérdések
Mikor érdemes egyedi tartalomtípust létrehozni a WordPressben?
Amikor egy önálló entitás ismétlődik azonos mezőkkel, saját adminisztrációval, kapcsolatokkal, archívummal vagy sablonnal. Ha egyetlen egyedi információs oldalról van szó további rekordok nélkül, a normál oldal általában egyszerűbb.
Mindig jobb a kategória, mint egy egyéni mező?
Nem. A kategória vagy taxonómia a közös rendszerezésre és a csoportok böngészésére alkalmas. A mező inkább egy konkrét tulajdonsághoz illik, például külső azonosítóhoz, dátumhoz vagy telefonszámhoz. Az érték tervezett felhasználása a döntő.
Módosítható-e később az adatmodell?
Igen, de a változás az értékek, sablonok, URL-ek és integrációk migrációját igényelheti. Ezért először próbálja ki az adatok másolatán, készítsen leképezést és biztonsági mentést, és ellenőrizze a régi és az új rekordokat is.
Források és további olvasnivaló
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
