ज्ञानकोष

HostBill, Blesta वा तपाईंको आफ्नै प्रणालीबाट Zinn® होस्टिङ बेच्नुहोस्

HostBill, Blesta वा तपाईंको आफ्नै प्रणालीबाट Zinn® होस्टिङ बेच्नुहोस्: निःशुल्क HostBill मोड्युल, एकल-फाइल PHP क्लाइन्ट, उल्लङ्घन गर्दा पैसा खर्च हुने दुई नियमहरू, र छुटाउन सजिलो हुने दुई अनुरोध क्षेत्रहरू।

यदि तपाईं WHMCS चलाउनुहुन्छ भने, यसको सट्टा WHMCS मोड्युल प्रयोग गर्नुहोस् — यो पृष्ठ अन्य सबै कुराका लागि हो। त्यहाँ दुईवटा विकल्पहरू छन्, दुवै निःशुल्क र दुवै GPL-2.0-or-later।

HostBill

WHMCS जस्तै छ वटा समान कार्यहरू भएको होस्टिङ मोड्युल।

  1. यसलाई डाउनलोड गर्नुहोस् र अनजिप गर्नुहोस्।
  2. zinn डाइरेक्टरीलाई includes/modules/Hosting/ मा अपलोड गर्नुहोस् ताकि फाइलहरू includes/modules/Hosting/zinn/class.zinn.php र includes/modules/Hosting/zinn/ZinnHostBillClient.php मा बसून्।
  3. Settings → Modules → Hosting मा जानुहोस्, Zinn Digital® सक्रिय गर्नुहोस्, र एउटा जडान थप्नुहोस्:
  • API address: https://api.zinndigital.com
  • API key: तपाईंको Zinn® API key (एउटा 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'));

// When an order is paid — once per CUSTOMER, then once per SERVICE:
$orgId  = $zinn->account('customer-4211', 'Acme Ltd');
$siteId = $zinn->provision('service-9915', $orgId, 'acme.com', 'mainstream', 'wordpress');
// Store $orgId against your customer and $siteId against your service.

$zinn->suspend($siteId, 'INV-2026-114 unpaid');   // an invoice goes unpaid
$zinn->unsuspend($siteId);                        // they pay
$zinn->terminate($siteId);                        // they cancel — schedules a deletion

// When they click "log in to my hosting" — mint it on the CLICK, never on page render:
header('Location: ' . $zinn->signInLink($siteId));

PHP लेख्नुहुन्न? उही कलहरू API सन्दर्भ मा छन् र तपाईं ती जुनसुकैबाट पनि गर्न सक्नुहुन्छ।

API key

सातवटा अनुमतिहरू, र त्योभन्दा बढी होइन: org.create, org.read, sites.create, sites.view, sites.delete, reseller.view, reseller.provision।

⛔ reseller.manage होइन। तपाईंले बिलिङ प्यानलमा टाँस्नुहुने कुञ्जीले भुक्तानी नगरेको खण्डमा ग्राहकलाई रोक्न र उनीहरूलाई साइन इन गराउन सक्नुपर्दछ; यसले तपाईंको आफ्नै भुक्तानी-गेटवे प्रमाणहरू पुन: लेख्न सक्नु हुँदैन।

दुईवटा नियमहरू जसलाई उल्लङ्घन गर्दा पैसा खर्च हुन्छ

  1. खातालाई तपाईंको CUSTOMER मा, र साइटलाई तपाईंको SERVICE मा आधारित गर्नुहोस्। ग्राहकको दोस्रो अर्डर उनीहरूसँग पहिले नै भएको खातामा जानुपर्छ। दुवैलाई सेवामा आधारित गर्दा एक ग्राहकका तीनवटा असम्बन्धित खाताहरू र तीनवटा छुट्टाछुट्टै नियन्त्रण प्यानलहरू हुन पुग्छन्।
  2. प्रत्येक सिर्जनामा वस्तुको लागि तपाईंको आफ्नै id बाट व्युत्पन्न गरिएको एउटा idempotency key पठाउनुहोस्। प्रत्येक बिलिङ प्रणालीले पुन: प्रयास गर्दछ — गेटवे कलब्याक दुई पटक आउँछ, प्रशासकले असफल प्रावधान पुन: चलाउँछ, ग्राहकले दुई पटक क्लिक गर्दछ। यस बिना दोस्रो प्रयासले दोस्रो साइट सिर्जना गर्दछ र तपाईंलाई यसको लागि बिल गरिन्छ। दुवै मोड्युल र PHP क्लाइन्टले यो तपाईंको लागि गर्दछन्; यदि तपाईं API लाई सिधै कल गर्दै हुनुहुन्छ भने, Idempotency-Key पठाउनुहोस्।

तीनवटा फिल्डहरू जुन छुटाउन सजिलो छ

प्रत्येकले पूरै भर्बलाई बिगार्छ, र पहिलो बाहेक कुनै पनि प्रमाणीकरण त्रुटि बाहेक अरू केहीको रूपमा देखा पर्दैन — पहिलो भने केही पनि नभएको रूपमा देखा पर्दछ:

  • ⛔⛔ ग्राहकको पहिलो साइट प्रोभिजन हुनु अगावै उनीहरूलाई कुनै योजनामा राख्नुपर्छ, 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} बाट डोमेन पुन: पढ्नुहोस्: यसलाई साइटको आफ्नै प्राथमिक डोमेनसँग तुलना गरिन्छ र कुनै उपनाम (alias) सँग कहिल्यै गरिँदैन।

वाक्य मात्र होइन, सम्पूर्ण त्रुटि पढ्नुहोस्

प्रमाणीकरण अस्वीकृतिको सन्देश जानाजानी सामान्य राखिएको हुन्छ — "अनुरोध सही ढाँचामा थियो तर प्रमाणीकरण असफल भयो।" — किनभने कार्यान्वयन योग्य आधा भाग details मा हुन्छ, जसले फाँट र यसको कारण खुलाउँछ। दुवै मोड्युलहरू र PHP क्लाइन्टले यसलाई तपाईंको एडमिनलाई देखाउने सन्देशमा जोड्दछन्। यदि तपाईं आफैँ API कल गर्दै हुनुहुन्छ भने, error.details पढ्नुहोस्; केही प्रविष्टिहरूले वाक्यको सट्टा केवल मान मात्र बोक्छन्, जुन तपाईंको रिसेलर योजनामा ठाउँ नहुँदा max_sites: 0 तपाईं समक्ष यसरी नै पुग्छ।

तपाईंको पहिलो अर्डर अघि

तपाईंका ग्राहकहरूले खरिद गर्ने साइटहरू तपाईंको रिसेलर योजनाको साइट सीमा विरुद्ध गणना हुन्छन्, त्यसैले तपाईंलाई ठाउँ भएको योजना चाहिन्छ। जडान परीक्षणले यो पत्ता लगाउन सक्दैन — यसले तपाईंको कार्यक्रम पढ्छ र केही पनि प्रोभिजन गर्दैन — त्यसैले यसले स्वस्थ खाता भएको रिपोर्ट गर्छ जसले अझै बेच्न सक्दैन। सीमा बिना गरिएको अर्डर ठ्याक्कै त्यही बताउने सन्देश सहित अस्वीकृत हुन्छ।

आफ्नो डाउनलोड प्रमाणित गर्नुहोस्

दुवै सङ्ग्रहहरू (archives) हाम्रो आफ्नै होस्टनामबाट TLS मार्फत सेवा गरिन्छ, अन्य कतै पनि पुन: निर्देशित गरिँदैन, र तिनीहरूको SHA-256 चेकसमहरू डाउनलोड पृष्ठ मा डाउनलोड लिङ्कहरूको छेउमा छापिएका छन्।

ब्लगबाट पछिल्लो

होस्टिङ, SEO र ठूलो मात्रामा साइटहरू सञ्चालन गर्ने बारे हामीले लेखेका कुराहरू।

होस्टिङ तहबाट एसइओ र लिङ्क निर्माण: २०२६ का अपरेटरको दृष्टिकोण

सन् २०२६ मा होस्टिङले इन्डेक्सिङ र लिङ्क इक्विटीलाई कसरी रूप दिन्छ: पृष्ठहरूलाई इन्डेक्समा राखिराख्ने, निर्माण गर्नुअघि पुराना डोमेनहरू जाँच गर्ने, कुनै सर्च फुटप्रिन्ट बिना लिङ्क निर्माण गर्ने, र पूर्वाधारले एसइओका लागि के गर्न सक्छ र के गर्न सक्दैन भन्ने बारेमा इमानदार दृष्टिकोण।

पोस्ट पढ्नुहोस् →

WordPress लाई द्रुत र सुरक्षित बनाउने: कार्यसम्पादन र प्लगइन चेकलिस्ट

द्रुत, सुरक्षित WordPress का लागि एक व्यावहारिक चेकलिस्ट: सर्भर-स्तरको क्यासिङ, प्रति-साइट अब्जेक्ट क्यास, चलाउन लायक केही सीमित प्लगइनहरू, स्ट्याकलाई अद्यावधिक राख्ने, र तपाईंले कहिल्यै क्यास गर्न नहुने WooCommerce पृष्ठहरू।

पोस्ट पढ्नुहोस् →

२०२६ मा व्यवस्थित वेब होस्टिङ कसरी छनौट गर्ने: एक खरिदकर्ताको गाइड

कन्ट्रोल प्यानल भएको सस्तो बक्सबाट राम्रो व्यवस्थित होस्टिङलाई वास्तवमा केले फरक पार्छ — माइग्रेसन, ब्याकअप, अलगाव, वास्तविक क्यासिङ र इमानदार स्केलिंग — र तपाईंले प्रतिबद्ध हुनुअघि यसलाई कसरी मूल्याङ्कन गर्ने।

पोस्ट पढ्नुहोस् →

ब्लग पढ्नुहोस् →

अझै पनि समस्या भइरहेको छ?

सबै योजनाहरूमा सहयोग समावेश गरिएको छ, हेल्पडेस्क दिनको 24 घण्टा खुला रहन्छ, र तपाईंले हाम्रा कुनै पनि 58 भाषाहरूमा हामीलाई लेख्न सक्नुहुन्छ—हामी तपाईंले बुझ्ने भाषामा जवाफ दिन्छौं।

सहयोगलाई सम्पर्क गर्नुहोस् → सबै लेखहरू →