Lokalne środowisko programistyczne z zinnector dev

zinnector dev uruchamia prawdziwego WordPress na Państwa własnym komputerze, obsługując wtyczki i motywy w Państwa projekcie z wybraną wersją PHP. Ten artykuł wyjaśnia dwa środowiska wykonawcze, z których może korzystać, sposób dobierania wersji, co jest serwowane skąd oraz gdzie środowisko wykonawcze znajduje się na dysku – dzięki czemu to, co testują Państwo lokalnie, jest tym, co wdrażają.

Dwa środowiska wykonawcze i dlaczego oba są prawdziwe

Playground jest ustawieniem domyślnym. WordPress Playground kompiluje PHP do WebAssembly i uruchamia je wewnątrz Node, dzięki czemu laptop z zainstalowanym wyłącznie programem Node uruchamia WordPress w kilka sekund. Dostępna jest każda wersja PHP od 5.2 do 8.5. Posiada on mały zestaw rozszerzeń PHP (intl, redis, memcached mierzony na obecnej kompilacji), co wystarcza do większości prac nad wtyczkami i motywami.

Docker uruchamia natywne kontenery php-fpm i MariaDB. Jest wolniejszy, wymaga demona Dockera oraz około 1,2 GB obrazów i obsługuje PHP od 7.4 do 8.5 – uruchamia jednak natywne PHP z pełnym zestawem rozszerzeń, w tym imagick oraz gd. Jest to uczciwa odpowiedź, gdy tym, co muszą Państwo przetestować, jest rozszerzenie, którego kompilacja WebAssembly nie zawiera.

zinnector dev                       # playground
zinnector dev --runtime docker      # natywne PHP + MariaDB

Docker nigdy nie jest włączany w sposób cichy jako mechanizm zapasowy. Deweloper, który uważa, że korzysta z WebAssembly, a faktycznie korzysta z Dockera, otrzymał błędną odpowiedź od narzędzia próbującego pomóc, dlatego należy go zażądać z nazwy.

Wybór wersji PHP i WordPress

zinnector dev --php 8.1 --wp 6.7    # programowanie pod kątem konkretnej pary
zinnector dev --port 9401           # gdy port 9400 jest zajęty
zinnector dev --no-login            # bez automatycznego logowania do wp-admin
zinnector dev --verbose             # wyświetlanie własnych komunikatów środowiska wykonawczego

Wartości domyślne pochodzą z pliku zinnector.json w projekcie – php, wordpress, runtime oraz port – który zapisuje polecenie zinnector new i który powinni Państwo zatwierdzić (commit), aby wszystkie osoby w projekcie korzystały z tych samych wersji. Flaga w wierszu poleceń ma pierwszeństwo przed plikiem dla danego uruchomienia.

Wersja, którą deklarują Państwo, oraz wersja, która uruchamia się, to różne fakty. zinnector dev --once uruchamia środowisko wykonawcze, wyświetla to, co ono faktycznie zgłasza – wersję PHP, wersję WordPress, załadowane rozszerzenia – i zatrzymuje się. zinnector check --probe korzysta z tego samego pomiaru podczas porównywania Państwa projektu ze slotem hostingowym.

Co jest serwowane z Państwa projektu

Środowisko wykonawcze montuje katalogi wp-content/plugins, wp-content/themes oraz wp-content/mu-plugins Państwa projektu bezpośrednio, dzięki czemu zapisany plik jest aktywny przy kolejnym przeładowaniu. Katalogi, które istnieją, ale nie zawierają prawdziwej zawartości, celowo nie są montowane: pusty katalog themes/ zamontowany nad własnymi motywami środowiska wykonawczego pozostawiłby WordPress całkowicie bez motywu, co oznacza pusty błąd 500 zamiast Państwa witryny. Właśnie dlatego rusztowanie zachowuje puste katalogi za pomocą pliku .gitkeep i dlatego nie przesłaniają one niczego, dopóki nie umieszczą Państwo w nich motywu.

Gdzie znajduje się środowisko wykonawcze

Środowisko wykonawcze WordPress jest pobierane podczas pierwszego użycia zamiast być dostarczane razem z interfejsem wiersza poleceń (CLI) – pakiet zawierający każdą kompilację PHP zajmuje około 570 MB, a deweloper, który jedynie wyświetla listę witryn, nie powinien za to płacić. Jest ono przechowywane we własnej pamięci podręcznej Zinnector®, czyli ~/.cache/zinnector/runtimes/playground/<version> (lub tam, dokąd wskazuje ZINNECTOR_CACHE_DIR), nigdy w Państwa projekcie, dzięki czemu nie może trafić do Państwa repozytorium ani do drzewa, które mierzy zinnector push. Pobieranie jest wykonywane przez Państwa własne npm, uruchamiane jako node npm-cli.js – nigdy za pośrednictwem powłoki systemowej.

Wersja środowiska wykonawczego jest powiązana z wersją interfejsu wiersza poleceń (CLI), dzięki czemu dwóch deweloperów pracujących nad jednym projektem uruchamia te same kompilacje PHP. zinnector dev --reset-runtime usuwa zainstalowane środowisko wykonawcze i instaluje je ponownie, co stanowi rozwiązanie problemu środowiska wykonawczego, które się zainstalowało, ale nie chce się uruchomić.

W systemie Node 26 lub nowszym

Sam interfejs wiersza poleceń (CLI) uruchamia się na każdej wersji Node od 24 wzwyż. Jednak moduł natywny środowiska wykonawczego udostępnia wstępnie skompilowane pliki binarne tylko dla środowisk Node 24 i 25 (stan na wrzesień 2026 r.). Zamiast cokolwiek kompilować – co w systemie Windows oznacza instalację programu Visual Studio – Zinnector® pobiera środowisko Node 24 wyłącznie dla środowiska wykonawczego (około 30 MB), zweryfikowane pod kątem sum kontrolnych publikowanych przez nodejs.org, do tej samej pamięci podręcznej. Komunikat instalacyjny informuje o tym podczas jego stosowania. Nic w Państwa własnym środowisku Node nie ulega zmianie.

Powiązane

• Pierwsze kroki · Wdrażanie · Dokumentacja poleceń · Rozwiązywanie problemów