Czy automatycznie określasz minimalną wersję WordPress wymaganą dla wtyczki?

22

Czy podczas opracowywania wtyczki istnieje sposób na automatyczne określenie minimalnej wersji WordPress wymaganej do jej uruchomienia? Chcę się upewnić, że Requiresnagłówek jest dokładny, ale ręczne sprawdzanie za każdym razem, gdy wywołuję nową funkcję podstawową, jest żmudne i podatne na błędy.

Myślę, że skrypt może to łatwo zrozumieć:

  1. Przeskanuj wszystkie pliki we wtyczce.
  2. Przetwarza wszystkie dawałaby klasy i wywołania funkcji opartych na new foo( [...] ), foo::bar( [...] ), bar( [...] ), call_user_func( [...] ), itd składnia.
  3. Analizuj źródło WP, aby określić, kiedy każda z tych klas / funkcji została dodana do WordPressa, używając @sinceznacznika phpDoc.
  4. Wygeneruj raport z listą każdej klasy / funkcji i wersji, która została dodana, wraz z najwcześniejszą wersją WordPress, która zawiera wszystkie klasy / funkcje.

Rozejrzałem się, ale nie mogłem znaleźć czegoś podobnego i nie mam czasu, żeby sam to napisać. Czy ktoś wie o istniejącym rozwiązaniu?

plugin-development wordpress-version automation Ian Dunn
źródło
Widziałeś to, wordpress.org/extend/plugins/log-deprecated-notices
Wyck
To byłby dobry początek, dziękuję za zwrócenie na to uwagi :)
Ian Dunn
@IanDunn Jeśli udało Ci się znaleźć rozwiązanie tego problemu, udostępnij je. :)
its_me
Nie znalazłem jeszcze rozwiązania.
Ian Dunn
2
Im więcej o tym myślę, tym bardziej wydaje się, że WordPress powinien po prostu to zbudować i uruchomić na wszystkich wtyczkach w repozytorium, aby numer wersji był dokładny dla wszystkich wtyczek na zawsze.
mrwweb

Odpowiedzi:

14

Znalazłem rozwiązanie jako zautomatyzowana usługa na stronie http://wpseek.com/pluginfilecheck/

Robi dokładnie to, o co proszono, w tym generowanie listy używanych funkcji i sugerowanie komentarzy do nagłówka wtyczki.

Carstenbach
źródło
To całkiem fajne, dzięki :) Myślę, że byłoby znacznie wygodniej, gdyby była to sama wtyczka WordPress, a nie usługa internetowa, ale jest lepsza niż nic.
Ian Dunn
2
Niestety jest również „na plik” - więc nie ma potrzeby przesyłania całej wtyczki. Ale wciąż bardzo przydatny zasób - świetne znalezisko!
Stephen Harris
2
Ta usługa obsługuje teraz przesyłanie pliku zip i automatycznie skanuje wszystkie zawarte w nim pliki :)
Ian Dunn,
Czy jest jakiś sposób, aby dodać to ( de.wpseek.com/pluginfilecheck ) lub inną alternatywę w statycznej analizie wtyczki podczas kompilacji, tak że nie muszę iść do powyższej witryny, aby sprawdzić ponownie n, a system kompilacji automatycznie generuje raport wraz z innymi analizami statycznymi przy każdym zatwierdzeniu.
learning_13
3

Aktualizacja: To nie jest już dokładne. Zobacz odpowiedź Carstenbacha .

Wygląda na to, że odpowiedź brzmi: „Nie, nie ma na to żadnego rozwiązania”.

Jeśli ktoś chciałby napisać, mogą być pomocne:

Myślę, że komentarz Marka na temat wbudowania funkcji w repozytorium WordPress.org jest naprawdę dobrym pomysłem, ale może być czymś, co społeczność musi najpierw stworzyć, aby udowodnić, że jest użyteczna, zanim główny zespół rozważy jej dodanie.

Ian Dunn
źródło
2

Cóż, jest to raczej punkt wyjścia, ale jest to miłe lista funkcji WP i wersje były dodawane / usuwane tutaj . Niestety, dotyczy to tylko WP 3.0.1, ale jeśli strzelasz do wersji 3.0 jako podstawy, to przynajmniej pomoże - jeśli nie ma jej na liście, została dodana później. Możesz wysłać Ozhowi wiadomość e-mail i poprosić go o aktualizację listy, a jeśli któryś z nas dostanie żart, ktoś może zrobić wtyczkę do sprawdzenia (np. Sprawdzanie wycofania ).

ETA: Per @mrwweb - Hook List Adama Browna ! Przejdź do wersji 3.3 i wraca do wersji 1.2.1, której nikt przy zdrowych zmysłach już nie uruchomi (data premiery 6 października 2004).

SickHippie
źródło
2
Dodałbym listę haczyków Adama Browna według wersji (z powrotem do 1.2.1!), Które również warto sprawdzić.
mrwweb,
Dziękujemy za link do wtyczki Deprecation Checker, która może dostarczyć przydatnego kodu do zbudowania, jeśli będę mieć czas na napisanie tego.
Ian Dunn
To genialna wtyczka autorstwa użytkownika WPSE Briana Fegtera.
SickHippie
0

Myślę, że odpowiedź leży w przestarzałych powiadomieniach - powinieneś rozwijać się z WP_DEBUG true - niezależnie od tego, czy je wyświetlasz, czy rejestrujesz, jest to wywołanie, ale WP powiadomi cię, jeśli użyjesz przestarzałej funkcji.

Można parsować @since, jak mówisz, ale narzędzia mogą zabrać cię tylko do tej pory - znajomość bazy kodu i ręczne sprawdzanie może być dobrym rozwiązaniem.

Chris Cox
źródło
1
Myślę, że odpowiedziałeś na odwrotność pytania. Pytanie ma na celu określenie, jak daleko sięga wsteczna obsługa obecnie obsługiwanych funkcji (np. Funkcja, której używa Twoja wtyczka, została wprowadzona w 3.1, więc wtyczka nie działa we wcześniejszych wersjach, ale ta funkcja nie generuje błędu ani powiadomienia ponieważ jest teraz obsługiwany.)
mrwweb
Masz rację, podaj mi, że jestem zmęczony. Następnie sugeruję ręczne sprawdzenie go w stosunku do ostatniej głównej wersji i użycie go jako dowolnego punktu wyjścia, ponieważ w interesie wszystkich leży zachęcenie użytkowników do aktualizowania WP. Po ustaleniu punktu początkowego komunikaty zatwierdzania są prawdopodobnie najlepszym miejscem do wyszukiwania w celu aktualizacji wersji Wymaganej, ponieważ należy tam odnotować wszelkie refaktoryzacje w celu uniknięcia przestarzałych funkcji i metod.
Chris Cox,
Patrząc na wordpress.org/about/stats powiedziałbym, że wersja 3.2 jest przyjemną wersją do strzelania, ponieważ wszelkie wcześniejsze wersje są nieistotne statystycznie.
Chris Cox,
Dzięki za pomysły, Chris, ale głównym impulsem było znalezienie zautomatyzowanego rozwiązania. Warto jednak zauważyć, że wersje starsze niż 3.2 są statystycznie nieistotne.
Ian Dunn
Zrobię ci umowę - daj mi znać, jeśli zrezygnujesz i napiszesz jedną, a dam ci znać, jeśli zabiorę się do napisania jednej. To dobry pomysł i byłby przydatnym narzędziem w czyimś zestawie narzędzi.
Chris Cox,