የ Zinn® ሆስቲንግን ከ HostBill፣ Blesta ወይም ከራስዎ ስርዓት ይሽጡ

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® ኤፒአይ ቁልፍ (HostBill በምስጠራ እንዲያስቀምጠው የ password መስክ ነው)

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 እየጻፉ አይደለም? ተመሳሳይ ጥሪዎች በኤፒአይ ማጣቀሻ ውስጥ ይገኛሉ እና ከማንኛውም ነገር ሊያደርጓቸው ይችላሉ።

የኤፒአይ ቁልፉ

ሰባት ፈቃዶች፣ ከዚህ በላይ የለም፦ org.create፣ org.read፣ sites.create፣ sites.view፣ sites.delete፣ reseller.view፣ reseller.provision።

⛔ reseller.manage አይደለም። በቢሊንግ ፓነል ውስጥ የሚለጥፉት ቁልፍ ደንበኛን ባለመክፈሉ ምክንያት ማገድ እና ማስገባት መቻል አለበት፤ የእርስዎን የክፍያ መተላለፊያ ምስክርነቶች እንደገና መጻፍ መቻል የለበትም።

ሲጣሱ ገንዘብ የሚያስወጡ ሁለቱ ደንቦች

1. መለያውን በደንበኛዎ (CUSTOMER) ላይ፣ ጣቢያውን ደግሞ በአገልግሎትዎ (SERVICE) ላይ ይመድቡ። የአንድ ደንበኛ ሁለተኛ ትዕዛዝ አስቀድሞ ባለው መለያ ውስጥ መግባት አለበት። ሁለቱንም በአገልግሎቱ ላይ ከመደቡ አንድ ደንበኛ ሶስት ያልተዛመዱ መለያዎች እና ሶስት የተለያዩ የቁጥጥር ፓነሎች ይኖሩታል።
2. በእያንዳንዱ ፍጥረት ላይ ከእራስዎ መለያ ቁጥር የተገኘ የ idempotency ቁልፍ ይላኩ። እያንዳንዱ የክፍያ መጠየቂያ ስርዓት እንደገና ይሞክራል — የጌትዌይ መልስ ጥሪ ሁለት ጊዜ ይመጣል፣ አስተዳዳሪ ያልተሳካ ዝግጅትን እንደገና ያሄዳል፣ ደንበኛ ሁለቴ ጠቅ ያደርጋል። ያለሱ ሁለተኛው ሙከራ ሁለተኛ ጣቢያ ይፈጥራል እና ክፍያ ይጠየቁበታል። ሁለቱም ሞጁሎች እና የPHP ደንበኛው ይህንን ለእርስዎ ያደርጉልዎታል፤ ኤፒአይውን በቀጥታ እየጠሩ ከሆነ 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} መልሰው ያንብቡ፡ ከጣቢያው ዋና ጎራ ጋር ይነጻጸራል እንጂ ከአሊያስ ጋር በፍፁም አይነጻጸርም።

ዓረፍተ ነገሩን ብቻ ሳይሆን ሙሉውን ስህተት ያንብቡ

የማረጋገጫ እምቢታ መልእክት ሆን ተብሎ አጠቃላይ ነው — "ጥያቄው በሚገባ የተቀረጸ ነበር ነገር ግን ማረጋገጫ አልተሳካም።" — ምክንያቱም እርምጃ የሚወሰድበት ግማሽ በመስኩ እና ለምን እንደሆነ በሚገልጸው details ውስጥ ነው። ሁለቱም ሞጁሎች እና የ PHP ደንበኛ ለአስተዳዳሪዎ በሚያሳዩት መልእክት ላይ ያክሉታል። ኤፒአዩን እራስዎ እየጠሩ ከሆነ፣ error.details ን ያንብቡ፤ አንዳንድ ምዝግቦች ከዓረፍተ ነገር ይልቅ ባዶ እሴት ይይዛሉ፣ ይህም የዳግም ሻጭ እቅድዎ ምንም ቦታ በማይኖረው ጊዜ max_sites: 0 እርስዎን የሚደርስበት መንገድ ነው።

ከመጀመሪያው ትዕዛዝዎ በፊት

ደንበኞችዎ የሚገዙዋቸው ጣቢያዎች ለእርስዎ የዳግም ሻጭ እቅድ የጣቢያ አበል ይቆጠራሉ፣ ስለዚህ በውስጡ ቦታ ያለው እቅድ ያስፈልግዎታል። የግንኙነት ሙከራ ይሄንን ማወቅ አይችልም — ፕሮግራምዎን ያነባል እና ምንም አያዘጋጅም — ስለዚህ እስካሁን መሸጥ የማይችል ጤናማ መለያ ሪፖርት ያደርጋል። ያለ አበል የተሰጠ ትዕዛዝ ልክ ይሄንን በሚገልጽ መልእክት ውድቅ ይደረጋል።

የወረደውን ፋይል ያረጋግጡ

ሁለቱም ማህደሮች ከራሳችን አስተናጋጅ ስም በ TLS በኩል ይቀርባሉ፣ በጭራሽ ወደ ሌላ ቦታ አይዛወሩም፣ እና የእነሱ SHA-256 ቼክሰሞች በየማውረዶች ገጽ ላይ ከማውረጃ አገናኞች ጎን ታትመዋል።