Локальна розробка за допомогою zinnector dev

zinnector dev запускає справжній WordPress на вашому власному комп'ютері, надаючи плагіни та теми з вашого проєкту, із вибраною вами версією PHP. У цій статті пояснюється, які два середовища виконання він може використовувати, як вибирати версії, що звідки надається та де середовище виконання зберігається на диску — щоб те, що ви тестуєте локально, відповідало тому, що ви розгортаєте.

Два середовища виконання та чому обидва є справжніми

Playground використовується за замовчуванням. WordPress Playground компілює PHP у WebAssembly та запускає його всередині Node, тому ноутбук, на якому не встановлено нічого, крім Node, завантажує WordPress за лічені секунди. Доступна будь-яка версія PHP від 5.2 до 8.5. Воно містить невеликий набір розширень PHP (intl, redis, memcached, за вимірюваннями поточної збірки), чого достатньо для більшості завдань із плагінами та темами.

Docker запускає нативні контейнери php-fpm і MariaDB. Воно працює повільніше, потребує демона Docker і близько 1,2 ГБ образів, а також підтримує PHP від 7.4 до 8.5 — проте воно запускає нативний PHP із повним набором розширень, включно з imagick і gd. Це надійне рішення, коли вам потрібно протестувати розширення, якого немає в збірці WebAssembly.

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

Перехід на Docker ніколи не відбувається непомітно. Розробник, який вважає, що працює на WebAssembly, а насправді використовує Docker, отримує хибний результат від інструмента, який намагався допомогти, тому його потрібно запитувати явно.

Вибір версій PHP і WordPress

zinnector dev --php 8.1 --wp 6.7    # develop against a specific pair
zinnector dev --port 9401           # when 9400 is taken
zinnector dev --no-login            # do not sign in to wp-admin automatically
zinnector dev --verbose             # show the runtime's own output

Значення за замовчуванням беруться з файлу zinnector.json у проєкті — php, wordpress, runtime і port — який створює команда zinnector new і який вам слід зафіксувати в системі контролю версій, щоб усі учасники проєкту запускали однакові версії. Прапорець у командному рядку має пріоритет над файлом для конкретного запуску.

Версія, яку ви оголошуєте, і версія, яка працює, — це різні речі. Команда zinnector dev --once завантажує середовище виконання, виводить те, про що воно фактично повідомляє — версію PHP, версію WordPress, завантажені розширення — і зупиняється. Команда zinnector check --probe використовує ті самі вимірювання, коли порівнює ваш проєкт із хостинг-слотом.

Що надається з вашого проєкту

Середовище виконання монтує каталоги вашого проєкту wp-content/plugins, wp-content/themes і wp-content/mu-plugins безпосередньо, тому збережений вами файл одразу доступний після наступного перезавантаження. Каталоги, які існують, але не містять реального вмісту, навмисно не монтуються: порожній каталог themes/, змонтований поверх власних тем середовища виконання, залишив би WordPress взагалі без теми, що призведе до порожньої помилки 500 замість вашого сайту. Ось чому шаблон зберігає порожні каталоги за допомогою .gitkeep і чому вони нічого не перекривають, доки ви не розмістите в них тему.

Де зберігається середовище виконання

Середовище виконання WordPress завантажується під час першого використання, а не постачається разом із CLI — пакет, який містить усі збірки PHP, важить близько 570 МБ, і розробник, який лише переглядає список сайтів, не повинен витрачати на це ресурси. Воно зберігається у власному кеші Zinnector®, ~/.cache/zinnector/runtimes/playground/<version> (або там, куди вказує ZINNECTOR_CACHE_DIR), і ніколи не потрапляє у ваш проєкт, тому воно не опиниться у вашому репозиторії чи в дереві файлів, яке аналізує zinnector push. Завантаження виконується вашим власним npm шляхом запуску node npm-cli.js — ніколи через командну оболонку.

Версія середовища виконання прив'язана до версії CLI, тому двоє розробників в одному проєкті запускають однакові збірки PHP. Команда zinnector dev --reset-runtime видаляє встановлене середовище виконання та встановлює його знову, що є вирішенням проблеми, коли середовище виконання встановилося, але не запускається.

На Node 26 або новіших версіях

Сам CLI працює на будь-якій версії Node від 24 і вище. Проте нативний модуль середовища виконання постачає попередньо скомпільовані бінарні файли лише для Node 24 і 25 (станом на вересень 2026 року). Замість компіляції будь-чого — що на Windows означає встановлення Visual Studio — Zinnector® завантажує Node 24 лише для середовища виконання (близько 30 МБ), перевірений за контрольними сумами, які публікує nodejs.org, у той самий кеш. Запит під час встановлення повідомляє про це, коли це застосовується. У вашому власному Node нічого не змінюється.

Пов'язані матеріали

• Початок роботи · Розгортання · Довідник команд · Виправлення неполадок