нов zinnector
Генерирайте базова структура на сайт, разширение или блокова тема, които стартират веднага. Без временни заместващи файлове, без TODO задачи — разширението се активира, а темата може да бъде избрана в момента на създаването ѝ.
Zinnector®
Zinnector® изгражда WordPress локално без нищо инсталирано освен Node — без Docker, без MAMP — след това проверява изграденото от вас спрямо хостинг слота, в който предстои да внедрите, и ви казва какво няма да съвпадне, преди да публикувате. Инсталирайте го с npm install -g zinnector. Той е безплатен, с лиценз MIT и изграден върху същия публичен API като всичко останало тук.
Повечето CLI за хостинг започват при внедряване. Zinnector® започва преди това — той изгражда сайта заедно с Вас и след това проверява работата Ви спрямо машината, към която се готвите да го изпратите. Разликата между „работеше на лаптопа ми“ и „работи на сървъра“ е мястото, където изчезват следобедите, и тази разлика е измерима.
Генерирайте базова структура на сайт, разширение или блокова тема, които стартират веднага. Без временни заместващи файлове, без TODO задачи — разширението се активира, а темата може да бъде избрана в момента на създаването ѝ.
Истински WordPress на вашата машина за секунди, обслужващ вашите собствени плъгини и теми, без Docker и без PHP във вашия PATH. Изберете произволен PHP от 5.2 до 8.5 за разработка.
Предполетната проверка. Сравнява това, което сте създали, със слота, в който предстои да внедрите, и посочва всяко несъответствие — и всяка проверка, която не е могла да бъде направена — преди да направите push.
Направете предварителна проверка, изпратете вашите комити, стартирайте внедряването и го наблюдавайте до завършване. Ако е неуспешно, дневникът на компилацията е само на една команда разстояние.
Попитайте асистента от терминала, използвайки вашия проект и вашия сайт като контекст. Той се изпълнява на платформата във вашия собствен акаунт, така че на вашето устройство никога не се съхранява ключ за модела.
Шест команди, последователно, и как изглежда успехът при всяка от тях. Всичко тук работи на собствената Ви машина; ключ за API е необходим само когато стигнете до слот за хостинг.
Изпълнете npm install -g zinnector на Node 24 или по-нова версия. Ако npm изведе EBADENGINE, Вашият Node е по-стар от 24 — инсталирайте текущата версия LTS от nodejs.org и стартирайте инсталацията отново.
zinnector --version извежда номер на версията като например 0.1.2. При версия на Node, по-стара от 24, извежда съобщение, че е необходим Node 24 или по-нова версия, и прекратява изпълнението.
zinnector --help изброява всяка команда по-долу с описание на целта в един ред. Всяка команда също така приема своя собствена опция --help.
zinnector new my-site създава проект, който се стартира веднага — zinnector.json, дървовидна структура на wp-content и README — и извежда следващите команди за изпълнение.
cd my-site, след това zinnector dev. Първото изпълнение изисква еднократно изтегляне на средата за изпълнение на WordPress (около 570 MB, съхранява се в собствения кеш на 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 е по подразбиране: PHP, компилиран до WebAssembly, работещ в Node, така че лаптоп само с инсталиран Node преминава от нулата до работещ WordPress за приблизително толкова време, колкото е необходимо за прочитането на това изречение.
Когато се нуждаете от нативен PHP — разширение като imagick, истински MySQL — подайте --runtime docker и вземете вместо това контейнери с php-fpm и MariaDB. И двата обслужват едни и същи файлове от един и същ проект, така че превключването между тях променя само двигателя и нищо друго.
Zinnector® е изграден върху същия публичен API като таблото за управление, така че всичко, което панелът може да прави, може да се прави и от него — и всяка команда е документирана операция в спецификацията на OpenAPI, а не частна крайна точка.
Извеждане на списък със сайтове, преглед на всичко, което платформата знае за даден сайт, повторно внедряване и преглед на историята на внедряванията и регистрационните файлове за компилиране.
Изброяване на домейни, четене и промяна на DNS записи с показване на записа преди записването му и четене на вашите пощенски услуги.
Превключвайте версиите на PHP, проверявайте използването на диска и inode спрямо предоставеното от вашия план, получете връзки за еднократна употреба към phpMyAdmin и следете в реално време регистрационните файлове за достъп и грешки.
Изпълнявайте разрешени WP-CLI команди за даден сайт и изчиствайте кешовете или стартирайте сканирания за зловреден софтуер за цяла селекция с едно извикване, вместо поотделно за всеки сайт.
Пълният списък, по един ред за всяко. Пълната справка — всеки флаг, пример за изпълнение и това, което всяка команда извежда — се генерира от самия CLI и се намира в документацията за разработчици и базата от знания, така че не може да се разминава с инструмента, който сте инсталирали.
Генерирайте базова структура за проект на WordPress, който можете да стартирате веднага.
Стартирайте този проект локално — не се изисква Docker.
Влезте с API ключ на Zinn Digital®.
Забравяне на запазен API ключ.
Показване като кого е удостоверен този CLI.
Избройте сайтовете, които този ключ може да вижда.
Всичко, което платформата знае за един сайт.
Предоставете достъп на един човек до един сайт — разработчик, дизайнер, клиент — с роля и причина.
Вижте на кого е предоставен достъп до даден сайт, каква е неговата роля и дали вече е приел поканата.
Отнемете достъпа на дадено лице чрез имейл или идентификатор на предоставяне.
Поканите, които ви чакат, и приемете една.
Насочете този проект към хостинг слот (и свържете хранилището му).
Изтеглете файловете на хоствания сайт в този проект за локална разработка и стартирайте отново за повторно синхронизиране. Използва бързия път, когато сайтът се синхронизира със собственото си хранилище, в противен случай работи от най-новото резервно копие.
Двупосочно синхронизиране между файловете на живо на хостван сайт и неговото хранилище: вижте текущото състояние, включете го, комитнете промените на сайта или изберете коя страна да има предимство.
Мост към Zinn Digital® MCP сървъра за Claude Desktop и други AI клиенти, които стартират само локални сървъри.
Създайте локален проект от хостван сайт в една стъпка: клонирайте хранилището му или изтеглете файловете му, запишете файла на проекта и бъдете готови да стартирате zinnector dev.
Сравнете този проект със слота, в който предстои да внедрите.
Направете предварителна проверка, изпратете промените си и внедрете.
Внедрете отново това, с което платформата вече разполага, без изтласкване.
История на внедряването на сайта.
Показване или превключване на PHP версията на сайт.
Използване на диск, файлове и база данни спрямо позволеното от плана.
Размер на базата данни и връзки за еднократна употреба към phpMyAdmin и файловия мениджър.
Проследявайте в реално време регистрационните файлове за достъп и грешки на сайта.
Изпълнете разрешена команда на WP-CLI на даден сайт.
Извеждане на списък и създаване на резервни копия на сайта. Подкоманди: list, now.
Избройте домейните, които този ключ може да вижда.
Преглеждайте и променяйте DNS записи. Подкоманди: list, add, rm.
Изброяване на пощенските услуги.
Изпълнение на една операция в множество сайтове (cache_purge, malware_scan, sitemap, block_ip).
Попитайте асистента на Zinn Digital®, като използвате този проект за контекст.
Не. За `zinnector new` и `zinnector dev` изобщо не е необходим акаунт — генерирайте структура на плъгин, тема или цял сайт и го стартирайте локално, безплатно, завинаги. API ключ е необходим само за командите, които комуникират с вашия хостинг.
Не и за средата за изпълнение по подразбиране. WordPress Playground компилира PHP до WebAssembly и се изпълнява в Node, така че `zinnector dev` стартира истински WordPress за секунди, без да е инсталирано нищо друго. Ако се нуждаете от нативен PHP — за да тествате разширение като imagick или ionCube — `--runtime docker` Ви предоставя вместо това контейнери с php-fpm и MariaDB. И двете се поддържат; нито едното не е резервен вариант.
Вашата локална версия на PHP спрямо тази на слота, дали слотът изобщо може да превключи към версията, на която сте компилирали, дали PHP на слота е с изтекъл срок на експлоатация и дали машината действително го е приложила, размерът на Вашия проект и броят на файловете спрямо оставащия дисков и inode капацитет, версиите на WordPress от всяка страна, дали слотът е завършил подготовката си и дали е свързано git хранилище за внедряване. Всичко, което не е могло да бъде проверено, се отчита като непроверено, вместо да се зачита като успешно.
Не, и това е умишлено. Предварителната проверка предупреждава и Ви позволява да продължите — `--force` внедрява независимо от откритите проблеми. Вие знаете за своя сайт неща, които инструментът за проверка не знае, а инструмент, който отказва да внедрява, е инструмент, който хората деинсталират.
Ключът никога не се чете от командния ред — само от подкана или подаден чрез stdin — така че не може да се озове в историята на вашата обвивка или в списък с процеси. Той се съхранява във вашата собствена конфигурационна директория с файлов режим 600, а Zinnector® потвърждава отново тези разрешения всеки път, когато записва.
Да. Задайте `ZINNECTOR_TOKEN` и всяка команда приема `--json`. Човешкият изход отива в stderr, а данните – в stdout, така че каналите остават чисти. `zinnector check` излиза с ненулев код, когато открие нещо, така че работи като шлюз в конвейера, а `--strict` също се проваля, когато не може да се направи сравнение.
Изпълнете npm install -g zinnector или го изпробвайте еднократно с npx zinnector new my-site. Безплатен, с лиценз MIT и изграден върху публичния API. Създайте структурата на проекта, стартирайте го локално без Docker и направете предварителна проверка преди внедряване.
Прочетете документацията