Oddzielny typ treści proszę tworzyć dla powtarzalnego bytu z własnymi polami, archiwum lub relacjami. Taksonomię należy stosować do wspólnej klasyfikacji, pole do konkretnej właściwości, a zwykłą stronę do treści jednorazowej. Model najpierw trzeba sprawdzić na rzeczywistych rekordach, a dopiero potem projektować szablony.
Model danych WordPressa określa, w jaki sposób informacje są zapisywane, edytowane, łączone i wyświetlane. Jeśli firma umieści usługi, referencje i profile osób jako zwykłe strony, pierwsza wersja może wyglądać poprawnie. Przy dziesiątkach rekordów redaktorzy jednak kopiują układ, filtry nie mają wiarygodnych danych, a zmiana jednej reguły wymaga ręcznych poprawek. Dobrze zaprojektowany model oddziela znaczenie treści od jej bieżącego wyglądu.
WordPress oferuje strony, wpisy, własne typy treści, taksonomie i metadane. Wybór nie jest techniczną formalnością: wpływa na adresy URL, panel administracyjny, linki wewnętrzne, wyszukiwanie, a także przyszłą migrację. Celem nie jest stworzenie jak największej liczby typów i pól, lecz znalezienie najmniejszej struktury, która odwzoruje rzeczywiste encje i zapobiegnie wprowadzaniu przez redaktora tej samej informacji w kilku miejscach.
Zacznij od inwentaryzacji rzeczywistych encji
Weź istniejącą stronę, arkusze i materiały, a następnie wypisz powtarzające się rzeczowniki: usługa, projekt, członek zespołu, oddział, wydarzenie lub dokument. Przy każdej encji zanotuj liczbę rekordów, właściciela, wspólne właściwości i relacje. Nie każdy rzeczownik potrzebuje własnego typu; decyduje to, czy będzie samodzielnie zarządzany, filtrowany, powiązywany lub wyświetlany na kilka sposobów.
Proszę pracować na konkretnych przykładach, łącznie z wyjątkami. Realizacja z portfolio może zawierać klienta, branżę, wykorzystane usługi, galerię i rok, jednak nie każda może ujawniać nazwę klienta. Model potrzebuje więc opcjonalności i jasnych zasad. Jeśli danych nie da się rzetelnie uzupełnić dla pięciu rzeczywistych rekordów, kolejne pola techniczne raczej powiększą problem, niż go rozwiążą.
- Nazwa encji i jej właściciel
- Właściwości obowiązkowe i opcjonalne
- Powiązania z inną treścią
- Wyjątki od standardowego scenariusza publikacji
Rozróżnij typ treści, taksonomię i pole
Własny typ treści jest odpowiedni, gdy wpis potrzebuje osobnej sekcji administracyjnej, szablonu, URL lub cyklu życia. Usługami i referencjami można wtedy zarządzać niezależnie od zwykłych stron. Jednorazowa strona O firmie nie potrzebuje własnego typu. Nie należy stosować typu treści tylko po to, by miał inny kolor w menu; musi reprezentować odmienne znaczenie lub zachowanie.
Taksonomia grupuje wpisy według powtarzalnej klasyfikacji, na przykład branży lub tematu. Pole przechowuje właściwość pojedynczego wpisu, na przykład czas trwania, zewnętrzne ID czy telefon. Jeśli według danej wartości regularnie się przegląda treści i ma ona własną stronę, sens może mieć taksonomia. Jeśli chodzi o daną do wyświetlenia lub integracji, zwykle trafniejsze jest pole z walidacją.
Projektuj pola według znaczenia, a nie według wyglądu
Pole nazwijcie zgodnie z treścią, którą zawiera, np. „krótka korzyść z usługi”, a nie „tekst w lewym szarym boksie”. Wygląd może się zmienić, znaczenie ma pozostać. Określcie typ danych, obowiązkowość, wartość domyślną, dozwolony format i tekst pomocniczy dla redaktora. Telefon, data, kwota i relacja do innego rekordu nie powinny być nieograniczonymi polami tekstowymi bez walidacji.
Nie należy tworzyć pola dla każdego zdania tylko po to, by mieć pełną kontrolę nad szablonem. Zbyt rozdrobniony formularz spowalnia pracę redakcji i nie pozwala na treści o odpowiedniej długości. Warto łączyć pola strukturalne dla danych, które system musi przetwarzać, z treścią blokową służącą wyjaśnieniom. W podglądzie należy pokazać, jak zachowuje się brakujące pole opcjonalne, aby nie powstawały puste nagłówki.
- Nazwa oddająca znaczenie
- Właściwy typ danych i walidacja
- Podpowiedź z przykładem
- Bezpieczny stan w przypadku brakującej wartości
Relacje i adresy URL planuj wspólnie
Realizacja może odnosić się do jednej lub kilku usług, a usługa może automatycznie wyświetlać powiązane realizacje. Taką relację należy zapisywać jako identyfikator rekordu, a nie jako ręcznie wpisaną nazwę czy skopiowany link. Przy zmianie tytułu powiązanie pozostaje. Wyświetlanie w obu kierunkach nie musi oznaczać zduplikowanego zapisu; jedną stronę relacji można wyliczyć z relacji kanonicznej.
Należy zdecydować, które encje mają publiczną stronę szczegółów, archiwum i indeksowalną taksonomię. Wewnętrzny rekord techniczny nie musi tworzyć URL. Slug typu i taksonomii warto wybrać przed wypełnieniem treścią, a w razie zmiany przygotować przekierowania. Nawigacja okruszkowa, mapa witryny i linki kanoniczne muszą odzwierciedlać tę samą architekturę, w przeciwnym razie system wysyła sprzeczne sygnały.
Przetestuj model i udokumentuj go dla redakcji
W środowisku staging utwórz małe, reprezentatywne portfolio: najkrótszy i najdłuższy wpis, brakujący obraz, wiele relacji, starą datę oraz nietypową wartość. Przetestuj listę w panelu administracyjnym, filtry, szybką edycję, import, eksport i wynik szablonu. Zaangażuj osobę, która będzie faktycznie wprowadzać treści; jej pytania ujawnią niejasne nazwy i zbędne pola.
Dokumentacja powinna zwięźle określać, kiedy tworzyć dany typ, które wartości są obowiązkowe, jak używać taksonomii i co dzieje się po archiwizacji. Zmiany schematu należy wersjonować, a przed masową migracją wykonać kopię zapasową danych. Gdy pojawi się nowe pole, trzeba też ustalić plan uzupełnienia starszych rekordów. Spójna treść powstaje dzięki połączeniu dobrego modelu, podpowiedzi i odpowiedzialności.
Najczęstsze pytania
Kiedy utworzyć własny typ treści w WordPressie?
Gdy powtarza się odrębny byt z tymi samymi polami, własną administracją, relacjami, archiwum lub szablonem. Jeśli chodzi o jedną unikalną stronę informacyjną bez kolejnych rekordów, zwykła strona jest zazwyczaj prostsza.
Czy kategoria jest zawsze lepsza niż własne pole?
Nie. Kategoria lub taksonomia nadaje się do wspólnego klasyfikowania i przeglądania grup. Pole lepiej sprawdza się dla konkretnej właściwości, na przykład zewnętrznego ID, daty czy telefonu. Decyduje planowany sposób wykorzystania wartości.
Czy model danych można później zmienić?
Tak, ale zmiana może wymagać migracji wartości, szablonów, adresów URL i integracji. Dlatego najpierw warto ją przetestować na kopii danych, przygotować mapowanie i kopię zapasową oraz sprawdzić zarówno stare, jak i nowe rekordy.