База от знания

Локална разработка със zinnector dev

Как zinnector dev изпълнява истински WordPress на Вашата собствена машина: двете среди за изпълнение (WebAssembly без Docker или нативен PHP в Docker), изборът на версия на PHP и WordPress, какво се сервира от Вашия проект, къде се намира средата за изпълнение от 570 MB и какво се случва на Node 26.

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      # нейтив PHP + MariaDB

Към Docker никога не се преминава тихо като резервен вариант. Разработчик, който смята, че е на WebAssembly, а всъщност е на Docker, е получил грешния отговор от инструмент, опитващ се да помогне, така че той трябва да бъде изрично поискан по име.

Избиране на версии на PHP и WordPress

zinnector dev --php 8.1 --wp 6.7    # разработка спрямо конкретна двойка
zinnector dev --port 9401           # когато 9400 е зает
zinnector dev --no-login            # без автоматично вписване в wp-admin
zinnector dev --verbose             # показване на собствения изход на средата за изпълнение

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

Свързани

Всички документи за разработчици →

Най-новото от блога

Какво сме писали за хостинга, SEO и мащабното управление на сайтове.

SEO и изграждане на връзки от слоя на хостинга: Поглед на оператора за 2026 г.

Как хостингът влияе на индексирането и предаването на линк авторитет през 2026 г.: запазване на страниците индексирани, проверка на стари домейни преди изграждане върху тях, изграждане на линкове без SEO отпечатък и честен поглед върху това какво инфраструктурата може и не може да направи за SEO.

Прочетете публикацията →

Как да направите WordPress бърз и сигурен: контролен списък за производителност и плъгини

Практичен контролен списък за бърз и сигурен WordPress: кеширане на ниво сървър, обектен кеш за всеки сайт, малкото добавки, които си струва да използвате, поддържане на стека актуален и страниците на WooCommerce, които никога не трябва да кеширате.

Прочетете публикацията →

Как да изберете управляван уеб хостинг през 2026 г.: Ръководство за купувача

Какво всъщност отличава добрия управляван хостинг от евтина кутия с контролен панел — миграции, резервни копия, изолация, реално кеширане и честно мащабиране — и как да го прецените, преди да се ангажирате.

Прочетете публикацията →

Прочетете блога →

Все още се затруднявате?

Поддръжката е включена във всеки план, отделът работи 24 часа в денонощието и можете да ни пишете на всеки от нашите 58 езика — ние ви отговаряме на вашия.

Свържете се с поддръжката → Всички статии →