WordPress Playground: bezpieczne testowanie WordPressa bezpośrednio w przeglądarce

Jak właściwie sklasyfikować WordPress Playground

WordPress Playground uruchamia izolowana instancja WordPressa bezpośrednio w przeglądarce. Bieżąca instalacja jest oddzielona od istniejącej strony internetowej: zmiany w wpisach, ustawieniach, motywach lub wtyczkach nie mają wpływu ani na hosting, ani na bazę danych działającej strony. W tym celu niezbędne komponenty są ładowane do przeglądarki i tam uruchamiane.

Rozwiązanie to nadaje się do wstępnego sprawdzenia wtyczki przed instalacją, do zapoznania się z motywem blokowym lub do stworzenia przejrzystej prezentacji podczas rozmowy z klientami i redakcją. Możesz skorzystać z czystego środowiska, aktywować rozszerzenia i sprawdzić, czy interfejs użytkownika oraz jasno zdefiniowana funkcja podstawowa działają w sposób zrozumiały. Zwłaszcza w przypadku komunikatów o konfliktach pusta instancja pomaga na początku wykluczyć problemy wynikające z istniejącej strony.

Playground nie jest jednak zwykłym środowiskiem testowym. System testowy powinien w idealnym przypadku jak najdokładniej odzwierciedlać przyszłą konfigurację serwera i procesy operacyjne; Playground służy natomiast przede wszystkim do szybkiego przeprowadzania testów w oddzielnym środowisku przeglądarki. Wnioski dotyczące zachowania konkretnej konfiguracji serwera, bazy danych lub hostingu wymagają zatem dodatkowego testu w środowisku docelowym, które jest jak najbardziej zbliżone do rzeczywistego.

W ten sposób WordPress działa bezpośrednio w przeglądarce

Za WordPress Playground nie stoi klasyczny stos składający się z serwera WWW, zainstalowanego PHP i oddzielnego serwera bazy danych. WordPress i środowisko uruchomieniowe PHP są przesyłane do przeglądarki; PHP działa tam w oparciu o WebAssembly. W ten sposób przeglądarka zapewnia środowisko uruchomieniowe, podczas gdy otwarta, produkcyjna instalacja WordPressa pozostaje technicznie nienaruszona.

W zakresie przechowywania danych Playground wykorzystuje integrację z SQLite zamiast samodzielnego serwera MySQL. Wystarcza to do wielu testów funkcjonalnych, na przykład podczas zapisywania ustawień, tworzenia treści lub zapoznawania się z interfejsem wtyczki. Zmienia to jednak podstawy techniczne w porównaniu z wieloma usługami hostingowymi WordPressa, które wykorzystują MySQL lub MariaDB.

Pozytywny wynik odpowiada zatem jedynie na konkretne pytanie, które zostało sprawdzone w tym środowisku przeglądarki. Jest to cenna wstępna ocena, ale nie stanowi ogólnego dowodu zgodności. Szczególnie w przypadku rozszerzeń, które wykonują własne zapytania do baz danych lub integrują usługi serwerowe, należy następnie przetestować środowisko odpowiadające docelowemu hostingowi.

• Zapytania SQL mogą zachowywać się w SQLite inaczej niż w MySQL lub MariaDB; dlatego funkcje wtyczek specyficzne dla danej bazy danych wymagają dodatkowego testowania.
• Szczególne rozszerzenia PHP, moduły serwerowe lub uprawnienia do plików w przyszłym hostingu nie są automatycznie częścią środowiska przeglądarki.
• Wyniki dotyczące wysyłania wiadomości e-mail, zewnętrznych webhooków, usług płatniczych i podobnych integracji serwerowych nie mogą być traktowane jako dowód prawidłowego działania systemu na żywo.

To ograniczenie nie jest wadą, lecz determinuje sensowne wykorzystanie: Playground zmniejsza nakład pracy związany z wczesnymi testami. Dla kompatybilność z usługami hostingowymi uzupełniasz test w przeglądarce o środowisko stagingowe lub lokalne środowisko serwerowe z odpowiednią bazą danych, konfiguracją PHP i faktycznie potrzebnymi usługami.

Instancja internetowa, pamięć i wybór wersji

Publiczna instancja internetowa to najszybszy sposób na rozpoczęcie pracy: wystarczy otworzyć ją w aktualnej przeglądarce na komputerze i w razie potrzeby skonfigurować wersję WordPressa, wersję PHP, język, opcje sieciowe lub tryb multisite. Dzięki temu można na przykład dokładnie sprawdzić, czy dane rozszerzenie działa w wybranej kombinacji WordPressa i PHP. Dostępne opcje konfiguracyjne sprawiają, że Playground to coś więcej niż tylko stała instalacja demonstracyjna.

W przypadku krótkich przeglądek zapisywanie danych w przeglądarce może wystarczyć. Jednak w przypadku ciągłej pracy nie jest to niezawodna strategia tworzenia kopii zapasowych: automatyczne zapisywanie ma ograniczoną liczbę zapisów, a czyszczenie przeglądarki, okno prywatne, inny profil lub brak miejsca na dysku mogą spowodować usunięcie danych. Jednym z Eksport do pliku ZIP jest to przenośny sposób na zapisanie stanowiska testowego poza przeglądarką i ponowne zaimportowanie go w późniejszym czasie.

W przypadku każdego testu, który można powtórzyć, należy odnotować konkretne wersje, zamiast używać jedynie określenia „najnowsza“. Zapisz co najmniej wersję WordPressa i PHP, a także wersję i pochodzenie testowanej wtyczki lub motywu. Tylko wtedy będzie można później rozróżnić, czy wynik testu wynika ze zmiany w rozszerzeniu, rdzeniu WordPressa czy środowisku uruchomieniowym.

Również terminy związane z Playgroundem muszą być wyraźnie rozróżniane. Termin „release” odnosi się do opublikowanej wersji; wersje pakietów dotyczą konkretnego pakietu. Gałąź rozwoju trunk jest natomiast wersją w trakcie rozwoju i nie zastępuje udokumentowanego wydania. W celu zapewnienia jakości i na potrzeby prezentacji należy zatem korzystać z konkretnie określonych wersji dostępnych w danym teście oraz dokumentować je wraz z celem testu.

Bezpieczne testowanie wtyczek i motywów

Aby przeprowadzić krótki test, uruchom nową instancję serwisu i, jeśli wymaga tego test, wybierz udokumentowaną wersję WordPressa i PHP. Wtyczkę lub motyw zainstaluj wyłącznie z wiarygodnego źródła, aktywuj je i najpierw sprawdź, czy pojawiają się oczekiwane menu, ustawienia lub bloki. Czysta instancja początkowa zapobiega zafałszowaniu wyników przez istniejące wtyczki, treści lub ustawienia.

Następnie sprawdź konkretną, jasno określoną funkcję podstawową: na przykład, czy blok formularza można skonfigurować, czy można utworzyć własny typ wpisu lub czy wyświetla się opcja motywu. Zanotuj używane wersje, źródło instalacji, poszczególne kroki i wynik. W ten sposób zwykłe badanie staje się Wstępna kontrola, które później można odtworzyć w innym środowisku. Playground nadaje się w szczególności do testowania wtyczek bez narażania na ryzyko działającej strony internetowej.

• Istotne jest to, że instalacja i aktywacja przebiegają pomyślnie, pojawia się interfejs użytkownika, a konkretnie wybrana funkcja podstawowa działa w nowo utworzonej instancji.
• Nadal pozostają otwarte następujące kwestie: zachowanie w warunkach rzeczywistego ruchu, wysyłka wiadomości e-mail, buforowanie, zewnętrzne interfejsy API, dostawcy usług płatniczych oraz specyfika przyszłego hostingu.
• W przypadku motywów blokowych sprawdzasz dodatkowo edytor strony, szablony, fragmenty szablonów i style globalne. Zmiany pozostają przy tym ograniczone do instancji testowej.

Pozytywny wynik nie oznacza zatem, że rozszerzenie nadaje się do każdej strony produkcyjnej. Playground nie posiada stałego adresu; ponadto uruchamianie w przeglądarce oraz brak usług serwerowych mogą ograniczać funkcje oferowane przez dostawców zewnętrznych. W przypadku decyzji o szczególnym znaczeniu należy uzupełnić test przeglądarkowy o test w środowisku, które pod względem technicznym jest zbliżone do przyszłej strony internetowej.

Schematy powtarzalnych środowisk testowych

A Plan jest opartym na formacie JSON opisem tego, w jaki sposób Playground ma utworzyć instancję. Zamiast za każdym razem ręcznie konfigurować wersję demonstracyjną, można na przykład określić stałe wersje WordPressa i PHP, wtyczki, motywy, opcje, etap logowania oraz treści testowe. Zapewnia to powtarzalne warunki dla szkoleń, opisów błędów lub zdefiniowanego przebiegu testów. Blueprinty można wykorzystywać w instancji internetowej, a także za pośrednictwem JavaScript i Node.js.

Plik ten automatyzuje konfigurację, ale nie zastępuje sprawdzenia załączonych zasobów. W przypadku wtyczek, motywów, importów WXR i zewnętrznych plików ZIP należy odnotować źródło i wersję. Nie należy używać prawdziwych danych dostępowych, adresów URL ze środowiska produkcyjnego ani treści poufnych. Szczególnie podczas importowania treści należy świadomie zdecydować, czy załączniki multimedialne mają zostać załadowane, a adresy URL przekształcone, zamiast bezkrytycznie przejmować dane z działającej witryny.

Kroki runSql oraz wp-cli mają znacznie szerszy zakres działania niż zwykła instalacja: umożliwiają modyfikowanie danych lub wykonywanie poleceń. W przypadku prezentacji w niniejszym artykule zaleca się uwzględnianie wyłącznie kroków, które można zweryfikować i które nie powodują uszkodzeń; zapytania o usunięcie danych lub zmiany schematu nie spełniałyby celu, jakim jest przedstawienie przykładu, który można w sposób pewny prześledzić. Również w przypadku WP-CLI obowiązuje zasada: dostępność danego kroku nie oznacza, że każde polecenie jest obsługiwane w kontekście przeglądarki.

Porównanie CLI, przeglądarki i środowiska testowego

Gdy zaczynasz pracować nad plikami własnej wtyczki lub motywu, interfejs przeglądarki niekoniecznie jest już najlepszym rozwiązaniem. Playground-CLI może uruchomić lokalną instancję WordPressa za pomocą terminala i automatycznie podłączyć lokalny katalog wtyczki. Wprowadź poniższe polecenie z katalogu głównego danego projektu wtyczki; uruchomi ono lokalną instancję deweloperską, a nie publicznie dostępny serwer produkcyjny.

npx @wp-playground/cli server --auto-mount

Udokumentowany przewodnik szybkiego startu nie zawiera konkretnej wersji pakietu. Dzięki temu można npx przy kolejnych wywołaniach korzystać z innej dostępnej wersji CLI. Jest to przydatne w przypadku spontanicznej eksploracji lokalnej; w przypadku powtarzalnych procesów programistycznych lub testowych należy określić i udokumentować w projekcie faktycznie używaną wersję pakietu, zamiast nieustannie polegać na zmiennej wersji.

Z Automatyczne montowanie CLI ładuje wtyczkę z lokalnego katalogu projektu do uruchomionej instancji Playground. Dzięki temu zmiany w lokalnym kodzie źródłowym można natychmiast sprawdzić w tym środowisku programistycznym. To, które inne pliki strony internetowej lub dane mają zostać zachowane po ponownym uruchomieniu, zależy od wybranego CLI, sposobu montowania oraz procedury przechowywania danych i musi zostać wyraźnie określone dla danego projektu.

Wybór zależy zatem od zadania: do szybkiego stworzenia demonstracji lub powtarzalnego interfejsu często wystarczy przeglądarka, natomiast do pracy z kodem źródłowym – instancja CLI z celowo podłączonym folderem projektu. Do testów akceptacyjnych z usługami zbliżonymi do serwerowych, zachowaniem bazy danych i stałym podglądem potrzebujesz Inscenizacja lub podobne środowisko docelowe. Dalsze kryteria dotyczące środowisk testowych i operacyjnych zbliżonych do warunków produkcyjnych wyjaśniono w artykule Wybór środowiska testowego i infrastruktury serwerowej dla WordPressa.

Zapewnienie bezpieczeństwa stanowisk testowych i prowadzenie przejrzystej dokumentacji

Skuteczny test na platformie Playground zaczyna się od jasno określonego celu: na przykład odtworzenia błędu, sprawdzenia interfejsu użytkownika wtyczki lub przeanalizowania wyglądu motywu blokowego. W tym celu należy odnotować wersję WordPressa i PHP, nazwę oraz dokładną wersję motywu lub wtyczki, źródło pochodzenia, a także wykonane czynności. Tylko te informacje sprawiają, że wyniki testu są zrozumiałe dla innych osób i możliwe do odtworzenia w późniejszym czasie.

Zapisz również zaobserwowany wynik w sposób jak najbardziej konkretny. Zamiast napisać „wtyczka nie działa“, warto podać, czy aktywacja się nie powiodła, czy w edytorze brakuje konkretnego bloku, czy też ustawienie nie zostało zapisane. Dodaj informację, czy test odbył się na nowo zainstalowanej instancji oraz jakie inne rozszerzenia były aktywne. W ten sposób z krótkiej próby powstaje opis błędu umożliwiający odtworzenie sytuacji.

Funkcja automatycznego zapisywania przeglądarki ułatwia wznowienie pracy, ale nie stanowi niezawodnego archiwum. Playground przechowuje jedynie ograniczoną liczbę najnowszych automatycznie zapisanych instancji; prywatne okna przeglądarki, usunięcie danych przeglądarki, zmiana profilu lub brak miejsca na dysku mogą spowodować utratę tych danych. Dlatego też należy wyeksportować ważny stan pracy jako plik ZIP i zapisać go wraz z notatkami z testów.

Eksport w formacie ZIP jest przenośny i oddziela środowisko testowe od konkretnej przeglądarki. W przypadku powtarzających się prezentacji eksport warto uzupełnić o schemat: opisuje on konfigurację wraz z określonymi wersjami, krokami instalacji i ustawieniami. Eksport zabezpiecza osiągnięty stan, natomiast schemat wyjaśnia, w jaki sposób należy celowo skonfigurować nową instancję.

Przykład: Sprawdzasz, czy motyw blokowy wyświetla szablon nieprawidłowo. Najpierw udokumentuj używane wersje WordPressa i PHP, plik motywu wraz z wersją oraz kroki wykonane w edytorze strony. Następnie wyeksportuj aktualny stan jako plik ZIP. Aby powtórzyć test, uruchom nową instancję, zainstaluj wyłącznie udokumentowany motyw i wprowadź te same zmiany.

Nie należy przy tym wykorzystywać ani danych dostępowych do systemów produkcyjnych, ani wyciągów z baz danych, ani treści poufnych. Do odtworzenia sytuacji używaj neutralnych stron przykładowych, obrazów testowych i fikcyjnych kont. Jeśli konieczne jest sprawdzenie błędu z treściami zbliżonymi do rzeczywistych, przed importem usuń dane osobowe i informacje wewnętrzne. Dokładna dokumentacja nie zastępuje starannego doboru danych, które mogą trafić do środowiska testowego.

Wykrywanie typowych błędów w instancji przeglądarki

Jeśli świeżo skonfigurowana instancja wydaje się być zresetowana, należy najpierw odróżnić aktualizację w ramach WordPressa od całkowitej Odświeżenie przeglądarki. Operacja „Reload” powoduje ponowne uruchomienie aplikacji Playground. W szczególności instancje tymczasowe z ?storage=temp zostaną przy tym utracone. Dlatego w przypadku standardowego etapu sprawdzania w WordPressie należy odświeżyć daną stronę WordPressa, a nie całą kartę przeglądarki bez sprawdzania.

Nawet nietypowe zachowanie w backendzie niekoniecznie oznacza błąd testowanej wtyczki. Playground wyświetla WordPressa w ramce iframe. Link z target="_top" W związku z tym strona otaczająca może się ponownie załadować; ponadto wyskakujące okienka JavaScript z ramki iframe nie zawsze są widoczne. W przypadku wystąpienia takich objawów sprawdź typ linku i, w razie potrzeby, powtórz tę czynność w uproszczonym środowisku testowym.

Zakres funkcji zależy ponadto od przeglądarki i platformy. Aby zapisywać pliki bezpośrednio w katalogu lokalnym, Playground wymaga interfejsu API dostępu do systemu plików. Wymóg ten jest wymieniony w dokumentacji instancji internetowej; dokumentacja błędów wskazuje, że przeglądarki Chrome i Edge zapewniają szczególnie szerokie wsparcie dla katalogów lokalnych. Jeśli w używanej przeglądarce brakuje tej funkcji, lepszym wyborem będzie eksport do pliku ZIP lub inna obsługiwana metoda zapisywania.

W przypadku zautomatyzowanych procesów obowiązuje jeszcze jedno ograniczenie: WP-CLI jest dostępne w Playground, ale dokumentacja nie zawiera pełnej listy obsługiwanych poleceń. Nie należy zatem traktować pojedynczego pomyślnie wykonanego polecenia jako dowodu na pełną Zgodność z WP-CLI. Sprawdź, jakie polecenia są faktycznie potrzebne, korzystając z przeznaczonej do tego celu wersji testowej, a w przypadku procesów związanych z serwerem dodaj test w środowisku docelowym.

Pomiary lub subiektywne różnice odczuwalne w instancji przeglądarki nie stanowią wiarygodnego wskaźnika czasów odpowiedzi, nagłówków pamięci podręcznej ani zachowania pod obciążeniem rzeczywistej witryny internetowej. Playground nie korzysta z tego samego serwera WWW, tej samej bazy danych ani tego samego łańcucha sieciowego, co Twój hosting. W zrozumieniu działania rzeczywistych pamięci podręcznych przeglądarki i serwera pomocny będzie ten artykuł Jak prawidłowo skonfigurować buforowanie przeglądarki w WordPressie; mimo to sprawdź wyniki testów zbliżone do warunków produkcyjnych w odpowiednim środowisku testowym lub hostingowym.

Kiedy Playground jest właściwym wyborem

WordPress Playground To dobre rozwiązanie, jeśli potrzebujesz szybko odizolowanej instancji WordPressa do rozwiązania konkretnego, ściśle określonego zadania. Dotyczy to na przykład wstępnego testowania wtyczki, zapoznania się z motywem blokowym, wprowadzania zmian w szablonach i stylach globalnych lub przygotowania prezentacji szkoleniowej. Instancja ta pozostaje oddzielona od hostingu i danych produkcyjnych, co pozwala na analizę procesów operacyjnych bez wprowadzania zmian w działającej witrynie.

W przypadku powtarzających się zgłoszeń do pomocy technicznej i prezentacji narzędzie Playground jest szczególnie przydatne, gdy schemat (Blueprint) określa wymagane komponenty i wersje. Inna osoba może wówczas odtworzyć ten sam punkt wyjścia, zamiast próbować odtworzyć niekompletnie opisaną instalację. Poprawia to możliwość porównania błędu, ale nie zastępuje sprawdzenia usług znajdujących się poza instancją przeglądarki.

• Wybierz Browser-Playground do szybkiego testowania funkcji, eksperymentów w edytorze i prezentacji bez wykorzystywania danych produkcyjnych.
• Wybierz Playground CLI, jeśli lokalne pliki projektu mają być włączone do projektu przez dłuższy czas i dalej wykorzystywane zgodnie z udokumentowaną procedurą przechowywania.
• Wybierz środowisko testowe lub serwerowe zbliżone do hostingu, jeśli konkretna infrastruktura stanowi część zadania.

Natomiast stałe środowisko podglądu lub testowania nie stanowi głównego zadania Playground. Jego środowisko przeglądarkowe i WebAssembly różni się od tradycyjnego stosu hostingowego; ponadto Playground wykorzystuje integrację z SQLite zamiast samodzielnego serwera MySQL. W przypadku funkcji, których wynik zależy od konkretnej konfiguracji serwera lub bazy danych, test w przeglądarce nie wystarcza zatem jako jedyne potwierdzenie.

Również w przypadku testów obciążeniowych, odbiorów związanych z bezpieczeństwem oraz zatwierdzeń związanych z hostingiem sam test w izolowanej przeglądarce nie jest wystarczający. Zapytania zależne od bazy danych, rozszerzenia PHP, buforowanie oraz konfiguracja serwera mogą zachowywać się inaczej w docelowym systemie. Dotyczy to również procesów, które wymagają konkretnej usługi pocztowej, webhooka lub usługi zewnętrznego dostawcy w środowisku docelowym.

Decyzja zależy zatem od konkretnego zagadnienia, a nie od ogólnego zwycięzcy. Jeśli chodzi o bezpieczne wykrycie rozszerzenia lub minimalną korektę błędu, to izolowana instancja testowa celowe. Jeśli natomiast proces ma być oceniany w ramach przewidzianego hostingu, z wykorzystaniem jego bazy danych lub powiązanych usług, po teście w środowisku testowym przeprowadza się dodatkową weryfikację w warunkach eksploatacyjnych jak najbardziej zbliżonych do rzeczywistych.