új zinnector
Hozza létre egy webhely, egy bővítmény vagy egy azonnal induló blokktéma vázát. Nincsenek helyőrző fájlok, nincsenek TODO-k – a bővítmény aktiválódik, és a téma a létrejötte pillanatában kiválasztható.
Zinnector®
A Zinnector® helyileg építi fel a WordPress-t úgy, hogy a Node-on kívül semmi más nincs telepítve – se Docker, se MAMP –, majd a push előtt összeveti az Ön által felépített tartalmat azzal a tárhely-slottal, ahová telepíteni készül, és jelzi, mi nem fog egyezni. Telepítse az npm install -g zinnector paranccsal. Ingyenes, MIT-licenccel rendelkezik, és ugyanarra a nyilvános API-ra épül, mint minden más itt.
A legtöbb tárhely-CLI a telepítéskor lép működésbe. A Zinnector® ennél korábban kezd — Önnel együtt építi fel az oldalt, majd ellenőrzi a munkáját azon a gépen, amelyre elküldeni készül. „A laptopomon még működött” és „A szerveren fut” közötti szakadékban vesznek el a délutánok, és ez a szakadék mérhető.
Hozza létre egy webhely, egy bővítmény vagy egy azonnal induló blokktéma vázát. Nincsenek helyőrző fájlok, nincsenek TODO-k – a bővítmény aktiválódik, és a téma a létrejötte pillanatában kiválasztható.
Egy valódi WordPress a gépén másodpercek alatt, amely kiszolgálja saját bővítményeit és sablonjait, Docker és a PATH-ban lévő PHP nélkül. Válasszon bármilyen PHP verziót 5.2-től 8.5-ig a fejlesztéshez.
Az előellenőrzés. Összehasonlítja az Ön által létrehozott tartalmat azzal a slottal, amelyre telepíteni készül, és a pusholás előtt megnevez minden eltérést — és minden olyan ellenőrzést, amelyet nem tudott elvégezni.
Végezze el az előzetes ellenőrzést, küldje be a commitokat, indítsa el a telepítést, és kövesse nyomon a befejezésig. Ha sikertelen, a build napló mindössze egyetlen parancsra van.
Kérdezze a segédet a terminálból, a projektjét és webhelyét kontextusként használva. A platformon, az Ön saját fiókjában fut, így a gépén soha nem tárolódik modellkulcs.
Hat parancs, sorrendben, és a sikeres kimenet kinézete mindegyiknél. Itt minden a saját gépén fut; API-kulcsra csak akkor van szükség, amikor elér egy tárhely-helyet.
Futtassa az npm install -g zinnector parancsot Node 24 vagy újabb verzió alatt. Ha az npm az EBADENGINE hibát írja ki, az Ön Node verziója régebbi, mint 24 — telepítse a jelenlegi LTS verziót a nodejs.org oldalról, és futtassa újra a telepítést.
A zinnector --version kiírja a verziószámot, például 0.1.2. A 24-esnél régebbi Node esetén kiír egy üzenetet, miszerint a Node 24 vagy újabb szükséges, és kilép.
A zinnector --help az alábbiakban felsorolja az összes parancsot egy-egy soros leírással. Mindegyik parancs elfogad egy saját --help opciót is.
A zinnector new my-site egy azonnal elinduló projektet hoz létre — egy zinnector.json fájlt, egy wp-content fastruktúrát és egy README fájlt —, majd kiírja a következőként futtatandó parancsokat.
cd my-site, majd zinnector dev. Az első futtatás egyszer kéri a WordPress futtatókörnyezet letöltését (kb. 570 MB, a CLI saját gyorsítótárában tárolva, soha nem az Ön projektjében). A sikeres futás így néz ki: „running at http://127.0.0.1:9400”.
A http://127.0.0.1:9400 egy új WordPress webhely; a /wp-admin már bejelentkezve nyitja meg a vezérlőpultot. Másoljon be egy bővítményt a wp-content/plugins könyvtárba, és a következő újratöltéskor ott lesz.
zinnector login, zinnector link, zinnector check, zinnector push — ellenőrizze előzetesen az elkészített elemet a slottal szemben, majd telepítse, és kövesse figyelemmel a befejezést.
Ön a PHP 8.3-as verziójára fejlesztett. A tárhelyfiók a 8.1-es verziót futtatja. Semmi sem jelzi ezt, amíg a webhely teljesen üres fehér képernyővé nem válik. Ez az a probléma, amelyre ez a parancs létezik, és ezt kérte név szerint a platform tulajdonosa is. A Zinnector® mindkét környezetet beolvassa és egymás mellé állítja őket — majd lehetővé teszi, hogy mindezek ellenére telepítsen, hiszen lehet rá nyomós oka.
A főverzió-eltérést magas prioritásúnak jelöljük, mivel az biztosan működésképtelenné teszi a webhelyet; a kisebb eltérést alacsonyabb prioritással látjuk el. Ha mindent kritikusnak minősít, az csak arra tanítja az embereket, hogy hagyják figyelmen kívül a figyelmeztetést.
Egy WordPress fa struktúra több tízezer apró fájlból áll, és egy webhely kimerítheti az inode keretét, miközben jóval a lemezkorlátja alatt marad. Mindkettőt a sloton ténylegesen fennmaradó kapacitás alapján ellenőrzik, nem pedig a csomag alapján.
Az az ellenőrzés, amely nem látja a tárgyát, ellenőrizetlenként jelent, soha nem sikeresként. Egy tiszta futás jelzi, hány dolgot nem tudott ellenőrizni, mert senki sem néz meg kétszer egy téves hibamentes jelzést.
Minden megállapítás felülbírálható a --force kapcsolóval, és az összegzés ezt jelzi is. A CI-ben ehelyett a kilépési kód jelenti a korlátot, így a folyamat szigorú lehet, miközben az irányítás az ember kezében marad.
A WordPress Playground az alapértelmezett: a WebAssembly-be lefordított PHP a Node-on belül fut, így egy olyan laptop, amelyre semmi más nincs telepítve, csak a Node, nagyjából annyi idő alatt jut el a semmiből a működő WordPress-ig, mint amennyi e mondat elolvasásához szükséges.
Ha natív PHP-re van szüksége – egy olyan kiterjesztésre, mint az imagick, vagy egy valódi MySQL-re –, adja át a --runtime docker paramétert, és használjon helyette php-fpm és MariaDB konténereket. Mindkettő ugyanazokat a fájlokat szolgálja ki ugyanabból a projektből, így a váltás kizárólag a motort módosítja, mást nem.
A Zinnector® ugyanarra a nyilvános API-ra épül, mint a vezérlőpult, így bármit, amire a panel képes, azt ez is képes megtenni — és minden parancs egy dokumentált művelet az OpenAPI-specifikációban, nem pedig egy privát végpont.
Webhelyek listázása, a platform által az adott webhelyről ismert összes adat olvasása, újbóli üzembe helyezés, valamint az üzembe helyezési előzmények és a buildnaplók olvasása.
Domainek listázása, DNS-rekordok olvasása és módosítása úgy, hogy a rekord a beírás előtt megjelenik, valamint a levelezési szolgáltatások olvasása.
Váltson PHP-verziót, kövesse nyomon a lemez- és inode-használatot a díjcsomagja által biztosított kerethez képest, kapjon egyszer használatos hivatkozásokat a phpMyAdmin felületére, és kövesse valós időben a hozzáférési és hibanaplókat.
Futtasson engedélyezőlistán szereplő WP-CLI-parancsokat egy webhelyen, és ürítse a gyorsítótárakat vagy indítson kártevő-ellenőrzéseket egy teljes kijelölésen egyetlen hívással ahelyett, hogy webhelyenként külön végezné el.
A teljes lista, soronként egy tétel. A teljes referencia — minden jelző, egy futtatható példa és az egyes parancsok kimenete — közvetlenül a CLI-ből generálódik, és a fejlesztői dokumentációban, valamint a tudásbázisban található, így nem térhet el a telepített eszköztől.
Hozza létre egy azonnal futtatható WordPress projekt vázát.
Futtassa ezt a projektet helyileg — Docker nem szükséges.
Jelentkezzen be egy Zinn Digital® API-kulccsal.
Tárolt API-kulcs elfelejtése.
Annak megjelenítése, hogy ez a CLI kiként van hitelesítve.
Sorolja fel azokat a webhelyeket, amelyeket ez a kulcs láthat.
Minden, amit a platform egy webhelyről tud.
Adjon hozzáférést egyetlen személynek egyetlen webhelyhez — egy fejlesztőnek, egy tervezőnek, egy ügyfélnek — egy szerepkörrel és egy indokkal.
Tekintse meg, ki kapott hozzáférést a webhelyhez, mi a szerepköre, és hogy elfogadta-e már a meghívást.
Vonja vissza egy személy hozzáférését e-mail vagy megadási azonosító alapján.
Az Önre váró meghívók, és fogadjon el egyet.
Irányítsa ezt a projektet egy tárhely-tárolóhelyre (és csatlakoztassa a tárolóját).
Húzza be egy üzemeltetett webhely fájljait ebbe a projektbe a helyi fejlesztéshez, és futtassa újra az újraszinkronizáláshoz. A gyors utat választja, ha a webhely a saját tárolójával szinkronizál, ellenkező esetben a legújabb biztonsági mentésből dolgozik.
Kétirányú szinkronizálás a tárhelyen lévő webhely élő fájljai és a repositoryja között: tekintse meg az állapotát, kapcsolja be, véglegesítse a webhely módosításait, vagy válassza ki, melyik oldal élvezzen prioritást.
Híd a Zinn Digital® MCP kiszolgálóhoz a Claude Desktop és egyéb, kizárólag helyi kiszolgálókat indító AI ügyfelek számára.
Hozzon létre egy helyi projektet egy hosztolt webhelyből egyetlen lépésben: klónozza a tárolóját vagy töltse le a fájljait, írja meg a projektfájlt, és álljon készen a zinnector dev futtatására.
Hasonlítsa össze ezt a projektet azzal a slottal, amelybe telepíteni készül.
Végezzen előzetes ellenőrzést, küldje be a módosításokat, és telepítsen.
Telepítse újra azt, amivel a platform már rendelkezik, push nélkül.
Egy webhely telepítési előzményei.
Egy webhely PHP-verziójának megjelenítése vagy váltása.
Tárhely-, fájl- és adatbázis-használat a csomag által biztosított mértékhez viszonyítva.
Adatbázis mérete, valamint egyszer használatos hivatkozások a phpMyAdmin és a fájlkezelő eléréséhez.
Kövesse valós időben egy webhely hozzáférési és hibanaplóit.
Futtasson engedélyezett WP-CLI-parancsot egy webhelyen.
Webhely biztonsági mentéseinek listázása és létrehozása. Alparancsok: list, now.
Sorolja fel azokat a tartományokat, amelyeket ez a kulcs láthat.
DNS-rekordok olvasása és módosítása. Alparancsok: list, add, rm.
Levelezési szolgáltatások listázása.
Futtasson le egy műveletet több webhelyen (cache_purge, malware_scan, sitemap, block_ip).
Kérdezze meg a Zinn Digital® asszisztenst, ezt a projektet használva környezetként.
Nem. A `zinnector new` és a `zinnector dev` egyáltalán nem igényel fiókot — hozza létre egy bővítmény, sablon vagy egy teljes webhely vázát, és futtassa helyileg, ingyen, örökre. API-kulcs csak azokhoz a parancsokhoz szükséges, amelyek a tárhelyével kommunikálnak.
Az alapértelmezett futtatókörnyezethez nem. A WordPress Playground a PHP-t WebAssembly-re fordítja, és a Node-on belül fut, így a `zinnector dev` másodpercek alatt elindít egy valódi WordPress-t anélkül, hogy bármi mást telepíteni kellene. Ha natív PHP-ra van szüksége – például egy olyan kiterjesztés teszteléséhez, mint az imagick vagy az ionCube –, a `--runtime docker` ehelyett php-fpm és MariaDB konténereket biztosít az Ön számára. Mindkettő támogatott; egyik sem biztonsági tartalékmegoldás.
Az Ön helyi PHP-verziója a slot verziójához képest, hogy a slot egyáltalán képes-e átváltani arra a verzióra, amelyre épített, hogy a slot PHP-verziója elérte-e már az élettartama végét, és hogy a gép ténylegesen alkalmazta-e azt, a projekt mérete és a fájlok száma a fennmaradó lemezterülethez és inód-kapacitáshoz képest, a WordPress-verziók mindkét oldalon, befejeződött-e a slot kiépítése, valamint hogy van-e csatlakoztatva git-tároló a telepítéshez. Bármi, amit nem tudott ellenőrizni, sikeres teszt helyett ellenőrizetlenként jelenik meg.
Nem, és ez szándékos. Az előzetes ellenőrzés figyelmeztet, de engedi a folytatást — a `--force` figyelmen kívül hagy minden észlelést a telepítés során. Ön olyan dolgokat is tud a saját webhelyéről, amelyeket egy ellenőrző nem, és egy olyan eszközt, amely megtagadja a telepítést, az emberek eltávolítanak.
A kulcs soha nem a parancssorból kerül beolvasásra — csak egy promptból vagy átirányított stdin-ből —, így nem kerülhet be a shell előzményeibe vagy a folyamatok listájába. A saját konfigurációs könyvtárában kerül tárolásra 600-as fájlmóddal, és a Zinnector® minden íráskor újra megerősíti ezeket az engedélyeket.
Igen. Állítsa be a `ZINNECTOR_TOKEN` környezeti változót, és minden parancs elfogadja a `--json` kapcsolót. Az ember által olvasható kimenet a stderr-re, az adatok pedig a stdout-ra kerülnek, így a pipe-ok tiszták maradnak. A `zinnector check` nem nulla kóddal lép ki, ha talál valamit, így pipeline kapuként működik, és a `--strict` is hibával zárul, ha az összehasonlítás nem végezhető el.
Futtassa a npm install -g zinnector parancsot, vagy próbálja ki egyszer a npx zinnector new my-site segítségével. Ingyenes, MIT licences és a nyilvános API-ra épül. Hozza létre a projekt vázát, futtassa helyileg Docker nélkül, és végezzen előzetes ellenőrzést az élesítés előtt.
Dokumentáció elolvasása