Gdzie umieścić mój kod: plugin lub functions.php?

Czy istnieje łatwy do zrozumienia schemat decydujący o tym, jaki kod należy do wtyczki lub motywu functions.php?

Tam są wiele spraw i wielu debat o tym temacie, głównie dlatego, że istnieje kilka błędnych przekonań na temat wewnętrznych mechanizmów WordPressa. Proszę o odpowiedź w oparciu o fakty, a nie opinie.

Powinien wyjaśnić, jak radzić sobie z tymi punktami (i prawdopodobnie więcej):

• niestandardowe typy postów i taksonomie
• formularze kontaktowe
• skróty
• niestandardowe widżety
• add_theme_support( 'automatic-feed-links' );
• SEO działa jak niestandardowe metaelementy
• przełącznik motywów

Po obu stronach często występują zalety i wady. Nasze najpopularniejsze pytanie Najlepsza kolekcja kodu dla pliku functions.php zawiera wiele fragmentów kodu jako odpowiedzi, które są co najmniej dyskusyjne.
Potrzebujemy kryteriów, które początkujący może zrozumieć, może listy kontrolnej - z uzasadnieniem.

Zobacz także powiązane pytanie Chipa Bennetta na naszej meta stronie: pytania konkretnie dotyczące rozwiązania „bez wtyczki”

Powiązane: Gdzie umieścić fragmenty kodu, które znalazłem tutaj lub w innym miejscu w sieci?

Zacznę od tego pytania: Czy funkcjonalność związana jest z prezentacją treści, generowaniem / zarządzaniem treścią, witryną lub tożsamością użytkownika?

Jeśli funkcjonalność nie jest związana konkretnie z prezentacją treści , to jest ona wyraźnie na terytorium wtyczki. Ta lista jest długa:

• Modyfikacja podstawowych filtrów WP ( wp_headzawartość, taka jak linki kanoniczne, generator i inne meta HTML itp.)
• Witryna Favicon
• Skróty post-content
• Linki do udostępniania postów
• Skrypty stopki Google Analytics (i podobne)
• Narzędzia / kontrole SEO
• itp.

Jeśli funkcja jest związana do prezentacji treści , to jest kandydatem do włączenia do tematu. W tym momencie powróciłbym do kryterium przełączania motywów @ Raf912 : czy przeoczyłbyś funkcjonalność podczas przełączania motywów? Jeśli odpowiedź na to pytanie brzmi „ nie” , funkcjonalność należy do motywu. Kilka przykładów:

• Usuwanie / przesłanianie podstawowego CSS Gallery CSS
• Filtrowanie długości fragmentów postów, tekstu „czytaj więcej” itp.
• Wszystko zaimplementowane przez add_theme_support()(chyba to powinno być oczywiste)
• niestandardowe CSS

Zwykle te dwa pytania zapewnią dość wyraźną linię różnicowania; są jednak wyjątki.

Niestandardowe typy postów

Niestandardowe typy postów, na przykład, są swoistą hybrydą generowania i prezentacji treści, biorąc pod uwagę sposób, w jaki Hierarchia szablonów działa dla stron indeksu archiwum pojedynczego typu i stron pojedynczych postów . Aspekt generowania treści CPT zwykle umieszczałby je prosto na terytorium wtyczek; wtyczki nie mogą jednak definiować stron szablonów, które z natury pasują do projektu / układu / stylu dla dowolnego motywu (szczególnie jeśli CPT wyświetla inny niż zwykły tytuł / treść / meta lub ma związane z nim niestandardowe taksonomie).

Długoterminowo rozwiązaniem tego rozbieżności, IMHO, jest posiadanie standardowej konwencji / konsensusu w sprawie definicji CPT dla określonych rodzajów treści (listy nieruchomości, wydarzenia w kalendarzu, produkty e-commerce, wpisy w książce / bibliotece multimediów itp. .). W ten sposób treść generowana przez użytkowników pozostanie przenośna między kompozycjami, które implementują standardową / konwencyjną definicję danego CPT, podczas gdy programiści zachowują elastyczność w definiowaniu projektu / układu / stylu tego CPT w plikach szablonów kompozycji.

Linki do mediów społecznościowych

Podobnie normalnie powiedziałbym, że linki profilu w mediach społecznościowych stały się niemal wszechobecne w obecnych Motywach, są Terytorium Wtyczki, ponieważ nie mają nic wspólnego z prezentacją treści. Najlepszym rozwiązaniem byłoby zdefiniowanie tych profili gdzieś w rdzeniu; jednak obecnie nie ma standardowych / konsensusowych sposobów definiowania tych łączy. Czy najlepiej je zdefiniować na poziomie konfiguracji witryny, czy na poziomie użytkownika? Jeśli na użytkownika, która meta użytkownika zostanie ujawniona w szablonie? itp.

Tak więc, w dalszej perspektywie, rozwiązaniem tej różnicy jest określenie przez rdzeń, gdzie te linki są zdefiniowane, lub społeczności twórców motywów, aby wypracować własny konsensus. W międzyczasie naprawdę nie ma na to nic, poza tym, aby były zdefiniowane w ramach każdego motywu.

Łatwy test, w którym kod jest najlepiej umieszczony:

• napisz kod do functions.php
• zmienić motyw

• brakuje Ci funkcjonalności, blog nie działa poprawnie lub zostały fragmenty starego motywu (np. skróty)?

  • tak: włóż to do wtyczki

  • nie: zostaw to w functions.php

Przykłady: Napisz krótki kod. Po zmianie motywu w postach pozostają proste skróty. Więc lepiej będzie umieścić go we wtyczce.

Napisz funkcję, aby wyświetlić ostatnie komentarze. Po zmianie motywu wszystko jest w porządku, ponieważ może drugi motyw ma równoważną funkcję.

To naprawdę zależy od kodu i tego, co zrobi. Niektóre kody wpływają tylko na styl lub treść motywu, inne modyfikują posty na blogu.

Nie sądzę, że istnieje łatwa odpowiedź na to pytanie, ale założę się, że moglibyśmy stworzyć schemat blokowy, aby pomóc w podjęciu decyzji. Oto ogólny zarys takiego schematu blokowego, który można i należy rozszerzyć. Komentuj z sugestiami!

• Czy ten kod ma być hostowany w instalacji WordPress w pojedynczej witrynie?
  • Tak - czy motyw witryny zmienia się tylko wraz z poważnymi zmianami i zmianami funkcjonalności?
    • Tak - czy dany kod jest specyficzny dla obecnego projektu ?
      • Tak: functions.php
      • Nie: wtyczka
    • Nie (zmienia się często lub pod wpływem kaprysu) - Wtyczka
  • Nie (Multisisite) - Czy prowadzisz instalację wielostanowiskową LUB czy jest to hostowane rozwiązanie wielostanowiskowe umożliwiające wtyczki?
    • Tak: Czy omawiana funkcja jest specyficzna dla tej witryny , czy może / powinna z niej korzystać inne witryny w sieci?
      • Specyficzne dla tej strony: functions.php
      • Dzielone między wiele witryn - Czy chcesz wymusić to na każdej stronie?
        • Tak: Wtyczka przechowywana w katalogu mu-plugins lub aktywowana przez sieć
        • Nie: Czy to sieć niepowiązanych stron? (np. różni klienci)
          • Tak: czy byłoby źle lub nieprofesjonalnie, gdyby klient A widział lub aktywował wtyczkę napisaną dla klientów B, C i D? (np. może to zniszczyć witrynę lub spowodować niepożądaną funkcjonalność)
            • Tak: functions.php
            • Nie: wtyczka
          • Nie: Prawdopodobnie wtyczka
    • Nie (hostowany przez usługę taką jak VIP, która nie zezwala na wtyczki): użyj funkcji.php

• Motywy nadrzędne - czasami ze wspólną funkcjonalnością lepiej byłoby utworzyć motyw nadrzędny i umieścić tę funkcję w pliku functions.php motywu nadrzędnego.
• Katalogi wtyczek dużych instalacji wielostanowiskowych mogą szybko stać się niesforne, więc czasami współdzieloną funkcjonalność używaną przez niski odsetek witryn (np. <1%) najlepiej byłoby powielić w plikach functions.php.

Stąd Tematy VS Wtyczki

Dodaj niestandardowy kod do motywu podrzędnego, aby po aktualizacji motywu nadrzędnego nie utracić kodu niestandardowego.

Możesz także utworzyć wtyczkę specyficzną dla witryny, która zawiera również cały kod niestandardowy.

Jeśli chodzi o pisanie kodu w porównaniu z wtyczkami, możesz używać wtyczek i funkcji, jednak dla większości tego, co chcesz, ręczne kodowanie jest najlepsze, ponieważ jest łatwiejsze do modyfikacji, z wyjątkiem niektórych przypadków, takich jak meta-boxy, w których możesz rozważyć użycie wtyczki, chyba że jesteś programistą motywów.

 function modify_contact_methods($profile_fields) {

// Add new fields
$profile_fields['twitter'] = 'Twitter Username';
$profile_fields['facebook'] = 'Facebook URL';
$profile_fields['gplus'] = 'Google+ URL';

return $profile_fields;
}
add_filter('user_contactmethods', 'modify_contact_methods');

http://codex.wordpress.org/Plugin_API/Filter_Reference/user_contactmethods

1. Dodaj nowy niestandardowy typ postu - Kod
2. Dodaj nowe pola do użytkowników - powyższy kod
3. Dodaj nowe widżety - Kod
4. Dodaj niestandardowe łącza bezpośrednie - Ustawienia łącza bezpośredniego WordPress

Wiem, że to martwy koń i Chip prawie go opisał, ale chciałem dodać kilka przemyśleń.

Jeśli tworzysz żywe programy i pracujesz na stronach Wordpress w wyznaczonych terminach, przekonasz się, że to naprawdę sprowadza się do czasu.

Częściej niż nie, szczególnie dla tych, którzy dopiero zaczynają, jest o wiele szybsze i łatwiejsze po prostu dodać do motywu wszystko, czego potrzebujesz, i nazwać to gotowym.

Biorąc to pod uwagę, jeśli pracujesz na wordpressie regularnie, powinieneś poważnie rozważyć wykonanie następujących czynności :

1. Zbuduj szkielet wtyczki

Powinno to obsłużyć wszystko, co zwykle musisz zrobić z wtyczką, w tym aktywację, dezaktywację, aktualizację wersji, budowanie paneli administracyjnych i odinstalowywanie.

Jeśli znajdziesz czas, aby to zrobić, znajdziesz:

• Dodanie funkcjonalności za pomocą wtyczek nie zajmuje już dużo czasu
• Możesz zacząć budować solidną listę wtyczek do ponownego wykorzystania w innych projektach w razie potrzeby, oszczędzając sobie dużo czasu na dłuższą metę.
• Możesz je udostępnić publicznie, jeśli chcesz uzyskać lepszą widoczność

Możesz teraz poprawnie budować i szybciej realizować przyszłe projekty.

2. Zbuduj szkielet motywu

Powinno to obsłużyć wszystko, co jest zwykle potrzebne w kompozycji:

• Podstawowy arkusz stylów zawierający często używane style (resetuje itp.)
• Właściwy plik index.php, obsługujący wszystko, czego potrzebujesz do dowolnego szablonu
• Plik funkcji.php - nie użyjesz go prawie tak często, ale nadal będzie przydatny.

Gdy to zrobisz, stwórz szkielet motywu potomnego, który używa twojego motywu podstawowego.

• Dodaj arkusz stylów, odwołując się do motywu nadrzędnego.
• Dodaj plik functions.php

Po wykonaniu tych dwóch czynności tworzenie nowych witryn dla ludzi staje się znacznie szybsze.

Jeśli wykonasz powyższe czynności, możesz pracować nad następującymi elementami:

• Poświęć swój nowy wolny czas na zapoznanie się z PHP, WordPress, JavaScript, CSS i / lub mySQL ... im więcej się o nich dowiesz, tym szybciej to zrobisz.
• Zaktualizuj szkielety wtyczek, motywów i motywów potomnych, gdy znajdziesz rzeczy, które powinieneś poprawić. Bez względu na to, jak dobry jesteś, jeśli będziesz się uczyć, znajdziesz ulepszenia do wprowadzenia.

A jeśli zrobisz wszystko powyższe , przekonasz się, że odpowiedź Chipa nie tylko będzie idealna, ale stanie się optymalna.

Prosta odpowiedź brzmi:

Czy kod zależy od jakiejkolwiek funkcjonalności wbudowanej w konkretny motyw? Jeśli tak, dodaj motyw.

Czy chcesz, aby ten kod mógł być przenoszony między stronami i między motywami? Jeśli tak, zainstaluj wtyczkę.

Jeśli odpowiedź jest przecząca na oba powyższe pytania, wyobraź sobie stronę za 5 lat, kiedy nadejdzie czas na przeprojektowanie. Czy funkcja kodu, który piszesz, przetrwa następną aktualizację projektu? Jeśli tak, wstaw wtyczkę.

Ponadto, jeśli nie używasz motywów potomnych i planujesz zaktualizować motyw, sugerowałbym również użycie wtyczki.