Գիտելիքների բազա

Տեղական մշակում zinnector dev-ի միջոցով

Ինչպես է zinnector dev-ը գործարկում իրական WordPress ձեր սեփական մեքենայի վրա. երկու միջավայրերը (WebAssembly՝ առանց Docker-ի, կամ բնօրինակ PHP՝ Docker-ում), PHP-ի և WordPress-ի տարբերակի ընտրությունը, այն, թե ինչ է մատուցվում ձեր նախագծից, որտեղ է տեղակայված 570 ՄԲ ծավալով միջավայրը, և ինչ է տեղի ունենում Node 26-ում:

zinnector dev-ն աշխատեցնում է իսկական WordPress Ձեր սեփական համակարգչի վրա՝ սպասարկելով Ձեր նախագծի փլագիններն ու թեմաները Ձեր ընտրած PHP տարբերակով: Այս հոդվածը բացատրում է երկու աշխատանույթերը (runtimes), որոնք այն կարող է օգտագործել, ինչպես ընտրել տարբերակները, ինչն որտեղից է սպասարկվում, և որտեղ է գտնվում աշխատանույթը սկավառակի վրա, որպեսզի այն, ինչ տեղայնորեն փորձարկում եք, համապատասխանի տեղակայվող տարբերակին:

Երկու աշխատանույթերը և թե ինչու են երկուսն էլ իսկական

Playground-ը լռելյայն տարբերակն է: WordPress Playground-ը կոմպիլյացնում է PHP-ն WebAssembly-ի և աշխատեցնում է այն Node-ի ներսում, այնպես որ այն նոթբուքը, որի վրա ոչինչ տեղադրված չէ, բացի Node-ից, գործարկում է WordPress-ը վայրկյանների ընթացքում: Հասանելի է ցանկացած PHP 5.2-ից մինչև 8.5 տարբերակ: Այն պարունակում է PHP ընդլայնումների փոքր հավաքածու (intl, redis, memcached՝ ըստ ընթացիկ կառուցվածքի (build) չափումների), ինչը բավարար է փլագինների և թեմաների աշխատանքի մեծ մասի համար:

Docker-ն աշխատեցնում է native php-fpm և MariaDB կոնտեյներներ: Այն ավելի դանդաղ է, պահանջում է Docker daemon և մոտ 1.2 ԳԲ պատկերներ (images) ու աջակցում է PHP 7.4-ից մինչև 8.5 տարբերակները, սակայն այն աշխատեցնում է native PHP ընդլայնումների ամբողջական հավաքածուով, ներառյալ imagick-ը և gd-ն: Սա ազնիվ լուծում է, երբ Ձեզ անհրաժեշտ է փորձարկել մի ընդլայնում, որը WebAssembly կառուցվածքը չի պարունակում:

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

Docker-ին երբեք լռելյայն չի վերադառնում (fallback): Այն մշակողը, ով կարծում է, թե օգտագործում է 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-ի կողմից, և որոնք Դուք պետք է ավելացնեք տարբերակների կառավարման համակարգ (commit), որպեսզի նախագծի վրա աշխատող բոլոր անձինք աշխատեցնեն նույն տարբերակները: Հրամանային տողի դրոշակը (flag) գերակայում է ֆայլի նկատմամբ տվյալ գործարկման համար:

Այն տարբերակը, որը Դուք հայտարարում եք, և այն տարբերակը, որը աշխատում է, տարբեր փաստեր են: zinnector dev --once-ը գործարկում է աշխատանույթը, տպում է այն, ինչ իրականում զեկուցվում է (PHP տարբերակը, WordPress տարբերակը, բեռնված ընդլայնումները) և կանգ առնում: zinnector check --probe-ն օգտագործում է նույն չափումը, երբ համեմատում է Ձեր նախագիծը հոսթինգի սլոթի հետ:

Ինչ է սպասարկվում Ձեր նախագծից

Աշխատանույթն ուղղակիորեն կցում է (mounts) Ձեր նախագծի wp-content/plugins, wp-content/themes և wp-content/mu-plugins պապկաները, այնպես որ Ձեր պահպանած ֆայլն անմիջապես ակտիվանում է հաջորդ վերաբեռնման ժամանակ: Այն պապկաները, որոնք գոյություն ունեն, բայց իրական բովանդակություն չեն պարունակում, միտումնավոր չեն կցվում. աշխատանույթի սեփական թեմաների վրա կցված դատարկ themes/ պապկան WordPress-ը կթողնի ընդհանրապես առանց թեմայի, ինչը Ձեր կայքի փոխարեն դատարկ 500 սխալ կցուցադրի: Ահա թե ինչու կառուցվածքը (scaffold) պահպանում է դատարկ պապկաները .gitkeep-ով, և թե ինչու դրանք չեն քողարկում որևէ բան, քանի դեռ դրանց մեջ թեմա չեք տեղադրել:

Որտեղ է գտնվում աշխատանույթը

WordPress աշխատանույթը ներբեռնվում է առաջին օգտագործման ժամանակ, այլ ոչ թե մատակարարվում է CLI-ի հետ. փաթեթը, որը պարունակում է PHP-ի բոլոր կառուցվածքները, մոտ 570 ՄԲ է, և այն մշակողը, ով միայն ցուցակագրում է կայքերը, չպետք է ծանրաբեռնվի դրանով: Այն պահվում է 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 և ավելի բարձր ցանկացած տարբերակի վրա: Աշխատանույթի native մոդուլը, սակայն, մատակարարում է նախապես կառուցված (prebuilt) բինար ֆայլեր միայն Node 24-ի և 25-ի համար (2026 թվականի սեպտեմբերի դրությամբ): Որևէ բան կոմպիլյացնելու փոխարեն (ինչը Windows-ում նշանակում է Visual Studio-ի տեղադրում), Zinnector®-ը ներբեռնում է Node 24 միայն աշխատանույթի համար (մոտ 30 ՄԲ), որը ստուգված է nodejs.org-ի հրապարակած ստուգիչ գումարների (checksums) հետ, նույն քեշի մեջ: Տեղադրման հարցումը տեղեկացնում է այդ մասին, երբ այն կիրառվում է: Ձեր սեփական Node-ի հետ կապված ոչինչ չի փոխվում:

Առնչվող հոդվածներ

Դեռ խնդի՞ր կա:

Աջակցությունը ներառված է յուրաքանչյուր սակագնային պլանում, և պատասխանները տրվում են ձեր սեփական լեզվով։

Կապվել աջակցման ծառայության հետ Բոլոր հոդվածները