Jak wielu z Was wie, w zeszłym tygodniu Syed Balkhi uczestniczył w WordCamp Raleigh 2012. Podczas wydarzenia jeden z jego tweetów wywołał sporą debatę. W tym artykule nasz założyciel Syed Balkhi będzie debatował, czy niestandardowe typy postów WordPress powinny znajdować się w pliku functions.php, czy w wtyczkach. Poniżej znajduje się tweet, który rozpoczął tę debatę:
Nie dodawaj niestandardowych typów postów w functions.php -> ZAWSZE powinieneś używać wtyczki specyficznej dla witryny – http://t.co/bebYXq2F #wcraleigh
— WordPress Beginner (@wpbeginner) 4 listopada 2012
Po tweecie, wielu szanowanych ludzi ze społeczności WordPress zabrało głos. Pełną rozmowę można zobaczyć tutaj. Curtis McHale poszedł o krok dalej i rozwinął temat w swoim nowym wpisie na blogu.
Rozmowa z Twittera poruszyła kilka świetnych punktów.
Podsumowanie argumentów
Argument wtyczek: Użytkownik zawsze będzie miał dane, nawet jeśli zmieni motyw. Może nie wyglądać tak ładnie, ale pozostanie.
Argument functions.php: Dane bez projektu byłyby nieistotne. Jeszcze bardziej zdezorientuje użytkowników.
Z którą stroną bardziej się zgadzasz? Wyraźnie obie strony mają swoje problemy, ale która jest mniejszym złem?
Oto dlaczego uważamy, że niestandardowe typy postów powinny ZAWSZE znajdować się w wtyczce specyficznej dla witryny lub całkowicie w osobnej wtyczce.
Niech żyje dane
Niestandardowe Typy Postów to dane. W większości przypadków Twoje dane przeżyją obecny projekt. Po kilkukrotnej zmianie naszych motywów jasno rozumiemy to stwierdzenie. Posty, strony, linki, załączniki i rewizje to wszystkie typy postów, które są wbudowane w WordPress. Ponadto mamy typy postów, takie jak książki, referencje, oferty itp. Czy wyobrażasz sobie teraz, że zmieniamy motyw i wszystko to znika? Na pewno byśmy tego nie chcieli.
Mając programistów w naszym zespole, nie powinno to mieć większego znaczenia. Biorąc pod uwagę, że wszystkie nasze motywy są projektowane na zamówienie przez nasz zespół, jaka jest faktyczna różnica? Sekret tkwi w dwóch słowach: czas i centralizacja. Dopóki mamy wszystkie niezbędne dane, wszystko, co musielibyśmy zrobić w przyszłości, to zmienić styl. Nie będziemy musieli martwić się o kopiowanie i wklejanie funkcji z jednego pliku do drugiego za każdym razem. Co jeśli chcesz odtworzyć funkcjonalność? Po prostu weź wtyczkę i umieść ją na swojej nowej stronie. Zmień styl i gotowe.
Zasady i standardy
Kiedy używamy słowa ZAWSZE, tak jak zrobiliśmy to w naszym tweecie, może ono oznaczać zarówno zasady, jak i standardy. Zarówno zasady, jak i standardy są tworzone dla większości. Zawsze będą istnieć szczególne sytuacje, w których zasady są łamane, a standardy naruszane, ale to nie znaczy, że powinniśmy całkowicie pozbyć się standardów.
Istnieje mnóstwo generycznych typów postów, które w większości wymagają tego samego zestawu dodatkowych pól meta. Kilka przykładów, które przychodzą na myśl, to: Cytaty, Książki, Przepisy, Referencje, Portfolio itp.
Biorąc pod uwagę dużą liczbę motywów fotograficznych i portfolio dostępnych na rynku darmowym i komercyjnym, nie ma sensu, aby użytkownik ponownie wprowadzał wszystkie swoje niestandardowe informacje o typach postów za każdym razem, gdy zmienia motyw. Przyjrzyjmy się przykładowemu scenariuszowi:
Fotograf – Użytkownik skonfigurował WordPress z funkcjonalnością bloga (domyślny typ posta „post”). Chce dodać portfolio swoich prac (wymaga niestandardowego typu posta „Portfolio”). Chce pokazywać referencje od klientów (wymaga niestandardowego typu posta „Referencje”). Wszystkie te informacje z pewnością przetrwają zmianę projektu motywu. Rok później użytkownik chce zmienić wygląd swojej strony i ją odświeżyć. Znajduje nowy motyw, który ma wszystkie podobne funkcje. W momencie przełączenia motywu, BOOM. Wszystkie poprzednie wprowadzone dane zniknęły. Istnieje menu o nazwie Portfolio i menu o nazwie Referencje, jednak żadne dane nie są dostępne. Użytkownik myśli „NA LITOŚĆ BOSKĄ, straciłem całą moją zawartość”. Tworzy nowe pytania wsparcia na forum. Wysyła e-maile do stron takich jak WPBeginner itp. Jeśli nie otrzymają dobrej odpowiedzi, będą musieli ponownie wprowadzić wszystkie dane. To jest beznadziejne doświadczenie użytkownika.
Jak więc rozwiązać ten problem?
Możliwe rozwiązanie?
Tworzymy nową standardową bazę. Justin Tadlock już jakiś czas temu zaczął pracować nad tym problemem, tworząc bazowy plugin portfolio. Czy będzie to idealne rozwiązanie dla wszystkich? NIE, ale będzie dla większości.
Jak pyta Justin w swoim poście, jakie standardowe pola powinny być zawarte w wtyczce portfolio (odnosząc się do metadanych posta). Tego typu rozmowy powinny odbywać się wśród programistów tworzących podobne funkcjonalności w swoich motywach. Po co kopiować i wklejać to samo raz po raz z jednego motywu do drugiego, skoro można to zrobić za pomocą wtyczki? Gdy stanie się to standardem, inni autorzy motywów zaczną się do niego dostosowywać.
Na przykład, widzimy wzrost wsparcia stylistycznego dla Gravity Forms w frameworkach motywów WordPress, takich jak Genesis i inne. Dlaczego? Ponieważ rozumieją, że ich użytkownicy z niego korzystają.
Istnieją solidne motywy WordPress, które są wyposażone w funkcjonalność, którą uważamy, że powinny być wtyczkami. Motywy ogłoszeń o pracę, motywy śledzenia zgłoszeń, motywy ogłoszeń drobnych, motywy nieruchomości itp. Wszystkie powinny być zasilane przez wtyczkę bazową. Dzieje się tak już w przypadku WooCommerce. WooThemes wydało wiele motywów, które mają wbudowane wsparcie stylistyczne dla wtyczki. Inne firmy motywowe obiecały również wydać motywy e-commerce oparte na WooCommerce. Możesz przełączać się z jednego motywu na inny i zachować wszystkie swoje produkty. To prawie tak, jakby motyw się zmienił, ale wszystko po prostu wpadło na swoje miejsce. To jest doświadczenie zmiany motywu, do którego powinniśmy dążyć.
Dlaczego nie zrobić tego samego z Portfolio, Referencjami i innymi ogólnymi niestandardowymi typami postów? Czy dlatego, że jest to zbyt proste w porównaniu do eCommerce, które jest większym wyzwaniem do pokonania? Wyraźnie, eCommerce ma zdecydowanie za dużo pól w porównaniu do innych, więc powinno być znacznie łatwiej dla tych ogólnych typów postów. To tylko kwestia świadomego wysiłku w celu ulepszenia rzeczy.
Spójrz na wtyczkę ReciPress. Tworzy niestandardowe pole meta z polami przepisów i dołącza je do postów. Jednak można je dołączyć do niestandardowych typów postów. Każdy, kto korzysta z tej wtyczki, może zmieniać motywy bez konieczności przechodzenia przez takie kłopoty.
Byłoby miło zobaczyć motywy takie jak AgentPress zasilane przez scentralizowaną wtyczkę bazową. Byłoby wspaniale zobaczyć, jak przejście między motywami staje się łatwiejsze. Na przykład, jeśli użytkownik przełączy się z jednego motywu fotograficznego na inny, nie powinno to być chaotyczne. Mogą wystąpić drobne błędy, ale przynajmniej w szerszym obrazie wszystko będzie działać.
Zawsze można podać przykłady mocno spersonalizowanych typów postów stworzonych na jednorazowe użycie przez klienta, ale to wyjątek, a nie reguła.
Co sądzicie o tym temacie? Gdzie powinien znajdować się kod niestandardowych typów postów? W pliku functions.php czy we wtyczkach?
Yazmin
Ponieważ wielokrotnie traciłem moje CPT podczas przełączania motywów, uważam za frustrujące konieczność wielokrotnego konfigurowania tej samej funkcjonalności w functions.php.
Zdecydowanie preferuję ścieżkę wtyczki i jest to metoda, której będę używać od teraz również w moich projektach biznesowych.
Joshua Jarvis
Mam dokładnie ten sam problem z motywem nieruchomości. „Listingu” były wszystkimi niestandardowymi typami w motywie, który jest teraz funkcjonalnie przestarzały. Kiedy próbowałem zaktualizować motyw, straciłem całą niestandardową zawartość postów, teraz muszę wymyślić sposób, aby to wszystko przenieść. Mam opcje, ale gdyby to był plugin, nie byłoby to konieczne.
Personel redakcyjny
Niezmiernie przepraszamy za niedogodności. Dlatego napisaliśmy ten post, ponieważ wiemy, że to naprawdę utrudnia życie użytkownikowi końcowemu.
Admin
Hugh H. Sands
„Nie będziemy musieli martwić się o kopiowanie i wklejanie funkcji z jednego pliku do drugiego za każdym razem.”
Nie wyobrażam sobie, żeby ktoś pisał kod dla CPT w functions.php, skoro tak łatwo go wyizolować za pomocą include'ów
Ta debata najczęściej krąży wokół danych kontra projektowanie, a zastanawiam się, będąc całkiem nowym w WP, co z wydajnością? Czy wtyczki nakładają jakiś narzut?
Personel redakcyjny
Ten artykuł powinien odpowiedzieć na Twoje pytanie dotyczące wtyczek i wydajności:
https://www.wpbeginner.com/opinion/how-many-wordpress-plugins-should-you-install-on-your-site/
Admin
Hugh Sands
Dzięki za link, bardzo pomocne!
Kelvin Alfonso
Zawsze dołączałem CPT za pomocą oddzielnego pliku do functions.php, ale myślę, że przejdę na ścieżkę wtyczek. Dziękuję!
Sudhakar
Jestem początkujący i nie mam żadnej wiedzy, aby komentować w jedną lub drugą stronę, za lub przeciw wtyczce lub functions.php. Ale zastanawiam się, czy chcę pójść drogą functions.php i zrobić to w motywie potomnym, jaki jest wtedy problem? Dlaczego potrzebuję tego w wtyczce, czy mój motyw potomny nie uchroni mnie przed przyszłymi aktualizacjami motywu i zmianami w motywach?
Personel redakcyjny
Twój motyw potomny (child theme) uratowałby Cię przed przyszłymi aktualizacjami motywu. Jednak NIE uratuje Cię, jeśli zmienisz swoje motywy. Ponieważ zmieniasz motyw potomny, jeśli zmienisz aktywny motyw.
Admin
Pat Ramsey
Jestem zwolennikiem podejścia z wtyczkami dla niestandardowych typów postów i taksonomii. Autor wspomina o wtyczce specyficznej dla strony, tak właśnie robię. Umieszczam wszelkie niestandardowe typy postów, niestandardowe taksonomie i metaboxy w tej wtyczce, dostosowanej do celu strony. Ostatecznie motyw strony się zmieni, ale dane pozostaną i będą nadal łatwo dostępne.
shawn
Jeśli deweloperzy będą nadal ignorować fakt, że oddzielenie „danych” od „projektu” jest konieczne do tworzenia modułowych aplikacji, i nie ma znaczenia, gdzie dane są umieszczone, ponowne wykorzystanie tych danych / kodu zawsze będzie problemem.
Wydaje się, że w społeczności WP istnieje pewne postrzeganie, z jednego lub drugiego powodu, że dane w ekosystemie WordPress można uzyskać tylko wtedy, gdy są one zawarte we wtyczce, dlatego wciąż widzimy dyskusje takie jak ta, przyczyniające się do "Wielkiej debaty wtyczka kontra motyw".
Należy skupić się na rozwijaniu archaicznego systemu wtyczek WordPress, tworząc biblioteki oparte na modułowych wzorcach projektowych, które oddzielają kod / dane od projektu. Biblioteki, które mogą być używane zarówno w motywach, jak i wtyczkach...
Debaty takie jak te są bezcelowe w erze PHP4 WordPressa!!! (re-post)
Mark Simchock
Re: „Jak Justin pyta w swoim poście, jakie standardowe pola powinny być zawarte w wtyczce portfolio (odnosząc się do metadanych posta). Tego typu rozmowy muszą odbywać się wśród programistów, którzy tworzą podobne funkcjonalności w swoich motywach.”
Ja? Wolałbym dobrze udokumentowaną wtyczkę, która jest zaprojektowana tak, aby można ją było rozszerzać, niż „zamknięte”, uniwersalne podejście, z którym trudno pracować (ten kod).
Chodzi mi o to, że być może można powiedzieć: „Nie próbuję być wszystkim dla wszystkich. Oto moja podstawowa wtyczka. Oto jak ją ulepszyć. Jest zaprojektowana tak, aby można ją było ulepszać” i po prostu zostawić to tak. Niezależnie od tego, co zrobisz, trudno przewidzieć każdy przypadek użycia, każdą potrzebę. Więc po co się starać? Dlaczego nie podejść do tego jako do pewnego rodzaju frameworka i pozwolić potrzebującemu deweloperowi po prostu dostosować go do potrzeb?
Justin Tadlock
To właściwie plan. Buduję niezwykle małą i łatwo konfigurowalną bazę. Ale chciałbym wiedzieć, jakie pola, jeśli w ogóle, powinny być standardowe.
Kevin Maines
Literówka?:
„Biorąc pod uwagę, że wszystkie nasze zespoły są niestandardowo zaprojektowane przez nasz zespół”
Personel redakcyjny
Fixed it. Thanks for catching that
Admin
Affan Ruslan
Uważam, że powinno to być wtyczce.
W przypadku, gdy użytkownik może nie potrzebować danych w przyszłości, zawsze może przekonwertować niestandardowy typ posta na „zwykły” typ posta. Istnieje wtyczka, która to umożliwia, przeszukaj repozytorium, a znajdziesz co najmniej jedną.
Christophe Debruel
Szczerze mówiąc, nie obchodzi mnie, co ludzie mówią. Niestandardowy typ posta trafia do wtyczki. Motyw można łatwo zmodyfikować, aby dopasować go do niestandardowego typu posta na froncie. Uważam, że bardziej logiczne jest stylizowanie motywu dla CTP niż posiadanie różnych motywów z tym samym kodem CTP.
Ingo
„Pods Framework” może być również dobrym rozwiązaniem wtyczki. Dla CPT, CT i CF.
http://wordpress.org/extend/plugins/pods/
Personel redakcyjny
Tak, pods jest świetny.
Admin
Elliott Richmond
Wtyczka dla mnie. Przynajmniej dla nietechnicznego klienta, chociaż motyw może nie działać poprawnie, stanie się jasne, że istnieje problem, a to skłoni ich do zatrudnienia dewelopera.
Kailas Mahajan
Wszystko zależy od projektu…
Jeśli ktoś zarządza projektem, który wymaga zmiany motywu po pewnym okresie czasu…może użyć wtyczki.
lub jeśli projekty, które trzymają się jednego motywu... mogą przejść z function.php
Ross W
Wszyscy mówią o tym, jak dane muszą być stylizowane przez motyw, i podają przykłady, gdzie tak jest, a gdzie dane i motyw mogą być rozdzielone.
Nie widzę, aby ktokolwiek mówił o przypadkach, gdy motyw zależy od dostępności pewnych specyficznych danych. Załóżmy, że masz motyw, który zawiera mapę krajów i pewne dane specyficzne dla kraju, i że bez tej mapy i danych motyw traci część swojej kluczowej funkcjonalności.
Tak, nadal można by to zrobić z danymi wtyczki, ale czy rozsądne jest, aby motyw zakładał istnienie pewnych danych? Czy rozsądne jest założenie, że wtyczka tworząca typy danych jest zainstalowana i włączona? (Prawdziwe pytania… dyskusja!)
Co jeśli mój nieco nietechniczny klient chce stworzyć kopię strony ze swoim „motywem”. Włączają motyw w nowej instalacji WordPressa, tylko po to, by odkryć, że brakuje lub jest zepsutych mnóstwo rzeczy? Myśleli, że motyw zawiera wszystko, czego potrzebowali, aby ich strona wyglądała poprawnie?
Widzę zastosowania dla obu podejść. W większości mojej pracy z klientami tworzę CPT, pola meta i niektóre funkcje, aby ułatwić dostęp do nich w plikach biblioteki i je dołączać. Dzięki temu wszystko, czego mój motyw potrzebuje do działania, jest w jednym pakiecie, ale łatwo jest przenieść CPT do nowego motywu, jeśli tylko będę chciał.
Oczywiście, jeśli CPT wygląda na to, że może być używany w wielu motywach i nie jest na tyle specyficzny, że dotyczy tylko danych pojedynczego klienta, wtedy przekształcasz go w wtyczkę, którą można wdrożyć w dowolnym momencie.
Nie sądzę, aby istniała prosta, jednokierunkowa zależność między danymi a motywami. Nie zawsze jest tak, że „mam dane, które wymagają stylizacji”… czasami „moja stylizacja potrzebuje danych”.
Co o tym myślisz?
Andres Hermosilla
Zdecydowanie zgadzam się, że istnieje korzyść z posiadania jednego „kompletnego” pakietu. Często istnieją bardzo specyficzne dla motywu funkcje, które lepiej jest powiązać bezpośrednio (tj. P2 od Auttomatic) niż z zainstalowanym motywem i wtyczką motywu.
Konstantin Kovshenin
Wtyczki. Kropka.
Curtis McHale
Twoje odniesienie do AgentPress jest jednym z powodów, dla których jestem w 100% za CPT w wtyczkach. Miałem do czynienia z takimi motywami i bardzo trudno je odpowiednio dostosować, chyba że usunie się niestandardową funkcję z motywu. Mój klient i ja spędziliśmy 20 godzin, doprowadzając kod do punktu, w którym mogliśmy faktycznie nad nim pracować.
Birgit
Moim najlepszym i ulubionym, polecanym rozwiązaniem jest bardzo elastyczny TOOLBOX: http://wordpress.org/extend/plugins/toolbox/
Personel redakcyjny
Ciekawy pomysł. Szkoda, że nie mogę zrozumieć, co pokazuje zrzut ekranu, bez pobierania wtyczki.
-Syed
Admin
Birgit
The plugin is a “toolbox” for code snippets, that you do normally in your functions.php.
But with a theme update, custom code in the theme’s function.php might get lost.
So I use within my network installation this plugin, activated it network-wide and then the plugin comes with “modules”, that you can access for example by FTP.
You can create modules as much as you like – I have one for each of my blogs within this network. In this modules (= just .php files, let’s say just like site-specific plugins) you can add all the code, that you normally put in your theme’s function.php.
Then at the options page of the plugin you can activate in each blog, which module you would like to load and whether to load it only for frontend or only for backend or for both.
So I only need to have 1 plugin to serve all blogs with individual code snippets, that normally go to their functions.php – and can decide, where to load these modules.
uff, hope this is understandable, because my English is not the best
Być może to pomoże Ci to przeczytać: http://tinyurl.com/bf5dflt
Personel redakcyjny
Brigit, I did translate the WP.org page as well. I understood what the plugin was intended for. However the screenshots were in German, and google is not smart enough to translate images just yet. Same issue is with the link you posted
Sara
Zawsze wolę wtyczki od pliku functions.php dla wszystkiego, co mogłoby znacząco „zepsuć” frontend lub utracić dane, jeśli motyw zostałby zmieniony. Dzieje się tak z dokładnie tych powodów, które cytujesz, a także uważam, że jest to SZALONE dla tych z nas, którzy nie są prawdziwymi programistami PHP, próbować rozwiązywać konflikty, gdy trzeba komentować fragmenty w functions.php, aby zidentyfikować problem.
matt
ok, jaką wtyczkę cpt polecasz?
Personel redakcyjny
Chodzi o to, że niestandardowe typy postów powinny być rejestrowane w wtyczce specyficznej dla danej witryny. Nie ma jeszcze konkretnej wtyczki. Ale to tylko rzucanie pomysłem stworzenia podstawowej wtyczki dla generycznych typów postów.
Admin
Muhammad Waqas
Jestem bardziej przekonany do używania funkcji lokalnych. ale w tym przypadku myślę, że wtyczce można bardziej zaufać. Na przykład, jeśli zaczniesz używać wp z konkretnym frameworkiem. W większości przypadków możliwe jest, że staniesz się niewolnikiem na długi czas, dopóki nie zatrudnisz profesjonalisty wp, który pomoże Ci uciec od tego frameworka bez utraty ustawień i danych. Z drugiej strony wtyczki mogą działać prawie w każdym motywie.
Kiedy zacząłem pracować z wp, wolałem framework niż wtyczkę. Rzeczywistość jest taka, że twórcy wtyczek uważają początkujących i mniej piśmiennych ludzi podczas tworzenia czegoś. Osobiście uważam, że większość użytkowników wp woli ręczne modyfikacje kodu niż poleganie na wtyczkach do podstawowych funkcji stron. W dłuższej perspektywie wtyczki nie są niezawodne. Tak czuję..