Lokal na pag-develop gamit ang zinnector dev

Pinapatakbo ng zinnector dev ang isang totoong WordPress sa sarili ninyong machine, inihahain ang mga plugin at theme sa inyong proyekto, gamit ang bersyon ng PHP na pipiliin ninyo. Ipinapaliwanag ng artikulong ito ang dalawang runtime na maaari nitong gamitin, kung paano pumili ng mga bersyon, kung ano ang inihahain mula saan, at kung saan nakalagay ang runtime sa disk — upang ang sinusubukan ninyo nang lokal ay siya mismong ide-deploy ninyo.

Ang dalawang runtime, at kung bakit parehong totoo ang mga ito

Playground ang default. Kino-compile ng WordPress Playground ang PHP patungong WebAssembly at pinapatakbo ito sa loob ng Node, kaya ang isang laptop na walang naka-install maliban sa Node ay nagbo-boot ng WordPress sa loob ng ilang segundo. Anumang PHP mula 5.2 hanggang 8.5 ay magagamit. Mayroon itong maliit na hanay ng mga extension ng PHP (intl, redis, memcached gaya ng nasukat sa kasalukuyang build), na sapat na para sa karamihan ng mga gawain sa plugin at theme.

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

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

Hindi kailanman lihim na bumabagsak pabalik sa Docker nang kusa. Ang isang developer na nag-aakalang nasa WebAssembly siya ngunit sa katunayan ay nasa Docker ay binigyan ng maling sagot ng isang tool na sumusubok tumulong, kaya kailangan itong hilingin ayon sa pangalan.

Pagpili ng mga bersyon ng PHP at WordPress

zinnector dev --php 8.1 --wp 6.7    # mag-develop para sa partikular na pares
zinnector dev --port 9401           # kapag may gumagamit na sa 9400
zinnector dev --no-login            # huwag awtomatikong mag-sign in sa wp-admin
zinnector dev --verbose             # ipakita ang sariling output ng runtime

Nagmumula ang mga default 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. Mas nangingibabaw ang isang flag sa command line kaysa sa file para sa pagpapatakbong iyon.

Ang bersyong inyong idinideklara at ang bersyong tumatakbo ay magkaibang katotohanan. Binubuksan ng zinnector dev --once ang runtime, ipinapakita ang 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 hosting slot.

Kung ano ang inihahain mula sa inyong proyekto

Direktang imina-mount ng runtime ang mga directory ng inyong proyekto na wp-content/plugins, wp-content/themes at wp-content/mu-plugins, kaya ang file na inyong ise-save ay agad na live sa susunod na pag-reload. Ang mga directory na umiiral ngunit walang totoong nilalaman ay sadyang hindi imina-mount: ang isang walang lamang themes/ na naka-mount sa sariling mga theme ng runtime ay mag-iiwan sa WordPress na walang anumang theme, na magdudulot ng blangkong 500 error sa halip na ang inyong site. Iyon ang dahilan kung bakit pinapanatili ng scaffold ang mga walang lamang directory gamit ang isang .gitkeep at kung bakit hindi tinatakpan ng mga ito ang anupaman hangga't hindi kayo naglalagay ng theme sa mga ito.

Kung saan nakalagay ang runtime

Dina-download ang WordPress runtime sa unang paggamit sa halip na isama sa CLI — ang package na naglalaman ng bawat PHP build ay humigit-kumulang 570 MB, at ang isang developer na naglilista lamang ng mga site ay hindi dapat pagdusahan ito. Itinatago ito sa sariling cache ng Zinnector®, ~/.cache/zinnector/runtimes/playground/<version> (o saanman nakaturo ang ZINNECTOR_CACHE_DIR), hindi kailanman sa inyong proyekto, kaya hindi ito maaaring mapunta sa inyong repository o sa tree 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 shell.

Ang bersyon ng runtime ay nakatali sa bersyon ng CLI, kaya ang dalawang developer sa isang proyekto ay nagpapatakbo ng parehong mga PHP build. Itinatapon ng zinnector dev --reset-runtime ang naka-install na runtime at ini-install itong muli, na siyang solusyon 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 native module ng runtime ay nagpapadala lamang ng mga prebuilt na binary para sa Node 24 at 25 (mula noong Setyembre 2026). Sa halip na mag-compile ng anuman — na sa Windows ay nangangahulugang pag-i-install ng Visual Studio — kumukuha ang Zinnector® ng isang Node 24 para lamang sa runtime, humigit-kumulang 30 MB, na napatunayan laban sa mga checksum na inilalathala ng nodejs.org, patungo sa parehong cache. Sinasabi ito ng prompt sa pag-install kapag ito ay nalalapat. Walang magbabago sa inyong sariling Node.

Kaugnay

• Pagsisimula · Pag-deploy · Sanggunian ng command · Pagtukoy at pag-aayos ng problema