Uwaga: ta odpowiedź jest właśnie tutaj, aby ułatwić dyskusję między @scribu a @kaiser. Mody: Proszę nie usuwać. Użytkownicy / czytelnicy: Proszę nie głosować. Jeśli chcesz śledzić dyskusję, zajrzyj do dziennika zmian / edycji. Jeśli chcesz dołączyć do dyskusji, edytuj odpowiedź. Jeśli dyskusja przyniesie wynik, zostanie oznaczona jako taka. Dziękuję Ci.
Scenariusze
Istnieją również różne scenariusze, które różnią się wagą, w których można mieć zależność od wtyczek. (Przykłady są tylko fikcyjne). Słowo „(nadrzędny) Plugin” można zamienić na „Theme” z nadrzędnego punktu widzenia.
- (trudny) Wtyczka podrzędna, która jedynie rozszerza funkcjonalność lub zmienia wyświetlanie (i podobne) istniejącej wtyczki i dlatego nie może istnieć bez elementu nadrzędnego. Przykład: BuddyPress »BuddyPress-FunkyCommentDisplay
- (normalny) Wtyczka o rozszerzonej funkcjonalności, gdy aktywowana jest wtyczka potomna. Przykład: jQueryAttachmentCarousel »jQuerySlideDeck
- (miękki) Wtyczka, która po prostu dodaje funkcję. Przykład: DisneyWonderlandTheme »MickeysSocialLinks
Poniżej próbuję naszkicować, co się stanie, gdy zaktualizujesz „inną” wtyczkę, a sprawdzenie już nie działa.
- Ad 1) Wtyczka nie mogła istnieć bez aktywacji BuddyPress »Rzeczy są całkowicie zepsute.
- Ad 2) Wtyczka nie mogła zaoferować opcji przełączenia z karuzeli na SlideDeck »Wyświetlacze przewodowe (zakładam, że style zostały zmodyfikowane do SlideDeck).
- Ad 3) MickeysSocialLinks znikają.
Czek
Istnieją trzy możliwości sprawdzenia, czy chcesz wiedzieć, czy wtyczka jest aktywna:
- A. Czy folder istnieje?
- B. Czy plik główny - opcja
'active_plugins'
- istnieje?
- C. Czy istnieje określona funkcja?
Jeśli teraz wezmę przykład mojej wtyczki Internal Link Checker , która nie oferuje publicznego interfejsu API i nie jest przeznaczona do rozszerzenia, nie widzę powodu (jako autora), aby nie zmieniać nazewnictwa funkcji wewnętrznych na żądanie lub po prostu . Więc jeśli ktoś spróbuje zastosować piggyback na tej wtyczce, wtedy rzeczy po prostu się zepsują (w zależności od funkcjonalności i szczelności pakowania) podczas aktualizacji. To samo dotyczy nazw plików. Nie miałbym żadnego prawdziwego powodu (poza tym, że wtyczka zostałaby dezaktywowana podczas aktualizacji), aby nie zmieniać nazwy pliku. Jedyną rzeczą, która powstrzymałaby mnie przed zmianą nazwy folderu jest to, że sprawdzanie aktualizacji i powiadomienie działa z nazwą pliku - jeśli jest przechowywany w oficjalnym repozytorium.
Powiedziałbym więc, że od najsłabszej (łatwej do zmiany) do najtrudniejszej (dużo mówi się przeciwko zmianie) części (macierzystej) wtyczki byłoby:
funkcja »nazwa głównego pliku» folder
Kiedy powiedziałem, że sprawdzanie funkcji jest mniej kruche niż używanie is_plugin_active()
, założyłem, że dana funkcja jest tą, którą autor wtyczki wyraźnie zachęca. Ostatecznym tego przykładem jest wp_pagenavi()
tag szablonu oferowany przez wtyczkę WP-PageNavi.
Trudność w definiowaniu zależności polega na tym, że nie ma standardowego sposobu jednoznacznej identyfikacji wtyczek, które nie wymagają nazw plików.
Więcej przemyśleń na ten temat:
http://wordpress.org/support/topic/plugin-plugin-dependencies-unreliable-plugin-namingidentifying-scheme
Myślę, że do tej pory możemy to podsumować w trzech punktach:
- Rozmawialiśmy o nieco innych tematach
- Zgadzamy się, że nie ma kuloodpornego sposobu na obejście tego, co według mnie byłoby tematem
- Z twojego zrozumienia pytania zaoferowałeś właściwą drogę
(Jak dotąd) najmądrzejszy sposób, w jaki mogę myśleć, że widziałem już w (o wiele za mało) wtyczkach:
// inside the plugin file:
add_action( 'plugin_custom_hook', 'plugin_trigger' );
// inside some template:
do_action( 'plugin_custom_hook' );
Nie zastanawiając się nad tym zbyt szczegółowo, ale myślę, że możesz podpiąć uwagę do filtra „wszystko” i sprawdzić w filtrze prądu, jeśli został on uruchomiony, gdy jesteś na shutdown
haku…?
Używanie haków działałoby dobrze w przypadku „normalnych” i „słabych” zależności. Jedyną wadą jest to, że nadal będziesz musiał skorzystać function_exists()
lub is_plugin_active()
jeśli chcesz przestać, jeśli zależność nie zostanie spełniona. Zastosowanie do tego filtru „wszystko” byłoby zbyt drogim IMO.
@scibu To było skierowane na „twój” temat. (Upuściłem już mówiąc o moim). :)
Zasadniczo, jeśli potrzebujesz zależności - a masz miłego autora - może zaoferować hak zamiast / jako zamiennik tagu szablonu. Ponieważ wtyczka zaczepiłaby się tylko, gdyby haczyk był obecny lub po prostu nic nie zrobił. Z drugiej strony nie byłoby błędu, gdy wtyczki nie były obecne.
Oto trudna część (lub więcej pytań): Aby napisać powiadomienie administratora, aby poinformować użytkownika o zależności „Musisz zainstalować» DisneyWonderLinks «”, możesz to sprawdzić array_keys( $GLOBALS['wp_filter']['template_tag_like_hook'] )
. Nie jestem pewien, czy to zadziała, ale afaik powinien być dostępny po obu stronach (publicznej / administracyjnej).
To by nie działało. To, że oddzwanianie jest zarejestrowane na przechwytywaniu, nie oznacza, że przechwytywanie zostanie uruchomione zgodnie z oczekiwaniami. Jedyną rzeczą, która byłaby swego rodzaju pracą, jest użycie haka „zamykania”, o którym wspominałeś wcześniej:
add_action( 'shutdown', function() {
if ( !did_action( 'template_tag_like_hook' ) )
echo 'Problem.';
} );
Oczywiście byłoby to wydrukowane na samym dole, po </html>
znaczniku, na froncie (ponieważ tam zwykle używane są znaczniki szablonów), co nie jest zbyt użyteczne.
Możesz spróbować zapisać wiadomość w wp_options, a następnie wyświetlić ją w obszarze administracyjnym, ale otworzy to zupełnie nową puszkę robaków: unieważnienie, buforowanie wtyczek itp.
function_exists
, zwykły użytkownik po prostu otrzyma wiadomość, że nie zainstalował wtyczki, na której opiera się inna wtyczka. Problem polega na tym, że użytkownik rzeczywiście będzie mieć zainstalowane wtyczki, a następnie po prostu zastanawiam się, dlaczego to doens't pracy . Och, i nie zamierzam cię za to głosować.