Lokalny rozwój z zinnector dev

zinnector dev uruchamia prawdziwego WordPressa na twojej własnej maszynie, serwując wtyczki i motywy z twojego projektu, z wybraną przez ciebie wersją PHP. W tym artykule wyjaśniono dwa środowiska wykonawcze, z których może korzystać, sposób wybierania wersji, co i skąd jest serwowane oraz gdzie środowisko wykonawcze znajduje się na dysku — tak aby to, co testujesz lokalnie, było tym, co wdrażasz.

Dwa środowiska wykonawcze i dlaczego oba są prawdziwe

Playground jest środowiskiem domyślnym. WordPress Playground kompiluje PHP do WebAssembly i uruchamia je wewnątrz środowiska Node, dzięki czemu laptop z zainstalowanym wyłącznie Node uruchamia WordPressa w kilka sekund. Dostępna jest dowolna wersja PHP od 5.2 do 8.5. Zawiera niewielki zestaw rozszerzeń PHP (intl, redis, memcached, jak zmierzono w bieżącej kompilacji), co wystarcza do większości prac nad wtyczkami i motywami.

Docker uruchamia natywne kontenery php-fpm oraz MariaDB. Jest wolniejszy, wymaga demona Docker i około 1,2 GB obrazów oraz obsługuje PHP od 7.4 do 8.5 — ale uruchamia natywne PHP z pełnym zestawem rozszerzeń, w tym imagick i gd. To rzetelne rozwiązanie, gdy musisz przetestować rozszerzenie, którego kompilacja WebAssembly nie zawiera.

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

Nigdy nie następuje ciche przejście na Docker w trybie awaryjnym. Programista, który myśli, że korzysta z WebAssembly, a w rzeczywistości używa Dockera, otrzymał niewłaściwą odpowiedź od narzędzia próbującego pomóc, dlatego należy o to poprosić wprost z nazwy.

Wybór wersji PHP i WordPress

zinnector dev --php 8.1 --wp 6.7    # programowanie z użyciem konkretnej pary
zinnector dev --port 9401           # gdy 9400 jest zajęty
zinnector dev --no-login            # nie loguj automatycznie do wp-admin
zinnector dev --verbose             # pokaż własne dane wyjściowe środowiska wykonawczego

Wartości domyślne pochodzą z pliku zinnector.json w projekcie — php, wordpress, runtime oraz port — który tworzy polecenie zinnector new i który należy zatwierdzić w repozytorium, aby wszyscy pracujący nad projektem uruchamiali te same wersje. Flaga w wierszu poleceń ma pierwszeństwo przed plikiem dla danego uruchomienia.

Wersja, którą deklarujesz, oraz wersja, która działa, to dwie różne kwestie. Polecenie zinnector dev --once uruchamia środowisko wykonawcze, wyświetla to, co faktycznie zgłasza — wersję PHP, wersję WordPressa, załadowane rozszerzenia — i zatrzymuje się. Polecenie zinnector check --probe korzysta z tego samego pomiaru podczas porównywania twojego projektu z miejscem hostingowym.

Co jest serwowane z twojego projektu

Środowisko wykonawcze montuje bezpośrednio katalogi wp-content/plugins, wp-content/themes oraz wp-content/mu-plugins Twojego projektu, więc zapisany plik jest dostępny natychmiast przy kolejnym przeładowaniu. Katalogi, które istnieją, ale nie zawierają rzeczywistej zawartości, celowo nie są montowane: pusty katalog themes/ zamontowany na własnych motywach środowiska wykonawczego pozostawiłby WordPressa bez żadnego motywu, co skutkuje pustym błędem 500, a nie twoją witryną. Z tego powodu szablon zachowuje puste katalogi za pomocą pliku .gitkeep i dlatego nie przesłaniają one niczego, dopóki nie umieścisz w nich motywu.

Gdzie znajduje się środowisko wykonawcze

Środowisko wykonawcze WordPress jest pobierane przy pierwszym użyciu, zamiast być dostarczane z CLI — pakiet zawierający każdą kompilację PHP ma około 570 MB, a programista, który jedynie wyświetla listę witryn, nie powinien go niepotrzebnie pobierać. Jest ono przechowywane we własnej pamięci podręcznej narzędzia Zinnector®, w ~/.cache/zinnector/runtimes/playground/<version> (lub w miejscu wskazanym przez ZINNECTOR_CACHE_DIR), nigdy w twoim projekcie, więc nie może trafić do twojego repozytorium ani do drzewa mierzonego przez zinnector push. Pobieranie jest realizowane przez twój własny npm, uruchamiany jako node npm-cli.js — nigdy za pośrednictwem powłoki.

Wersja środowiska wykonawczego jest przypięta do wersji CLI, dzięki czemu dwóch programistów pracujących nad jednym projektem uruchamia te same kompilacje PHP. Polecenie zinnector dev --reset-runtime usuwa zainstalowane środowisko wykonawcze i instaluje je ponownie, co stanowi rozwiązanie problemu ze środowiskiem, które zostało zainstalowane, ale nie chce się uruchomić.

Na środowisku Node 26 lub nowszym

Samo CLI działa na dowolnej wersji Node od 24 w górę. Jednak natywny moduł środowiska wykonawczego dostarcza wstępnie skompilowane pliki binarne tylko dla Node 24 i 25 (stan na wrzesień 2026 r.). Zamiast kompilować cokolwiek — co w systemie Windows oznacza instalację programu Visual Studio — Zinnector® pobiera do tej samej pamięci podręcznej wersję Node 24 przeznaczoną wyłącznie dla środowiska wykonawczego (około 30 MB), zweryfikowaną pod kątem sum kontrolnych publikowanych przez nodejs.org. Komunikat instalacyjny informuje o tym, gdy ma to zastosowanie. W twojej własnej instalacji Node nic się nie zmienia.

Powiązane

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