Локална разработка с 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 GB образи и поддържа 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 записва и които трябва да стъргнете (commit), така че всички в проекта да работят с едни и същи версии. Флаг в командния ред е с предимство пред файла за това изпълнение.

Версията, която декларирате, и версията, която се изпълнява, са различни факти. 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 MB, и разработчик, който само изброява сайтове, не трябва да плаща за него. Тя се съхранява в собствения кеш на 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 MB, верифициран спрямо контролните суми, публикувани от nodejs.org, в същия кеш. Подканата за инсталиране указва това при прилагането си. Нищо във вашия собствен Node не се променя.

Свързани

• Първи стъпки · Деплойване · Справка за команди · Отстраняване на неизправности