zinnector նոր
Ստեղծեք կայքի, փլագինի կամ բլոկային թեմայի կառուցվածքը, որն անմիջապես գործարկվում է: Ոչ մի տեղապահ ֆայլ, ոչ մի TODO — փլագինն ակտիվանում է, իսկ թեման կարող է ընտրվել ստեղծման պահից:
Zinnector®
Zinnector®-ը կառուցում է WordPress-ը տեղական մակարդակում՝ առանց որևէ այլ բան տեղադրելու, բացի Node-ից — առանց Docker-ի, առանց MAMP-ի — ապա ստուգում է ձեր կառուցածը այն հոսթինգի սլոտի հետ, որտեղ պատրաստվում եք տեղակայել, և նախքան push անելը հայտնում է ձեզ, թե ինչը չի համապատասխանի: Տեղադրեք այն npm install -g zinnector-ի միջոցով: Այն անվճար է, ունի MIT արտոնագիր և կառուցված է նույն հանրային API-ի վրա, ինչ այստեղ մնացած ամեն ինչ:
Հոսթինգի CLI-ների մեծ մասը սկսում է տեղակայման փուլից: Zinnector®-ը սկսում է դրանից առաջ՝ այն կառուցում է կայքը Ձեզ հետ միասին, ապա ստուգում է Ձեր աշխատանքն այն մեքենայի հետ համեմատ, որին պատրաստվում եք ուղարկել այն: «Իմ նոութբուքի վրա աշխատում էր» և «այն աշխատում է սերվերի վրա» միջև եղած անդունդն այն տեղն է, որտեղ անցնում են կեսօրները, և այդ անդունդը չափելի է:
Ստեղծեք կայքի, փլագինի կամ բլոկային թեմայի կառուցվածքը, որն անմիջապես գործարկվում է: Ոչ մի տեղապահ ֆայլ, ոչ մի TODO — փլագինն ակտիվանում է, իսկ թեման կարող է ընտրվել ստեղծման պահից:
Իսկական WordPress ձեր համակարգչում վայրկյանների ընթացքում՝ մատուցելով ձեր սեփական փլագիններն ու թեմաները, առանց Docker-ի և առանց PHP-ի ձեր PATH-ում: Ընտրեք ցանկացած PHP 5.2-ից մինչև 8.5՝ ծրագրավորելու համար:
Նախնական ստուգում: Համեմատում է ձեր կառուցածը այն սլոտի հետ, որտեղ պատրաստվում եք տեղակայել, և նշում է յուրաքանչյուր անհամապատասխանություն — և յուրաքանչյուր ստուգում, որը չի հաջողվել կատարել — նախքան ուղարկելը:
Կատարեք նախնական ստուգում, ուղարկեք ձեր commit-ները, գործարկեք տեղակայումը և հետևեք դրան մինչև ավարտը: Եթե այն ձախողվի, կառուցման մատյանը ընդամենը մեկ հրամանի հեռավորության վրա է:
Հարցրեք օգնականին տերմինալից՝ օգտագործելով ձեր նախագիծը և ձեր կայքը որպես համատեքստ: Այն աշխատում է հարթակում ձեր սեփական հաշվի միջոցով, ուստի մոդելի որևէ բանալի երբեք չի պահվում ձեր սարքում:
Վեց հրաման՝ ըստ հերթականության, և ինչպիսին է հաջողության արդյունքը յուրաքանչյուրում: Այստեղ ամեն ինչ աշխատում է ձեր սեփական մեքենայում. API բանալի պահանջվում է միայն այն ժամանակ, երբ հասնում եք հոսթինգի սլոտին:
Գործարկեք npm install -g zinnector-ը Node 24 կամ ավելի նոր տարբերակում: Եթե npm-ը տպում է EBADENGINE, ձեր Node-ը 24-ից հին է — տեղադրեք ընթացիկ LTS-ը nodejs.org-ից և կրկին գործարկեք տեղադրումը:
zinnector --version-ը տպում է տարբերակի համար, օրինակ՝ 0.1.2: 24-ից հին Node-ի դեպքում այն տպում է հաղորդագրություն այն մասին, որ անհրաժեշտ է Node 24 կամ ավելի նոր տարբերակ, և ավարտում է աշխատանքը:
zinnector --help-ը ստորև թվարկում է յուրաքանչյուր հրաման իր նպատակի մեկտողանոց նկարագրությամբ։ Յուրաքանչյուր հրաման ընդունում է նաև իր սեփական --help տարբերակը։
zinnector new my-site-ը ստեղծում է նախագիծ, որն անմիջապես գործարկվում է՝ zinnector.json, wp-content ծառային կառուցվածք և README, և տպում է հաջորդ գործարկվելիք հրամանները:
cd my-site, այնուհետև zinnector dev: Առաջին գործարկումը մեկ անգամ խնդրում է ներբեռնել WordPress գործարկման միջավայրը (մոտ 570 ՄԲ, պահվում է CLI-ի սեփական քեշում, երբեք ոչ ձեր նախագծում): Հաջողության դեպքում ցուցադրվում է «running at http://127.0.0.1:9400»:
http://127.0.0.1:9400-ը WordPress-ի նոր կայք է, /wp-admin-ը բացում է կառավարման վահանակն արդեն մուտք գործած վիճակում: Տեղադրեք փլագին wp-content/plugins պանակում, և այն հասանելի կլինի հաջորդ վերաբեռնման ժամանակ:
zinnector login, zinnector link, zinnector check, zinnector push — նախապես ստուգեք ձեր ստեղծածը սլոթի նկատմամբ, ապա տեղակայեք և հետևեք ավարտին:
Դուք կառուցել եք PHP 8.3-ի վրա: Սլոտն աշխատեցնում է 8.1-ը: Ոչինչ ձեզ չի տեղեկացնում, քանի դեռ կայքը չի սպիտակել: Սա այն խնդիրն է, որի համար գոյություն ունի այս հրամանը, և սա հենց այն է, ինչ այս հարթակի սեփականատերը խնդրել էր անվանապես: Zinnector®-ը կարդում է երկու միջավայրերն էլ և դնում դրանք կողք կողքի — ապա թույլ է տալիս ձեզ միևնույն է տեղակայել, քանի որ դուք կարող եք պատճառ ունենալ:
Հիմնական տարբերակի տարբերությունը նշվում է որպես բարձր, քանի որ այն հաստատապես խաթարում է կայքի աշխատանքը. չնչին տարբերությունը նշվում է ավելի ցածր: Ամեն ինչ որպես կրիտիկական դասակարգելը մարդկանց պարզապես սովորեցնում է անտեսել նախազգուշացումը:
WordPress-ի ծառը բաղկացած է տասնյակ հազարավոր փոքր ֆայլերից, և կայքը կարող է սպառել իր inode-ի սահմանաչափը՝ գտնվելով իր սկավառակի սահմանաչափից զգալիորեն ցածր մակարդակի վրա: Երկուսն էլ ստուգվում են ոչ թե ըստ պլանի, այլ ըստ նրա, թե իրականում ինչ է մնացել սլոտում:
Ստուգումը, որը չի կարողանում տեսնել իր առարկան, հաղորդում է չստուգված լինելու մասին, բայց երբեք՝ հաջողված։ Մաքուր գործարկումը նշում է, թե քանի բան չի կարողացել ստուգել, քանի որ կեղծ հանգստացնող ազդանշանին ոչ ոք կրկին չի նայում։
Յուրաքանչյուր արդյունք կարող է շրջանցվել --force-ի միջոցով, և ամփոփումը նշում է այդ մասին: CI-ում դրա փոխարեն ելքային կոդն է ծառայում որպես անցակետ, ուստի փայփլայնը կարող է լինել խիստ, մինչդեռ մարդը պահպանում է վերահսկողությունը:
WordPress Playground-ը լռելյայն տարբերակն է. WebAssembly-ում կոմպիլացված PHP-ն աշխատում է Node-ի ներսում, այնպես որ նոութբուքը, որտեղ տեղադրված է միայն Node, զրոյից անցնում է աշխատող WordPress-ի մոտավորապես այն ժամանակահատվածում, որն անհրաժեշտ է այս նախադասությունը կարդալու համար:
Երբ ձեզ անհրաժեշտ է բնօրինակ PHP՝ imagick-ի նման ընդլայնում, իրական MySQL, փոխանցեք --runtime docker և փոխարենը ստացեք php-fpm ու MariaDB կոնտեյներներ: Երկուսն էլ սպասարկում են նույն նախագծի նույն ֆայլերը, ուստի դրանց միջև անցումը փոխում է միայն շարժիչը և ուրիշ ոչինչ:
Zinnector®-ը ստեղծված է նույն հանրային API-ի վրա, ինչ կառավարման վահանակը, ուստի այն ամենը, ինչ կարող է անել վահանակը, կարող է անել նաև այն — և յուրաքանչյուր հրաման փաստաթղթավորված գործողություն է OpenAPI-ի տեխնիկական բնութագրում, այլ ոչ թե անձնական վերջնակետ:
Թվարկեք կայքերը, կարդացեք այն ամենը, ինչ հարթակը գիտի որևէ մեկի մասին, վերատեղակայեք և կարդացեք տեղակայման պատմությունն ու կառուցման մատյանները:
Թվարկեք տիրույթները, կարդացեք և փոփոխեք DNS գրառումները՝ նախքան գրառումը պահպանելը այն ցուցադրելով, ինչպես նաև կարդացեք ձեր փոստային ծառայությունները:
Փոխեք PHP-ի տարբերակները, ստուգեք սկավառակի և inode-երի օգտագործումը՝ Ձեր սակագնային պլանի տրամադրած սահմանաչափերի համեմատ, ստացեք միանգամյա օգտագործման հղումներ դեպի phpMyAdmin և իրական ժամանակում հետևեք մուտքի ու սխալների մատյաններին:
Գործարկեք կայքում թույլատրված WP-CLI հրամանները և մաքրեք հիշապահեստը կամ գործարկեք վնասակար ծրագրերի սկանավորումներ ամբողջ ընտրանու համար մեկ կանչով՝ յուրաքանչյուր կայքի համար առանձին կանչի փոխարեն:
Ամբողջական ցանկը, յուրաքանչյուրը մեկ տողում։ Ամբողջական տեղեկատուն՝ յուրաքանչյուր դրոշակ, գործարկվող օրինակ և այն, ինչ տպում է յուրաքանչյուր հրաման, գեներացվում է հենց CLI-ից և գտնվում է ծրագրավորողների փաստաթղթերում ու գիտելիքների բազայում, ուստի չի կարող տարբերվել ձեր տեղադրած գործիքից։
Ստեղծեք WordPress նախագծի հիմնակմախքը, որը կարող եք անմիջապես գործարկել:
Գործարկեք այս նախագիծը տեղայնորեն — Docker չի պահանջվում:
Մուտք գործեք Zinn Digital® API բանալիով:
Մոռանալ պահված API բանալին:
Ցույց տալ, թե ում անունով է նույնականացված այս CLI-ն:
Թվարկեք այն կայքերը, որոնք այս բանալին կարող է տեսնել:
Այն ամենը, ինչ հարթակը գիտի մեկ կայքի մասին:
Տվեք մեկ անձի մուտքի իրավունք դեպի մեկ կայք՝ ծրագրավորողի, դիզայների, հաճախորդի՝ դերով և պատճառով։
Տեսեք, թե ում է տրամադրվել կայքի հասանելիություն, նրանց դերը և արդյոք նրանք արդեն ընդունել են հրավերը։
Հետ կանչեք անձի մուտքի իրավունքը էլ. փոստի կամ տրամադրման նույնացուցիչի միջոցով:
Ձեզ սպասող հրավերները, և ընդունեք մեկը:
Ուղղորդեք այս նախագիծը դեպի հոսթինգի սլոթ (և միացրեք դրա ռեպոզիտորիան):
Տեղական մշակման համար քաշեք հոսթինգ ունեցող կայքի ֆայլերը այս նախագծի մեջ և նորից գործարկեք՝ վերասինխրոնացնելու համար: Օգտագործում է արագ ուղին, երբ կայքը սինխրոնացվում է իր սեփական պահոցի հետ, հակառակ դեպքում աշխատում է վերջին պահուստային պատճենից:
Երկկողմանի սինխրոնիզացիա հոսթինգում գտնվող կայքի ակտիվ ֆայլերի և դրա պահոցի (repository) միջև. տեսեք ընթացիկ վիճակը, միացրեք այն, հաստատեք (commit) կայքի փոփոխությունները կամ ընտրեք, թե որ կողմն ունի առաջնահերթություն:
Կամուրջ դեպի Zinn Digital® MCP սերվեր Claude Desktop-ի և AI այլ հաճախորդների համար, որոնք գործարկում են միայն տեղական սերվերներ:
Ստեղծեք լոկալ նախագիծ հոսթինգում գտնվող կայքից մեկ քայլով. կլոնավորեք դրա ռեպոզիտորիան կամ քաշեք դրա ֆայլերը, գրեք նախագծի ֆայլը և պատրաստ եղեք գործարկել zinnector dev-ը:
Համեմատեք այս նախագիծն այն սլոտի հետ, որտեղ պատրաստվում եք տեղակայել:
Կատարեք նախնական ստուգում, ուղարկեք ձեր փոփոխությունները և տեղակայեք:
Կրկին տեղակայեք այն, ինչ հարթակն արդեն ունի, առանց push-ի:
Կայքի տեղակայման պատմություն:
Ցուցադրել կամ փոխել կայքի PHP տարբերակը:
Սկավառակի, ֆայլերի և տվյալների բազայի օգտագործումը՝ ըստ սակագնային պլանով նախատեսվածի։
Տվյալների բազայի չափը և մեկանգամյա օգտագործման հղումներ դեպի phpMyAdmin և ֆայլերի կառավարիչ:
Հետևեք կայքի մուտքի և սխալների մատյաններին իրական ժամանակում:
Գործարկեք թույլատրված WP-CLI հրաման կայքում:
Ցուցակագրել և ստեղծել կայքի պահուստային պատճեններ։ Ենթահրամաններ՝ list, now։
Թվարկեք այն տիրույթները, որոնք այս բանալին կարող է տեսնել:
Կարդացեք և փոփոխեք DNS գրառումները: Ենթահրամաններ՝ list, add, rm:
Ցուցակագրել փոստային ծառայությունները:
Գործարկեք մեկ գործողություն մի քանի կայքերում (cache_purge, malware_scan, sitemap, block_ip):
Հարցրեք Zinn Digital®-ի օգնականին՝ այս նախագիծը որպես համատեքստ օգտագործելով:
Ոչ: `zinnector new`-ի և `zinnector dev`-ի համար ընդհանրապես հաշիվ անհրաժեշտ չէ — ստեղծեք փլագինի, թեմայի կամ ամբողջ կայքի կմախքը և գործարկեք այն տեղայնորեն, անվճար, ընդմիշտ: API բանալի պահանջվում է միայն այն հրամանների համար, որոնք հաղորդակցվում են ձեր հոսթինգի հետ:
Ոչ լռելյայն runtime-ի համար։ WordPress Playground-ը կոմպիլացնում է PHP-ն WebAssembly-ի և աշխատում Node-ի ներսում, այնպես որ `zinnector dev`-ը վայրկյանների ընթացքում գործարկում է իրական WordPress՝ առանց որևէ այլ բան տեղադրելու։ Եթե Ձեզ անհրաժեշտ է բնիկ PHP՝ imagick կամ ionCube ընդլայնումը փորձարկելու համար, ապա `--runtime docker`-ը փոխարենը տրամադրում է php-fpm և MariaDB կոնտեյներներ։ Երկուսն էլ ապահովվում են. դրանցից ոչ մեկը պահուստային տարբերակ չէ։
Ձեր տեղային PHP տարբերակը սլոթի տարբերակի համեմատ, արդյոք սլոթը կարող է անցնել այն տարբերակին, որի վրա կառուցել եք, արդյոք սլոթի PHP-ի շահագործման ժամկետն ավարտվել է, և արդյոք մեքենան իրականում կիրառել է այն, ձեր նախագծի չափը և ֆայլերի քանակը՝ մնացած սկավառակի և inode-ի ազատ տարածության համեմատ, WordPress տարբերակները յուրաքանչյուր կողմում, արդյոք սլոթն ավարտել է նախապատրաստումը, և արդյոք կապված է git պահոց տեղակայում իրականացնելու համար: Այն ամենը, ինչ հնարավոր չի եղել ստուգել, հաջողված համարվելու փոխարեն գրանցվում է որպես չստուգված:
Ոչ, և դա միտումնավոր է: Նախնական ստուգումը նախազգուշացնում է և թույլ է տալիս շարունակել. `--force`-ը տեղակայում է՝ շրջանցելով ցանկացած բացահայտում: Դուք ձեր կայքի մասին գիտեք բաներ, որոնք ստուգիչը չգիտի, իսկ այն գործիքը, որը հրաժարվում է տեղակայել, մարդիկ ապատեղադրում են:
Բանալին երբեք չի կարդացվում հրամանի տողից — միայն հուշումից կամ փոխանցված stdin-ից — այնպես որ այն չի կարող հայտնվել ձեր shell-ի պատմության մեջ կամ գործընթացների ցանկում: Այն պահվում է ձեր սեփական կազմաձևման գրացուցակում՝ 600 ֆայլի ռեժիմով, և Zinnector®-ը վերահաստատում է այդ թույլտվությունները ամեն անգամ գրելիս:
Այո։ Սահմանեք `ZINNECTOR_TOKEN`-ը, և յուրաքանչյուր հրաման ընդունում է `--json`։ Մարդու համար նախատեսված ելքը գնում է stderr, իսկ տվյալները՝ stdout, այնպես որ խողովակները (pipes) մնում են մաքուր։ `zinnector check`-ը ավարտվում է ոչ զրոյական կոդով, երբ որևէ բան է գտնում, ուստի այն գործում է որպես pipeline gate, իսկ `--strict`-ը նույնպես ձախողվում է, երբ համեմատություն հնարավոր չէր կատարել։
Գործարկեք npm install -g zinnector-ը կամ փորձեք այն մեկ անգամ npx zinnector new my-site-ով: Անվճար է, MIT արտոնագրով և կառուցված հանրային API-ի հիման վրա: Ստեղծեք նախագծի հիմնակմախքը, գործարկեք այն տեղում առանց Docker-ի և նախնական ստուգում անցկացրեք նախքան տեղակայելը:
Կարդացեք փաստաթղթերը