nowy zinnector
Stwórz szkielet witryny, wtyczki lub motywu blokowego, który uruchamia się natychmiast. Żadnych plików zastępczych, żadnych zadań TODO — wtyczka aktywuje się, a motyw można wybrać w momencie jego utworzenia.
Zinnector®
Zinnector® tworzy lokalne środowisko WordPress bez niczego zainstalowanego oprócz Node – bez Dockera, bez MAMP – a następnie sprawdza to, co zostało zbudowane, pod kątem zgodności z miejscem hostingu, na które masz zamiar wdrożyć projekt, i informuje Cię, co nie będzie pasować, zanim wdrożysz zmiany. Zainstaluj go za pomocą npm install -g zinnector. Jest darmowy, posiada licencję MIT i został stworzony na bazie tego samego publicznego API co wszystkie inne narzędzia tutaj.
Większość interfejsów CLI hostingu zaczyna się od wdrożenia. Zinnector® zaczyna się wcześniej — buduje witrynę razem z Tobą, a następnie sprawdza Twoją pracę w odniesieniu do maszyny, na którą zamierzasz ją wysłać. Przepaść między „to działało na moim laptopie” a „to działa na serwerze” to czas, który bezpowrotnie mija, a tę przepaść można zmierzyć.
Stwórz szkielet witryny, wtyczki lub motywu blokowego, który uruchamia się natychmiast. Żadnych plików zastępczych, żadnych zadań TODO — wtyczka aktywuje się, a motyw można wybrać w momencie jego utworzenia.
Prawdziwy WordPress na Twoim komputerze w kilka sekund, obsługujący Twoje własne wtyczki i motywy, bez Dockera i bez PHP w zmiennej PATH. Wybierz dowolną wersję PHP od 5.2 do 8.5 do prac programistycznych.
Kontrola przedwddrożeniowa. Porównuje to, co zbudowano, ze slotem, na który ma nastąpić wdrożenie, i wskazuje każdą niezgodność oraz każdą weryfikację, której nie udało się przeprowadzić, zanim wykonasz powiadomienie (push).
Przed startem zatwierdź zmiany, wyzwól wdrożenie i monitoruj jego postęp aż do ukończenia. Jeśli się nie powiedzie, dziennik kompilacji dzieli od Ciebie tylko jedno polecenie.
Zapytaj asystenta z poziomu terminala, uwzględniając swój projekt i witrynę jako kontekst. Działa on na platformie w ramach Twojego konta, dzięki czemu żadne klucze modelu nie są przechowywane na Twoim komputerze.
Six commands, in order, and what success looks like at each one. Everything here runs on your own machine; an API key is only needed when you reach a hosting slot.
Run npm install -g zinnector on Node 24 or newer. If npm prints EBADENGINE, your Node is older than 24 — install the current LTS from nodejs.org and run the install again.
zinnector --version prints a version number such as 0.1.2. On a Node older than 24 it prints a message saying Node 24 or newer is needed, and exits.
zinnector --help lists every command below with a one-line purpose. Every command also takes --help of its own.
zinnector new my-site creates a project that boots immediately — a zinnector.json, a wp-content tree and a README — and prints the next commands to run.
cd my-site, then zinnector dev. The first run asks once to download the WordPress runtime (about 570 MB, kept in the CLI’s own cache, never in your project). Success looks like “running at http://127.0.0.1:9400”.
http://127.0.0.1:9400 is a fresh WordPress site; /wp-admin opens the dashboard already signed in. Drop a plugin into wp-content/plugins and it is there on the next reload.
zinnector login, zinnector link, zinnector check, zinnector push — pre-flight what you built against the slot, then deploy and watch it finish.
Budujesz na PHP 8.3. Slot obsługuje wersję 8.1. Nic Ci o tym nie mówi, dopóki strona nie padnie. Właśnie po to istnieje ta nazwa komendy, i o nią poprosił z imienia właściciel tej platformy. Zinnector® odczytuje oba środowiska i stawia je obok siebie — a potem i tak pozwala na wdrożenie, bo możesz mieć powód.
Rozbieżność w głównej wersji jest oznaczana jako wysokie zagrożenie, ponieważ bezbłędnie powoduje awarię witryny; mniejsza rozbieżność jest oznaczana niżej. Ocenianie wszystkiego jako krytycznego uczy ludzi jedynie ignorowania ostrzeżenia.
Drzewo WordPress składa się z dziesiątek tysięcy małych plików, a witryna może wyczerpać swój limit węzłów (inode), nawet jeśli jej zajętość dysku jest znacznie poniżej limitu. Oba parametry są sprawdzane pod kątem tego, co faktycznie pozostało na koncie, a nie w planie.
Kontrola, która nie widzi swojego przedmiotu, zgłasza brak sprawdzenia i nigdy nie kończy się sukcesem. Czysty przebieg informuje, ilu rzeczy nie udało mu się zweryfikować, ponieważ fałszywy komunikat o braku błędów to ten, któremu nikt nie przygląda się dwa razy.
Każde ustalenie można pominąć za pomocą --force, o czym informuje podsumowanie. W środowisku CI rolę blokady pełni kod wyjścia, dzięki czemu potok może być restrykcyjny, podczas gdy człowiek zachowuje kontrolę.
WordPress Playground to domyślne rozwiązanie: PHP skompilowane do WebAssembly, działające w środowisku Node, dzięki czemu laptop z zainstalowanym wyłącznie środowiskiem Node przechodzi od zera do działającego WordPress w około tyle czasu, ile zajmuje przeczytanie tego zdania.
Gdy potrzebujesz natywnego języka PHP — rozszerzenia takiego jak imagick, prawdziwej bazy danych MySQL — użyj parametru --runtime docker, aby w zamian otrzymać kontener php-fpm i MariaDB. Oba obsługują te same pliki z tego samego projektu, więc przełączanie się między nimi zmienia jedynie silnik i nic więcej.
Zinnector® został zbudowany na tym samym publicznym interfejsie API co panel sterowania, więc wszystko, co potrafi panel, potrafi i on – a każde polecenie jest udokumentowaną operacją w specyfikacji OpenAPI, a nie prywatnym punktem końcowym.
Wyświetlaj listę witryn, odczytuj wszystkie informacje, jakie platforma o nich posiada, wdrażaj ponownie oraz przeglądaj historię wdrożeń i logi budowania.
Wyświetlanie domen, odczytywanie i edytowanie rekordów DNS z wyświetleniem rekordu przed jego zapisaniem oraz odczytywanie usług pocztowych.
Przełączaj wersje PHP, sprawdzaj zużycie dysku i inodów w porównaniu z limitami swojego planu, generuj jednorazowe linki do phpMyAdmin oraz śledź logi dostępu i błędów na bieżąco.
Wykonuj polecenia WP-CLI z białej listy dla danej witryny oraz czyszcz pamięć podręczną lub uruchamiaj skanowanie złośliwego oprogramowania dla całego wyboru za pomocą jednego wywołania zamiast osobnego dla każdej witryny.
The full list, one line each. The complete reference — every flag, a runnable example and what each command prints — is generated from the CLI itself and lives in the developer docs and the knowledge base, so it cannot drift from the tool you have installed.
Scaffold a WordPress project you can run immediately.
Run this project locally — no Docker required.
Sign in with a Zinn Digital® API key.
Forget a stored API key.
Show who this CLI is authenticated as.
List the sites this key can see.
Everything the platform knows about one site.
Give one person access to a single site — a developer, a designer, a client — with a role and a reason.
See who has been given access to a site, their role, and whether they have accepted yet.
Take a person's access back, by email or grant id.
The invitations waiting for you, and accept one.
Point this project at a hosting slot (and connect its repository).
Pull a hosted site's files into this project for local development, and re-run to re-sync. Takes the fast path when the site syncs to its own repository, otherwise works from the latest backup.
Make a local project from a hosted site in one step: clone its repository or pull its files, write the project file, and leave you ready to run zinnector dev.
Compare this project against the slot you are about to deploy to.
Pre-flight, push your commits, and deploy.
Redeploy what the platform already has, without pushing.
A site's deploy history.
Show or switch a site's PHP version.
Disk, files and database usage against what the plan grants.
Database size, and single-use links into phpMyAdmin and the file manager.
Tail a site's access and error logs.
Run an allow-listed WP-CLI command on a site.
List and take site backups. Subcommands: list, now.
List the domains this key can see.
Read and change DNS records. Subcommands: list, add, rm.
List mail services.
Run one operation across many sites (cache_purge, malware_scan, sitemap, block_ip).
Ask the Zinn Digital® assistant, with this project as context.
Nie. Polecenia `zinnector new` i `zinnector dev` nie wymagają żadnego konta – możesz utworzyć szkielet wtyczki, motywu lub całej witryny i uruchomić ją lokalnie, za darmo i na zawsze. Klucz API jest potrzebny tylko w przypadku poleceń, które łączą się z Twoim hostingiem.
Nie dotyczy domyślnego środowiska wykonawczego. WordPress Playground kompiluje PHP do WebAssembly i działa wewnątrz Node, więc `zinnector dev` uruchamia prawdziwego WordPressa w kilka sekund bez instalowania czegokolwiek innego. Jeśli potrzebujesz natywnego PHP – aby przetestować rozszerzenie takie jak imagick lub ionCube – `--runtime docker` udostępnia w zamian kontener php-fpm oraz MariaDB. Oba rozwiązania są obsługiwane; żadne z nich nie jest rozwiązaniem zastępczym.
Twoja lokalna wersja PHP w porównaniu z wersją slotu, czy slot w ogóle może przełączyć się na wersję, na której zbudowano projekt, czy wersja PHP slotu nie ma już wsparcia i czy maszyna faktycznie ją zastosowała, rozmiar Twojego projektu i liczba plików w odniesieniu do pozostałego miejsca na dysku i wolnych inodów, wersje WordPress po obu stronach, czy slot zakończył wdrażanie oraz czy z biurkiem powiązane jest repozytorium git, z którego ma następować wdrożenie. Wszystko, czego nie udało się sprawdzić, jest zgłaszane jako niesprawdzone, a nie zaliczone.
Nie, i jest to celowe. Kontrola przedstartowa ostrzega i pozwala przejść dalej — `--force` wdraża pomimo wszelkich wykrytych problemów. Znasz swoją witrynę lepiej niż jakikolwiek skaner, a narzędzie, które odmawia wdrożenia, to narzędzie, które użytkownicy odinstalowują.
Klucz nigdy nie jest odczytywany z wiersza poleceń – wyłącznie z monitu lub potoku wejściowego (stdin) – dzięki czemu nie trafi do historii powłoki ani na listę procesów. Jest przechowywany we własnym katalogu konfiguracyjnym z trybem pliku 600, a Zinnector® przy każdym zapisie ponownie wymusza te uprawnienia.
Tak. Ustaw `ZINNECTOR_TOKEN`, a każde polecenie obsługuje flagę `--json`. Komunikaty dla użytkownika trafiają do stderr, a dane do stdout, dzięki czemu potoki pozostają czyste. Polecenie `zinnector check` kończy działanie kodem błędu (non-zero) po wykryciu problemu, co pozwala stosować je jako bramkę w potoku, a flaga `--strict` powoduje awarię również w przypadku braku możliwości porównania.
Uruchom npm install -g zinnector lub wypróbuj go raz za pomocą npx zinnector new my-site. Bezpłatne narzędzie na licencji MIT, oparte na publicznym API. Stwórz szkielet projektu, uruchom go lokalnie bez Dockera i przetestuj przed wdrożeniem.
Przeczytaj dokumentację