Jeśli korzystasz z WordPressa i zależy Ci na większej kontroli, automatyzacji lub bezpieczeństwie – koniecznie poznaj Must-use plugins, czyli specjalny typ wtyczek, których nie da się wyłączyć z poziomu panelu admina. W najnowszym odcinku podcastu wyjaśniam, czym są MU Plugins, jak działają, gdzie je umieścić i w jakich sytuacjach mogą uratować Twoją stronę. Opowiadam też, jak sam wykorzystuję je w migracjach i codziennej pracy. 🎧 Sprawdź ten odcinek – gwarantuję, że znajdziesz coś dla siebie: zarówno jeśli jesteś deweloperem, jak i administratorem WordPressa!
🎁 Partner odcinka: CyberFolks
Z kodem podcast otrzymasz 20% zniżki na hosting WordPress.
Podcast dostępny m.in w: Spotify, Apple Podcasts, Google Podcasts
TRANSKRYPCJA AUTOMATYCZNA:
Cześć, witam Cię w kolejnym odcinku podkastu. Dzisiaj porozmawiamy o wtyczkach, ale nie o takich zwykłych wtyczkach, a o wtyczkach, których nie można wyłączyć. Być może jeszcze nie słyszałeś o tym rodzaju wtyczek, więc w tym odcinku postaram się przybliżyć ten temat, opowiedzieć jak to działa, do czego może Ci się przydać i czy zawsze to jest dobry pomysł. Zanim jednak przejdziemy do tematu odcinka, chwila dla partnera mojego podkastu, czyli marki Cyberfolks, od której możecie kupić domenę bądź hosting pod swojego WordPressa. Z kodem podcast macie 20 % rabatu na usługę hostingu WordPress. Przejdźmy do tematu odcinka. To jak działają wtyczki w WordPressie myślę, że wszyscy wiedzą i bardzo zaawansowani użytkownicy i ci zupełnie początkujący wiedzą, że jeśli potrzebujemy coś, to idziemy do zakładki wtyczki, szukamy sobie jakiejś wtyczki, instalujemy i mamy dodatkową funkcję w naszym WordPressie. Natomiast co to są wtyczki tzw. Must-use Plugins? To są takie wtyczki, których się nie da wyłączyć.
Działa to w ten sposób, że te wtyczki pojawiają się w zakładce wtyczki w panelu administracyjnym i tam jest taka specjalna zakładka wymuszane w polskiej wersji językowej WordPressa i możecie tam zobaczyć kilka pozycji, ale nie zobaczycie przy nich przycisków typu wyłącz czy usuń, bo to są wtyczki, no zresztą jak sama nazwa wskazuje, use, czyli takie, których musicie używać. A przynajmniej ktoś kto dodał tą u w tamtym miejscu. Tak jak już powiedziałem, podstawową różnicą w stosunku do takich zwykłych WordPress’owych wtyczek jest to, że nie możemy nimi zarządzać z poziomu panelu administracyjnego, co za tym idzie. Nie możemy sobie ich tak po prostu włączyć czy wyłączyć, czy dodać właśnie z poziomu panelu, czy to z repozytoriumu WordPressa, czy na przykład z dysku z pliku zip.
Te wtyczki są ładowane w taki dosyć specyficzny sposób, ponieważ tak jak wszystkie zwykłe wtyczki są trzymane w katalogu WP Content Plugins, to te wtyczki Must-use są trzymane w takim katalogu MU Myślnik Plugins. To jest oczywiście domyślna lokalizacja tych MU Plugins. Za pomocą odpowiedniej stałej można ten katalog, tą ścieżkę do tych wtyczek Must-use zmodyfikować na jakąś customową jeśli zachodziłaby taka potrzeba. Jeśli w twojej wersji WordPressa nie ma takiego katalogu to wystarczy, że go po prostu stworzysz i dodasz tamte wtyczki. Kolejną istotną różnicą, która jest w stosunku do zwykłych wtyczek to to, że WordPress i mechanizm tych Must-use Plugins działa w taki sposób, że ładowane są wszystkie pliki z katalogu Must-use Plugins. I tutaj też mała uwaga. Jeśli mamy kilka wtyczek małych, jednoplikowych, które realizują bardzo proste rzeczy typu dodanie stałych do WordPressa czy dodanie kilku akcji, huków, filtrów itd. to zwykle nie jest to problem, że one są w pojedynczych plikach. Natomiast gdybyśmy mieli jakąś większą wtyczkę, która zawiera jeszcze np. jakieś dodatkowe biblioteki czy coś takiego. No trochę ciężko byłoby to trzymać wszystko w jednym katalogu, bo tak czysto organizacyjnie trudno byłoby się w tym połapać. Wtedy można to obejść w taki sposób, że robimy sobie taki krótki plik PHP-owy, który po prostu skanuje nam katalogi w tym katalogu.mu.pl i tam ładujemy poszczególne z pomocą tego jednego pliku, który jest załadowany automatycznie przez WordPressa. I w ten sposób możemy sobie to obsłużyć.
A jeśli są to proste rzeczy to tak jak powiedziałem wystarczy, że po prostu wrzucimy tam plik PHP. Co ciekawe ten plik nawet nie musi mieć tej standardowej sekcji nagłówkowej, takiego komentarza PHPowego, którym zawarte są takie rzeczy jak choćby nazwa, wtyczki, wersja, informacje o autorze, o linku do strony wtyczki. Może być to po prostu zwykły plik PHPowy. I wtedy na liście wtyczek zamiast jakiejś takiej ładnej nazwy wyświetli wam się nazwa tego pliku, czyli jeśli byśmy wrzucili do EMU Plugins wtyczkę załóżmy abc.php i może być to nawet pusty plik, to już na liście wtyczek w WordPressie w panelu normalnie zobaczycie taką pozycję jak abc.php.
Kolejną bardzo istotną różnicą wynikającą właśnie bezpośrednio z tego, że te pliki są ładowane bez pośrednictwa bazy danych jest to, że to jest sporo szybsze niż ładowanie pozostałych wtyczek i też w całej sekwencji uruchamiania poszczególnych akcji w WordPressie załadowanie tych plików z Must-use Plugins następuje bardzo, bardzo szybko, ponieważ te pliki podczas uruchomienia WordPressa de facto, no bo jeśli wchodzimy na stronę, no to cała ta sekwencja jest wykonywana za każdym razem od początku. No to tam wtedy działa to w ten sposób, że te wtyczki z Must-use Plugins są ładowane przed wtyczkami, które działają normalnie w WordPressie, przed tym jak zostanie załadowany kod z motywu, między innymi z pliku Functions.php, przed tym jak są rejestrowane taksonomie, post-typy.
Więc to jest zainicjalizowane na takim bardzo, bardzo wczesnym etapie uruchomienia WordPressa, co daje nam też dosyć duże możliwości w kwestii modyfikacji jego zachowania. Czy to właśnie przez standardowe mechanizmy hooków, filtrów akcji i tak dalej, czy ewentualnie przez zmiany zachodzące za pomocą definicji odpowiednich stałych w WordPressie, które determinują różne aspekty działania tego WordPressa, choćby takie rzeczy jak przechowywanie określonej ilości rewizji wpisów, czy wyłączenie edytora plików wtyczki, czy plików motywu z poziomu WP-admina. To wszystko można zrobić też w WP-konfigu, ale ma to pewne ograniczenia, a o tym powiem troszkę później. Jeśli chcemy jeszcze mieć wpływ na to w jakiej kolejności załadują się te nasze Must-use plugins, no to najprostszym sposobem jest uszeregowanie nazw tych plików w sposób alfabetyczny, bo WordPress ładuje je po prostu w kolejności alfabetycznej. Więc jeśli kod, który się tam znajduje w jakiś sposób zależy jeden od drugiego i jeden kod musi się załadować wcześniej niż inny, no to najprostszą metodą na to jest uszeregowanie tego…
Za pomocą nazw plików w kolejności alfabetycznej i w takiej kolejności też WordPress załaduje nam te pliki. I tak jak już wcześniej padło w tym odcinku, ogólna filozofia i zasada działania można powiedzieć tych Must-use plugins jest taka, że to powinny być rzeczy, które zawsze muszą działać w danym WordPressie, w danym wdrożeniu. Zawsze, no to znaczy zawsze pod takim względem, że wyłączenie danej wtyczki powodowałoby na przykład wywalenie się całej strony. Czasem zdarzają się, szczególnie przy jakichś bardziej skomplikowanych, bardziej złożonych wdrożeniach, takie elementy, które są krytyczne dla działania całego systemu i dosłownie bez nich cała strona przestaje działać, przestaje funkcjonować, bo jest to jakiś taki krytyczny element danego wdrożenia i wtedy te Must-use Plugins to jest odpowiednie miejsce, żeby coś takiego załadować, tam trzymać. Tutaj też sobie zapewniamy takie bezpieczeństwo pod tym względem, że nikt gdzieś tam przez przypadek nie kliknie nam i nie wyłączy tej wtyczki, przez co cała strona mogłaby się nam posypać. Kilka innych takich, można powiedzieć, dosyć standardowych zastosowań to jest właśnie albo dołączenie jakichś bibliotek, które muszą być ładowane w WordPressie, bo są potrzebne gdzieś tam w innych miejscach czy zmuszanie odpowiednich zachowań naszego WordPressa choćby właśnie przez te opcje konfiguracyjne dostępne za pomocą definicji stałych, choćby takie jak wcześniej wspomniana edycja plików przez kokpit, czyli możemy sobie zablokować tę edycję, możemy wymusić jakieś konkretne zachowania jeśli chodzi o konkretną ilość rewizji, która jest przechowywana w bazie danych.
Możemy na tym etapie zdefiniować sobie jakieś dodatkowe formaty zdjęć w bibliotece mediów. Wszystko co jest takie można powiedzieć globalne z punktu widzenia działania tego WordPressa, konkretnej instalacji. Często gdzieś tam jeśli to jest powiedzmy jakaś grupa stron, która ma część wspólną być może to będzie grupa stron firmowych czy tam grupa stron marek jednej jakiejś większej firmie jakiegoś holdingu, to często takie wspólne rzeczy wydziela się właśnie do czegoś takiego co można wrzucić do Must-use Plugins. Wszystkie rzeczy związane z bezpieczeństwem, z hardeningiem WordPressa, czyli choćby takie najprostsze rzeczy jak ukrywanie wersji WordPressa, czy wycinanie z assetów właśnie tej wersji, która jest tam przypisywana automatycznie.
Tutaj też pomocne może być to przy ograniczeniu pewnych praw, które nie do końca możemy ograniczyć, na przykład za pomocą tego standardowego mechanizmu roli WordPressowych, bo czasem jest potrzeba, że musimy dać komuś dostęp do konta administratora, ale niekoniecznie chcemy mu dać dostęp do wyłączania funkcji. I tu właśnie te Must-use plugins sprawdzą się świetnie, bo jak wcześniej powiedziałem nie można wyłączyć takiej wtyczki przez panel, tylko przez bezpośredni dostęp do plików na serwerze. Musimy po prostu ten plik albo usunąć, albo przenieść go w inną lokalizację, taką z której automatycznie nie zostanie wczytany. Również jakieś rzeczy związane z logowaniem błędów. Możemy sobie ustawiać jakieś customowe ścieżki do debug loga. Takie rzeczy, które na co dzień się mogą przydać. Szczególnie jeśli pracujemy na wielu stronach chcemy wprowadzić sobie jakąś standaryzację tego, to takie wtyczki świetnie się do tego sprawdzają.
Ja osobiście bardzo często korzystam z tego mechanizmu w sytuacjach, których przygotowuję jakieś takie większe migracje. I w zasadzie w tym momencie jestem w trakcie opracowywania takiej procedury migracji strony w zasadzie takiego systemu opartego WordPressa, gdzie między innymi są wysyłane duże ilości maili i również jest interakcja z jakimiś tam zewnętrznymi systemami, choćby właśnie z MailerLitem, gdzie na bazie jakichś tam triggerów w WordPressie są ustawiane odpowiednie grupy dla konkretnych użytkowników w MailerLite. I w momencie, którym ja teraz pracuję nad tym, przygotować sobie całą procedurę migracji, skrypt migracyjny, który po prostu raz odpalony przeprowadzi mi cały proces, no to muszę pamiętać o tym, że jeśli ja kopiuję bazę danych i tam są jakieś zadania w WP-Kronie ustawione, to one się wykonają i w efekcie tego klient dostanie jakiegoś maila. Ale ten mail będzie kierował do jakiejś domeny, nowej, docelowej, której jeszcze klienci na tym etapie nie powinni wiedzieć. Więc jednym z takich standardowych pluginów, które sobie wrzucam w takiej automatyzacji jest przekierowanie wszystkich maili wychodzących z WordPressa na mój adres. Czyli nawet jeśli coś by się tam strigerowało i ten mail został wysłany teoretycznie do klienta na jakiś adres klienta tej strony, no to nie jest to żaden problem, bo za pomocą odpowiedniego hooka ja te maile wszystkie sobie łapię i przekierowuję elegancko na swój adres mailowy, przez co również mogę wykonywać sobie różne testy i wiem, że klient końcowy nie dostanie żadnego powiadomienia. W ten sam sposób mogę sobie np. wyłączyć tą integrację z Mailer Lite’em czy ewentualnie jakąś tam zmodyfikować jej zachowanie tak, aby właśnie nie wpływała na te produkcyjne dane.
I właśnie z tego względu, że to jest narzędzie i mechanizm na tyle prosty, że wystarczy wrzucić plik do odpowiedniego katalogu i on jest już wczytywany przez WordPressa i wykonywany, no to to się świetnie sprawdza przy wszelkich automatyzacjach. Czy to właśnie za pomocą jakiegoś skryptu, tak jak ja buduję to teraz, gdzie buduję sobie po prostu takie narzędzie oparte o AirSync, jakiegoś tam MySQL dumpa. SSH itd. wszystkie takie standardowe narzędzia, można powiedzieć taki standardowy zestaw narzędzi przydatnych przy emigracji strony no to również mogę za pomocą WPCLI wykonywać pewne rzeczy oczywiście mógłbym też taką wtyczkę instalować za pomocą WPCLI aktywować ją itd. to też nie jest problem kiedyś też tak robiłem natomiast to Must-use plugins są na tyle fajne że po prostu wrzucasz pliki, Cię nic więcej nie interesuje stan bazy danych no bo musimy pamiętać że, tym tradycyjnymi wtyczkami tak naprawdę zarządza baza danych w takim rozumieniu, to czy wtyczka jest włączona czy nie, czy ona jest wykonywana zależy od tego jak to zostało zapisane w konfiguracji bazy danych. A tutaj wrzucamy i mamy pewność, że zawsze ta wtyczka zostanie wykonana, że ten kod, który tam wrzucimy będzie wykonany i nie będzie tu żadnego problemu takiego, że mieliśmy ten kod wrzucony, ale on się nie wykonał, bo wgraliśmy np. jakąś inną wersję bazy danych, gdzie ta wtyczka była wyłączona, bo nie w ogóle nie było w tym warto jeszcze tutaj zwrócić uwagę na jeden aspekt, czyli na aktualizację takich wtyczek ze względu na to, że one nie są dostępne w żaden sposób przez panel WordPressa czy przez repozytorium WordPressowe. No aktualizacja takich wtyczek musi nastąpić ręcznie. Ręcznie w takim rozumieniu, że musimy zmienić te pliki po prostu bezpośrednio na serwerze, a czy robimy to faktycznie ręcznie przez FTP, SSH czy jakimiś tam innymi metodami.
Czy jest to element całego automatycznego procesu deploy’u za pomocą np. GitHub Actions czy jakichś pipeline’ów bitbucketowych. To już ma mniejsze znaczenie. Chodzi o to, żeby coś tam zmienić w kodzie, to musimy podmienić ten plik na serwerze bezpośrednio. Myślę, że nakreśliłem Ci mniej więcej zasady działania tego wszystkiego. Podrzuciłem też parę pomysłów na to jak można te Must-use plugins wykorzystać. Jakie mają wady, jakie zalety. Podsumujmy jeszcze to krótko. Zalety zawsze są aktywne. Nie da się ich wyłączyć. Ten punkt może być potraktowany zarówno w jednej jak i w drugiej kategorii. Ale wszędzie tam gdzie zależy nam na tym żeby jakiś użytkownik nawet z prawami administratora nie wyłączył pewnych rzeczy to Must-use Plugins są idealnym rozwiązaniem. Są szybciej się ładują, ze względu na to, że są ładowane bezpośrednio z pliku, bez udziału bazy danych. Są też ładowane na bardzo wczesnym etapie. Są świetne dla wszystkich DevOpsów, bo bardzo prosto można sobie utrzymywać pewne rzeczy w takim stanie między różnymi stronami. Bardzo łatwo się to automatyzuje, bo praktycznie tak jak mówię nie trzeba nic robić poza tym, żeby wrzucić kawałek kodu do pliku, odpowiedniego katalogu i już, i WordPress już sobie z tego tutaj do wad zaliczyłbym, że jeśli coś się nam wysypie, przykład, no to bez dostępu do serwera na takim poziomie, gdzie możemy zarządzać plikami, no niestety nie jesteśmy w stanie nic zrobić. I tak samo jeśli nie znamy projektu, a byłyby tam jakieś Must-use Plugins, to możemy na pierwszy rzut ocha nie zauważyć, że oprócz tej listy wtyczek standardowej, którą mamy, jest tam jeszcze ta zakładka wymuszana i możemy mieć jakieś tam niestandardowe zachowanie WordPressa i nie do końca będziemy wiedzieć skąd ono się bierze, a to właśnie może być działanie MassDusePlugin.
