Локальна розробка за допомогою 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, а не через оболонку (shell).

Версія середовища виконання прив'язана до версії 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 не змінюється.

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

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