Zinnector®
Node അല്ലാതെ മറ്റൊന്നും ഇൻസ്റ്റാൾ ചെയ്യാതെ തന്നെ Zinnector® പ്രാദേശികമായി WordPress നിർമ്മിക്കുന്നു — Docker ഇല്ല, MAMP ഇല്ല — തുടർന്ന് നിങ്ങൾ വിന്യസിക്കാൻ പോകുന്ന ഹോസ്റ്റിംഗ് സ്ലോട്ടുമായി നിങ്ങൾ നിർമ്മിച്ചവ പരിശോധിച്ച്, പുഷ് ചെയ്യുന്നതിന് മുൻപായി പൊരുത്തപ്പെടാത്തവ എന്തൊക്കെയാണെന്ന് നിങ്ങളെ അറിയിക്കുന്നു. npm install -g zinnector ഉപയോഗിച്ച് ഇത് ഇൻസ്റ്റാൾ ചെയ്യുക. ഇത് സൗജന്യവും, MIT-ലൈസൻസുള്ളതും, ഇവിടെയുള്ള മറ്റെല്ലാം പോലെ അതേ പബ്ലിക് API-യിൽ നിർമ്മിച്ചതുമാണ്.
മിക്ക ഹോസ്റ്റിംഗ് CLI-കളും ഡിപ്ലോയ് ചെയ്യുന്ന ഘട്ടത്തിലാണ് ആരംഭിക്കുന്നത്. Zinnector® അതിനും മുൻപേ ആരംഭിക്കുന്നു — ഇത് നിങ്ങളോടൊപ്പം സൈറ്റ് നിർമ്മിക്കുകയും തുടർന്ന് നിങ്ങൾ അത് അയയ്ക്കാൻ പോകുന്ന മെഷീനുമായി നിങ്ങളുടെ വർക്ക് ഒത്തുനോക്കുകയും ചെയ്യുന്നു. "ഇത് എൻ്റെ ലാപ്‌ടോപ്പിൽ പ്രവർത്തിച്ചു", "ഇത് സെർവറിൽ പ്രവർത്തിക്കുന്നു" എന്നിവ തമ്മിലുള്ള വ്യത്യാസത്തിലാണ് ഉച്ചതിരിവുകൾ പാഴായിപ്പോകുന്നത്, ആ വ്യത്യാസം അളക്കാവുന്നതുമാണ്.
ഉടൻ തന്നെ ബൂട്ട് ചെയ്യുന്ന ഒരു സൈറ്റ്, പ്ലഗിൻ അല്ലെങ്കിൽ ബ്ലോക്ക് തീം എന്നിവയുടെ ചട്ടക്കൂട് രൂപീകരിക്കുക. പ്ലേസ്‌ഹോൾഡർ ഫയലുകളോ TODO-കളോ ഇല്ല — പ്ലഗിൻ സജീവമാകുകയും തീം നിർമ്മിക്കപ്പെട്ട ഉടൻ തന്നെ അത് തിരഞ്ഞെടുക്കപ്പെടുകയും ചെയ്യുന്നു.
Docker ഇല്ലാതെയും നിങ്ങളുടെ PATH-ൽ PHP ഇല്ലാതെയും, നിങ്ങളുടെ സ്വന്തം പ്ലഗിനുകളും തീമുകളും ലഭ്യമാക്കുന്ന ഒരു യഥാർത്ഥ WordPress നിമിഷങ്ങൾക്കകം നിങ്ങളുടെ മെഷീനിൽ. ഡെവലപ്‌മെന്റിനായി 5.2 മുതൽ 8.5 വരെയുള്ള ഏത് PHP-യും തിരഞ്ഞെടുക്കുക.
പ്രീ-ഫ്ലൈറ്റ്. നിങ്ങൾ നിർമ്മിച്ചതിനെ വിന്യസിക്കാൻ പോകുന്ന സ്ലോട്ടുമായി താരതമ്യം ചെയ്യുകയും പുഷ് ചെയ്യുന്നതിന് മുമ്പ് പൊരുത്തക്കേടുകളും — നടത്താൻ കഴിയാത്ത ഓരോ പരിശോധനകളും — വ്യക്തമാക്കുകയും ചെയ്യുന്നു.
പ്രീ-ഫ്ലൈറ്റ് നടത്തുക, നിങ്ങളുടെ കമ്മിറ്റുകൾ പുഷ് ചെയ്യുക, വിന്യാസം ട്രിഗർ ചെയ്യുക, അത് പൂർത്തിയാകുന്നതുവരെ നിരീക്ഷിക്കുക. ഇത് പരാജയപ്പെടുകയാണെങ്കിൽ, ബിൽഡ് ലോഗ് ഒരു കമാൻഡ് മാത്രം അകലെയാണ്.
നിങ്ങളുടെ പ്രോജക്റ്റും നിങ്ങളുടെ സൈറ്റും സന്ദർഭമായി സ്വീകരിച്ച് ടെർമിനലിൽ നിന്ന് അസിസ്റ്റന്റിനോട് ചോദിക്കുക. ഇത് നിങ്ങളുടെ സ്വന്തം അക്കൗണ്ടിലൂടെ പ്ലാറ്റ്‌ഫോമിൽ പ്രവർത്തിക്കുന്നു, അതിനാൽ നിങ്ങളുടെ മെഷീനിൽ ഒരിക്കലും മോഡൽ കീ സംഭരിക്കപ്പെടുന്നില്ല.
ക്രമത്തിൽ ആറ് കമാൻഡുകൾ, ഓരോന്നിലും വിജയം എങ്ങനെ കാണപ്പെടുന്നു എന്നതും. ഇവിടെയുള്ളതെല്ലാം നിങ്ങളുടെ സ്വന്തം മെഷീനിലാണ് പ്രവർത്തിക്കുന്നത്; നിങ്ങൾ ഒരു ഹോസ്റ്റിംഗ് സ്ലോട്ടിൽ എത്തുമ്പോൾ മാത്രമേ ഒരു 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® രണ്ട് എൻവയോൺമെന്റുകളും വായിച്ച് അവയെ പരസ്പരം താരതമ്യം ചെയ്യുന്നു — അതിനുശേഷം നിങ്ങൾക്ക് എന്തെങ്കിലും കാരണമുണ്ടാകാം എന്നതിനാൽ വിന്യസിക്കാൻ അനുവദിക്കുകയും ചെയ്യുന്നു.
ഒരു പ്രധാന പതിപ്പ് വ്യത്യാസം ഉയർന്നതായി അടയാളപ്പെടുത്തുന്നു, കാരണം അത് ഒരു സൈറ്റിന്റെ പ്രവർത്തനത്തെ തീർച്ചയായും തകരാറിലാക്കുന്നു; ഒരു ചെറിയ വ്യത്യാസം താഴ്ന്നതായി അടയാളപ്പെടുത്തുന്നു. എല്ലാം നിർണായകമായി തരംതിരിക്കുന്നത് മുന്നറിയിപ്പ് അവഗണിക്കാൻ മാത്രമേ ആളുകളെ പഠിപ്പിക്കൂ.
ഒരു WordPress ട്രീയിൽ പതിനായിരക്കണക്കിന് ചെറിയ ഫയലുകൾ അടങ്ങിയിരിക്കുന്നു, കൂടാതെ ഒരു സൈറ്റിന് അതിന്റെ ഡിസ്ക് പരിധിക്ക് വളരെ താഴെയായിരിക്കുമ്പോഴും അതിന്റെ inode അലവൻസ് തീർന്നുപോയേക്കാം. ഇവ രണ്ടും പ്ലാനിന് അനുസരിച്ചല്ല, മറിച്ച് സ്ലോട്ടിൽ യഥാർത്ഥത്തിൽ അവശേഷിക്കുന്നത് എന്താണോ അതിനെ അടിസ്ഥാനമാക്കിയാണ് പരിശോധിക്കുന്നത്.
പരിശോധനാ വിഷയം കാണാൻ കഴിയാത്ത ഒരു പരിശോധന, ഒരിക്കലും പാസായി എന്ന് റിപ്പോർട്ട് ചെയ്യില്ല, പരിശോധിച്ചില്ല എന്ന് മാത്രമാണ് റിപ്പോർട്ട് ചെയ്യുക. എത്ര കാര്യങ്ങൾ സ്ഥിരീകരിക്കാൻ കഴിഞ്ഞില്ല എന്ന് ഒരു പിഴവറ്റ റൺ വ്യക്തമാക്കുന്നു, കാരണം തെറ്റായ ക്ലിയറൻസ് ആരും രണ്ടാമതൊന്ന് പരിശോധിക്കാറില്ല.
ഓരോ കണ്ടെത്തലും --force ഉപയോഗിച്ച് തിരുത്താനാകും, സംഗ്രഹം അങ്ങനെ വ്യക്തമാക്കുന്നുമുണ്ട്. CI-ൽ എക്സിറ്റ് കോഡാണ് ഒരു ഗേറ്റായി പ്രവർത്തിക്കുന്നത്, അതിനാൽ ഒരാൾ നിയന്ത്രണം നിലനിർത്തുന്നതിനൊപ്പം പൈപ്പ്‌ലൈൻ കർശനമായി തുടരാനും കഴിയും.
WordPress Playground ആണ് ഡിഫോൾട്ട്: WebAssembly-യിലേക്ക് കംപൈൽ ചെയ്ത PHP, Node-നുള്ളിൽ പ്രവർത്തിക്കുന്നു, അതിനാൽ Node മാത്രം ഇൻസ്റ്റാൾ ചെയ്തിട്ടുള്ള ഒരു ലാപ്‌ടോപ്പ് ഈ വാക്യം വായിക്കാൻ എടുക്കുന്ന സമയത്തിനുള്ളിൽ ഒന്നുമില്ലായ്മയിൽ നിന്ന് പ്രവർത്തിക്കുന്ന ഒരു WordPress-ലേക്ക് മാറുന്നു.
നിങ്ങൾക്ക് ഒരു നേറ്റീവ് PHP ആവശ്യമായി വരുമ്പോൾ — imagick പോലെയുള്ള ഒരു എക്സ്റ്റൻഷൻ, ഒരു യഥാർത്ഥ MySQL — --runtime docker നൽകി പകരം php-fpm, MariaDB കണ്ടെയ്‌നറുകൾ നേടുക. രണ്ടും ഒരേ പ്രോജക്റ്റിൽ നിന്നുള്ള ഒരേ ഫയലുകളാണ് നൽകുന്നത്, അതിനാൽ അവയ്ക്കിടയിൽ മാറുന്നത് എഞ്ചിനെ മാത്രമാണ് മാറ്റുന്നത്, മറ്റൊന്നിനെയും ബാധിക്കില്ല.
Zinnector® ഡാഷ്‌ബോർഡിന്റെ അതേ പബ്ലിക് API-യിലാണ് നിർമ്മിച്ചിരിക്കുന്നത്, അതിനാൽ പാനലിന് ചെയ്യാൻ കഴിയുന്ന എന്തും ഇതിനും ചെയ്യാൻ കഴിയും — കൂടാതെ ഓരോ കമാൻഡും ഒരു സ്വകാര്യ എൻഡ്‌പോയിന്റിനേക്കാൾ OpenAPI സ്പെസിഫിക്കേഷനിലെ രേഖപ്പെടുത്തപ്പെട്ട പ്രവർത്തനമാണ്.
സൈറ്റുകൾ ലിസ്റ്റ് ചെയ്യുക, ഒന്നിനെക്കുറിച്ച് പ്ലാറ്റ്‌ഫോമിന് അറിയാവുന്നതെല്ലാം വായിക്കുക, വീണ്ടും വിന്യസിക്കുക, ഒപ്പം വിന്യാസ ചരിത്രവും ബിൽഡ് ലോഗുകളും വായിക്കുക.
ഡൊമെയ്‌നുകൾ ലിസ്റ്റ് ചെയ്യുക, റെക്കോർഡ് എഴുതുന്നതിന് മുമ്പ് കാണിക്കുന്ന റെക്കോർഡ് സഹിതം DNS റെക്കോർഡുകൾ വായിക്കുകയും മാറ്റുകയും ചെയ്യുക, കൂടാതെ നിങ്ങളുടെ മെയിൽ സേവനങ്ങൾ വായിക്കുകയും ചെയ്യുക.
PHP പതിപ്പുകൾ മാറുക, നിങ്ങളുടെ പ്ലാൻ അനുവദിക്കുന്ന പരിധിക്ക് അനുസൃതമായി ഡിസ്ക്, inode ഉപയോഗം പരിശോധിക്കുക, phpMyAdmin-ലേക്ക് ഒറ്റത്തവണ ഉപയോഗിക്കാവുന്ന ലിങ്കുകൾ നേടുക, ആക്സസ്, പിശക് ലോഗുകൾ തത്സമയം നിരീക്ഷിക്കുക.
ഒരു സൈറ്റിൽ അനുമതിയുള്ള WP-CLI കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കുക, ഒപ്പം ഓരോ സൈറ്റിനും വെവ്വേറെ ചെയ്യുന്നതിന് പകരം ഒരൊറ്റ കോളിലൂടെ തിരഞ്ഞെടുത്തവയിലെല്ലാം കാഷെകൾ നീക്കം ചെയ്യുകയോ മാൽവെയർ സ്കാനുകൾ ആരംഭിക്കുകയോ ചെയ്യുക.
മുഴുവൻ പട്ടികയും, ഓരോ വരിയിലും ഓരോന്ന് വീതം. സമ്പൂർണ്ണ റഫറൻസ് — ഓരോ ഫ്ലാഗും, പ്രവർത്തിപ്പിക്കാവുന്ന ഒരു ഉദാഹരണവും, ഓരോ കമാൻഡും എന്ത് പ്രിൻ്റ് ചെയ്യുന്നു എന്നതും — CLI-ൽ നിന്ന് നേരിട്ട് സൃഷ്ടിക്കപ്പെടുന്നതും ഡെവലപ്പർ ഡോക്യുമെന്റുകളിലും നോളജ് ബേസിലും ലഭ്യവുമാണ്, അതിനാൽ നിങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്ത ടൂളിൽ നിന്ന് ഇതിന് വ്യത്യാസമുണ്ടാകില്ല.
നിങ്ങൾക്ക് ഉടനടി റൺ ചെയ്യാൻ കഴിയുന്ന ഒരു WordPress പ്രോജക്റ്റിന്റെ ഘടന തയ്യാറാക്കുക.
ഈ പ്രോജക്റ്റ് ലോക്കലായി പ്രവർത്തിപ്പിക്കുക — Docker ആവശ്യമില്ല.
ഒരു Zinn Digital® API കീ ഉപയോഗിച്ച് സൈൻ ഇൻ ചെയ്യുക.
സംഭരിച്ച API കീ മറക്കുക.
ഈ CLI ആരായാണ് പ്രാമാണീകരിച്ചിരിക്കുന്നത് എന്ന് കാണിക്കുക.
ഈ കീക്ക് കാണാൻ കഴിയുന്ന സൈറ്റുകൾ ലിസ്റ്റ് ചെയ്യുക.
ഒരു സൈറ്റിനെക്കുറിച്ച് പ്ലാറ്റ്‌ഫോമിന് അറിയാവുന്ന എല്ലാം.
ഒരു വ്യക്തിക്ക് ഒരു സൈറ്റിലേക്ക് മാത്രം ആക്സസ് നൽകുക — ഒരു ഡെവലപ്പർക്ക്, ഒരു ഡിസൈനർക്ക്, ഒരു ക്ലയന്റിന് — ഒരു റോളും കാരണവും സഹിതം.
ഒരു സൈറ്റിലേക്ക് ആർക്കൊക്കെ ആക്സസ് നൽകിയിട്ടുണ്ടെന്നും അവരുടെ റോൾ എന്താണെന്നും അവർ ഇതിനകം സ്വീകരിച്ചിട്ടുണ്ടോ എന്നും കാണുക.
ഇമെയിൽ വഴിയോ ഗ്രാന്റ് ഐഡി വഴിയോ ഒരു വ്യക്തിയുടെ ആക്സസ് പിൻവലിക്കുക.
നിങ്ങൾക്കായി കാത്തിരിക്കുന്ന ക്ഷണങ്ങൾ, ഒരെണ്ണം സ്വീകരിക്കുക.
ഈ പ്രോജക്റ്റ് ഒരു ഹോസ്റ്റിംഗ് സ്ലോട്ടിലേക്ക് ചൂണ്ടിക്കാണിക്കുക (അതിന്റെ ശേഖരം ബന്ധിപ്പിക്കുക).
ലോക്കൽ ഡെവലപ്‌മെന്റിനായി ഹോസ്റ്റ് ചെയ്ത സൈറ്റിന്റെ ഫയലുകൾ ഈ പ്രോജക്റ്റിലേക്ക് പുൾ ചെയ്യുക, വീണ്ടും സമന്വയിപ്പിക്കാൻ വീണ്ടും റൺ ചെയ്യുക. സൈറ്റ് സ്വന്തം ശേഖരണത്തിലേക്ക് സമന്വയിപ്പിക്കുമ്പോൾ വേഗതയേറിയ പാത സ്വീകരിക്കുന്നു, അല്ലാത്തപക്ഷം ഏറ്റവും പുതിയ ബാക്കപ്പിൽ നിന്ന് പ്രവർത്തിക്കുന്നു.
ഹോസ്റ്റ് ചെയ്ത സൈറ്റിന്റെ തത്സമയ ഫയലുകളും അതിന്റെ റിപ്പോസിറ്ററിയും തമ്മിലുള്ള ദ്വിമുഖ സമന്വയം: നിലവിലെ അവസ്ഥ കാണുക, അത് ഓണാക്കുക, സൈറ്റിലെ മാറ്റങ്ങൾ കമ്മിറ്റ് ചെയ്യുക, അല്ലെങ്കിൽ ഏത് വശത്തിനാണ് മുൻഗണനയെന്ന് തിരഞ്ഞെടുക്കുക.
ലോക്കൽ സെർവറുകൾ മാത്രം ആരംഭിക്കുന്ന Claude Desktop-നും മറ്റ് AI ക്ലയന്റുകൾക്കുമുള്ള Zinn Digital® MCP സെർവറിലേക്കുള്ള ഒരു പാലം.
ഹോസ്റ്റ് ചെയ്ത സൈറ്റിൽ നിന്ന് ഒറ്റ ഘട്ടത്തിൽ ഒരു ലോക്കൽ പ്രോജക്റ്റ് സൃഷ്‌ടിക്കുക: അതിന്റെ ശേഖരം ക്ലോൺ ചെയ്യുക അല്ലെങ്കിൽ അതിന്റെ ഫയലുകൾ വലിക്കുക, പ്രോജക്റ്റ് ഫയൽ എഴുതുക, ഒപ്പം 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 കീ ആവശ്യമുള്ളൂ.
ഡീഫോൾട്ട് runtime-ന് വേണ്ടിയുള്ളതല്ല. WordPress Playground, PHP-യെ WebAssembly-ലേക്ക് കംപൈൽ ചെയ്യുകയും Node-നുള്ളിൽ പ്രവർത്തിക്കുകയും ചെയ്യുന്നു, അതിനാൽ മറ്റ് യാതൊന്നും ഇൻസ്റ്റാൾ ചെയ്യാതെ തന്നെ `zinnector dev` ഏതാനും നിമിഷങ്ങൾക്കുള്ളിൽ യഥാർത്ഥ WordPress ബൂട്ട് ചെയ്യുന്നു. imagick അല്ലെങ്കിൽ ionCube പോലുള്ള ഒരു എക്സ്റ്റൻഷൻ ടെസ്റ്റ് ചെയ്യുന്നതിന് നിങ്ങൾക്ക് നേറ്റീവ് PHP ആവശ്യമുണ്ടെങ്കിൽ — പകരം `--runtime docker` നിങ്ങൾക്ക് php-fpm, MariaDB കണ്ടെയ്‌നറുകൾ നൽകുന്നു. രണ്ടും പിന്തുണയ്ക്കുന്നു; ഒന്നുപോലും ഒരു ഫാൾബാക്ക് അല്ല.
സ്ലോട്ടിന്റേതുമായി താരതമ്യം ചെയ്യുമ്പോൾ നിങ്ങളുടെ ലോക്കൽ PHP പതിപ്പ്, നിങ്ങൾ നിർമ്മിച്ച പതിപ്പിലേക്ക് സ്ലോട്ടിന് മാറാൻ കഴിയുമോ എന്നത്, സ്ലോട്ടിന്റെ PHP-യുടെ കാലാവധി കഴിഞ്ഞതാണോ എന്നും മെഷീൻ അത് യഥാർത്ഥത്തിൽ ബാധകമാക്കിയിട്ടുണ്ടോ എന്നത്, ശേഷിക്കുന്ന ഡിസ്കും ഐനോഡ് പരിധിയും കണക്കിലെടുക്കുമ്പോൾ നിങ്ങളുടെ പ്രോജക്റ്റിന്റെ വലുപ്പവും ഫയലുകളുടെ എണ്ണവും, ഓരോ വശത്തുമുള്ള 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 ഇല്ലാതെ തന്നെ ലോക്കലായി റൺ ചെയ്യുക, ഒപ്പം വിന്യസിക്കുന്നതിന് മുൻപ് അത് പരിശോധിച്ച് ഉറപ്പുവരുത്തുക.
രേഖകൾ വായിക്കുക