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

ຖ້າທ່ານໃຊ້ 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: ຄີ API ຂອງ Zinn® ຂອງທ່ານ (ຊ່ອງ password, ດັ່ງນັ້ນ HostBill ຈຶ່ງຈັດເກັບມັນໄວ້ແບບເຂົ້າລະຫັດ)

1. ຢູ່ທີ່ຜະລິດຕະພັນ ໃຫ້ຕັ້ງ Product line (ເຊັ່ນ: mainstream), Stack (wordpress ເປັນ

ຄ່າເລີ່ມຕົ້ນ), ແລະ ເລືອກຕັ້ງ Application ແລະ PHP version ໄດ້ຕາມຕ້ອງການ.

2. ກົດ Test connection.

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

ສິ່ງອື່ນໆ — ໄຄລແອນ PHP

ຟາຍດຽວ, ບໍ່ມີ dependencies, ບໍ່ມີການກຳນົດລ່ວງໜ້າກ່ຽວກັບແຜງຄວບຄຸມ. ວາງ ZinnProvisioning.php ເຂົ້າໄປໃນ codebase ຂອງທ່ານເອງ ແລະ ເອີ້ນໃຊ້ຫົກເມທອດ.

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

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

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

ສອງກົດລະບຽບທີ່ຈະເຮັດໃຫ້ເສຍເງິນເມື່ອມີການລະເມີດ

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

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

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

ລະບົບຮຽກເກັບເງິນມີການລອງໃໝ່ — ການເອີ້ນກັບຂອງປະຕູຊຳລະເງິນມາຮອດສອງຄັ້ງ, ຜູ້ເບິ່ງແຍງລະບົບເປີດໃຊ້ງານຊ້ຳການສະໜອງບໍລິການທີ່ຫຼົ້ມເຫຼວ, ລູກຄ້າຄລິກສອງເທື່ອ. ຖ້າບໍ່ມີມັນ ຄວາມພະຍາຍາມຄັ້ງທີສອງຈະສ້າງເວັບໄຊຕ໌ທີສອງຂຶ້ນມາ ແລະ ທ່ານຈະຖືກຮຽກເກັບເງິນສຳລັບມັນ. ທັງສອງໂມດູນ ແລະ ໄຄລແອນ PHP ຈະຈັດການສິ່ງນີ້ໃຫ້ທ່ານ; ຖ້າທ່ານ ເອີ້ນໃຊ້ API ໂດຍກົງ, ໃຫ້ສົ່ງ Idempotency-Key.

ສາມຊ່ອງຂໍ້ມູນທີ່ມັກຖືກລະເລີຍໄດ້ງ່າຍ

ແຕ່ລະຊ່ອງຂໍ້ມູນຈະເຮັດໃຫ້ verb ທັງໝົດໃຊ້ການບໍ່ໄດ້, ແລະ ບໍ່ມີຊ່ອງໃດສະແດງຜົນເປັນຢ່າງອື່ນນອກຈາກຂໍ້ຜິດພາດໃນການກວດສອບ — ຍົກເວັ້ນ ຊ່ອງທຳອິດ, ເຊິ່ງຈະສະແດງຜົນເປັນ ບໍ່ມີຫຍັງເລີຍ:

• ⛔⛔ ລູກຄ້າຕ້ອງຖືກກຳນົດແພັກເກດ ກ່ອນ ທີ່ເວັບໄຊຕ໌ທຳອິດຂອງພວກເຂົາຈະຖືກສະໜອງບໍລິການ, ດ້ວຍ

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

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

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

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

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

ກວດສອບຄວາມຖືກຕ້ອງຂອງການດາວໂຫຼດຂອງທ່ານ

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