Lokal na pagpapaunlad gamit ang zinnector dev

Ang zinnector dev ay nagpapatakbo ng totoong WordPress sa inyong sariling makina, na nagsisilbi sa mga plugin at tema sa inyong proyekto, gamit ang bersyon ng PHP na inyong napili. Nililinaw ng artikulong ito ang dalawang runtime na magagamit nito, kung paano pumili ng mga bersyon, kung ano ang isinisilbi mula saan, at kung saan naninirahan ang runtime sa disk — upang ang inyong sinusubukan nang lokal ay siyang inyong dini-deploy.

Ang dalawang runtime, at kung bakit tunay ang pareho

Ang Playground ang default. Kino-compile ng WordPress Playground ang PHP sa WebAssembly at pinapatakbo ito sa loob ng Node, kaya ang isang laptop na walang naka-install kundi ang Node ay nag-a-activate ng WordPress sa loob ng ilang segundo. Mayroon itong maliit na hanay ng mga PHP extension (intl, redis, memcached gaya ng nakasaad sa kasalukuyang build), na sapat para sa karamihan ng gawain sa plugin at tema.

Ang Docker ay nagpapatakbo ng mga katutubong php-fpm at MariaDB container. Mas mabagal ito, nangangailangan ng Docker daemon at humigit-kumulang 1.2 GB ng mga imahe, at sumusuporta sa PHP 7.4 hanggang 8.5 — ngunit nagpapatakbo ito ng katutubong PHP na may buong hanay ng extension, kabilang ang imagick at gd. Ito ang matapat na sagot kapag ang kailangan ninyong subukan ay isang extension na wala sa build ng WebAssembly.

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

Hindi kailanman awtomatikong lumilipat sa Docker nang walang abiso. Ang isang developer na nag-aakalang siya ay nasa WebAssembly ngunit nasa Docker pala ay binigyan ng maling sagot ng isang tool na sumusubok tumulong, kaya kailangan itong hilingin sa pamamagitan ng pangalan.

Pagpili ng mga bersyon ng PHP at WordPress

zinnector dev --php 8.1 --wp 6.7    # bumuo laban sa isang tiyak na pares
zinnector dev --port 9401           # kapag ang 9400 ay ginagamit na
zinnector dev --no-login            # huwag awtomatikong mag-sign in sa wp-admin
zinnector dev --verbose             # ipakita ang sariling output ng runtime

Ang mga default ay nagmumula sa zinnector.json sa proyekto — php, wordpress, runtime at port — na isinusulat ng zinnector new at dapat ninyong i-commit, upang ang lahat sa proyekto ay magpatakbo ng parehong mga bersyon. Ang isang flag sa command line ay mangingibabaw sa file para sa pagpapatakbong iyon.

Ang bersyon na inyong idinideklara at ang bersyon na tumatakbo ay magkaibang katotohanan. Ang zinnector dev --once ay nag-a-activate sa runtime, nag-iimprinta ng aktwal nitong iniuulat — bersyon ng PHP, bersyon ng WordPress, mga na-load na extension — at humihinto. Ginagamit ng zinnector check --probe ang parehong pagsukat kapag inihahambing nito ang inyong proyekto laban sa isang slot ng pag-host.

Kung ano ang isinisilbi mula sa inyong proyekto

Tuwirang ini-mount ng runtime ang mga direktoryo ng wp-content/plugins, wp-content/themes at wp-content/mu-plugins ng inyong proyekto, kaya ang isang file na inyong ini-save ay live na sa susunod na pag-reload. Ang mga direktoryo na umiiral ngunit walang totoong nilalaman ay sadyang hindi ini-mount: ang isang blangkong themes/ na naka-mount sa ibabaw ng mga sariling tema ng runtime ay mag-iiwan sa WordPress na walang tema, na magiging isang blangkong 500 sa halip na ang inyong site. Iyon ang dahilan kung bakit pinapanatili ng scaffold ang mga blangkong direktoryo na may kasamang .gitkeep at kung bakit hindi nila sinasaklaw ang anuman hanggang sa maglagay kayo ng tema sa kanila.

Kung saan naninirahan ang runtime

Ang runtime ng WordPress ay dina-download sa unang paggamit sa halip na isama sa CLI — ang pakete na nagdadala ng bawat build ng PHP ay humigit-kumulang 570 MB, at ang isang developer na naglilista lamang ng mga site ay hindi dapat magbayad para dito. Pinapanatili ito sa sariling cache ng Zinnector®, ~/.cache/zinnector/runtimes/playground/<version> (o kung saanman tumuturo ang ZINNECTOR_CACHE_DIR), hindi kailanman sa inyong proyekto, kaya hindi ito mapupunta sa inyong repositoryo o sa puno na sinusukat ng zinnector push. Ang pag-download ay ginagawa ng inyong sariling npm, na pinapatakbo bilang node npm-cli.js — hindi kailanman sa pamamagitan ng isang shell.

Ang bersyon ng runtime ay naka-pin sa bersyon ng CLI, kaya ang dalawang developer sa isang proyekto ay nagpapatakbo ng parehong mga build ng PHP. Itinatapon ng zinnector dev --reset-runtime ang naka-install na runtime at muli itong ini-install, na siyang lunas para sa isang runtime na na-install ngunit ayaw mag-boot.

Sa Node 26 o mas bago

Ang CLI mismo ay tumatakbo sa anumang Node mula 24 pataas. Gayunpaman, ang katutubong module ng runtime ay nagpapadala ng mga paunang binuong binary para lamang sa Node 24 at 25 (simula noong Setyembre 2026). Sa halip na mag-compile ng anuman — na sa Windows ay nangangahulugan ng pag-install ng Visual Studio — kumukuha ang Zinnector® ng isang Node 24 para sa runtime lamang, mga 30 MB, na na-verify laban sa mga checksum na inilalathala ng nodejs.org, sa parehong cache. Sinasabi ito ng prompt ng pag-install kapag inilapat ito. Walang nagbabago sa inyong sariling Node.

Kaugnay

• Pagsisimula · Pag-deploy · Sanggunian ng command · Pag-troubleshoot