Zakładanie wiki społeczności w celu zebrania obiektywnych najlepszych praktyk w zakresie opracowywania wtyczek. To pytanie zostało zainspirowane komentarzami @ EAMann dotyczącymi wp-hackerów .

Chodzi o to, aby współpracować nad tym, jakie obiektywne najlepsze praktyki mogą być, abyśmy mogli potencjalnie wykorzystać je w procesie przeglądu współpracy społeczności.

AKTUALIZACJA: Po zobaczeniu kilku pierwszych odpowiedzi staje się jasne, że potrzebujemy tylko jednego pomysłu / sugestii / najlepszych praktyk na odpowiedź i ludzie powinni przejrzeć listę, aby upewnić się, że nie ma duplikatów przed opublikowaniem.

Użyj akcji i filtrów

Jeśli sądzisz, że ludzie chcieliby dodać lub zmienić niektóre dane: podaj return_filters () przed powrotem .

PS Jedną rzeczą, która wydaje mi się nieco rozczarowująca, jest to, że twoje pytania dotyczą odsetka wtyczek, które są przeznaczone tylko dla użytkowników końcowych, tj. Nie mają własnych haczyków. Wyobraź sobie, że WordPress został zaprojektowany jak większość wtyczek? Byłoby to nieelastyczne i bardzo niszowe rozwiązanie.

Może byłoby inaczej, gdyby WordPress miał możliwość automatycznego instalowania wtyczek, od których zależały inne wtyczki? W tej chwili zazwyczaj muszę napisać wiele funkcji, których potrzebuję od zera, ponieważ klienci chcą pewnych rzeczy w określony sposób, a dostępne wtyczki, podczas gdy 90% tam, nie pozwalają mi na aktualizację pozostałych 10%.

Naprawdę żałuję, że osoby prowadzące społeczność WordPress nie znalazły sposobu, aby zapewnić, że wtyczki są nagradzane za przestrzeganie najlepszych praktyk (takich jak dodawanie haków dla innych programistów), podobnie jak dobre odpowiedzi są nagradzane na stronie StackExchange.

Weźmy przykład z innego pytania :

Przykład: Chcę coś zrobić we wtyczce, gdy ktoś ponownie prześle artykuł. Gdyby w dowolnej popularnej wtyczce z retweetem był niestandardowy hak, do którego mógłbym się podłączyć i odpalić, byłoby świetnie. Nie ma, więc mogę zmodyfikować ich wtyczkę, aby ją uwzględnić, ale to działa tylko na moją kopię i nie chcę próbować jej rozpowszechniać.

Związane z

• Oferta formularzy rozszerzalnych

Załaduj skrypty / CSS za pomocą wp_enqueue_scriptiwp_enqueue_style

Wtyczki nie powinny ładować / próbować ładować duplikatów plików JS / CSS, szczególnie jQuery i innych plików JS zawartych w WP Core.

Wtyczki powinny zawsze używać wp_enqueue_scripti wp_enqueue_stylepodczas łączenia plików JS i CSS, a nigdy bezpośrednio przez <script>tagi.

Związane z

• Ponownie użyj istniejących funkcji

Wsparcie I18n

Wszystkie ciągi wyjściowe powinny być połączone z odpowiednią domeną tekstową, aby umożliwić internacjonalizację przez zainteresowane strony, nawet jeśli programista nie jest zainteresowany tłumaczeniem własnej wtyczki.

Pamiętaj, że bardzo ważne jest, aby załadować pliki językowe podczas initakcji, aby użytkownik mógł się do niej przyczepić.

Zobacz Codex: I18n dla programistów WordPress

A także ten artykuł: Poprawne ładowanie plików językowych WP .

Od WordPress 4.6+

WP 4.6 zmienił kolejność ładowania i sprawdzone lokalizacje, znacznie ułatwiło to programistom i użytkownikom.

Biorąc pod uwagę wtyczkę z „my-plugin” domeny tekstowej, WordPress PIERWSZE szuka pliku tłumaczenia w:
/wp-content/languages/plugins/my-plugin-en_US.mo

Jeśli nie uda się go znaleźć, będzie szukał takiego, w którym wtyczka każe mu szukać (zwykle w folderze „języka” pluigns, jeśli postępuje zgodnie z kodeksem):
/ wp-content / plugins / my-plugin / languages ​​/ my- plugin-en_US.mo

Na koniec, jeśli nie zostanie znaleziony żaden plik językowy, sprawdzi domyślną lokalizację:
/wp-content/languages/my-plugin-en_US.mo

Pierwsze sprawdzenie zostało dodane w 4.6 i daje użytkownikom określone miejsce do dodania pliku językowego, ponieważ wcześniej musieliby wiedzieć, gdzie programista dodał plik językowy, teraz użytkownik musi tylko znać domenę tekstową wtyczki: / wp-content / języki / wtyczki / TEXTDOMAIN-LOCAL.mo

Poniżej jest stary sposób (Nie dotyczy od WP 4.6+)

[...]
Na koniec chciałbym podkreślić, że ważne jest, aby załadować niestandardowe pliki języka użytkownika z WP_LANG_DIR przed załadowaniem plików językowych dostarczonych z wtyczką . Gdy wiele plików mo zostanie załadowanych dla tej samej domeny, zostanie użyte pierwsze znalezione tłumaczenie. W ten sposób pliki językowe dostarczone przez wtyczkę będą służyć jako rezerwowe ciągi znaków nie przetłumaczone przez użytkownika.

public function load_plugin_textdomain()
{
    $domain = 'my-plugin';
    // The "plugin_locale" filter is also used in load_plugin_textdomain()
    $locale = apply_filters( 'plugin_locale', get_locale(), $domain );

    load_textdomain( 
            $domain, 
            WP_LANG_DIR . '/my-plugin/' . $domain . '-' . $locale . '.mo' 
    );
    load_plugin_textdomain( 
            $domain, 
            FALSE, 
            dirname( plugin_basename(__FILE__) ) . '/languages/' 
    );
}

Upewnij się, że wtyczki nie generują błędów dzięki WP_DEBUG

Zawsze testuj wtyczki przy WP_DEBUGwłączonych i najlepiej włączaj je podczas całego procesu programowania. Wtyczka nie powinna generować ŻADNYCH błędów przy WP_DEBUGwłączeniu. Obejmuje to przestarzałe powiadomienia i niesprawdzone indeksy.

Aby włączyć debugowanie, edytuj wp-config.phpplik tak, aby WP_DEBUGstała była ustawiona na true. Aby uzyskać więcej informacji, zobacz Kodeks dotyczący debugowania .

Najpierw użyj istniejących funkcji w WordPress Core

Jeśli możesz: użyj istniejących funkcji zawartych w rdzeniu WordPress zamiast pisać własne. Twórz niestandardowe funkcje PHP tylko wtedy, gdy nie ma odpowiedniej wcześniej istniejącej funkcji w rdzeniu WordPress.

Jedną z korzyści jest to, że można użyć „nieaktualnych powiadomień”, aby łatwo monitorować funkcje, które należy wymienić. Kolejną korzyścią jest to, że użytkownicy mogą przeglądać dokumentację funkcji w Kodeksie i lepiej zrozumieć, co robi wtyczka, nawet jeśli nie są doświadczonym programistą PHP.

Związane z

• Wsparcie I18n
• Załaduj skrypty / CSS za pomocą wp_enqueue_script i wp_enqueue_style
• Oferta formularzy rozszerzalnych

Odinstalowanie powinno usunąć wszystkie dane wtyczki

Po usunięciu z instalacji WordPress wtyczka powinna usunąć wszystkie pliki, foldery, wpisy bazy danych i tabele, które utworzyła, a także utworzone przez siebie wartości opcji .

Wtyczki mogą oferować opcję eksportowania / importowania ustawień, dzięki czemu ustawienia można zapisać poza WordPress przed usunięciem.

Związane z

• Dezaktywacja nie powinna powodować utraty danych

Zapobiegaj wstrzykiwaniu SQL za pomocą danych wejściowych

Wtyczka powinna zdezynfekować wszystkie dane wejściowe użytkownika pobrane bezpośrednio lub pośrednio (np. Przez $_POSTlub$_GET ) przed użyciem wartości wejściowych do zapytania do bazy danych MySQL.

Zobacz: Formatowanie instrukcji SQL .

Prefiks Wszystkie globalne elementy przestrzeni nazw

Wtyczka powinna poprawnie poprzedzać WSZYSTKIE globalne elementy przestrzeni nazw (stałe, funkcje, klasy, zmienne, a nawet rzeczy takie jak niestandardowe taksonomie, typy postów, widżety itp.). Na przykład nie twórz funkcji o nazwie init(); zamiast tego nazwij to jakoś jpb_init().

Zwykle powinien używać trzy- lub czteroliterowego prefiksu przed nazwami lub korzystać z funkcji przestrzeni nazw PHP . Porównaj: Jednoliterowy prefiks dla stałych klas PHP?

Związane z

• Globalna przestrzeń nazw jest ograniczonym zasobem

Użyj zorientowanego na klasy i obiekt kodu PHP5

Nie ma powodu, aby nie pisać czystego, obiektowego kodu PHP5. Obsługa PHP4 zostanie wycofana po następnej wersji (WP 3.1). Oczywiście możesz prefiksować wszystkie nazwy funkcji, aby skończyć na nieskończenie długich nazwach funkcji z licznymi partiami, ale o wiele łatwiej jest napisać prostą klasę i spakować wszystko. Ponadto umieść klasę w osobnym pliku i nadaj jej odpowiednią nazwę, abyś mógł ją łatwo rozszerzać i utrzymywać:

// in functions.php
require 'inc/class-my-cool-plugin.php';
new MyCoolPlugin();

// in inc/class-my-cool-plugin.php
class MyCoolPlugin {
    function __construct() {
        // add filter hooks, wp_enqueue_script, etc.

        // To assign a method from your class to a WP 
        // function do something like this
        add_action('admin_menu', array($this, "admin"));
    }

    public function admin() {
        // public methods, for use outside of the class
        // Note that methods used in other WP functions 
        // (such as add_action) should be public
    }

    private function somethingelse() {
        // methods you only use inside this class
    }
}

Dezaktywacja nie powinna powodować utraty danych

Wtyczka nie powinna usuwać żadnych danych po dezaktywacji .

Związane z

• Odinstaluj powinien usunąć wszystkie dane wtyczki

Uwzględnij tylko pliki, których potrzebujesz ...

Jeśli jesteś w interfejsie, nie dołączaj kodu związanego z obszarem administracyjnym.

Ogłoś utratę danych przy deinstalacji wtyczek

Po odinstalowaniu wtyczka powinna poinformować użytkownika, że ​​usunie swoje dane, i otrzymać potwierdzenie, że użytkownik jest w stanie usunąć dane przed zrobieniem tego, a wtyczka powinna również pozwolić użytkownikowi na zachowanie danych po odinstalowaniu. (Ten pomysł @EAMann.)

Związane z

• Odinstaluj powinien usunąć wszystkie dane wtyczki
• Dezaktywacja nie powinna powodować utraty danych

Pozwól zmienić nazwę folderu wtyczki

/ plugins / nazwa wtyczki / {różne}

„Nazwa wtyczki” używana dla folderu powinna zawsze być zmienialna.

Zwykle jest to obsługiwane przez definiowanie stałych i konsekwentne ich używanie w całej wtyczce.

Nie trzeba dodawać, że wiele popularnych wtyczek jest grzesznikami.

Związane z:

• plugins_url() dla łatwego linkowania do zasobów, zawartych we wtyczce.

Użyj WordPress (wbudowany) Obsługa błędów

Nie tylko, return;jeśli dane wprowadzone przez użytkownika były nieprawidłowe. Podaj im, że niektóre informacje zostały zrobione źle.

function some_example_fn( $args = array() ) 
{
    // If value was not set, build an error message
    if ( ! isset( $args['some_value'] ) )
        $error = new WP_Error( 'some_value', sprintf( __( 'You have forgotten to specify the %1$s for your function. %2$s Error triggered inside %3$s on line %4$s.', TEXTDOMAIN ), '$args[\'some_value\']', "\n", __FILE__, __LINE__ ) );

    // die & print error message & code - for admins only!
    if ( isset( $error ) && is_wp_error( $error ) && current_user_can( 'manage_options' ) ) 
        wp_die( $error->get_error_code(), 'Theme Error: Missing Argument' );

    // Elseif no error was triggered continue...
}

Jeden błąd (obiekt) dla wszystkich

Możesz ustawić globalny obiekt błędu dla swojej kompozycji lub wtyczki podczas ładowania:

function bootstrap_the_theme()
{
    global $prefix_error, $prefix_theme_name;
    // Take the theme name as error ID:
    $theme_data = wp_get_theme();
    $prefix_theme_name = $theme_data->Name;
    $prefix_error = new WP_Error( $theme_data->Name );

    include // whatever, etc...
}
add_action( 'after_setup_theme', 'bootstrap_the_theme' );

Później możesz dodać nieograniczoną liczbę błędów na żądanie:

function some_theme_fn( $args )
{
    global $prefix_error, $prefix_theme_name;
    $theme_data = wp_get_theme();
    if ( ! $args['whatever'] && current_user_can( 'manage_options' ) ) // some required value not set
        $prefix_error->add( $prefix_theme_name, sprintf( 'The function %1$s needs the argument %2$s set.', __FUNCTION__, '$args[\'whatever\']' ) );

    // continue function...
}

Następnie możesz pobrać je wszystkie na końcu swojego motywu. W ten sposób nie przerywasz renderowania strony i nadal możesz wygenerować wszystkie błędy do opracowania

function dump_theme_errors()
{
    global $prefix_error, $prefix_theme_name;

    // Not an admin? OR: No error(s)?
    if ( ! current_user_can( 'manage_options' ) ! is_wp_error( $prefix_error ) )
        return;

    $theme_errors = $prefix_error->get_error_messages( $prefix_theme_name );
    echo '<h3>Theme Errors</h3>';
    foreach ( $theme_errors as $error )
        echo "{$error}\n";
}
add_action( 'shutdown', 'dump_theme_errors' );

Można znaleźć dalsze informacje na ten Q . Powiązany bilet, aby naprawić „współpracę” WP_Errori wp_die()jest stamtąd połączony, a następnie pojawi się kolejny bilet. Komentarze, krytycy i takie są mile widziane.

Minimalizuj nazwy dodane do globalnej przestrzeni nazw

Wtyczka powinna maksymalnie ograniczyć jej wpływ, minimalizując liczbę nazw dodawanych do globalnej przestrzeni nazw .

Można to zrobić poprzez enkapsulację funkcji wtyczki w klasę lub użycie funkcji przestrzeni nazw PHP . Prefiksowanie wszystkiego może również pomóc, ale nie jest tak elastyczne.

Oprócz funkcji i klas wtyczka nie powinna wprowadzać zmiennych globalnych. Korzystanie z klas zwykle je przestarza i upraszcza obsługę wtyczek.

Związane z

• Prefiks poprawnie

Komentuj za pomocą PhpDoc

Najlepsza praktyka jest zbliżona do stylu PhpDoc. Jeśli nie używasz IDE takiego jak „Eclipse”, możesz po prostu rzucić okiem na Podręcznik PhpDoc .

Nie musisz dokładnie wiedzieć, jak to działa. Profesjonalni programiści mogą mimo to odczytać kod i potrzebują go tylko jako podsumowania. Koderzy i użytkownicy hobbystów mogą docenić sposób, w jaki to wyjaśniasz na tym samym poziomie wiedzy.

Użyj interfejsu API ustawień przed opcją add_option

Zamiast dodawać opcje do DB za pomocą funkcji add_option, powinieneś przechowywać je jako tablicę za pomocą interfejsu API ustawień, który dba o wszystko za Ciebie.

Użyj interfejsu API modyfikacji motywów przed opcją add_option

Modyfikacje API jest dość prosta konstrukcja i bezpieczny sposób, który umożliwia dodawanie i pobieranie opcje. Wszystko zostaje zapisane jako wartość zserializowana w bazie danych. Łatwy, bezpieczny i prosty.

Chroń prywatność użytkowników wtyczek

(Wcześniej: anonimowa komunikacja API)

Jeśli wtyczka komunikuje się z zewnętrznym systemem lub interfejsem API (np. Niektórymi usługami internetowymi), powinna to zrobić anonimowo lub zapewnić użytkownikowi anonimową opcję, która zagwarantuje, że żadne dane powiązane z użytkownikiem wtyczki nie wyciekną do drugiej strony w sposób niekontrolowany.

Host Wtyczki na WordPress.org

Użyj repozytorium SVN podanego na WordPress.org do hostowania wtyczek. Ułatwia to aktualizację interfejsu użytkownika, a jeśli nigdy wcześniej nie korzystałeś z SVN, możesz go zrozumieć, używając go w kontekście, który to uzasadnia.

Zapewnij kontrolę dostępu za pomocą uprawnień

W wielu przypadkach użytkownicy mogą nie chcieć, aby wszyscy mieli dostęp do obszarów utworzonych przez wtyczkę, szczególnie w przypadku wtyczek wykonujących wiele skomplikowanych operacji, pojedyncze sprawdzenie zdolności może nie być wystarczające.

Przynajmniej sprawdź odpowiednie możliwoś ci wszystkich różnych procedur, do których można wykorzystać wtyczkę.

Importuj / eksportuj ustawienia wtyczek

Nie jest to tak powszechne we wszystkich wtyczkach, ale jeśli wtyczka ma (niektóre) ustawienia, powinna zapewniać import / eksport danych, takich jak konfiguracja i wprowadzanie danych przez użytkownika .

Import / eksport poprawia użyteczność wtyczki.

Przykładową wtyczką, która ma taką funkcję importowania i eksportowania (a także mechanizm cofania) jest Breadcrumb NavXT (Wtyczka Wordpress) (pełne ujawnienie: trochę kodu przeze mnie tam, większość została wykonana przez mtekk).

Związane z

• Odinstaluj powinien usunąć wszystkie dane wtyczki
• Dezaktywacja nie powinna powodować utraty danych

Uporządkuj swój kod

Zawsze trudno jest odczytać kod, który nie jest zapisany w kolejności wykonania. Najpierw włącz / wymagaj, zdefiniuj, wp_enqueue_style & _script itp., A następnie funkcje, których potrzebuje wtyczka / motyw, a na końcu program budujący (np. Ekran administratora, elementy zintegrowane z motywem itp.).

Spróbuj oddzielić rzeczy takie jak css i js we własnych folderach. Spróbuj także zrobić to z funkcjami, które są tylko pomocnikami, takimi jak spłaszczacze tablic i tym podobne. Utrzymywanie „głównego” pliku tak czystym i łatwym do odczytania, jak to możliwe, jest sposobem, który pomaga użytkownikom, programistom i tobie, gdy próbujesz dokonać aktualizacji za rok i nie widziałeś kodu przez dłuższy czas.

Dobrze jest też mieć strukturę, którą często powtarzasz, więc zawsze znajdziesz drogę. Opracowanie w znanej strukturze różnych projektów da ci czas na ulepszenie, a nawet jeśli twój klient zmieni się na innego programistę, nigdy nie usłyszysz „opuścił chaos”. To buduje twoją reputację i powinno być długoterminowym celem.

Umrzyj ze stylem

umierać w przyzwoity sposób Wszystkie funkcje wtyczek (a nawet motywów) powinny być używane wp_die()w krytycznych miejscach, aby dać użytkownikowi trochę informacji o tym, co się stało. Błędy php są denerwujące i wp_diemogą dać użytkownikowi przyjemny styl wiadomości o tym, co wtyczka (lub ona) zrobiła źle. Dodatkowo, jeśli użytkownik wyłączył debugowanie, wtyczka po prostu się zepsuje.

Korzystanie wp_die()pomaga również, że twoje wtyczki / motywy są kompatybilne z wordsu testsuite .

• Użyj obsługi błędów WP

Zapewnij użytkownikom ekrany pomocy

Lepiej jest powiedzieć RTFM (kliknięcie pomocy) jako odpowiedź niż konieczność ciągłego odpowiadania na pytanie.

/**
  * Add contextual help for this screen
  * 
  * @param $rtfm
  * @uses get_current_screen
  */ 
  function ContextualHelp( /*string*/ $rtfm) 
  { 
     $current_screen = get_current_screen();
     if ($current_screen->id == $this->_pageid) 
     {
        $rtfm .= '<h3>The WordPress Plugin - Screen A</h3>';
        $rtfm .= '<p>Here are some tips: donate to me ' .
     }
     return $rtfm; 
  }
add_action('contextual_help', array($this,'ContextualHelp'),1,1);

aktualizacja / uwaga: (patrz komentarze Kaisera): powyższy przykład należy zastosować w klasie

Oferta formularzy rozszerzalnych

Kiedy wtyczka oferuje możliwość wprowadzania danych, zawsze powinna mieć haczyk na końcu, tuż przed przyciskiem „prześlij” i / lub „zresetuj”, aby programiści mogli z łatwością rozszerzyć formularz nie tylko o pola, ale także przyciski.

Zobacz: Ustawienia API

Związane z

• Użyj akcji i filtrów
• Ponownie użyj istniejących funkcji
• Wsparcie I18n

obejmują funkcję zawsze przez hak, a nie bezpośrednio.

Przykład:

• Nie należy używać do włączenia klasy wtyczki poprzez nowy bez haka

• Użyj haka plugins_loaded

  // add the class to WP                                   
  function my_plugin_start() {                                                               
      new my_plugin();   
  }                                                        
  add_action( 'plugins_loaded', 'my_plugin_start' );

Aktualizacja: mały przykład na żywo: Plugin-svn-trunk-page i pseudo przykład

//avoid direct calls to this file where wp core files not present
if (!function_exists ('add_action')) {
        header('Status: 403 Forbidden');
        header('HTTP/1.1 403 Forbidden');
        exit();
}

if ( !class_exists( 'plugin_class' ) ) {
    class plugin_class {

        function __construct() {
        }

    } // end class

    function plugin_start() {

        new plugin_class();
    }

    add_action( 'plugins_loaded', 'plugin_start' );
} // end class_exists

Możesz także załadować za pomocą mu_plugins_loaded podczas instalacji na wielu serwerach, zobacz kodeks działań: http://codex.wordpress.org/Plugin_API/Action_Reference Widzisz też, jak inlcude wP z tym hakiem: http: // adambrown. info / p / wp_hooks / hook / plugins_loaded? version = 2.1 & file = wp-settings.php Używam tego bardzo często i nie jest to tak trudne i wczesne, lepsze jak nowa klasa ();

Wtyczki licencji na licencji zgodnej z GPL

Wtyczki i motywy powinny być licencjonowane na podstawie licencji zgodnej z WordPress. Umożliwia to ich ponowną dystrybucję z WordPress jako „program”. Zalecaną licencją jest GPL . Uważaj, aby wszystkie biblioteki kodów dołączone do wtyczki były zgodne z tą samą licencją.

(Był to problem i poważny punkt debaty zarówno w przeszłości, jak i obecnie .)

Opis wtyczki powinien dokładnie określać funkcje wtyczki. Istnieje 10 polecanych wtyczek postowych. Wszystkie z nich zawierają polecane posty, ale wiele z nich ma różne funkcje. Powinno być łatwo porównać wtyczkę z podobnymi wtyczkami, czytając opis.

Powinieneś unikać przechwalania się tym, jak prosta jest Twoja wtyczka, chyba że jest naprawdę bardzo prosta. W opisie należy podać przydatne linki, takie jak link do ustawień.

Minimalizuj skutki uboczne zdalnych źródeł danych i usług sieciowych

Wtyczka powinna buforować / chronić żądania Webservice i / lub XMLRPC / SOAP przez warstwę buforującą / dostawcę danych, jeśli ich używasz, aby nie wysuwać żądań frontowych na (powolną) odpowiedź usługi internetowej.

Obejmuje to pobieranie kanału RSS i innych stron. Zaprojektuj swoje wtyczki, aby żądały danych w tle.

Jednym z możliwych KROKÓW jest (Weźmy przykład do ping.fm): Utwórz tabelę buforów, powiedzmy: ping_fm_buffer_post (data, godzina, wiadomość, przesłane_czas, status)

1. Za każdym razem, gdy chcesz przesłać aktualizację do ping.fm, dodaj ją do tej tabeli.
2. Teraz musimy utworzyć wtyczkę do obsługi tych danych. Ta wtyczka będzie działać przez crontab, aby sprawdzić każdą aktualizację, która nie została jeszcze przesłana
3. Ponieważ mamy tę tabelę, możemy również wyświetlić każdą wiadomość przesłaną do ping.fm i sprawdzić status każdego postu. Na wypadek, gdyby wystąpił problem po stronie ping.fm, możemy go ponownie przesłać.

Przetestuj swoją wtyczkę

Powinniśmy definitywnie mieć narzędzia do testowania w naszym środowisku programowania wtyczek.

Na podstawie tej odpowiedzi przez Ethan Seifert na pytanie testu, są dobre praktyki, których należy przestrzegać:

• Twoje testy jednostkowe powinny przetestować najmniejszą liczbę zachowań, jakie klasa może wykonać.
• Gdy przejdziesz do poziomu testów funkcjonalnych, możesz przetestować kod przy użyciu zależności Wordpress.
• W zależności od tego, co robi Twoja wtyczka - rozważ użycie testów opartych na Selenium, które sprawdzają obecność danych w DOM przy użyciu identyfikatorów