Używanie haków WordPress do czyszczenia kodu, aktywacji i odinstalowywania
Opublikowany: 2015-01-23Twórcy wtyczek poświęcają tyle czasu i energii na główną funkcjonalność swoich produktów, że pozwalają odejść mniej ważnym rzeczom.
Weźmy na przykład aktywację i dezaktywację. Chociaż podpięcia aktywacji są szeroko rozpowszechnione – wiele wtyczek wymaga dodania pewnych opcji, opróżnienia reguł przepisywania, może utworzenia tabeli bazy danych lub sprawdzenia różnic wersji podczas instalacji – podpięcia dezaktywacji i deinstalacji są znacznie mniej powszechne.
O co tu chodzi? Wielu autorów wtyczek nie poświęca czasu na sprzątanie po sobie. Czy instalacja WordPressa naprawdę potrzebuje niestandardowej tabeli, którą utworzyłeś po usunięciu wtyczki? Dlaczego nie wyczyścić kilku opcji, które są wyłączne dla wtyczki, zanim ją wyrzucisz?
W tym artykule pokażę, jak używać haków aktywacji, dezaktywacji i dezinstalacji, aby zainicjować wtyczkę i łatwiej wyczyścić wszystko po tym, jak użytkownicy skończą z produktem.
- Hak aktywacyjny
- Sekwencja instalacji
- Flushing Rewrite Rules
- Tworzenie tabel bazy danych
- Kontrole zależności
- Hak dezaktywacyjny
- Hak dezinstalacyjny
- Dodatkowe zabezpieczenia
- Czas posprzątać
Uwaga: jeśli planujesz przejrzeć ten artykuł, zdecydowanie sugeruję zajrzeć do sekcji „Dodatkowe zabezpieczenia” na końcu, która uzupełnia kod o kilka cennych kontroli bezpieczeństwa. Ponadto, jeśli potrzebujesz pomocy z hakami wtyczek WordPress, oto krótkie przypomnienie o korzystaniu z haków WordPress i jak aktywować funkcję w WordPress.
Hak aktywacyjny
Chociaż hak aktywacji jest dość prosty, jego instalacja jest trochę szczególnym przypadkiem, więc musimy zwrócić uwagę na kolejność zdarzeń. Zanim przejdziemy do tego wszystkiego, oto prosty przykład:
Kluczem do tego wszystkiego jest funkcja register_activation_hook() . Pierwszy parametr to ścieżka do głównego pliku wtyczki; drugi parametr definiuje funkcję do uruchomienia. Wewnętrznie funkcja register_activation_hook() jest opakowaniem dla akcji „activate_[nazwa_wtyczki]”, ale ponieważ jest nieco łatwiejsza w użyciu, rzadko można zobaczyć zaczep we wtyczkach.
Sekwencja instalacji
Zrozumienie kolejności instalacji jest ważne, ponieważ zapobiega używaniu metod, do których możesz być przyzwyczajony. register_activation_hook() jest wywoływana pomiędzy kliknięciem przez użytkownika linku aktywacyjnego i wyświetleniem powiadomienia o aktywacji. Działa na stronie pośredniczącej, która przekierowuje bezpośrednio przed uruchomieniem jakichkolwiek podpięć.
Spójrzmy na przykład, aby zobaczyć, dlaczego jest to ogromny błąd:
Flushing Rewrite Rules
Wiele wtyczek tworzy niestandardowe typy postów. Opróżnienie reguł przepisywania przy aktywacji, aby upewnić się, że użytkownicy nie otrzymają błędu 404 podczas odwiedzania wpisu z nowego niestandardowego typu wpisu, jest mądrym posunięciem.
Poniższy kod wydaje się logiczny, ale nie powiedzie się.
Wydaje się, że jest w porządku. Tworzony jest niestandardowy typ posta, a po aktywacji usuwamy reguły przepisywania. Problem polega na tym, że niestandardowe typy postów nie zostały jeszcze utworzone, gdy opróżniamy reguły przepisywania.
Oto jak wygląda przebieg procesu:
- Użytkownik instaluje wtyczkę.
- Użytkownik klika link aktywacyjny.
- Strona pośrednia uruchamia tylko hak aktywacyjny, nic więcej. To opróżnia zasady przepisywania.
- Wtyczka jest aktywna, a kod działa normalnie. Zarejestrowano niestandardowy typ poczty.
Rozwiązanie zamieszczone na Stack Overflow, oficjalnie zatwierdzonym przez WordPress Codex, rozwiązuje nasz mały problem. Rozwiązanie polega na dodaniu opcji wskazującej, że wtyczka została właśnie zainstalowana.
Jeśli ta opcja istnieje, wykonujemy naszą aktywację, a następnie ją usuwamy.
Coś takiego:
Osobiście nie przepadam za tym rozwiązaniem. Problem polega na tym, że sprawdzanie w wierszu ósmym jest uruchamiane przy każdym załadowaniu strony. Nie ma się czym martwić, ponieważ nie spowoduje to dużego obciążenia serwerów i nie spowolni działania witryny dla użytkowników. To bardzo szybkie sprawdzenie, które ma znikomy wpływ na wydajność. W 99,9% przypadków jest to jednak niepotrzebne.
Jest lepsze rozwiązanie wspomniane w Kodeksie w dokumentacji funkcji flush_rewrite_rules() . W tym rozwiązaniu wykorzystujemy modułowość naszych funkcji, aby osobno zarejestrować niestandardowy typ postu przy aktywacji:
Zamiast polegać na sprawdzaniu, które musi być uruchamiane przez cały czas, używamy funkcji aktywacji, aby zarejestrować nasze typy postów. Zauważ, że gdy nasza wtyczka zostanie aktywowana, typy postów będą zawsze rejestrowane z haka init .
To smutny przykład tego, że Kodeks jest wszędzie. Ogólnie rzecz biorąc, WordPress ma dobrą dokumentację, ale jeśli coś wydaje się marnotrawne lub nielogiczne, nie bój się przeprowadzić własnych badań.
Tworzenie tabel bazy danych
Innym zadaniem, które wykonują niektóre wtyczki, jest tworzenie tabel bazy danych. Najczęściej jest to niepotrzebne, ale istnieją pewne uzasadnione przypadki użycia.
Ten przykład z artykułu Codex na temat tworzenia tabel pokazuje, jak można użyć wielu wywołań aktywacji:
Pierwsza funkcja, jal_install() , tworzy nową tabelę bazy danych. Druga funkcja, jal_install_data , dodaje początkowe dane do tabeli. Zamiast używać register_activation_hook() do dodania jednej funkcji zawierającej cały ten kod, możemy wielokrotnie użyć register_activation_hook .
To świetna praktyka modułowości. Z jednej strony nie musisz dodawać początkowych danych testowych – to tak proste, jak usunięcie haka aktywacyjnego – dzięki czemu możesz zachować funkcję nienaruszoną. Z drugiej strony możesz ponownie używać tych funkcji w dowolnym miejscu, ponieważ są one oddzielne.
Kontrole zależności
Innym częstym zadaniem funkcji aktywacji jest sprawdzenie zależności. Twoja wtyczka może polegać na określonej wersji WordPressa, innej wtyczce, a nawet określonej wersji PHP.
Poniższy kod sprawdza minimalną wersję WP i PHP i w razie potrzeby przekierowuje użytkownika (bez aktywacji wtyczki):
Hak dezaktywacyjny
Podpięcia dezaktywacji działają, gdy użytkownik dezaktywował wtyczkę, ale przed jej odinstalowaniem (usunięciem). Haki dezaktywacyjne są używane w taki sam sposób jak haki aktywacyjne:
Dezaktywacja oznacza, że użytkownik dezaktywował tylko twoją wtyczkę, więc nie będziesz chciał robić tak dużo, jak podczas dezinstalacji. Być może będziesz chciał opróżnić reguły przepisywania, ale na tym etapie nie będziesz chciał pozbyć się wszystkich opcji i tabeli bazy danych (jeśli ją masz).
Jest to dość proste, ale zwrócę szczególną uwagę na opróżnianie reguł przepisywania, ponieważ po raz kolejny są one problematyczne.
Kodeks zaleca wykonanie ich w sposób pokazany poniżej, ale to nie działa :
Powód, dla którego to nie działa, jest taki sam jak wcześniej. Uruchomienie dezaktywacji wykonuje zaczep init , co oznacza, że gdy dezaktywujemy naszą wtyczkę, rejestrujemy również nasz niestandardowy typ postu. Reguły przepisywania są opróżniane, ale uwzględniają niestandardowy typ posta.
Bilet Traca jest na miejscu, aby rozwiązać ten problem, ale do tego czasu nie mogę dać ci bardzo dobrego sposobu na zrobienie tego. Jedynym sposobem, w jaki znalazłem, że działa, jest całkowite usunięcie reguł przepisywania:
Chociaż działało to dla mnie w przeszłości, nie polecam tego. Wprowadza to większą niepewność niż problem posiadania kilku dodatkowych reguł przepisywania. Wolałbym wyświetlać notatkę użytkownikom z prośbą o odwiedzenie ustawień permalink po dezaktywacji, co spowodowałoby usunięcie reguł przepisywania. Dopóki nie zostanie wdrożone lepsze rozwiązanie, utkniemy z tym… przepraszam!
Hak dezinstalacyjny
Istnieją dwa sposoby uruchamiania kodu podczas odinstalowywania wtyczki. Możesz użyć haka dezinstalacyjnego poprzez register_uninstall_hook() lub możesz użyć dedykowanego pliku uninstall.php w swojej wtyczce. Pokażę ci oba, ale preferowaną metodą jest użycie pliku odinstalowującego.
Główny problem z hakiem dezinstalacji polega na tym, że „uniemożliwia uruchamianie głównego pliku wtyczki podczas deinstalacji, co może być problematyczne, jeśli wtyczka uruchamia kod w przestrzeni globalnej. Lepsze jest również to, że kod dezinstalacyjny jest scentralizowany”. – Scott Riley
Poniższy kod pokazuje proces deinstalacji przy użyciu podstawowego haka:
Jak wspomniano, nie jest to najlepsze rozwiązanie. O wiele lepszym sposobem obsługi dezinstalacji jest użycie pliku uninstall.php . Wszystko, co musisz zrobić, to go utworzyć i będzie używany, jeśli będzie dostępny.
Jak widać, jest to właściwie prostsze rozwiązanie. A co najlepsze, jest samowystarczalny.
Dodatkowe zabezpieczenia
Nie chciałem nadmiernie komplikować pokazanych dotąd przykładów kwestiami związanymi z bezpieczeństwem, ale naprawdę powinieneś podjąć pewne kroki, aby upewnić się, że tylko ci, którzy są do tego uprawnieni, mogą wykonywać te działania.
Użyj poniższego fragmentu kodu podczas aktywacji i dezaktywacji:
Ten blok kodu zapewnia, że użytkownik ma uprawnienia do wykonania tej akcji i że akcja pochodzi z odpowiedniej strony. Powinno to chronić przed większością złośliwych prób.
Proces dezinstalacji jest wyjątkowy, więc będziemy musieli użyć nieco innego kodu:
Czas posprzątać
Jeśli twoja wtyczka dodaje coś do WordPressa, Twoim obowiązkiem jako programisty jest usunięcie go, gdy użytkownik zdecyduje się usunąć wtyczkę.
Korzystanie z opisanych powyżej metod aktywacji, dezaktywacji i dezinstalacji pozwoli Ci zbudować system, który robi to bezpiecznie i bezpiecznie. Gorąco polecam również przeczytanie tego wątku Stackexchange, który opisuje te procesy w środowiskach OOP.
Jeśli nie jesteś jeszcze członkiem WPMU DEV, zarejestruj się już dziś, aby uzyskać bezpłatną wersję próbną, całkowicie bez ryzyka. Jako członek uzyskasz dostęp do wszystkich naszych wspaniałych wtyczek i niesamowicie szybkiej usługi hostingowej, a także specjalistyczną pomoc techniczną 24/7 w przypadku wszystkich pytań i problemów związanych z WordPressem.
Tagi: