د HostBill، Blesta، یا خپل سیسټم څخه د Zinn® کوربه توب وپلورئ

که تاسو 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. تنظیمات → ماډلونه → کوربه توب، Zinn Digital® فعال کړئ، او یو پیوستون اضافه کړئ:

• د API پته: https://api.zinndigital.com
• د API کلي: ستاسو د Zinn® د API کلي (د password ساحه ده، نو ځکه HostBill دا په کوډ شوې بڼه ساتي)

1. په محصول باندې د محصول کرښه (د بېلګې په توګه mainstream)، سټیک (په اصلي بڼه wordpress)، او اختیاري توګه اپلیکیشن او د PHP نسخه وټاکئ.
2. پیوستون و ازمویئ باندې کلیک وکړئ.

⛔ د 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 کلي

اووه اجازې، او نور هېڅ نه: org.create، org.read، sites.create، sites.view، sites.delete، reseller.view، reseller.provision.

⛔ نه reseller.manage. هغه کلي چې تاسو یې د بلینګ په پنل کې لګوئ باید د دې وړتیا ولري چې یو پیرودونکی د نه تادیې له امله وځنډوي او هغه ننوځي؛ دا باید ونه شي کولی چې ستاسو د تادیې د لارې خپل اسناد بیا ولیکي.

دوه هغه قواعد چې د ماتېدو په صورت کې پیسې ضایع کوي

1. حساب له خپل پیرودونکي سره، او سایټ له خپل خدمت سره ونښلوئ. د یو پیرودونکي دوهم فرمایش باید په هغه حساب کې راشي چې دوی یې دمخه لري. که دواړه له خدمت سره ونښلوئ نو یو پیرودونکی به په دریو نامربوطه حسابونو او دریو جلا کنټرول پنلونو پای ته ورسیږي.
2. په هر جوړولو باندې د آيډم پوټینسي کلي ولېږئ، چې د هماغه شي لپاره ستاسو له خپل پیژند څخه اخیستل شوې وي. د بلینګ هر سیسټم بیا هڅه کوي — د ګیټ وے کال بیک دوه ځله راځي، یو اډمین ناکامه شوې پروسه بیا پرمخ وړي، یو پیرودونکی دوه ځله کلیک کوي. پرته له دې، دوهمه هڅه دوهم سایټ جوړوي او ستاسو څخه به د هغې بیل واخیستل شي. دواړه ماډلونه او د PHP کلینټ دا کار ستاسو لپاره کوي؛ که تاسو په مستقیم ډول API غواړئ، Idempotency-Key واستوئ.

درې ساحې چې په اسانۍ سره پاتې کېدای شي

هر یو یې یو بشپړ فعل ماتوي، او هېڅ یو یې پرته له تاییدي تېروتنې نه ښکاري — پرته له لومړي څخه، چې د هېڅ شی په توګه نه ښکاري:

• ⛔⛔ یو پېرودونکی باید د خپل لومړي سایټ له چمتو کېدو مخکې په یو پلان کې شامل شي، د POST /v1/reseller/clients/{orgId}/plan له لارې، او د هغې subscription_id باید POST /v1/sites ته واستول شي. دا هغه یو دی چې د لوستلو لپاره هیڅ تېروتنه نلري. د نوي پېرودونکي حساب هیڅ ګډون (subscription) نلري او POST /v1/sites د پلان هیڅ ساحه نلري، نو له دې پرته چمتو شوی سایټ هیڅ پلان نلري: ستاسو عمده پلور بیان (wholesale statement) ستاسو د پېرودونکو له فعالو ګډونونو څخه جوړیږي، نو هیڅ کرښه نه اضافه کیږي او Zinn® تاسو ته هیڅ لګښت نه درکوي تر هغه وخته چې کوربه توب روان وي؛ ستاسو پېرودونکی هیڅ امتیازات نه ترلاسه کوي، نو د هغوی په سایټ هیڅ کوټه نه پلي کیږي؛ او د لوړولو (upgrade) لپاره هیڅ نشته چې بدل شي. سپارښتنه 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) سره نه پرتله کیږي.

ټوله تېروتنه ولولئ، نه یوازې جمله

د تایید د رد کولو پیغام په قصدي ډول عمومي دی — "The request was well-formed but failed validation." — ځکه چې د اقدام وړ برخه په details کې ده، کوم چې ساحه او لامل په ګوته کوي. دواړه ماډلونه او د PHP پېرودونکی دا هغه پیغام ته ضمیمه کوي چې ستاسو اډمین ته ښودل کیږي. که تاسو پخپله API غواړئ، نو error.details ولولئ؛ ځینې داخلې د یوې جملې پرځای یو خالي ارزښت لري، چې دا په دې ډول دی چې max_sites: 0 تاسو ته رسیږي کله چې ستاسو د پلورونکي پلان ځای ونه لري.

ستاسو د لومړي سپارښتنې څخه مخکې

هغه سایټونه چې ستاسو پېرودونکي یې اخلي ستاسو د پلورونکي پلان د سایټ امتیازاتو کې حساب کیږي، نو تاسو داسې پلان ته اړتیا لرئ چې ځای ولري. د پیوستون ازموینه نشي کولی دا کشف کړي — دا ستاسو پروګرام لولي او هیڅ شی نه چمتو کوي — نو دا د یو روغ حساب راپور ورکوي چې لاهم نشي پلورلی. پرته له کافي امتیازاتو ثبت شوې سپارښتنه د یوه داسې پیغام سره رد کیږي چې دقیقا همدا وایي.

خپل ډاونلوډ تایید کړئ

دواړه آرشیفونه زموږ د خپل کوربه نوم څخه د TLS له لارې وړاندې کیږي، هیڅکله بل ځای ته نه راګرځول کیږي، د دوی SHA-256 چیک سمونو سره چې د ډاونلوډونو پاڼه کې د ډاونلوډ لینکونو ترڅنګ چاپ شوي دي.