ຂາຍໂຮສຕິ້ງ Zinn® ຈາກ HostBill, Blesta, ຫຼື ລະບົບຂອງທ່ານເອງ

ຖ້າທ່ານໃຊ້ WHMCS, ກະລຸນາໃຊ້ ໂມດູນ WHMCS ຖ້ານອກນັ້ນ — ໜ້ານີ້ແມ່ນສຳລັບ ທຸກໆຢ່າງອື່ນ. ມີສອງຕົວເລືອກ, ທັງສອງແມ່ນຟຣີ ແລະ ທັງສອງເປັນ GPL-2.0-or-later.

HostBill

ໂມດູນ ໂຮສຕິ້ງ ທີ່ມີຫົກການດຳເນີນການຄືກັນກັບຂອງ WHMCS.

1. ດາວໂຫຼດມັນ ແລະ ແຕກໄຟລ໌ zip.
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: API key ຂອງ Zinn® ຂອງທ່ານ (ຟີລດ໌ password, ດັ່ງນັ້ນ HostBill ຈະເກັບຮັກສາມັນໄວ້ແບບເຂົ້າລະຫັດ)

1. ໃນຜະລິດຕະພັນ ໃຫ້ກຳນົດ Product line (ຕົວຢ່າງ mainstream), Stack (wordpress ໂດຍ

ເລີ່ມຕົ້ນ), ແລະ ຕົວເລືອກ Application ແລະ PHP version.

2. ກົດ Test connection.

⛔ ຢ່າປ່ຽນຊື່ໄດເລກທໍຣີ zinn. Loader ຂອງ HostBill ໄດ້ຮັບ ຄລາສ ທີ່ມັນຊອກຫາ ຈາກຊື່ໄດເລກທໍຣີ, ດັ່ງນັ້ນການປ່ຽນຊື່ຈະສ້າງໂມດູນທີ່ແຜງຄວບຄຸມສະແດງລາຍຊື່ແຕ່ບໍ່ເຄີຍຮຽກໃຊ້ງານ.

ອື່ນໆ — PHP client

ໄຟລ໌ດຽວ, ບໍ່ມີ dependencies, ບໍ່ມີຂໍ້ກຳນົດກ່ຽວກັບແຜງຄວບຄຸມ. ວາງ 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 reference ແລະ ທ່ານສາມາດຮຽກໃຊ້ພວກມັນໄດ້ຈາກທຸກຢ່າງ.

API key

ເຈັດສິດທິ, ແລະ ບໍ່ມີຫຼາຍກວ່ານັ້ນ: org.create, org.read, sites.create, sites.view, sites.delete, reseller.view, reseller.provision.

⛔ ບໍ່ແມ່ນ reseller.manage. ຄີ ທີ່ທ່ານວາງລົງໃນແຜງລະບົບຊຳລະເງິນຄວນຈະສາມາດລະງັບ ລູກຄ້າເນື່ອງຈາກບໍ່ຊຳລະເງິນ ແລະ ເຂົ້າສູ່ລະບົບໃຫ້ພວກເຂົາໄດ້; ມັນບໍ່ຄວນຈະສາມາດຂຽນທັບຂໍ້ມູນ ປະຕູຊຳລະເງິນຂອງທ່ານເອງໄດ້.

ສອງກົດເກນທີ່ຕ້ອງເສຍເງິນເມື່ອລະເມີດ

1. ກຳນົດ Key ຂອງບັນຊີຕາມ ລູກຄ້າ ຂອງທ່ານ, ແລະ ກຳນົດ Key ຂອງເວັບໄຊຕາມ ບໍລິການ ຂອງທ່ານ. ບອກຄຳສັ່ງຊື້ທີສອງຂອງລູກຄ້າ

ຕ້ອງໄປຢູ່ໃສ່ບັນຊີທີ່ພວກເຂົາມີຢູ່ແລ້ວ. ຖ້າກຳນົດ Key ທັງສອງຕາມບໍລິການ, ລູກຄ້າຄົນດຽວ ຈະຈົບລົງດ້ວຍສາມບັນຊີທີ່ບໍ່ກ່ຽວຂ້ອງກັນ ແລະ ສາມແຜງຄວບຄຸມທີ່ແຍກກັນ.

2. ສົ່ງ idempotency key ໃນທຸກໆການສ້າງ, ໂດຍອ້າງອີງຈາກ ID ຂອງທ່ານເອງສຳລັບສິ່ງນັ້ນ. ທຸກໆ

ລະບົບຊຳລະເງິນຈະພະຍາຍາມໃໝ່ — ການຄືນຄ່າ callback ຂອງປະຕູຊຳລະເງິນມາຮອດສອງຄັ້ງ, ແອດມິນດຳເນີນການຈັດສັນ ທີ່ລົ້ມເລວຄືນໃໝ່, ລູກຄ້າກົດດັບເບິນຄລິກ. ຖ້າບໍ່ມີມັນ ການພະຍາຍາມຄັ້ງທີສອງຈະສ້າງເວັບໄຊທີສອງ ແລະ ທ່ານຈະຖືກເກັບເງິນສຳລັບມັນ. ທັງສອງໂມດູນ ແລະ PHP client ຈະເຮັດສິ່ງນີ້ໃຫ້ທ່ານ; ຖ້າທ່ານ ຮຽກໃຊ້ 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} ຕ້ອງການ body `{"confirm_domain": "<the site's own

domain>"}** — ການຢືນຢັນໂດຍການພິມ, ເພາະວ່ານີ້ແມ່ນຄຳສັ່ງທີ່ຈະລົບຂໍ້ມູນ. ຖ້າຂ້າມມັນໄປ ຈະບໍ່ມີ ການຍົກເລີກໃດປະສົບຜົນສໍາເລັດ, ດັ່ງນັ້ນບໍລິການຈະສືບຕໍ່ເຮັດວຽກ ແລະ ທ່ານຈະຖືກເກັບເງິນສຳລັບມັນຕໍ່ໄປ. ໃຫ້ອ່ານໂດເມນຄືນຈາກ GET /v1/reseller/services/{siteId}` ແທນທີ່ຈະໃຊ້ ບັນທຶກຂອງທ່ານເອງ: ມັນຈະຖືກປຽບທຽບກັບໂດເມນຫຼັກຂອງເວັບໄຊເອງ ແລະ ບໍ່ເຄີຍປຽບທຽບກັບ alias.

ອ່ານຂໍ້ຜິດພາດທັງໝົດ, ບໍ່ແມ່ນແຕ່ປະໂຫຍດດຽວ

ຂໍ້ຄວາມການປະຕິເສດການກວດສອບຄວາມຖືກຕ້ອງແມ່ນມີລັກສະນະທົ່ວໄປໂດຍເຈດຕະນາ — "The request was well-formed but failed validation." — ເພາະວ່າເຄິ່ງໜຶ່ງທີ່ສາມາດດຳເນີນການໄດ້ແມ່ນຢູ່ໃນ details, ຢ່າງໃດກໍຕາມໄດ້ລະບຸຊື່ຟີລດ໌ ແລະ ເຫດຜົນ. ທັງສອງໂມດູນ ແລະ PHP client ຈະຕໍ່ມູນນັ້ນໃສ່ຂໍ້ຄວາມທີ່ພວກເຂົາສະແດງໃຫ້ແອດມິນຂອງທ່ານເບິ່ງ. ຖ້າທ່ານ ຮຽກໃຊ້ API ດ້ວຍໂຕທ່ານເອງ, ໃຫ້ອ່ານ error.details; ບາງລາຍການຈະມີຄ່າທີ່ຫວ່າງເປົ່າແທນທີ່ຈະເປັນ ປະໂຫຍດ, ເຊິ່ງແມ່ນວິທີທີ່ max_sites: 0 ສ່ງເຖິງທ່ານ ເມື່ອແພັກເກດຕົວແທນຈໍາໜ່າຍຂອງທ່ານບໍ່ມີພື້ນທີ່ຫວ່າງ.

ກ່ອນຄຳສັ່ງຊື້ທຳອິດຂອງທ່ານ

ເວັບໄຊທີ່ລູກຄ້າຂອງທ່ານຊື້ຈະຖືກນັບໃສ່ໃນໂຄຕາເວັບໄຊຂອງແພັກເກດຕົວແທນຈໍາໜ່າຍ ຂອງທ່ານ, ດັ່ງນັ້ນທ່ານຕ້ອງການ ແພັກເກດທີ່ມີພື້ນທີ່ຫວ່າງ. ການທົດສອບການເຊື່ອມຕໍ່ບໍ່ສາມາດກວດພົບສິ່ງນີ້ໄດ້ — ມັນຈະອ່ານໂຄຣແກຣມຂອງທ່ານ ແລະ ບໍ່ຈັດສັນຫຍັງເລີຍ — ດັ່ງນັ້ນມັນຈຶ່ງລາຍງານບັນຊີທີ່ສົມບູນດີແຕ່ຍັງບໍ່ສາມາດຂາຍໄດ້. ຄຳສັ່ງຊື້ທີ່ດຳເນີນການ ໂດຍບໍ່ມີໂຄຕາຈະຖືກປະຕິເສດດ້ວຍຂໍ້ຄວາມທີ່ລະບຸແນວນັ້ນຢ່າງຊັດເຈນ.

ຢືນຢັນການດາວໂຫຼດຂອງທ່ານ

ທັງສອງ ໄຟລ໌ເກັບ ໄດ້ຖືກໃຫ້ບໍລິການຜ່ານ TLS ຈາກ hostname ຂອງພວກເຮົາເອງ, ບໍ່ເຄີຍຖືກປ່ຽນເສັ້ນທາງໄປບ່ອນອື່ນ, ໂດຍມີ SHA-256 checksums ພິມຢູ່ທາງຂ້າງລິ້ງດາວໂຫຼດໃນ ໜ້າດາວໂຫຼດ.