Jak utworzyć interfejs API dla mojej wtyczki?

Tworzę wtyczki do WordPressa, większość opracowanych przeze mnie wtyczek wykorzystuje dwie lub trzy klasy, a więc nie tak duże jak Buddypress czy WooCommerce.

Planuję opracować dwie wtyczki typu open source w celu dostarczenia pewnego rodzaju złożonego systemu (obecnie nie mogę udostępniać szczegółów, ale później podczas programowania), w którym inni programiści mogą dostosowywać funkcje, a system dla nich musi być taki sam jak Buddypress i WooCommerce .

Gdy sprawdzam pliki wtyczek i zdaję sobie sprawę, że zarejestrowały własne akcje i filtry, które programiści mogą modyfikować w zależności od potrzeb. Jednak moim problemem jest to, że nie mogę w pełni zrozumieć, jak powinienem napisać wtyczkę, w której inni mogą elastycznie zastępować funkcje, a także dodawać własne.

Wiem, że trudno jest podać jednoznaczną odpowiedź, ale potrzebuję przewodnika dla początkujących, aby móc iść w dobrym kierunku. Czy muszę rejestrować własne działania i filtry? Jeśli tak jak? jeśli nie to jakie są moje opcje?

Twoja rada bardzo mi pomoże ... Dzięki

Interfejs API, który oferujesz we wtyczce lub kompozycji, zależy od logiki tego konkretnego kodu. Prawdopodobnie nie ma przewodnika, który dotyczy wszystkich sytuacji.

Jestem współtwórcą wielu wtyczek z interfejsami API i nauczyłem się do tej pory:

1. Nie oferuj interfejsu API, dopóki naprawdę nie wiesz, jak ludzie używają Twojego kodu.

   Wydaj pierwsze dwie lub trzy wersje bez interfejsu API. Bez niestandardowych akcji lub filtrów, bez publicznych metod i funkcji (i nigdy żadnych zmiennych globalnych), jeśli to możliwe. Zaczekaj na żądania od użytkowników, ale nie dodawaj kodu, dopóki nie dowiesz się, że wewnętrzna struktura kodu będzie działać na dłuższą metę.

   Utrzymanie wstecznej kompatybilności API jest trudne . Może to zapobiec koniecznym ulepszeniom w innych miejscach. Pomyśl o wszystkich globalnych zmiennych, których WordPress nie może obecnie usunąć. To zły interfejs API i utknęliśmy z nim przez wiele lat, ponieważ ludzie już go używają .

2. Rozważ oddzielenie interfejsu API od reszty kodu (zobacz pomysł na poprzedni link).
   Twój interfejs API powinien być użyteczny nie tylko dla programistów zewnętrznych, ale także dla Ciebie. Nie dodawaj sobie ograniczeń, jeśli nie musisz.

3. Zjedz własną karmę dla psów.
   Jeśli oferujesz niestandardowe haki, użyj ich w kodzie. To da innym programistom przydatne przykłady i wkrótce zobaczysz możliwe wady.
   Gdyby rdzeń WordPress używałby tak zwanego Settings API wewnętrznie, nie mielibyśmy dzisiaj tego bałaganu. Może.

4. Dawaj dobry przykład.
   Użyj dobrych części podstawowego interfejsu API WordPress we wtyczce. Unikaj anonimowych obiektów , stałych, zmiennych globalnych i wszelkiego rodzaju nieprzewidywalnych kodów .

5. Upewnij się, że używasz spójnego schematu nazewnictwa (nie taki bałagan ) i umieść wszystko pod własną przestrzenią nazw.

6. Najpierw napisz dokumentację. Zwolnij nowy interfejs API (część) później.
   Twórz przydatne przykłady wszystkiego. Będziesz zaskoczony, jak wiele dziur i zwolnień znajdziesz.

7. Unikaj piekła zwrotnego.
   Oferuj określone narzędzia do debugowania interfejsu API, gdy rzeczy nie działają tak, jak powinny (w tym niezminimalizowane skrypty i arkusze stylów). Napisałem przykład, jak debugować AJAX , aby zilustrować kreatywność. Ponownie narzędzia te należy wyjaśnić w dokumentacji przed ich wydaniem.

8. Alternatywą dla paradygmatu wywołania zwrotnego WordPress może być wzorzec Observer . Zwiększyłoby to barierę dla programistów zewnętrznych, ale mogłoby to spowodować lepszy kod po obu stronach.