Baza wiedzy
Błędy, na które użytkownicy rzeczywiście napotykają w Zinnector® CLI, oraz rozwiązania każdego z nich: spawn EINVAL w systemie Windows, ostrzeżenie EBADENGINE od npm, node-gyp wymagający Visual Studio w Node 26, EPERM podczas instalacji, środowisko uruchomieniowe, które się nie uruchamia, oraz zajęty port.
Błędy, na które użytkownicy rzeczywiście natrafiają w CLI Zinnector®, znaczenie każdego z nich oraz sposób naprawy. Każdy wpis zawiera dokładny tekst komunikatu, dzięki czemu można go wyszukać na tej stronie. Jeśli danego błędu tu nie ma, proszę uruchomić problematyczne polecenie ze zmienną ZINNECTOR_DEBUG=1 i otworzyć zgłoszenie na stronie github.com/Zinn-Digital/zinnector/issues, podając dane wyjściowe, wersję node --version oraz swój system operacyjny.
Błąd w Zinnector® w wersjach 0.1.0 i 0.1.1. W systemie Windows instalator środowiska uruchamiał plik npm.cmd według nazwy, a od czasu poprawki dla błędu CVE-2024-27980 Node odmawia uruchamiania plików .cmd bez powłoki — instalacja zawieszała się więc sekundę po wpisaniu odpowiedzi Y. Naprawiono w wersji 0.1.2: npm jest teraz uruchamiany jako node npm-cli.js, co działa tak samo na każdej platformie i nie wymaga powłoki. Proszę uruchomić npm install -g zinnector@latest, a następnie ponownie zinnector dev.
Zainstalowana wersja środowiska Node jest starsza niż 24. npm wyświetla to ostrzeżenie, ponieważ pakiet deklaruje engines: >=24.18.1; instalacja kończy się mimo to, ale zinnector odmawia uruchomienia (kod wyjścia 78), zamiast powodować mylące błędy na późniejszym etapie. Proszę zainstalować bieżącą wersję LTS ze strony nodejs.org — za pomocą winget install OpenJS.NodeJS.LTS w systemie Windows lub brew install node@24 w systemie macOS — upewnić się, że polecenie node --version zwraca v24 lub wyższą, i ponownie zainstalować Zinnector®.
Środowisko wykonawcze WordPress zawiera moduł natywny, którego wstępnie skompilowane pliki binarne istnieją tylko dla Node 24 i 25. W przypadku nowszej wersji Node (od wersji 26 wzwyż, stan na wrzesień 2026 r.) instalator przechodzi w tryb kompilacji ze źródeł, co na standardowym komputerze z systemem Windows kończy się żądaniem instalacji środowiska Visual Studio. Naprawiono w wersji 0.1.2: Zinnector® wykrywa to przed pobraniem czegokolwiek i pobiera Node 24 wyłącznie na potrzeby środowiska wykonawczego — około 30 MB, zweryfikowane pod kątem sum kontrolnych nodejs.org — dzięki czemu nic nie musi być kompilowane. Jeśli po aktualizacji problem nadal występuje, proszę uruchomić zinnector dev --reset-runtime, aby najpierw usunąć niedokończoną instalację z przeszłości.
Prawie zawsze jest to program antywirusowy lub indeksator wyszukiwania blokujący otwarty plik w katalogu node_modules środowiska wykonawczego, podczas gdy npm próbuje go usunąć. Instalacja jest ponawiana z czystego katalogu przy następnym wywołaniu zinnector dev; jeśli błąd nadal występuje, polecenie zinnector dev --reset-runtime najpierw usuwa cały katalog środowiska i instaluje je ponownie.
Komunikat zawiera ostatnie wiersze wygenerowane przez npm oraz dokładne polecenie uruchomione przez Zinnector®, więc można uruchomić je samodzielnie, aby zobaczyć pełne dane wyjściowe. Najczęstszymi przyczynami są problemy z siecią lub serwerem proxy — środowisko jest pobierane za pomocą lokalnej instalacji npm, więc obowiązują ustawienia npm config set proxy … oraz serwer lustrzany rejestru — albo niedokończona wcześniejsza instalacja, którą usuwa flaga --reset-runtime.
Proszę uruchomić zinnector dev --verbose, aby zobaczyć dane wyjściowe samego środowiska wykonawczego. Częstą przyczyną jest zajęty port: proszę użyć zinnector dev --port 9401 lub ustawić port w pliku zinnector.json. W przypadku środowiska, które zostało zainstalowane, ale nie chce się uruchomić: zinnector dev --reset-runtime. Pierwsze uruchomienie pobiera również sam WordPress, więc przy wolniejszym połączeniu należy odczekać kilka minut; CLI czeka do pięciu minut przed zgłoszeniem przekroczenia limitu czasu, zamiast zawieszać działanie.
Wdrożenia bazują na repozytorium, dlatego zinnector push wymaga repozytorium ze zdalnym serwerem (remote), do którego platforma ma dostęp. Proszę wykonać git init && git add -A && git commit -m initial, dodać zdalne repozytorium GitHub lub GitLab, a następnie uruchomić zinnector link, aby połączyć je z witryną.
Proszę uruchomić zinnector check. W dziewięciu na dziesięć przypadków przyczyną jest różnica wersji PHP — projekt został zbudowany na nowszej wersji PHP niż uruchomiona w danym slocie — a raport wskaże, na którą wersję przełączyć slot za pomocą zinnector php <version> lub z którą wersją prowadzić prace programistyczne za pomocą zinnector dev --php <version>. Polecenie zinnector logs --error wyświetla sam błąd krytyczny.
Co pisaliśmy o hostingu, SEO i prowadzeniu witryn na dużą skalę.
Jak hosting wpływa na indeksowanie i link equity w 2026 roku: utrzymywanie zindeksowanych stron, weryfikacja domen z historią przed rozpoczęciem prac, link building bez zostawiania śladów (footprint) oraz szczera ocena tego, co infrastruktura może, a czego nie może zrobić dla SEO.
Przeczytaj wpis →Praktyczna lista kontrolna dla szybkiego i bezpiecznego WordPress: buforowanie na poziomie serwera, pamięć podręczna obiektów dla poszczególnych witryn, garść wtyczek wartych uruchomienia, utrzymywanie aktualnego stosu technologicznego oraz strony WooCommerce, których nigdy nie należy buforować.
Przeczytaj wpis →Co naprawdę odróżnia dobry hosting zarządzany od taniej maszyny z panelem sterowania — migracje, kopie zapasowe, izolacja, prawdziwe buforowanie i uczciwe skalowanie — oraz jak to ocenić przed podjęciem decyzji.
Przeczytaj wpis →Pomoc jest wliczona w każdy plan, dział wsparcia jest czynny przez 24 godzin na dobę i możesz pisać do nas w dowolnym z naszych 58 języków – odpowiadamy w twoim.
Skontaktuj się z pomocą techniczną → Wszystkie artykuły →