Chciałbym uzyskać opinie na temat najlepszych praktyk w tworzeniu wtyczek WordPress zapewniających integrację motywów.
Aby mieć sens, gdy zadaję to pytanie, zacznę od hipotetycznego przykładu interesującego mnie scenariusza. Wyobraź sobie, że tworzę wtyczkę o nazwie „Dyskografia”. Dyskografia rejestruje trzy niestandardowe typy postów: „Zespoły”, „Albumy” i „Utwory”. Wtyczka zapewnia również meta-skrzynki, które zawierają szczegółowe informacje o każdym typie postu, a także niestandardowe taksonomie do uporządkowania każdego typu postu. Te typy postów są powiązane razem z wtyczką Posts 2 Posts . W ramach administratora użytkownik może dodawać nowe pasma, które mogą być powiązane z albumami, które z kolei są powiązane ze ścieżkami, wszystkie, które będą miały wiele innych danych dodanych do nich za pośrednictwem meta-boxów i taksonomii.
Teraz nie chcę, aby ta wtyczka po prostu konfigurowała administratora, aby użytkownicy mogli wprowadzać te informacje; Chciałbym, aby zapewnił pewne domyślne wyświetlanie danych. Bardziej zaawansowany użytkownik / programista miałby dobrze, mając tylko tego administratora. Łatwo byłoby jej zdobyć te dane i wykorzystać je w motywie; jednak bez niektórych domyślnych widoków ta wtyczka byłaby bezużyteczna dla większości użytkowników. W tym przykładzie możesz wyświetlić coś podobnego (nawiasy pokazują sposoby wyświetlania informacji w kolejności hierarchii szablonów):
- Zespoły (single-prefix-band.php, single.php, index.php, shortcode)
- Albumy (single-prefix-album.php, single.php, index.php, shortcode)
- Utwory (single-prefix-track.php, single.php, index.php, shortcode)
- Lista pasm (template-band-list.php, page-band-listing.php, page- {id} .php, page.php, index.php, shortcode)
- Lista albumów (template-album-list.php, page-album-listing.php, page- {id} .php, page.php, index.php, shortcode)
- Oś czasu albumu (szablon-album-timeline.php, strona-album-timeline.php, strona- {id} .php, page.php, index.php, shortcode)
Ważne jest, aby istniała domyślna prezentacja dla tych typów postów, ponieważ domyślne pliki szablonów nie wyświetlałyby wszystkich informacji potrzebnych dla każdego z typów postów. Na przykład motyw Twenty Eleven domyślnie wyświetlałby tylko nazwę, kategorie, opis i datę publikacji albumu. Niezbyt przydatne w przypadku albumu. Chciałbym udostępnić pojedynczy szablon posta, który ściąga zespół, datę wydania, wytwórnię, wersje albumu, utwory itp. Jako programista wtyczek uważam, że byłoby to ważne. Wiem, że szablon nie zadziałałby dla każdego motywu, ale powinny istnieć pewne ustawienia domyślne, które można dodatkowo zintegrować z motywem użytkownika.
Znów jestem ciekawy, jak najlepiej poradzić sobie z tą sytuacją? Myślę, że możesz wykonać jedną z następujących czynności.
Skróty
Skróty można wykorzystać jako bardzo elastyczny i przyjazny dla użytkownika sposób, aby umożliwić programistom dodawanie zespołów, albumów, utworów, list zespołów itp. W dowolnym miejscu na stronie. Przydałoby się wyróżnianie pasm na określonych stronach lub tworzenie osobnych stron dla każdego pasma (niezbyt wydajne, ale niektórzy użytkownicy podchodzą do tego w ten sposób). Krótki kod wygenerowałby HTML, który byłby powiązany z dostarczonym plikiem CSS, który zapewniłby ładny domyślny widok pożądanych danych. Wszystko byłoby zawarte w plikach wtyczek i nic nie musiałoby być zrobione z tym motywem.
Pliki szablonów
Wtyczka może również być dostarczana z plikami szablonów. Pliki szablonów można oznaczyć i nadać im styl, aby uzyskać ładny widok domyślny. Możesz podać instrukcje dla użytkownika, aby przenieść pliki do folderu motywu, aby motyw znalazł odpowiednie szablony podczas przeglądania typów postów. Możesz nawet posunąć się tak daleko, jak udostępnienie interfejsu, który pozwala użytkownikowi przenosić pliki jednym kliknięciem (uwaga: nie aktywowałbym plików w folderze motywów użytkownika podczas aktywacji, ponieważ dodawanie plików do motywu bez inicjowania go jest złe) .
Możesz także użyć filtrów, aby wykorzystać te pliki bez przenoszenia ich z folderu wtyczki, utrzymując wszystko w spokoju. Widziałem używane do tego celu filtry „template_include” i „{$ type} _template”. W rzeczywistości możesz użyć szablonów z folderu motywów, a jeśli nie są obecne, możesz skorzystać z tych filtrów, aby uzyskać domyślne widoki.
Pytanie
Lubię wiedzieć, co inni uważają za najlepsze praktyki w takich sytuacjach, jeśli przedstawione pomysły są w jakikolwiek sposób problematyczne oraz wszelkie alternatywy, których nie uwzględniłem.
Dziękuję Ci!
źródło
Odpowiedzi:
Nie mogę odpowiedzieć na każde pytanie, o które pytałeś, ponieważ czytanie Q zajęło jak dotąd wystarczająco dużo czasu;), ale staram się dać ci wgląd w moje osobiste doświadczenia związane z tworzeniem darmowych wtyczek typu open source.
1. Nigdy nie rób za dużo. Funkcje są śmiercią każdej wtyczki. Najpierw zbuduj wersję podstawową i sprawdź reakcję użytkowników. Jeśli twoja wtyczka zyska dużo uwagi, możesz zintegrować funkcje, które są najczęściej wymagane.
2. Unikaj wypełniania każdego przypadku użycia. Musisz utrzymać wtyczkę. WP oferuje nową wersję co trzy miesiące. A czasem trudno jest śledzić wszystkie wtyczki. Na przykład: Nowa wersja interfejsu API ustawień jest obecnie omawiana w Trac. Kiedy to się skończy, jest szansa, że wielu programistów wtyczek lub motywów będzie musiało zmienić dużą część kodu, a niektórzy ludzie - jak ja - nawet napisali warstwę abstrakcji nad API. Musisz więc cofnąć się, przepisać warstwę podstawową / abstrakcji, a następnie przerobić wszystko, co nazywa to jej częścią. Obiecuję, że to dużo pracy. Co więcej, jeśli jest ściśle związany z Twoim kodem. Kiedy zaczynasz wypełniać wiele przypadków użycia, dostajesz również dużo ewolucji podstawowego kodu WP, który musisz monitorować, a także dużo pracy przy aktualizowaniu kodu.
3. Nigdy nie próbuj dołączać wielu przykładów kodu (lub szablonów) do swoich wtyczek lub motywów. Jeśli chcesz kierować reklamy do programistów i użytkowników końcowych: użyj swojego bloga do dokumentacji. Programiści nienawidzą takich rzeczy, a użytkownicy końcowi nigdy nie są zadowoleni (patrz: wypełnianie każdego przypadku użycia).
4. Mądrze podziel kod na pojedyncze pliki. Ogólna zasada: jeden plik na jedną część. Przykład: styles.php, scripts.php, taxonomies.php, cpts.php itp. Załaduj wszystko z klasy „matki” (fabryki) i utrzymuj swoje elementy w stanie „podłączalnym”. Jeśli musisz przepisać różne rzeczy, łatwo je znajdziesz. Jeśli twórcy czegoś szukają: łatwo to znajdą. Wiele dobrze nazwanych plików, nie krzywdź cię.
5. Jeśli masz listę podstawowych stylów (klas), pozostaw ją użytkownikowi . Szanse są po prostu zbyt duże, że style z motywu lub innych wtyczek przechwycą twoje definicje (bez względu na to, ile konkretności wrzucisz). Spróbuj wyjaśnić to gdzieś z jak najmniejszą ilością tekstu.
6. Uwielbiam swoją wtyczkę. Ale puść, jeśli się nudzisz. :)
Teraz - krótko mówiąc - szczegółowo o swoim pomyśle dotyczącym wtyczek:
A. Pliki szablonów są złe. Jak powiedziałem: udokumentuj to na swoim blogu, podaj tam przykładowe narzuty i style. Twój blog będzie zarabiał (i Ty również, jeśli masz reklamy).
B. Skróty to kool. Nie krzywdzą nikogo, jeśli wtyczka zniknie (w większości przypadków), a później można ją rozszerzyć / rozwinąć do przycisków TinyMCE (które ludzie kochają).
C. Wyjaśnij, że Twoja wtyczka potrzebuje innej wtyczki. Pytanie to i dodaj notatkę do admin_notices (przez register_activation_hook), jeśli druga wtyczka nie wychodzi (w tym przypadku link) lub nie jest aktywowana (możesz to zrobić dla użytkownika przy aktywacji). Pamiętaj też, że ta wtyczka pochodzi z zaufanego źródła i będzie utrzymywana przez następne lata.
Uwaga: Nic, co napisałem, nie jest niczym więcej niż moją osobistą opinią, która odzwierciedla moje doświadczenie.
źródło
W niektórych aspektach musisz rozważyć równowagę między tworzeniem wtyczki lub motywu, jeśli Twój scenariusz wymaga wielu dostosowań / funkcji, zwykle zawsze lepiej jest utworzyć motyw. W ten sposób użytkownik może następnie dostosować wygląd, co jest zawsze łatwiejsze niż skłonienie użytkownika do dostosowania funkcjonalności (poprzez zacinanie wszędzie skrótów), masz większą kontrolę funkcji, działa z innymi wtyczkami itp.
Wtyczka próbująca silnie zintegrować się ze wszystkimi różnorodnymi motywami na rynku z pewnością sprawi ci wiele problemów i, szczerze mówiąc, dużo pracy.
Na przykład zamiast tworzyć bardzo zintegrowaną wtyczkę opartą na zarządzaniu muzyką i dyskografią, zamiast tworzyć motyw do tego celu, staje się to coraz bardziej popularne na niszowych rynkach, które wymagają niestandardowej pracy. Przykładem w świecie rzeczywistym byłby motyw oparty na nieruchomościach, nie ma sposobu, bym użył do tego wtyczki, ponieważ ma tak głęboki zestaw funkcji, zamiast tego jest tworzony od podstaw jako motyw, ponieważ motywy mogą korzystać z w każdym razie wszystkie funkcje wtyczek.
Jest również prawdopodobne, że z perspektywy marketingowej niszowy motyw poradzi sobie lepiej niż wtyczka podczas równoważenia funkcji frontonu.
źródło
Wirtualne strony
Trzecią techniką, którą zobaczyłem, było przypisanie specjalnej strony jako symbolu zastępczego wtyczki i użycie filtru „the_content” do wypisania wszystkiego, co potrzebujesz.
W ten sposób możesz tworzyć szablony, które wtapiają się w strukturę motywu, ponieważ nie musisz zajmować się nagłówkami, paskami bocznymi, stopkami i divami otoki.
Świetny przykład tego można znaleźć we wtyczce bbPress:
http://bbpress.trac.wordpress.org/browser/branches/plugin/bbp-includes/bbp-core-compatibility.php?rev=3434#L931
źródło