Ponieważ wielu z nas kontynuuje rozwój PHP7+, możemy nadal korzystać z wielu nowych funkcji oferowanych przez język.
W międzyczasie jednak nadal istnieją funkcje PHP i powiązanego oprogramowania, których możemy użyć, aby usprawnić nasz rozwój. Najmniejszym z nich (i tym, o czym trochę pisałem i o którym mówiłem) są przestrzenie nazw.
Oto jednak rzecz: lubię mieć strukturę plików i katalogów mojej wtyczki, aby były zorganizowane tak, aby odzwierciedlały konwencje przestrzeni nazw, których przestrzegają. Można to zrobić w przypadku taksonomii, metaboxów, obiektów domen, funkcji związanych z bazą danych i tak dalej.
W tym poście chcę jednak opowiedzieć o sposobie organizowania ekranów ustawień WordPressa zarówno ze struktur logicznych – czyli lokalizacji systemu plików – jak i wirtualnych – czyli przestrzeni nazw – struktur organizacyjnych.
Organizowanie ekranów ustawień WordPress
Pierwszą kwestią, którą chcę poruszyć, jest to: chociaż mówię o organizowaniu ekranów ustawień WordPressa, nie mówię nic o API. Zamiast tego załóżmy, że w tym poście mówię o następujących kwestiach:
- niestandardowe menu z powiązaną stroną menu,
- strona menu, która renderuje wymagania dla strony ustawień (takie jak pole nonce itd.)
- podszablon zawierający rzeczywiste ustawienia (lub wiele podszablonów, jeśli chcesz uwzględnić wiele ustawień).
Nie będę mówił o procesie sanityzacji, serializacji, wyszukiwaniu, walidacji i wyświetlaniu. To jest czysto organizacyjne.
Myślenie przez proces
Biorąc pod uwagę, że zamierzamy organizować nasze pliki za pomocą katalogów, które również mapują 1:1 z przestrzeniami nazw, zastanówmy się dokładnie, czego będziemy potrzebować. Podchodzę do tego tak:
- Tworzymy coś specjalnie dla kontekstowej aplikacji WordPress. Wskazuje to przestrzeń nazw.
- Zamierzamy stworzyć menu administracyjne, co oznacza, że oboje pracujemy w obszarze administracyjnym WordPressa, a więc w innej przestrzeni nazw, oraz z menu, które są inną przestrzenią nazw.
- Następnie potrzebujemy plików do wyświetlenia standardowego ekranu dla WordPressa, więc potrzebujemy przestrzeni nazw Views,
- A potem będziemy potrzebować kodu specyficznego dla domeny, aby wpaść do widoku, więc ostatecznie będziemy potrzebować katalogu Partials (a tym samym przestrzeni nazw).
Tak więc ostateczna, logiczna organizacja danych wyglądałaby mniej więcej tak:
Być może najważniejszą rzeczą, na którą należy zwrócić uwagę w tej konkretnej organizacji plików, jest to, że klasa AdminMenu jest klasą bazową, z której mogą dziedziczyć wszystkie określone (lub bardziej konkretne) klasy.
Oznacza to, że klasa AcmeAdminMenu dziedziczy z niej pewne właściwości i funkcje, a następnie implementuje jej logikę lub dodaje również jej logikę.
Przestrzeń nazw każdego pliku
Kiedy organizujesz swoje pliki w ten sposób, przestrzenie nazw stają się niemal oczywiste, prawda? Oto przestrzeń nazw dla każdego z plików:
- WordPressAdministratorMenuAdminMenu
- WordPressAdminMenuAcmeAdminMenu
- WordPressAdminMenuWidokiUstawienia
- WordPressAdminMenuWidokiUstawieniaCzęści
Zauważ, że ponieważ acme-settings.php jest technicznie tylko znacznikiem dla opcji renderowania, niekoniecznie musi być umieszczony w przestrzeni nazw, ponieważ jest zawarty w widoku, który go renderuje.
Niezależnie od tego, jeśli jesteś fanem utrzymywania rzeczy tak zorganizowanych, jak to tylko możliwe, sensowne jest zagnieżdżanie części w katalogu o nazwie właśnie tak.
A co z kodem?
Jeśli chcesz zobaczyć kod czegoś takiego, rozważam utworzenie małej wtyczki, która pokazuje, jak to wszystko pasuje do siebie. W końcu to trochę na wysokim poziomie, prawda? Mam na myśli, że nie ma implementacji.
Z drugiej strony, jeśli to pomoże ci wskazać właściwy kierunek dla obecnego lub przyszłego projektu, może to wystarczyć.