zinnector नवीन
त्वरित बूट होणारी साइट, प्लगइन किंवा ब्लॉक थीमची रचना तयार करा. कोणत्याही प्लेसहोल्डर फाइल्स नाहीत, कोणतेही TODOs नाहीत — प्लगइन सक्रिय होते आणि थीम तयार होताच निवडली जाऊ शकते.
Zinnector®
WordPress होस्टिंगसाठी डेव्हलपर CLI
Zinnector® केवळ Node व्यतिरिक्त इतर काहीही इन्स्टॉल न करता स्थानिक पातळीवर WordPress तयार करते — Docker नाही, MAMP नाही — नंतर आपण डिप्लॉय करणार असलेल्या होस्टिंग स्लॉटशी आपण तयार केलेल्या गोष्टींची पडताळणी करते आणि पुश करण्यापूर्वी काय जुळणार नाही हे आपल्याला सांगते. npm install -g zinnector सह ते इन्स्टॉल करा. हे विनामूल्य आहे, MIT-परवानाधारक आहे आणि येथील इतर सर्व गोष्टींप्रमाणेच समान सार्वजनिक API वर तयार केले आहे.
पाच कमांड्स, आणि मधली ही मुख्य बाब आहे
बहुतेक होस्टिंग CLI डिप्लॉयपासून सुरू होतात. Zinnector® त्यापूर्वीच सुरू होते — ते तुमच्यासोबत साइट तयार करते आणि नंतर तुम्ही ज्या मशीनवर ती पाठवणार आहात त्याच्याशी तुमच्या कामाची पडताळणी करते. "ते माझ्या लॅपटॉपवर चालले" आणि "ते सर्व्हरवर चालते" यामधील अंतरामध्येच दुपारचा वेळ निघून जातो, आणि ते अंतर मोजण्यायोग्य आहे.
zinnector dev
तुमच्या स्वतःच्या प्लगइन्स आणि थीम्ससह, तुमच्या PATH वर कोणतेही Docker आणि PHP नसताना, काही सेकंदांत तुमच्या मशीनवर प्रत्यक्ष WordPress मिळवा. डेव्हलपमेंटसाठी 5.2 ते 8.5 मधील कोणतीही PHP निवडा.
झिनेक्टर तपासणी
प्री-फ्लाइट तपासणी. तुम्ही जे तयार केले आहे त्याची तुलना तुम्ही ज्या स्लॉटवर डिप्लॉय करणार आहात त्याशी करते आणि तुम्ही पुश करण्यापूर्वी प्रत्येक विसंगती — आणि ती करू न शकलेली प्रत्येक तपासणी — नमूद करते.
झिननेक्टर पुश
पूर्व-तपासणी करा, तुमचे कमिट पुश करा, डिप्लॉय सुरू करा आणि पूर्ण होईपर्यंत त्याचे निरीक्षण करा. ते अयशस्वी झाल्यास, बिल्ड लॉग फक्त एका कमांडच्या अंतरावर आहे.
zinnector ai
तुमचा प्रकल्प आणि तुमची साइट संदर्भ म्हणून ठेवून टर्मिनलवरून सहाय्यकाला विचारा. हे तुमच्या स्वतःच्या खात्याद्वारे प्लॅटफॉर्मवर चालते, त्यामुळे तुमच्या मशीनवर कोणतीही मॉडेल की कधीही साठवली जात नाही.
दोन मिनिटांत हे कसे कार्य करते ते तपासा, खात्याची आवश्यकता नाही
क्रमाने सहा आज्ञा आणि प्रत्येकामध्ये यश कसे दिसते. येथील प्रत्येक गोष्ट तुमच्या स्वतःच्या मशीनवर चालते; जेव्हा तुम्ही होस्टिंग स्लॉटवर पोहोचता तेव्हाच API की आवश्यक असते.
हे स्थापित करा
Node 24 किंवा नवीन आवृत्तीवर npm install -g zinnector चालवा. npm ने EBADENGINE मुद्रित केल्यास, तुमचे Node 24 पेक्षा जुने आहे — nodejs.org वरून वर्तमान LTS स्थापित करा आणि स्थापना पुन्हा चालवा.
आवृत्ती तपासा
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 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® दोन्ही वातावरण वाचतो आणि ते समोरासमोर ठेवतो — तरीही तुम्हाला डिप्लॉय करण्याची मुभा देतो, कारण कदाचित तुमच्याकडे एखादे कारण असू शकते.
PHP, प्रामाणिकपणे मूल्यमापन केलेले
मुख्य-आवृत्तीतील अंतर उच्च म्हणून चिन्हांकित केले जाते कारण ते निश्चितपणे साइट खंडित करते; किरकोळ अंतर कमी म्हणून चिन्हांकित केले जाते. प्रत्येक गोष्टीला गंभीर म्हणून श्रेणीबद्ध करणे लोकांना केवळ चेतावणीकडे दुर्लक्ष करण्यास शिकवते.
डिस्क आणि फाइल संख्या, स्वतंत्रपणे
WordPress ट्रीमध्ये हजारो लहान फायली असतात, आणि एखादी साइट तिच्या डिस्क मर्यादेच्या खूप खाली असतानाही तिचा inode कोटा संपवू शकते. या दोन्ही गोष्टी योजनेनुसार नव्हे, तर स्लॉटवर प्रत्यक्षात काय शिल्लक आहे यावरून तपासल्या जातात.
“तपासणी करता आली नाही” हे स्वतःच एक उत्तर आहे
जी तपासणी स्वतःचा विषय पाहू शकत नाही, ती कधीही उत्तीर्ण झाल्याचा अहवाल देत नाही तर न तपासल्याचा अहवाल देते. एक निर्दोष रन अशा किती गोष्टींची पडताळणी होऊ शकली नाही हे दर्शवतो, कारण सर्व काही ठीक असल्याच्या खोट्या अहवालाकडे कोणीही पुन्हा पाहत नाही.
इशारा देतो, कधीही ब्लॉक करत नाही
प्रत्येक निष्कर्ष --force द्वारे ओव्हरराइड केला जाऊ शकतो, आणि सारांशात तसेच नमूद केले आहे. CI मध्ये त्याऐवजी एक्झिट कोड हा गेट म्हणून काम करतो, त्यामुळे व्यक्तीचे नियंत्रण कायम असताना पाइपलाइन कठोर असू शकते.
दोन स्थानिक रनटाईम्स, दोन्ही वास्तविक
WordPress Playground हे डीफॉल्ट आहे: WebAssembly मध्ये कंपाईल केलेले PHP, Node च्या आत चालते, त्यामुळे केवळ Node इन्स्टॉल असलेला लॅपटॉप हे वाक्य वाचण्यासाठी लागणाऱ्या वेळेत शून्यावरून चालू WordPress पर्यंत पोहोचतो.
जेव्हा आपल्याला नेटिव्ह PHP ची आवश्यकता असते — imagick सारखा विस्तार, खरा MySQL — तेव्हा --runtime docker पास करा आणि त्याऐवजी php-fpm आणि MariaDB कंटेनर मिळवा. दोन्ही एकाच प्रोजेक्टमधील समान फाइल्स सर्व्ह करतात, त्यामुळे त्यांच्यामध्ये स्विच केल्याने केवळ इंजिन बदलते आणि इतर काहीही नाही.
पॅनेलमध्ये तुम्ही आधीपासूनच करत असलेल्या इतर सर्व गोष्टी
Zinnector® डॅशबोर्डप्रमाणेच सार्वजनिक API वर तयार केले आहे, त्यामुळे पॅनेल जे काही करू शकते ते हे देखील करू शकते — आणि प्रत्येक कमांड खाजगी एंडपॉइंटऐवजी OpenAPI वैशिष्ट्यामध्ये दस्तऐवजीकरण केलेले ऑपरेशन आहे.
साइट्स आणि डिप्लॉयमेंट्स
साइट्सची सूची तयार करा, एखाद्या साइटबद्दल प्लॅटफॉर्मला ज्ञात असलेली सर्व माहिती वाचा, पुनर्उपयोजित करा, आणि उपयोजन इतिहास तसेच बिल्ड नोंदी वाचा.
डोमेन्स, DNS आणि मेल
डोमेनची सूची तयार करा, रेकॉर्ड लिहिण्यापूर्वी दाखवलेल्या रेकॉर्डसह DNS रेकॉर्ड वाचा आणि बदला आणि तुमच्या मेल सेवा वाचा.
PHP, कोटा, डेटाबेस आणि नोंदी
PHP आवृत्त्या बदला, तुमच्या प्लॅनने दिलेल्या मर्यादेनुसार डिस्क आणि inode वापर तपासा, phpMyAdmin साठी एकल-वापर लिंक्स मिळवा, आणि अ‍ॅक्सेस व एरर लॉग्स रिअल-टाइममध्ये ट्रॅक करा.
WP-CLI आणि बल्क ऑपरेशन्स
एखाद्या साइटवर अनुमती दिलेल्या सूचीतील WP-CLI कमांड चालवा आणि प्रत्येक साइटसाठी एक-एक करण्याऐवजी एकाच कॉलमध्ये संपूर्ण निवडीवरील कॅशे साफ करा किंवा मालवेअर स्कॅन सुरू करा.
प्रत्येक कमांड, अगदी जशी --help सूचीत दिली आहे
पूर्ण सूची, प्रत्येकी एक ओळ. संपूर्ण संदर्भ — प्रत्येक फ्लॅग, एक कार्यान्वित करता येण्याजोगे उदाहरण आणि प्रत्येक कमांड काय प्रिंट करते — थेट CLI मधूनच जनरेट केला जातो आणि डेव्हलपर दस्तऐवज व ज्ञानकोशात उपलब्ध असतो, त्यामुळे तुम्ही इंस्टॉल केलेल्या टूलपेक्षा तो वेगळा असू शकत नाही.
नवीन झिन्नेक्टर
तुम्ही त्वरित सुरू करू शकाल अशा WordPress प्रकल्पाची संरचना तयार करा.
zinnector dev
हा प्रकल्प स्थानिक पातळीवर चालवा — Docker ची आवश्यकता नाही.
झिनेक्टर लॉगिन
Zinn Digital® API की सह साइन इन करा.
झिनेक्टर लॉगआउट
साठवलेली API की विसरा.
zinnector whoami
हा CLI कोणाच्या रूपात प्रमाणीकृत आहे ते दाखवा.
zinnector साइट्स
या कीद्वारे पाहिल्या जाऊ शकणाऱ्या साइट्सची सूची तयार करा.
झिनेक्टर स्थिती
एका साइटबद्दल प्लॅटफॉर्मला माहीत असलेली सर्व माहिती.
zinnector शेअर
एका व्यक्तीला एकाच साइटचा ॲक्सेस द्या — डेव्हलपर, डिझायनर, क्लायंट — भूमिका आणि कारणासह.
zinnector सहकाऱ्या
एखाद्या साइटवर कोणाला ॲक्सेस दिला गेला आहे, त्यांची भूमिका काय आहे आणि त्यांनी अद्याप स्वीकारले आहे का ते पहा.
झिननेक्टर शेअरिंग समाप्त करा
ईमेल किंवा ग्रँट आयडीद्वारे एखाद्या व्यक्तीचा ॲक्सेस परत घ्या.
झिनेक्टर आमंत्रणे
तुमच्यासाठी प्रलंबित असलेली आमंत्रणे, आणि एक स्वीकारा.
zinnector लिंक
हा प्रकल्प होस्टिंग स्लॉटवर निर्देशित करा (आणि त्याचे रिपॉझिटरी कनेक्ट करा).
zinnector pull
स्थानिक विकासासाठी होस्ट केलेल्या साइटच्या फाइल्स या प्रोजेक्टमध्ये आणा आणि पुन्हा सिंक करण्यासाठी पुन्हा चालवा. साइट स्वतःच्या रेपॉजिटरीमध्ये सिंक होते तेव्हा जलद मार्ग स्वीकारते, अन्यथा नवीनतम बॅकअपवरून कार्य करते.
zinnector सिंक
होस्ट केलेल्या साइटच्या थेट फाइल्स आणि तिचे रिपॉझिटरी यांमधील दुतर्फा सिंक: स्थिती पहा, ते सुरू करा, साइटचे बदल कमिट करा किंवा कोणत्या बाजूला प्राधान्य द्यायचे ते निवडा.
झिनेक्टर एमसीपी
Claude Desktop आणि फक्त स्थानिक सर्व्हर्स सुरू करणाऱ्या इतर AI क्लायंटसाठी Zinn Digital® MCP सर्व्हरचा एक पूल.
झिननेक्टर क्लोन
होस्ट केलेल्या साइटवरून एका चरणात स्थानिक प्रकल्प तयार करा: त्याचे भांडार क्लोन करा किंवा त्याच्या फायली खेचा, प्रकल्प फाइल लिहा आणि zinnector dev चालवण्यासाठी सज्ज व्हा.
झिननेक्टर तपासा
या प्रोजेक्टची तुलना तुम्ही ज्या स्लॉटमध्ये डिप्लॉय करणार आहात त्याच्याशी करा.
zinnector push
पूर्व-तपासणी करा, तुमचे कमिट्स पुश करा आणि उपयोजित करा.
zinnector deploy करा
पुश न करता, प्लॅटफॉर्मवर आधीच उपलब्ध असलेले पुन्हा उपयोजित करा.
झिनेक्टर तैनात करत आहे
साइटचा डिप्लॉय इतिहास.
zinnector php
साइटची PHP आवृत्ती दाखवा किंवा बदला.
झिनेक्टर कोटा
प्लॅननुसार मंजूर केलेल्या मर्यादेच्या तुलनेत डिस्क, फाइल्स आणि डेटाबेसचा वापर.
zinnector db
डेटाबेसचा आकार, आणि phpMyAdmin व फाइल व्यवस्थापकासाठीच्या एकल-वापर लिंक्स.
झिनेक्टर लॉग्स
साइटचे ॲक्सेस आणि त्रुटी लॉग रिअल-टाइममध्ये ट्रॅक करा.
zinnector wp
एखाद्या साइटवर अनुमती दिलेली WP-CLI कमांड चालवा.
झिननेक्टर बॅकअप
साइट बॅकअपची सूची तयार करा आणि बॅकअप घ्या. उप-आज्ञा: list, now.
झिनेक्टर डोमेन
या कीद्वारे पाहता येणाऱ्या डोमेनची सूची द्या.
zinnector dns
DNS रेकॉर्ड वाचा आणि बदला. उप-आज्ञा: list, add, rm.
झिननेक्टर मेल
मेल सेवांची सूची तयार करा.
zinnector बल्क
अनेक साइट्सवर एकच कृती चालवा (cache_purge, malware_scan, sitemap, block_ip).
zinnector ai
या प्रकल्पाच्या संदर्भासह, Zinn Digital® सहाय्यकाला विचारा.
प्रश्न
हे वापरण्यासाठी मला Zinn Digital® चा ग्राहक असणे आवश्यक आहे का?
नाही. `zinnector new` आणि `zinnector dev` साठी कोणत्याही खात्याची अजिबात आवश्यकता नाही — प्लगइन, थीम किंवा संपूर्ण साइटचा सांगाडा तयार करा आणि ती स्थानिक पातळीवर, विनामूल्य, कायमस्वरूपी चालवा. केवळ तुमच्या होस्टिंगशी संवाद साधणाऱ्या कमांड्ससाठी API की आवश्यक आहे.
याला Docker ची आवश्यकता आहे का?
डिफॉल्ट runtime साठी नाही. WordPress Playground हे PHP ला WebAssembly मध्ये कंपाईल करते आणि Node मध्ये चालते, त्यामुळे `zinnector dev` इतर काहीही इन्स्टॉल न करता काही सेकंदात प्रत्यक्ष WordPress सुरू करते. जर आपल्याला मूळ (नेटिव्ह) PHP ची आवश्यकता असेल — imagick किंवा ionCube सारख्या एक्स्टेंशनची चाचणी घेण्यासाठी — तर `--runtime docker` आपल्याला त्याऐवजी php-fpm आणि MariaDB कंटेनर्स प्रदान करते. दोन्ही समर्थित आहेत; यापैकी कोणताही केवळ फॉलबॅक पर्याय नाही.
प्री-फ्लाईट तपासणी प्रत्यक्षात कशाची तुलना करते?
स्लॉटच्या आवृत्तीशी तुलना करता तुमची स्थानिक PHP आवृत्ती, तुम्ही ज्या आवृत्तीवर काम केले त्यावर स्लॉट स्विच होऊ शकतो का, स्लॉटची PHP कालबाह्य झाली आहे का आणि मशीनने ती प्रत्यक्षात लागू केली आहे का, शिल्लक डिस्क आणि आयनोड क्षमतेच्या तुलनेत तुमच्या प्रोजेक्टचा आकार आणि फाइल्सची संख्या, दोन्ही बाजूंच्या WordPress आवृत्त्या, स्लॉटचे प्रोव्हिजनिंग पूर्ण झाले आहे का आणि डिप्लॉय करण्यासाठी git रिपॉझिटरी जोडलेली आहे का. ज्या गोष्टी तपासणे शक्य झाले नाही, त्या यशस्वी मानण्याऐवजी न तपासलेल्या म्हणून नोंदवल्या जातात.
हे मला तैनात करण्यापासून रोखू शकते का?
नाही, आणि हे जाणूनबुजून केलेले आहे. प्री-फ्लाइट चेतावणी देते आणि आपल्याला पुढे जाण्याची अनुमती देते — `--force` कोणत्याही निष्कर्षाकडे दुर्लक्ष करून उपयोजन करते. आपल्याला आपल्या स्वतःच्या साइटबद्दल अशा गोष्टी माहित असतात ज्या तपासणी साधनांना माहित नसतात, आणि उपयोजन करण्यास नकार देणारे साधन लोक अनइन्स्टॉल करतात.
माझी API की सुरक्षित आहे का?
की कधीही कमांड लाइनवरून वाचली जात नाही — फक्त प्रॉम्प्ट किंवा पाइप्ड stdin वरून वाचली जाते — त्यामुळे ती तुमच्या शेल हिस्ट्रीमध्ये किंवा प्रक्रिया सूचीमध्ये जाऊ शकत नाही. ती तुमच्या स्वतःच्या कॉन्फिगरेशन डिरेक्टरीमध्ये 600 फाईल मोडसह साठवली जाते आणि Zinnector® प्रत्येक वेळी लिहिताना त्या परवानग्या पुन्हा लागू करते.
मी हे CI मध्ये वापरू शकतो का?
होय. `ZINNECTOR_TOKEN` सेट करा, आणि प्रत्येक कमांड `--json` स्वीकारते. मानवी वाचनासाठीचे आउटपुट stderr वर आणि डेटा stdout वर जातो, ज्यामुळे पाइप्स स्वच्छ राहतात. `zinnector check` ला काही आढळल्यास ते नॉन-झिरो कोडसह बाहेर पडते, त्यामुळे ते पाइपलाइन गेट म्हणून कार्य करते आणि तुलना करता येत नसेल तर `--strict` देखील अयशस्वी होते.
संबंधित
ते स्थापित करा आणि पुढच्या मिनिटात साइट चालवा
npm install -g zinnector चालवा, किंवा npx zinnector new my-site सह एकदा वापरून पहा. विनामूल्य, MIT परवानाधारक आणि सार्वजनिक API वर तयार केलेले. प्रोजेक्टचे स्केफोल्ड तयार करा, Docker शिवाय स्थानिक पातळीवर चालवा आणि डिप्लॉय करण्यापूर्वी पूर्व-चाचणी करा.
दस्तऐवज वाचा