zinnector dev ဖြင့် ဒေသတွင်း ဖန်တီးတည်ဆောက်ခြင်း

zinnector dev သည် သင်ရွေးချယ်ထားသော PHP ဗားရှင်းဖြင့် သင့်ပရောဂျက်ရှိ ပလပ်အင်များနှင့် သီးမူးများကို ဝန်ဆောင်မှုပေးကာ သင့်စက်ပေါ်တွင် စစ်မှန်သော WordPress တစ်ခုကို လည်ပတ်စေပါသည်။ ဤဆောင်းပါးတွင် ၎င်းအသုံးပြုနိုင်သည့် runtime နှစ်ခု၊ ဗားရှင်းများကို မည်သို့ရွေးချယ်ရမည်၊ မည်သည့်အရာကို မည်သည့်နေရာမှ ဝန်ဆောင်မှုပေးသည်နှင့် runtime သည် ဒစ်ခ်ပေါ်တွင် မည်သည့်နေရာ၌ တည်ရှိသည်တို့ကို ရှင်းပြထားပါသည် — သို့မှသာ သင် locally စမ်းသပ်သည့်အရာသည် သင် deploy လုပ်သည့်အရာ ဖြစ်လာမည်ဖြစ်ပါသည်။

Runtime နှစ်ခုနှင့် ၎င်းတို့နှစ်ခုစလုံး အဘယ်ကြောင့် အစစ်အမှန်ဖြစ်ရသနည်း

Playground သည် မူရင်း (default) ဖြစ်ပါသည်။ WordPress Playground သည် PHP ကို WebAssembly သို့ compile လုပ်ပြီး Node အတွင်း၌ လည်ပတ်စေသောကြောင့် Node သာ ထည့်သွင်းထားသည့် လက်ပ်တော့ပ်တစ်ခုသည် စက္ကန့်ပိုင်းအတွင်း WordPress ကို စတင်လည်ပတ်စေနိုင်ပါသည်။ 5.2 မှ 8.5 အထိ မည်သည့် PHP ဗားရှင်းမဆို ရရှိနိုင်ပါသည်။ ၎င်းတွင် PHP တိုးချဲ့မှု အနည်းငယ် (လက်ရှိ build တွင် တိုင်းတာထားသည့်အတိုင်း intl၊ redis၊ memcached) ပါဝင်ပြီး၊ ၎င်းသည် ပလပ်အင်နှင့် သီးမူးလုပ်ဆောင်မှု အများစုအတွက် လုံလောက်ပါသည်။

Docker သည် native php-fpm နှင့် MariaDB container များကို လည်ပတ်စေပါသည်။ ၎င်းသည် ပိုမိုနှေးကွေးပြီး Docker daemon နှင့် image များအတွက် 1.2 GB ခန့် လိုအပ်ကာ PHP 7.4 မှ 8.5 အထိကို ထောက်ပံ့ပေးပါသည် — သို့သော် ၎င်းသည် imagick နှင့် gd အပါအဝင် ပြည့်စုံသော တိုးချဲ့မှုအစုံအလင်ဖြင့် native PHP ကို လည်ပတ်စေပါသည်။ သင်စမ်းသပ်ရန် လိုအပ်သည့်အရာသည် WebAssembly build တွင် မပါဝင်သော တိုးချဲ့မှုတစ်ခုဖြစ်နေသည့်အခါ ၎င်းသည် အကောင်းဆုံးအဖြေဖြစ်ပါသည်။

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

Docker သို့ အသံတိတ် အလိုအလျောက် ပြောင်းလဲသွားခြင်းမျိုး ဘယ်တော့မှ မရှိပါ။ မိမိကိုယ်ကို WebAssembly ပေါ်တွင် ရှိနေသည်ဟု ထင်မှတ်ထားသော်လည်း အမှန်တကယ်တွင် Docker ပေါ်၌ ရောက်ရှိနေသော developer တစ်ဦးသည် ကူညီရန် ကြိုးစားနေသည့် tool တစ်ခုကြောင့် အဖြေမှားကို ရရှိသွားခြင်းဖြစ်နိုင်သောကြောင့် ၎င်းကို အမည်အားဖြင့် တိုက်ရိုက်တောင်းဆိုရမည် ဖြစ်ပါသည်။

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 ပြုလုပ်ထားသင့်ပါသည်။ command line ပေါ်ရှိ flag တစ်ခုသည် ထိုအကြိမ်လည်ပတ်မှုအတွက် ဖိုင်ပါသတ်မှတ်ချက်ကို ကျော်လွန်လုပ်ဆောင်ပါမည်။

သင် ကြေညာထားသော ဗားရှင်းနှင့် အမှန်တကယ်လည်ပတ်နေသော ဗားရှင်းတို့သည် မတူညီသော အချက်အလက်များ ဖြစ်ကြပါသည်။ zinnector dev --once သည် runtime ကို စတင်လည်ပတ်စေပြီး၊ ၎င်းအမှန်တကယ် အစီရင်ခံသည့်အရာများဖြစ်သော — PHP ဗားရှင်း၊ WordPress ဗားရှင်း၊ ထည့်သွင်းထားသော တိုးချဲ့မှုများ — ကို ပြသကာ ရပ်တန့်သွားပါသည်။ zinnector check --probe သည် သင့်ပရောဂျက်ကို hosting slot တစ်ခုနှင့် နှိုင်းယှဉ်သည့်အခါ အဆိုပါ တိုင်းတာချက်ကိုပင် အသုံးပြုပါသည်။

သင့်ပရောဂျက်မှ မည်သည့်အရာကို ဝန်ဆောင်မှုပေးသနည်း

runtime သည် သင့်ပရောဂျက်၏ wp-content/plugins၊ wp-content/themes နှင့် wp-content/mu-plugins directory များကို တိုက်ရိုက် mount လုပ်ထားသောကြောင့် သင်သိမ်းဆည်းလိုက်သော ဖိုင်တစ်ခုသည် နောက်တစ်ကြိမ် reload လုပ်ရာတွင် တိုက်ရိုက်အကျိုးသက်ရောက်မှု ရှိစေပါသည်။ တည်ရှိနေသော်လည်း အမှန်တကယ် အကြောင်းအရာမရှိသော directory များကို ရည်ရွယ်ချက်ရှိရှိဖြင့် mount မလုပ်ပါ- runtime ၏ ကိုယ်ပိုင်သီးမူးများပေါ်တွင် အလွတ်ဖြစ်နေသော themes/ ကို mount လုပ်မိပါက WordPress တွင် မည်သည့်သီးမူးမျှ မကျန်တော့ဘဲ သင့်ဆိုက်အစား 500 error အလွတ်သာ ပေါ်လာမည်ဖြစ်ပါသည်။ ထို့ကြောင့် scaffold သည် အလွတ် directory များကို .gitkeep ဖြင့် ထိန်းသိမ်းထားခြင်းဖြစ်ပြီး သင်သည် ၎င်းတို့အတွင်းသို့ သီးမူးတစ်ခု မထည့်မချင်း မည်သည့်အရာကိုမျှ ဖုံးကွယ်သွားမည် မဟုတ်ပါ။

Runtime သည် မည်သည့်နေရာတွင် တည်ရှိသနည်း

WordPress runtime ကို CLI နှင့်အတူ ပူးတွဲပေးပို့ခြင်းထက် ပထမဆုံးအကြိမ် အသုံးပြုချိန်တွင် ဒေါင်းလုဒ်လုပ်ပါသည် — PHP build တိုင်းပါဝင်သော package သည် 570 MB ခန့်ရှိပြီး ဆိုက်များကို စာရင်းကြည့်ရုံသာ ပြုလုပ်မည့် developer တစ်ဦးအနေဖြင့် ၎င်းအတွက် ပေးဆပ်ရန်မလိုသင့်ပါ။ ၎င်းကို Zinnector® ၏ ကိုယ်ပိုင် cache ဖြစ်သည့် ~/.cache/zinnector/runtimes/playground/<version> (သို့မဟုတ် ZINNECTOR_CACHE_DIR ညွှန်ပြသည့်နေရာ) တွင် ထားရှိပြီး သင့်ပရောဂျက်ထဲတွင် မည်သည့်အခါမျှ မထားရှိသောကြောင့် သင့် repository ထဲသို့သော်လည်းကောင်း၊ zinnector push တိုင်းတာသည့် tree ထဲသို့သော်လည်းကောင်း ရောက်ရှိသွားမည် မဟုတ်ပါ။ ဒေါင်းလုဒ်လုပ်ခြင်းကို သင့်ကိုယ်ပိုင် npm ဖြင့် node npm-cli.js အဖြစ် လုပ်ဆောင်ခြင်းဖြစ်ပြီး — shell မှတစ်ဆင့် မည်သည့်အခါမျှ မပြုလုပ်ပါ။

runtime ဗားရှင်းကို CLI ဗားရှင်းနှင့် ချိတ်ဆက်ထားသောကြောင့် ပရောဂျက်တစ်ခုတည်းရှိ developer နှစ်ဦးသည် တူညီသော PHP build များကို လည်ပတ်စေမည် ဖြစ်ပါသည်။ zinnector dev --reset-runtime သည် ထည့်သွင်းထားသော runtime ကို ဖယ်ရှားပြီး ပြန်လည်ထည့်သွင်းပေးပါသည်၊ ၎င်းသည် ထည့်သွင်းထားသော်လည်း စတင်လည်ပတ်၍မရသော runtime တစ်ခုအတွက် ဖြေရှင်းနည်းဖြစ်ပါသည်။

Node 26 သို့မဟုတ် နောက်ပိုင်းဗားရှင်းများတွင်

CLI ကိုယ်တိုင်သည် 24 မှစ၍ မည်သည့် Node တွင်မဆို လည်ပတ်နိုင်ပါသည်။ သို့သော် runtime ၏ native module သည် Node 24 နှင့် 25 အတွက်သာ ကြိုတင် build လုပ်ထားသော binary များကို ပံ့ပိုးပေးပါသည် (စက်တင်ဘာ ၂၀၂၆ အထိ)။ မည်သည့်အရာကိုမျှ compile လုပ်နေမည့်အစား — Windows တွင် ယင်းသည် Visual Studio ကို ထည့်သွင်းရမည်ဟု ဆိုလိုသည် — Zinnector® သည် runtime တစ်ခုတည်းအတွက်သာ ရည်ရွယ်ပြီး nodejs.org မှ ထုတ်ပြန်သော checksum များနှင့် ကိုက်ညီမှုစစ်ဆေးထားသည့် 30 MB ခန့်ရှိသော Node 24 ကို အဆိုပါ cache ထဲသို့ ဆွဲယူပေးပါသည်။ ၎င်းအကျုံးဝင်သည့်အခါ install prompt က ထိုအကြောင်းကို အသိပေးပါမည်။ သင့်ကိုယ်ပိုင် Node နှင့်ပတ်သက်၍ မည်သည့်အရာမျှ ပြောင်းလဲမည် မဟုတ်ပါ။

ဆက်စပ်အကြောင်းအရာများ

• စတင်ခြင်း · Deploy ပြုလုပ်ခြင်း · Command လမ်းညွှန် · ပြဿနာဖြေရှင်းခြင်း