پایگاه دانش

میزبانی Zinn® را از طریق HostBill، Blesta یا سیستم خود به فروش برسانید

میزبانی Zinn® را از طریق HostBill، Blesta یا سیستم اختصاصی خود بفروشید: ماژول رایگان HostBill، کلاینت PHP تک‌فایلی، دو قانونی که نقض آن‌ها هزینه مالی در پی دارد و دو فیلد درخواست که نادیده گرفتن آن‌ها بسیار محتمل است.

اگر از WHMCS استفاده می‌کنید، به جای این از ماژول WHMCS استفاده نمایید — این صفحه برای موارد دیگر است. دو گزینه وجود دارد که هر دو رایگان و هر دو تحت مجوز GPL-2.0-or-later هستند.

HostBill

یک ماژول هاستینگ با همان شش عملیات ماژول WHMCS.

۱. آن را دانلود کنید و از حالت فشرده خارج نمایید. ۲. دایرکتوری zinn را در includes/modules/Hosting/ بارگذاری کنید تا فایل‌ها در includes/modules/Hosting/zinn/class.zinn.php و includes/modules/Hosting/zinn/ZinnHostBillClient.php قرار گیرند. ۳. به مسیر Settings → Modules → Hosting بروید، Zinn Digital® را فعال کنید و یک اتصال اضافه نمایید:

  • API address: https://api.zinndigital.com
  • API key: کلید API مربوط به Zinn® شما (یک فیلد password، بنابراین HostBill آن را به‌صورت رمزگذاری‌شده ذخیره می‌کند)
  • ۴. روی محصول، گزینه‌های Product line (مثلاً mainstream)، Stack (به‌طور پیش‌فرض wordpress)، و در صورت تمایل Application و PHP version را تنظیم کنید. ۵. روی 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

هفت مجوز، و نه بیشتر: org.create، org.read، sites.create، sites.view، sites.delete، reseller.view، reseller.provision.

⛔ نه reseller.manage. کلیدی که در یک پنل صورت‌حساب جای‌گذاری می‌کنید باید بتواند مشتری را به دلیل عدم پرداخت معلق کند و او را وارد سیستم نماید؛ این کلید نباید قادر به بازنویسی اطلاعات اعتباری درگاه پرداخت خود شما باشد.

دو قانونی که در صورت نقض شدن هزینه مالی در پی دارند

۱. حساب را بر اساس CUSTOMER خود و سایت را بر اساس SERVICE خود کلیدگذاری کنید. سفارش دوم مشتری باید در حسابی که از قبل دارد قرار گیرد. اگر هر دو را بر اساس سرویس کلیدگذاری کنید، یک مشتری در نهایت با سه حساب نامرتبط و سه پنل کنترل جداگانه مواجه می‌شود. ۲. در هر ایجاد، یک کلید یکتایی (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}` بخوانید: این مقدار با دامنه اصلی خود سایت مقایسه می‌شود و هرگز با یک نام مستعار مقایسه نمی‌گردد.

کل پیام خطا را بخوانید، نه فقط جمله را

پیام رد اعتبارسنجی عمداً عمومی است — "The request was well-formed but failed validation." — زیرا نیمی از اطلاعات قابل اقدام در details قرار دارد که نام فیلد و دلیل آن را مشخص می‌کند. هر دو ماژول و کلاینت PHP آن را به پیامی که به مدیر شما نشان می‌دهند پیوست می‌کنند. اگر خودتان API را فرامی‌خوانید، error.details را بخوانید؛ برخی از ورودی‌ها به جای یک جمله حاوی یک مقدار صرف هستند، یعنی همان شیوه‌ای که وقتی طرح نمایندگی شما فضا ندارد max_sites: 0 به دست شما می‌رسد.

پیش از نخستین سفارش شما

سایت‌هایی که مشتریان شما خریداری می‌کنند جزو سهمیه سایت طرح نمایندگی شما محسوب می‌شوند، بنابراین به یک طرح با فضای خالی نیاز دارید. آزمون اتصال نمی‌تواند این را تشخیص دهد — برنامه شما را می‌خواند و چیزی راه‌اندازی نمی‌کند — بنابراین گزارش یک حساب سالم را ارائه می‌دهد که هنوز نمی‌تواند بفروشد. سفارشی که بدون سهمیه ثبت شود با پیامی دقیقاً حاوی همین مضمون رد خواهد شد.

فایل دانلودی خود را تأیید کنید

هر دو آرشیو از طریق TLS از نام میزبان خود ما ارائه می‌شوند، هرگز به جای دیگری تغییر مسیر نمی‌دهند، و چک‌سام‌های SHA-256 آن‌ها در کنار پیوندهای دانلود در صفحه دانلودها درج شده است.

جدیدترین‌های وبلاگ

آنچه درباره میزبانی وب، سئو و مدیریت سایت‌ها در مقیاس بزرگ نوشته‌ایم.

سئو و لینک‌سازی از لایه میزبانی: دیدگاه یک اپراتور در سال ۲۰۲۶

چگونه هاستینگ در سال ۲۰۲۶ بر ایندکس شدن و انتقال اعتبار لینک تأثیر می‌گذارد: حفظ صفحات در ایندکس، ارزیابی دامنه‌های قدیمی قبل از راه‌اندازی سایت روی آن‌ها، لینک‌سازی بدون ردپای سئو، و رویکردی واقع‌بینانه درباره اینکه زیرساخت چه کارهایی را می‌تواند و چه کارهایی را نمی‌تواند برای سئو انجام دهد.

خواندن مطلب ←

سریع و امن کردن WordPress: چک‌لیست عملکرد و افزونه‌ها

یک چک‌لیست کاربردی برای WordPress سریع و ایمن: کش کردن در سطح سرور، کش اشیاء به ازای هر سایت، تعداد اندک افزونه‌هایی که ارزش استفاده دارند، به‌روز نگه داشتن بسته نرم‌افزاری، و برگه های WooCommerce که هرگز نباید آن‌ها را کش کنید.

خواندن مطلب ←

نحوه انتخاب هاست مدیریت‌شده وب در سال ۲۰۲۶: راهنمای خریدار

چه چیزی واقعاً یک میزبانی مدیریت‌شده خوب را از یک جعبه ارزان‌قیمت دارای کنترل‌پنل متمایز می‌کند — مهاجرت‌ها، نسخه‌های پشتیبان، جداسازی، حافظه پنهان واقعی و مقیاس‌پذیری صادقانه — و چگونه پیش از تعهد، آن را ارزیابی کنید.

خواندن مطلب ←

وبلاگ را بخوانید ←

هنوز به مشکل برخورده‌اید؟

پشتیبانی در تمامی پلن‌ها گنجانده شده است، میز خدمت 24 ساعت در روز باز است و می‌توانید به هر یک از زبان‌های 58 ما برای ما بنویسید؛ ما به زبان شما پاسخ می‌دهیم.

تماس با پشتیبانی → همه مقاله‌ها →