HostBill, Blesta അല്ലെങ്കിൽ നിങ്ങളുടെ സ്വന്തം സിസ്റ്റത്തിൽ നിന്ന് Zinn® ഹോസ്റ്റിംഗ് വിൽക്കുക

നിങ്ങൾ WHMCS ആണ് പ്രവർത്തിപ്പിക്കുന്നതെങ്കിൽ, പകരം WHMCS മൊഡ്യൂൾ ഉപയോഗിക്കുക — ഈ പേജ് മറ്റെല്ലാ ആവശ്യങ്ങൾക്കുമുള്ളതാണ്. രണ്ട് ഓപ്ഷനുകൾ ലഭ്യമാണ്, രണ്ടും സൗജന്യവും GPL-2.0-or-later പ്രകാരമുള്ളതുമാണ്.

HostBill

WHMCS മൊഡ്യൂളിന് സമാനമായ ആറ് പ്രവർത്തനങ്ങളുള്ള ഒരു ഹോസ്റ്റിംഗ് മൊഡ്യൂൾ.

1. ഇത് ഡൗൺലോഡ് ചെയ്ത് അൺസിപ്പ് ചെയ്യുക.
2. ഫയലുകൾ includes/modules/Hosting/zinn/class.zinn.php, includes/modules/Hosting/zinn/ZinnHostBillClient.php എന്നിവിടങ്ങളിൽ എത്തുന്നതിനായി zinn ഡയറക്ടറി includes/modules/Hosting/ എന്നതിലേക്ക് അപ്‌ലോഡ് ചെയ്യുക.
3. Settings → Modules → Hosting എന്നതിലേക്ക് പോയി, Zinn Digital® ആക്റ്റിവേറ്റ് ചെയ്ത് ഒരു കണക്ഷൻ ചേർക്കുക:

• API address: https://api.zinndigital.com
• API key: നിങ്ങളുടെ Zinn® API കീ (ഇതൊരു password ഫീൽഡ് ആയതിനാൽ HostBill ഇത് എൻക്രിപ്റ്റ് ചെയ്ത് സൂക്ഷിക്കുന്നു)

1. പ്രൊഡക്റ്റിൽ Product line (ഉദാ. mainstream), Stack (ഡിഫോൾട്ടായി wordpress), ആവശ്യമെങ്കിൽ Application, PHP version എന്നിവ സജ്ജീകരിക്കുക.
2. Test connection അമർത്തുക.

⛔ zinn ഡയറക്ടറിയുടെ പേര് മാറ്റരുത്. HostBill-ന്റെ ലോഡർ അന്വേഷിക്കുന്ന ക്ലാസ് കണ്ടെത്തുന്നത് ഡയറക്ടറിയുടെ പേരിൽ നിന്നാണ്, അതിനാൽ പേര് മാറ്റിയാൽ പാനൽ ലിസ്റ്റ് ചെയ്യുന്നതും എന്നാൽ ഒരിക്കലും കോൾ ചെയ്യാത്തതുമായ ഒരു മൊഡ്യൂളായി അത് മാറും.

മറ്റെന്തിനും — PHP ക്ലയന്റ്

ഒറ്റ ഫയൽ, ഡിപൻഡൻസികളില്ല, പാനൽ അനുമാനങ്ങളുമില്ല. നിങ്ങളുടെ സ്വന്തം കോഡ്‌ബേസിലേക്ക് ZinnProvisioning.php ഉൾപ്പെടുത്തി ആറ് മെത്തേഡുകൾ കോൾ ചെയ്യുക.

require_once 'ZinnProvisioning.php';

$zinn = new ZinnProvisioning(getenv('ZINN_API_KEY'));

// ഒരു ഓർഡർ പണമടച്ചു കഴിയുമ്പോൾ — ഓരോ കസ്റ്റമർക്കും ഒരു തവണ, തുടർന്ന് ഓരോ സർവീസിനും ഒരു തവണ:
$orgId  = $zinn->account('customer-4211', 'Acme Ltd');
$siteId = $zinn->provision('service-9915', $orgId, 'acme.com', 'mainstream', 'wordpress');
// നിങ്ങളുടെ ഉപഭോക്താവിനെതിരെ $orgId-യും നിങ്ങളുടെ സേവനത്തിനെതിരെ $siteId-യും സൂക്ഷിക്കുക.

$zinn->suspend($siteId, 'INV-2026-114 unpaid');   // ഒരു ഇൻവോയ്സ് തുക അടയ്ക്കാതിരിക്കുമ്പോൾ
$zinn->unsuspend($siteId);                        // അവർ പണം അടയ്ക്കുമ്പോൾ
$zinn->terminate($siteId);                        // അവർ റദ്ദാക്കുമ്പോൾ — ഡിലീഷൻ ഷെഡ്യൂൾ ചെയ്യുന്നു

// അവർ "എന്റെ ഹോസ്റ്റിംഗിലേക്ക് ലോഗിൻ ചെയ്യുക" എന്നത് ക്ലിക്ക് ചെയ്യുമ്പോൾ — പേജ് റെൻഡർ ചെയ്യുമ്പോഴല്ല, ക്ലിക്കിൽ തന്നെ ഇത് നിർമ്മിക്കുക:
header('Location: ' . $zinn->signInLink($siteId));

PHP എഴുതുന്നില്ലേ? ഇതേ കോളുകൾ API റഫറൻസിൽ ലഭ്യമാണ്, നിങ്ങൾക്ക് ഏത് ഭാഷയിൽ നിന്നും അവ ചെയ്യാവുന്നതാണ്.

API കീ

ഏഴ് അനുമതികൾ മാത്രം, അതിൽ കൂടുതലില്ല: org.create, org.read, sites.create, sites.view, sites.delete, reseller.view, reseller.provision.

⛔ reseller.manage അല്ല. ഒരു ബില്ലിംഗ് പാനലിലേക്ക് നിങ്ങൾ നൽകുന്ന കീക്ക് പണമടയ്ക്കാത്തതിന്റെ പേരിൽ ഒരു ക്ലയന്റിനെ തടഞ്ഞുനിർത്താനും അവരെ സൈൻ ഇൻ ചെയ്യിക്കാനും സാധിക്കണം; നിങ്ങളുടെ സ്വന്തം പേയ്‌മെന്റ് ഗേറ്റ്‌വേ ക്രെഡൻഷ്യലുകൾ മാറ്റിയെഴുതാൻ അതിന് കഴിയരുത്.

ലംഘിച്ചാൽ സാമ്പത്തിക നഷ്ടമുണ്ടാക്കുന്ന രണ്ട് നിയമങ്ങൾ

1. അക്കൗണ്ട് നിങ്ങളുടെ CUSTOMER-ലും, സൈറ്റ് നിങ്ങളുടെ SERVICE-ലും കേന്ദ്രീകരിക്കുക. ഒരു ഉപഭോക്താവിന്റെ രണ്ടാമത്തെ ഓർഡർ അവർക്ക് ഇതിനകം ഉള്ള അക്കൗണ്ടിലാണ് വരേണ്ടത്. രണ്ടും സർവീസിൽ കേന്ദ്രീകരിച്ചാൽ ഒരൊറ്റ ഉപഭോക്താവിന് പരസ്പരബന്ധമില്ലാത്ത മൂന്ന് അക്കൗണ്ടുകളും മൂന്ന് വ്യത്യസ്ത കൺട്രോൾ പാനലുകളും ലഭിക്കുന്ന അവസ്ഥയുണ്ടാകും.
2. ഓരോ നിർമ്മാണത്തിലും, ആ നിർദ്ദിഷ്ട കാര്യത്തിനായുള്ള നിങ്ങളുടെ സ്വന്തം ഐഡിയിൽ നിന്ന് രൂപപ്പെടുത്തിയ ഐഡംപൊറ്റൻസി കീ അയക്കുക. എല്ലാ ബില്ലിംഗ് സിസ്റ്റങ്ങളും വീണ്ടും ശ്രമിക്കാറുണ്ട് — ഒരു ഗേറ്റ്‌വേ കോൾബാക്ക് രണ്ട് തവണ വരുന്നു, ഒരു അഡ്മിൻ പരാജയപ്പെട്ട പ്രൊവിഷൻ വീണ്ടും പ്രവർത്തിപ്പിക്കുന്നു, ഒരു ഉപഭോക്താവ് ഇരട്ട ക്ലിക്ക് ചെയ്യുന്നു. ഇതില്ലെങ്കിൽ രണ്ടാമത്തെ ശ്രമം മറ്റൊരു സൈറ്റ് സൃഷ്ടിക്കുകയും അതിനായി നിങ്ങൾക്ക് ബിൽ ചെയ്യപ്പെടുകയും ചെയ്യും. രണ്ട് മൊഡ്യൂളുകളും PHP ക്ലയന്റും നിങ്ങൾക്കായി ഇത് ചെയ്യുന്നു; നിങ്ങൾ API നേരിട്ട് കോൾ ചെയ്യുകയാണെങ്കിൽ, Idempotency-Key അയക്കുക.

ഒഴിവാക്കപ്പെടാൻ എളുപ്പമുള്ള മൂന്ന് ഫീൽഡുകൾ

ഓരോന്നും ഓരോ പൂർണ്ണമായ പ്രവർത്തനത്തെ തകരാറിലാക്കുന്നു, കൂടാതെ സാധുതാ പിശകല്ലാതെ (validation error) മറ്റൊന്നും കാണിക്കുകയുമില്ല — ആദ്യത്തേത് ഒഴികെ, അത് യാതൊന്നും തന്നെ കാണിക്കുന്നില്ല:

• ⛔⛔ ഒരു ക്ലയന്റിന്റെ ആദ്യ സൈറ്റ് പ്രൊവിഷൻ ചെയ്യുന്നതിന് മുമ്പ് അവരെ ഒരു പ്ലാനിൽ ഉൾപ്പെടുത്തിയിരിക്കണം, അത് POST /v1/reseller/clients/{orgId}/plan ഉപയോഗിച്ചും, അതിന്റെ subscription_id എന്നത് POST /v1/sites-ലേക്ക് നൽകിക്കൊണ്ടുമാണ് ചെയ്യേണ്ടത്. പിശകുകളൊന്നും കാണിക്കാത്ത സാഹചര്യമാണിത്. ഒരു പുതിയ ക്ലയന്റ് അക്കൗണ്ടിൽ സബ്‌സ്‌ക്രിപ്ഷൻ ഒന്നും ഉണ്ടാകില്ല, കൂടാതെ POST /v1/sites-ൽ പ്ലാൻ ഫീൽഡും ഇല്ല, അതിനാൽ ഒന്നുമില്ലാതെ പ്രൊവിഷൻ ചെയ്യുന്ന സൈറ്റിന് ഒരു പ്ലാനും ഉണ്ടാകില്ല: നിങ്ങളുടെ ക്ലയന്റുകളുടെ സജീവ സബ്‌സ്‌ക്രിപ്ഷനുകളിൽ നിന്നാണ് നിങ്ങളുടെ മൊത്തവ്യാപാര സ്റ്റേറ്റ്‌മെന്റ് നിർമ്മിക്കുന്നത്, അതിനാൽ ഒരു ലൈനും ചേർക്കപ്പെടില്ല കൂടാതെ ഹോസ്റ്റിംഗ് പ്രവർത്തിക്കുന്നിടത്തോളം കാലം Zinn® നിങ്ങളിൽ നിന്ന് ഒന്നും ഈടാക്കില്ല; നിങ്ങളുടെ ക്ലയന്റിന് അലവൻസുകളൊന്നും ലഭിക്കാത്തതിനാൽ അവരുടെ സൈറ്റിൽ ക്വാട്ടയൊന്നും ബാധകമാകില്ല; ഒരു അപ്‌ഗ്രേഡ് വഴി മാറ്റാൻ ഇവിടെ ഒന്നുമില്ല. ഓർഡർ 201 നൽകുന്നു, സൈറ്റ് പ്രൊവിഷൻ ചെയ്യപ്പെടുന്നു, അത് തികച്ചും അനുയോജ്യമായി പ്രവർത്തിക്കുന്നു. രണ്ട് വശത്തുനിന്നും ഇതിനെക്കുറിച്ച് ഒന്നും റിപ്പോർട്ട് ചെയ്യുന്നില്ല.

ക്രമം പ്രധാനമാണ്: POST /v1/sites അത് പ്രവർത്തിക്കുന്ന നിമിഷത്തിൽ നിലവിലുള്ള സബ്‌സ്‌ക്രിപ്ഷൻ രേഖപ്പെടുത്തുന്നു, അതിനാൽ പിന്നീട് സജ്ജീകരിക്കുന്ന ഒരു പ്ലാൻ മുൻകാല പ്രാബല്യത്തോടെ ചേർക്കപ്പെടില്ല.

• POST /v1/sites-ന് stack_type ആവശ്യമാണ്. അത് ഒഴിവാക്കിയാൽ ഒരു ഓർഡറും വിജയകരമാകില്ല.
• DELETE /v1/sites/{siteId}-ന് {"confirm_domain": "<the site's own domain>"} എന്ന ബോഡി ആവശ്യമാണ് — ഇതൊരു വിനാശകരമായ പ്രവർത്തനമായതിനാൽ ടൈപ്പ് ചെയ്ത സ്ഥിരീകരണം ആവശ്യമാണ്. അത് ഒഴിവാക്കിയാൽ ഒരു റദ്ദാക്കലും വിജയകരമാകില്ല, അതിനാൽ സേവനം തുടർന്നും പ്രവർത്തിക്കുകയും അതിനായി നിങ്ങളിൽ നിന്ന് നിരക്ക് ഈടാക്കുകയും ചെയ്യും. നിങ്ങളുടെ സ്വന്തം റെക്കോർഡ് ഉപയോഗിക്കുന്നതിന് പകരം GET /v1/reseller/services/{siteId}-ൽ നിന്ന് ഡൊമെയ്ൻ വായിക്കുക: ഇത് സൈറ്റിന്റെ സ്വന്തം പ്രൈമറി ഡൊമെയ്നുമായാണ് താരതമ്യം ചെയ്യുന്നത്, ഒരിക്കലും ഒരു അപരനാമവുമായല്ല.

വാചകം മാത്രമല്ല, മുഴുവൻ പിശകും വായിക്കുക

സാധുത പരിശോധന നിരസിക്കൽ സന്ദേശം മനഃപൂർവം പൊതുവായ ഒന്നാണ് — "അഭ്യർത്ഥന ശരിയായ രൂപത്തിലുള്ളതായിരുന്നുവെങ്കിലും സാധുത പരിശോധന പരാജയപ്പെട്ടു." — കാരണം നടപടിയെടുക്കാൻ സാധിക്കുന്ന ഭാഗം details-ൽ ആണ് ഉള്ളത്, അത് ഫീൽഡും കാരണവും വ്യക്തമാക്കുന്നു. മൊഡ്യൂളുകളും PHP ക്ലയന്റും അവർ നിങ്ങളുടെ അഡ്മിന് കാണിക്കുന്ന സന്ദേശത്തിലേക്ക് ഇത് ചേർക്കുന്നു. നിങ്ങളാണ് സ്വയം API കോൾ ചെയ്യുന്നതെങ്കിൽ, error.details വായിക്കുക; ചില എൻട്രികൾ ഒരു വാചകത്തിന് പകരം ഒരു കേവല മൂല്യം വഹിക്കുന്നു, നിങ്ങളുടെ റീസെല്ലർ പ്ലാനിൽ ഇടമില്ലാത്തപ്പോൾ max_sites: 0 നിങ്ങളിലേക്ക് എത്തുന്നത് അങ്ങനെയാണ്.

നിങ്ങളുടെ ആദ്യ ഓർഡറിന് മുമ്പ്

നിങ്ങളുടെ ക്ലയന്റുകൾ വാങ്ങുന്ന സൈറ്റുകൾ നിങ്ങളുടെ റീസെല്ലർ പ്ലാനിന്റെ സൈറ്റ് അലവൻസിലേക്ക് കണക്കാക്കുന്നു, അതിനാൽ നിങ്ങൾക്ക് ഇടമുള്ള ഒരു പ്ലാൻ ആവശ്യമാണ്. ഒരു കണക്ഷൻ ടെസ്റ്റിന് ഇത് കണ്ടെത്താനാകില്ല — ഇത് നിങ്ങളുടെ പ്രോഗ്രാം വായിക്കുകയും ഒന്നും പ്രൊവിഷൻ ചെയ്യാതിരിക്കുകയും ചെയ്യുന്നു — അതിനാൽ ഇതുവരെ വിൽക്കാൻ കഴിയാത്ത ഒരു അക്കൗണ്ട് തകരാറില്ലാത്തതായി ഇത് റിപ്പോർട്ട് ചെയ്യുന്നു. അലവൻസ് ഇല്ലാതെ നൽകുന്ന ഓർഡർ കൃത്യമായി ആ കാര്യം വ്യക്തമാക്കുന്ന സന്ദേശത്തോടെ നിരസിക്കപ്പെടും.

നിങ്ങളുടെ ഡൗൺലോഡ് സ്ഥിരീകരിക്കുക

രണ്ട് ആർക്കൈവുകളും ഞങ്ങളുടെ സ്വന്തം ഹോസ്റ്റ്‌നെയിമിൽ നിന്ന് TLS വഴി നൽകുന്നു, മറ്റെങ്ങോട്ടും റീഡയറക്ട് ചെയ്യുന്നില്ല, അവയുടെ SHA-256 ചെക്ക്സമ്മുകൾ ഡൗൺലോഡ് പേജിലെ ഡൗൺലോഡ് ലിങ്കുകൾക്ക് സമീപം അച്ചടിച്ചിരിക്കുന്നു.