W tym momencie omówiliśmy, jak tworzyć encje we wtyczce (co, jak powiedzieliśmy, jest tylko fantazyjnym słowem na inny konkretny pomysł). Mianowicie mamy użytkownika i niestandardowy typ posta, czyli książkę. I tutaj zaczynamy łączyć dwie oddzielne jednostki i pracować z tym, co nazwiemy powiązaniem metadanych WordPress.
Ale zanim to zrobisz, ważne jest, aby zrozumieć dwa typy metadanych, z którymi będziemy pracować, oraz dwa sposoby (lub trzy sposoby, w zależności od tego, jak na to spojrzysz), jak możemy powiązać metadane.
Podobnie jak w przypadku pozostałych postów z tej serii, nie jest to szczegółowe zagłębienie się w zrozumienie każdej z tabel ani szczegółowe zagłębienie się w każdą z funkcji API. Zamiast tego zbadamy, co jest dostępne, wykorzystamy je i pozostawimy dokładniejsze szczegóły dla przyszłych postów (lub być może dyskusji w komentarzach).
Stowarzyszenie Metadanych WordPress
Metadane nie dotyczą wyłącznie WordPressa. Prawdopodobnie to wiesz. I często jest definiowany jako :
Informacje o informacjach lub dane o danych.
I dobrze to ująć. WordPress oferuje kilka różnych tabel baz danych, których możemy użyć do dostarczenia informacji o niektórych innych typach podmiotów w WordPressie. W dalszej części tego postu użyjemy kilku z nich, ale wystarczy powiedzieć, że WordPress oferuje :
- metadane komentarza,
- metadane posta,
- metadane terminów,
- i metadane użytkownika
A wszystko to dostępne po wyjęciu z pudełka.
Jedna z tabel metadanych WordPressa.
Interfejsy API dla każdego z nich są spójne, co również jest miłe. Ale znowu będziemy się zajmować tylko kilkoma z nich do końca tego postu.
1 Tabele metadanych
W naszym przykładzie użyjemy jednej lub obu z poniższych dwóch tabel:
Oczywiście w twojej instalacji mogą mieć inny prefiks, ale sufiks jest taki sam i masz pomysł.
Po drugie, będziemy używać powiązanych funkcji API do kojarzenia naszych metadanych. Przyjrzymy się im w kodzie podczas kojarzenia danych między naszym użytkownikiem a niestandardowym typem posta (lub naszym autorem i naszymi książkami, jeśli chcesz użyć dokładniejszej terminologii).
W porządku. Cała pierwsza część postu stanowi jedynie podstawę do tego, z jakich części podstawowej infrastruktury WordPressa będziemy korzystać. Mając to wszystko na uwadze, spójrzmy, jak możemy programowo przekształcić tę rzecz w coś bardziej przydatnego.
2 Kojarzenie metadanych
Idea skojarzenia metadanych WordPressa wydaje się bardziej skomplikowana, niż jest w rzeczywistości. Pomyśl o tym w ten sposób:
- Biorąc pod uwagę dwie tabele, w jaki sposób możemy udostępniać informacje między dwoma podmiotami, które informują jedno o drugim?
Na przykład, biorąc pod uwagę użytkownika, w jaki sposób możemy poinformować metadane użytkownika o metadanych postu. Lub, odwracając to, w jaki sposób możemy poinformować metadane postów o powiązanych metadanych użytkownika?
Na wysokim poziomie właśnie to robimy: dajemy jednej istocie znać, że istnieje druga i łączymy ją z drugą. Albo może pójść w drugą stronę. W zależności od implementacji, jedna może być bardziej korzystna niż druga.
1 W jedną stronę
Kiedy mówimy o tworzeniu jednokierunkowych skojarzeń WordPress, zwykle mówimy o pomyśle, że tylko jeden podmiot jest świadomy drugiego. Oznacza to, że użytkownik może tylko znać post.
Możemy więc skonfigurować po utworzeniu posta, gdy dany użytkownik jest świadomy postu, który właśnie został utworzony :
<?php
// Using post title as the value, but it's just an example.
add_user_meta( $user_id, $post_id, $post_title );A może oznacza to, że post jest świadomy użytkownika:
<?php
// User user email address a value but just an example.
add_post_meta( $post_id, $user_id, $email_address );Ale bez względu na to, jak na to spojrzysz, skojarzenie idzie tylko w jedną stronę.
I chociaż związek idzie w jedną stronę, nie musi tak być. Oznacza to, że obie jednostki mogą być świadome siebie nawzajem.
2 Dwukierunkowy
Ponieważ interfejsy API metadanych są tak łatwe i spójne w obsłudze, praca z nimi nie jest trudna. Każdy z nich zwykle wymaga co najmniej dwóch z następujących elementów:
- identyfikator rodzaju, z którym powiązane są metadane,
- metaklucz, który można wykorzystać do wyszukania informacji,
- wartość, która przechowuje informacje związane z identyfikatorem i wpisem.
To, jaki identyfikator i jaki klucz wybierzesz, często zależy od twojej implementacji, jak widzieliśmy.
Do tego momentu przyjrzeliśmy się, jak stworzyć jednokierunkowe skojarzenie. Dwukierunkowe skojarzenie niczym się nie różni. Zamiast uświadamiać jedną istotę drugiej, uświadamiamy obu istotom drugą:
<?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 );
Ale to nie jest decyzja, którą należy podjąć tylko ze względu na to. Zamiast tego warto przemyśleć niektóre z powodów, dla których możesz chcieć wybrać jeden lub drugi.
Przemyślanie problemu
Jeśli chodzi o rozwiązywanie takich problemów, nie ma ostatecznego rozwiązania w kategoriach „powinieneś to zrobić [w ten sposób]" w jakikolwiek sposób. Zamiast tego musisz zadać sobie pytania typu „co sprawia, że najłatwiejszy sposób zarządzania tymi danymi?”
Na przykład, jeśli interesuje Cię przede wszystkim zarządzanie użytkownikami, być może wszystko, czego potrzebujesz, to mieć świadomość metadanych użytkownika o dowolnej encji, z którą są powiązane. W ten sposób, gdy użytkownik zostanie usunięty, upewnij się również, że wyszukasz powiązane z nim encje za pomocą tabeli metadanych użytkownika i również je usuniesz.
Podobnie, być może ta sama funkcjonalność działałaby w obie strony. Oznacza to, że tak jak chcesz się upewnić, że gdy użytkownik zostanie usunięty, jego posty również zostaną usunięte, możesz również chcieć, aby użytkownik został usunięty (lub zmodyfikowany) za każdym razem, gdy jeden z jego postów zostanie usunięty. A jeśli tak jest, to dwukierunkowe skojarzenie na to pozwala.
Ponieważ masz identyfikator danego posta i identyfikator danego użytkownika, a także określone klucze meta, możliwy jest prawie każdy rodzaj zapytania, który możesz zobrazować za pomocą interfejsu API metadanych WordPress lub WP_Query , a nawet za pomocą WP_User_Query.
Koniec
Ostatecznie mam nadzieję, że ta seria dostarczyła pewnych informacji o tym, jak nie tylko tworzyć skojarzenia metadanych WordPress, ale także jak abstrakcyjnie myśleć o koncepcjach w WordPressie w odniesieniu do tworzenia implementacji wyższego poziomu we wtyczkach i aplikacjach internetowych.
Dla zainteresowanych, rozważam wydanie tej serii jako małego zasobu w formacie PDF wraz z działającą wtyczką do nauki. Jeśli jest to coś, co Cię interesuje, zapisz się na listę dyskusyjną tutaj, a na pewno dam Ci znać, gdy będzie gotowa; w przeciwnym razie wykorzystaj informacje z serii, aby iść naprzód i stworzyć coś wartego
Chcieć więcej?
Posty z serii
- Stowarzyszenie metadanych WordPress: jak to zrobić
- Programowe tworzenie użytkowników WordPress
- Typy postów WordPress: abstrakcja dla podmiotów
- Stowarzyszenie metadanych WordPress: powiązane podmioty