FAQ

How do I install it?

TODO

تغییرات

0.4.7

اصلاح‌شده

• آسیب‌پذیری «تعریفِ مجددِ تابعِ هسته در آزمونِ دودی» برطرف شد: `src/tests/smoke.php` تابع‌هایِ شبه‌سازِ هستهٔ وردپرس (`get_option`، `wp_parse_args` و…) را تعریف می‌کرد؛ چون در بستهٔ ۰٫۴٫۶ داخلِ پکیج منتشر می‌شد، رنیمر فکر می‌کرد این‌ها تابع‌هایِ تعریف‌شدهٔ پروژه‌اند و همهٔ فراخوانی‌هایِ واقعی را همنامِ جدید می‌کرد → هنگامِ فعّال‌سازیِ پلاگین: `Call to undefined function`. حالا درختِ `tests/` هرگز داخلِ محصول منتشر نمی‌شود و فراخوانی‌هایِ هسته دست‌نخورده می‌مانند. نسخهٔ سه‌طرفه؛ باندلِ SDK همچنان `2.0.1` و به‌روز.
  



0.4.6





اصلاح‌شده


• انتشار نگهداری بدون تغییر رفتاری: همگام‌سازی سه‌طرفهٔ نسخه (`Version:` هدر، `IMEDGE_VERSION` و `khaleghi.json` همگی `0.4.6`)؛ باندلِ SDK همچنان `2.0.1` و به‌روز.
  



0.4.5





افزوده‌شده


• بستهٔ Khaleghi SDK به محصول اضافه شد: در بالاترین نقطهٔ فایلِ اصلیِ پلاگین (نگهبانِ `KHALEGHI_SDK_VERSION` → `require_once khaleghi-sdk/khaleghi-sdk.php` → `Khaleghi\SDK\Init(__FILE__)`) بارگذاری می‌شود. کارِ SDK فقط یک چیز است: تضمینِ نصب/فعال بودنِ پلاگینِ همراهِ «Khaleghi Repository» روی سایت؛ اگر همراه نبود، آن را به‌صورتِ برنامه‌ریزی‌شده دانلود/نصب/فعال می‌کند و به مدیر اعلام می‌کند. بارگذاریِ نسخهٔ تکراری (از چند محصولِ خالقی) با نگهبان‌هایِ اعلام، هرگز خطایِ «cannot redeclare» نمی‌دهد — اولین نسخه‌ای که بارگذاری شود، پیاده‌سازیِ کل سایت را فراهم می‌کند.
  
• برشِ «ثبتِ خودکار + نردبانِ تلاش مجدد» (که مضمونِ آن زیرِ 0.4.4 شرح داده شد) با همین نسخه به‌صورتِ رسمی واردِ بستهٔ منتشرشده می‌شود.
  
• نسخه‌های `khaleghi.json`، هدرِ وردپرس، `IMEDGE_VERSION` و فایل‌هایِ `imedge.pot/imedge-fa_IR.po/.mo` همگی ۰٫۴٫۵.
  



پوشش آزمون


• `php -l` روی همهٔ فایل‌هایِ PHP (شاملِ باندلِ SDK) پاک؛ آزمونِ دودی ۲۰۵ بررسی / ۰ شکست؛ `kwp_validate` پاک (باندلِ SDK حالا حضور دارد).
  



0.4.4





افزوده‌شده


• بازبست‌شدنِ امکانِ «اگر شکست خورد اپراتور بفهمد»: ثبتِ خودکارِ این سایت حالا در خودِ وردپرس یک رکوردِ بازبینی‌پذیر نگه می‌دارد — `imedge_registration_state()` (گزینهٔ مستقلِ `imedge_registration_state`، بیرون از تنظیماتِ اپراتور تا ذخیره/بازنشانیِ تنظیمات هرگز آن را پاک نکند). نقشهٔ وضعیت/تلاش‌ها/آخرین‌کد/آخرین‌خطا/گامِ بعدی به‌صورتِ زنده در داشبوردِ «اتصال» رندر می‌شود، پس اپراتور دقیقاً می‌بیند چه اتفاقی در وردپرس افتاده (در انتظارِ تأیید در صندوقِ ورودیِ موتور، قبلاً روی‌برد شده، امتناعِ ۴۰۳/خطایِ انتقال/محدودیتِ نرخ). این که آیا شکستِ ثبت فقط در موتور قابل‌مشاهده است یا در وردپرس: قراردادِ این برش، روی‌بردِ خطا در وردپرس و بازبینیِ اپراتور در همان داشبورد است — موتور دست نمی‌خورد.
  
• نردبانِ تلاشِ مجددِ سقف‌دارِ غیرانباشتنی: تلاشِ بعدی با صعودِ ۵دقیقه←۳۰دقیقه←۲ساعت←۱۲ساعت←۱روز و سقفِ پایانی‌دار برنامه‌ریزی می‌شود (گزارشِ ۲۰۲ پیامِ ترموب؛ اگر تلاش‌ها ≥۵، عقب‌اندازی خالی می‌شود و دیگر تلاشی نمی‌فرستیم). هر رویدادِ کرون با `wp_next_scheduled` نگهبانی می‌شود — هرگز دو رویداد روی هم انباشته نمی‌شوند.
  



پوشش آزمون


• آزمونِ دودی به ۲۰۵ بررسی رسید؛ هدرِ `0.4.4` هم در `khaleghi.json`، هم در هدرِ وردپرس، هم در `IMEDGE_VERSION` و هم در زبان‌باندلِ `imedge.pot/imedge.po/imedge-fa_IR.po/.mo`.
  



0.4.3





افزوده‌شده


• کارگاهِ صدورِ زنده (Live TLS wizard): به‌جای اینکه فقط دکمهٔ «درخواست SSL» را نشان بدهد، صفحهٔ تنظیمات حالا چرخهٔ واقعیِ صدور را گام‌به‌گام و زنده نمایش می‌دهد: ثبت‌شده ← تأییدِ موتور ← در حالِ صدور ← فعال. این کارگاه هر ۳ ثانیه وضعیت را از نقطهٔ جدیدِ موتور (`GET /v1/tls/status?host=…`) می‌پرسد (که مسئولِ خودکارِ صدور، `imedge-tls-issuer`، همیشه به‌روز نگه می‌دارد؛ وضعیتِ `tls_status` در پست‌گرس) و در هر گام هم به‌صورت زنده بررسی می‌کند که آیا گواهیِ ارائه‌شده واقعاً دامنه را پوشش می‌دهد (`cert_covers`). اگر صدور شکست بخورد، پیامِ خطا + دکمهٔ تلاشِ مجدد را نشان می‌دهد (بازفرستادنِ درخواستِ TLS، بی‌اثر است و لولهٔ `pg_notify` مسئولِ خودکار را فوراً دوباره اجرا می‌کند)؛ به‌محضِ زنده شدنِ گواهی، دکمهٔ بارگذاریِ مجدد برای فعال‌سازی ظاهر می‌شود تا همان گامِ Activateٔ کارگاه رندر شود. حالت‌های مختلف (دامنهٔ ناشناخته، دست‌نیافتنی بودنِ موتور، امتناعِ ۴۰۳) هر کدام پیامِ خود را دارند.
  
• ۱۴ رشتهٔ جدید به فارسی ترجمه شد؛ فایلِ `imedge-fa_IR.po/.mo` دوباره ساخته شد (۲۴۰ پیامِ ترجمه‌شده، `msgfmt` پاک).
  
• نسخه‌های `khaleghi.json`، هدرِ وردپرس و `IMEDGE_VERSION` همگی ۰٫۴٫۳.
  



پوشش آزمون


• هارنسِ رندر اکنون حالتِ هم‌گراشده را هم می‌پذیرد: چون صدورِ خودکار، گواهیِ واقعیِ `images.neshinkala.ir` را پیش از این زنده کرده، سناریویِ «درحالِ پذیرش» یا باید دکمهٔ «درخواست SSL» را بدهد (گواهیِ catch-allِ پلتفرم) یا مسیرِ Activate را با گواهیِ پوشش‌دهندهٔ واقعی. دروازهٔ رگرسیونِ catch-all همچنان در `ssl_conditions` (قفلِ `cert_covers`) محافظت می‌شود و آزمونِ دودی ۲۰۵ بررسی را سبز گذراند.
  



0.4.2





رفع‌شده


• دکمهٔ «درخواست SSL» (Request SSL) برای دامنهٔ درحالِ روی‌برد حذف نشده است: موتور هنگام مسیریابیِ هر دامنه، گواهیِ catch-all خودش را روی پورت ۴۴۳ ارائه می‌دهد؛ بررسیِ قدیمیِ «گواهی حضور دارد» روزهایِ همان گواهیِ پلتفرم را می‌خواند و نتیجه می‌گرفت گواهیِ همین دامنه فعال است — برای همین دکمهٔ درخواست، بی‌صدا حذف می‌شد و کاربر در کارگاه گیر می‌کرد. حالا «گواهی حضور دارد» فقط وقتی صادق است که گواهیِ ارائه‌شده واقعاً دامنه را پوشش دهد (همان منطقِ `cert_covers` که گامِ «گواهی با دامنه مطابقت دارد» در نردبان به‌کار می‌برد). اگر گواهیِ catch-allِ پلتفرم برگردد، روزهایش بی‌ارزش است و دکمهٔ «درخواست SSL» دوباره ظاهر می‌شود.
  
• نسخه‌های `khaleghi.json`، هدرِ وردپرس و `IMEDGE_VERSION` همگی ۰٫۴٫۲.
  



پوشش آزمون


• هارنسِ رندر حالا دقیقاً حالتِ گزارش‌شده را بازتولید می‌کند: دامنه به لبهٔ ImEdge می‌رسد و لبه گواهیِ catch-allِ خودش را سرو می‌کند (غیرپوشش‌دهنده) → دکمهٔ «درخواست SSL» رندر می‌شود. خودِ سیاستِ پوشش با بررسی‌های دودیِ `cert_covers` (پوشش دقیق، وایلدکارد برای زیردامنه و ریشهٔ حوزه، حساسیت‌به‌حروف، فهرستِ خالی) شپینگ‌شده؛ آزمون به ۲۰۵ بررسی رسید.
  



0.4.1





رفع‌شده


• صفحهٔ تنظیمات حالا تغییراتِ اپراتورِ موتور را همان لحظه می‌بیند: پلن/وضعیت/تاریخِ انقضا/آی‌پیِ مقید از آخرین «فعال‌سازی» در پلاگین می‌ماند، پس ارتقای پلن از `free` به `max` در پنلِ اپراتور هرگز به‌روز نمی‌شد و قفلِ پلنِ رایگان روی صفحه می‌ماند. حالا پلاگین وضعیتِ فعلی را از نقطهٔ فقط‌خواندنیِ جدیدِ موتور (`GET /v1/status`) می‌خواند (کشِ ~۵ دقیقه، هدرِ دامنه برای همان `403`-محورِ #34) و فیلدهایِ واقعیِ لایسنس را ادغام می‌کند؛ اگر موتور دست‌نیافتنی بود، هیچ‌چیز پاک نمی‌شود و صفحه همان حقایقِ ذخیره‌شده را نشان می‌دهد. فعال‌سازیِ دوباره بازنشانیِ توکن نمی‌کند — نقطهٔ `/v1/status` اصلاً چیزی را تغییر نمی‌دهد، پس پلاگین می‌تواند در هر رندر آن را بپرسد.
  
• ترجمهٔ فارسیِ کاملِ بازطراحیِ ۰٫۴٫۰: همهٔ رشته‌هایِ جدیدِ شبکهٔ وضعیت (موتور، میزبانِ سرو، گزینه‌ها، نردبان، کارگاه و…) از طریقِ `xgettext`/`msgmerge` به `imedge-fa_IR.po/.mo` اضافه و به فارسی ترجمه شدند (۲۲۹ پیامِ ترجمه‌شده؛ `msgfmt --check` پاک) — جفت «میزبانِ سرو / Serving host» و امثال آن دیگر انگلیسی به‌جای فارسی رندر نمی‌شوند.
  



پوشش آزمون


• آزمونِ دودی به ۱۹۹ بررسی رسید: سیاستِ ادغامِ `merge_status_sync` (ارتقای پلن، رشته‌هایِ غایب/خالیِ معتبر، نادیده‌گرفتنِ انواعِ غیررشته‌ای و بی‌دست‌زدنِ دامنهٔ سفارشی) + شاخهٔ پنجمِ هارنسِ رندر: «پلنِ ذخیره‌شده رایگان اما موتور حالا `max` می‌گوید → قفل در همین رندر آزاد می‌شود». نسخه‌های `khaleghi.json`، هدرِ وردپرس و `IMEDGE_VERSION` همگی ۰٫۴٫۱.
  



0.4.0





افزوده‌شده


• بازطراحی کاملِ برگهٔ «تنظیمات» به یک شبکهٔ وضعیتِ تک‌صفحه‌ای: به‌جای بخش‌های پراکنده، چهار پرسشِ طراحی را بالا‌به‌پایین پاسخ می‌دهد (دِلیوری کار می‌کند؟ تصاویر از کجا می‌آیند؟ میزبان را چگونه عوض کنم؟ چطور سالم بمانم؟): موتور (میزبانِ ثابت + پروبِ کش‌شدهٔ `/health` که با صراحت می‌گوید «هیچ سروری برای پیکربندی اینجا نیست») → میزبانِ سرو (خلاصهٔ اینکه تصاویر همین حالا از کجا سرو می‌شوند + قفلِ پلتفرم برای پلن رایگان) → آزمون اتصال → لایسنس → تنظیمات. هر عدد واقعی است؛ وضعیت‌ها با زبانِ استانداردِ قرص/پروب.
  
• کارگاهِ میزبانیِ سفارشیِ مرحله‌بندی‌شده (جایگزینِ بخشِ قدیمیِ «Origin TLS»): یک دامنه را برای «روی‌برد» وارد می‌کنید → در «حوزهٔ پذیرش» (`custom_domain_pending`) ثبت می‌شود و هیچ نشانیِ تصویری را بازنویسی نمی‌کند → «Request SSL» آن را با موتور ثبت می‌کند (پاسخِ موتور با `serving:true` همین‌جا پیامِ موفقیت می‌سازد و در نشانِ `imedge_ssl_requests` ذخیره می‌شود تا گامِ «ثبت‌شده برای سرو» در نردبان سبز شود) → «Activate» فقط وقتی رأیِ «گواهیِ زنده» سبز باشد. گواهی، نه تایپِ کاربر، میزبان را ارتقا می‌دهد.
  
• نردبانِ زنجیرهٔ تحویل: گام‌های DNS ← HTTP-01 ← TLS ← گواهی ← مسیریابی به موتور ← ثبت‌شده برای سرو؛ هر کدام یا از پروبِ زندهٔ آمادگی می‌آید یا از پاسخی که خودِ موتور داده (نشانِ `serving`) — هیچ گامی ساختگی نیست.
  
• قفلِ پلن رایگان: پلنِ رایگان به میزبانِ مشترکِ پلتفرم قفل است؛ جعبهٔ «قفل» دلیل را می‌گوید. دامنهٔ سفارشی فقط با لایسنسِ فعال + پلنِ پولی میسر است (`plan_allows_custom`)؛ ردهٔ پلن از همان پاسخِ واقعیِ فعال‌سازیِ موتور خوانده می‌شود.
  



پوشش آزمون


• آزمونِ دودی به ۱۹۰ بررسی رسید: ماتریسِ حالت/قرصِ `serving_state` (پلتفرم، زنده با گواهی، زنده بدون گواهی، درحالِ پذیرش) و سیاستِ `plan_allows_custom`؛ افزون‌بر آن یک هارنسِ رندرِ قطعی چهار شاخهٔ صفحه (قفلِ رایگان، پولی–پلتفرم، پولی–درحالِ پذیرش، زنده با گواهیِ فعال) را ساختارِ-تأیید کرد. `php -l` پاک، `kwp_validate` سبز و بستهٔ ۰٫۴٫۰ ساخته شد. نسخه‌های `khaleghi.json`، هدرِ وردپرس و `IMEDGE_VERSION` همگی ۰٫۴٫۰.
  



0.3.7





افزوده‌شده


• درخواستِ TLS به موتور می‌رسد، نه فقط محلی: دکمهٔ «انجام» در کارگاهِ «Origin TLS» (و مسیرِ مشابه در هنگام صدور) حالا به جای‌این‌که فقط یک نشانِ محلی در وردپرس ثبت کند، درخواست را با توکنِ مدیریت واقعاً به موتور می‌فرستد (`POST /v1/tls/request` با هدرِ مجوز و `X-ImEdge-Domain`). موتور به‌طور خودکار آن را در همان فهرستِ «تأییدهای TLS» که پانلِ اپراتور و سایدکارِ صدور می‌خوانند تأییدِ خودکار می‌کند؛ اپراتور دیگر هیچ کلیکی نمی‌زند. پیامِ موفقیت/ردِ موتور همین‌جا همان زبانه نمایش داده می‌شود (برای نمونهٔ «رد»، همان دروازهٔ واقعیِ موتور یعنی `403` رویِ دامنهٔ خارجِ حوزه).
  
• نسخه‌های `khaleghi.json`، هدرِ وردپرس و `IMEDGE_VERSION` همگی ۰٫۳٫۷.
  



پوشش آزمون


• آزمونِ دودی همچنان ۱۷۳ بررسی سبز؛ `php -l` پاک و `kwp_validate` سبز.
  



0.3.6





اصلاح‌شده


• رفع خطای بحرانی در بخش «Origin TLS»: یک سطرِ مردهٔ نیمه‌کاره در `tls_readiness()` به خاصیتِ استاتیکِ اعلان‌نشدهٔ `self::$engine_box_ip` و تابعِ ناموجودِ `arvan_ips_of()` ارجاع می‌داد و با هر رندرِ بخشِ TLS این زبانه، وردپرس را دچار خطای بحرانی (`Error`) می‌کرد — همان جعبهٔ «یک خطای مهم در این وب سایت وجود دارد» که وسطِ داشبورد ظاهر می‌شد. آن سطر حذف شد؛ پایان‌حالتِ سالمِ «دامنهٔ جلوی CDN با گواهیِ زندهٔ منطبق» همچنان توسط بررسیِ `route` (گواهیِ منطبق = OK) و رأیِ نهاییِ «فعال» حفظ شده است.
  



پوشش آزمون


• آزمونِ دودی همچنان ۱۷۳ بررسی سبز است (آمادگیِ TLS، تطبیقِ SAN و فعال‌سازی/پارک)؛ `php -l` پاک و `kwp_validate` سبز. نسخه‌های `khaleghi.json`، هدرِ وردپرس و `IMEDGE_VERSION` همگی ۰٫۳٫۶.
  



0.3.5





افزوده‌شده


• روی‌بردِ مرحله‌ایِ دامنهٔ سفارشی: دامنهٔ سفارشیِ تازه از این پس در فیلد جداگانهٔ «New custom domain» (تنظیمِ درونی `custom_domain_pending`) ثبت می‌شود و هیچ نشانیِ تصویری را بازنویسی نمی‌کند. کارگاهِ «Origin TLS» همان جریانِ آمادگی (پروب + درخواست + صدور) را دقیقاً رویِ همین دامنهٔ در حالِ پذیرش اجرا می‌کند؛ دامنه فقط وقتی «فعال» می‌شود و تصاویر را به آن بازنویسی می‌کند که خودِ اپراتور بعد از زنده‌شدنِ گواهی، دکمهٔ «Activate … for image URLs» را بزند. این همان چیزی است که می‌گوییم «آن را یک‌باره رویِ دامنهٔ بدونِ گواهی نگذار که تصاویر بشکنند».
  
• گردشِ بازگشتی برای دامنهٔ فعالِ شکسته: اگر دامنهٔ فعالِ فعلی هنوز گواهیِ زنده ندارد (حالت «در حالِ صدور»، «آماده» یا «آماده نیست»)، بخشِ TLS یک پیشنهادِ «Park as “New custom domain”» نشان می‌دهد که آن را به فهرستِ پذیرش برمی‌گرداند و بازنویسیِ شکسته را می‌ایستد — بدون این‌که دامنه یا درخواستِ گواهی‌اش گم شود. این دقیقاً همان سناریویِ تصاویرِ شکستهٔ این ماه است: کسی دامنه را رویِ `custom_domain` گذاشت پیش از آن‌که گواهیِ آن صادر شود.
  



اصلاح‌شده


• «فعال‌سازی» فقط با رأیِ «گواهی زنده» (`active`) مجاز است؛ رأی‌های «آماده» یا «هنوز آماده نیست» دکمهٔ فعال‌سازی را نشان نمی‌دهند («آماده» یعنی منتظرِ صدورِ اپراتور — هنوز تصاویر را به آن بازنویسی نمی‌کنیم). «پارک» هم فقط وقتی پیشنهاد می‌شود که گواهیِ زنده هنوز فعال نیست؛ یک دامنه با گواهیِ سالم «پارک» نمی‌شود.
  
• توکنِ ذخیره درست: این بار `custom_domain_pending` وقتی از رویِ فرمِ ذخیرهٔ تنظیمات نیامد، از مقدارِ ذخیره‌شدهٔ قبلی حفظ می‌شود (همان الگوی بازگشتیِ `customer_id`) — پیش از این ذخیرهٔ سادهٔ هر زبانه، دامنهٔ در حالِ پذیرش را پاک می‌کرد.
  



پوشش آزمون


• آزمونِ دودی به ۱۷۳ بررسی رسید؛ بررسی‌های تازه برای «فعال‌سازی فقط با گواهیِ زنده» و «پارک فقط برای دامنهٔ بدونِ گواهیِ سالم»؛ `php -l` پاک و `kwp_validate` سبز. نسخه‌های `khaleghi.json`، هدرِ وردپرس و `IMEDGE_VERSION` همگی ۰٫۳٫۵.
  



0.3.4





اصلاح‌شده


• دست‌داد TLS در پروبِ آمادگی: بستر SSL اکنون `verify_peer_name` را هم خاموش می‌کند. PHP این گزینه را پیش‌فرض روشن نگه می‌دارد حتی وقتی `verify_peer` خاموش است؛ وقتی دامنهٔ سفارشی پشت گواهیِ پیش‌فرض (مثلاً گواهیِ imedge.khaleghi.info در پیکاپ‌آل) باشد، دست‌داد بی‌صدا رد می‌شد و پروب «پورت ۴۴۳ باز نیست» دروغ می‌گفت. حالا درست تشخیص می‌دهد: پورت ۴۴۳ باز است ولی گواهیِ رویِ آن برای دامنهٔ شما نیست — یعنی دقیقاً همان چیزی که باید صادر شود.
  



0.3.3





افزوده‌شده


• پروبِ آمادگیِ TLS: بخش «اوریجین‌های ترافیکی» حالا هر بار یک آزمون زندهٔ آمادگی برای دامنهٔ سفارشی اجرا می‌کند — بررسی DNS، باز بودن پورت ۸۰ (پیش‌شرطِ صدور HTTP-01)، دست‌داد TLS روی پورت ۴۴۳ با بازخوانیِ گواهی (SANها)، و یک رفت‌وبرگشت `GET /health` که نشان می‌دهد دامنه واقعاً به کارگاه (ایم‌‌اج) رسیده است یا هنوز به سرورِ مبدأ می‌رود. نتیجه، یک رأی شفاف است: «آمادهٔ صدور»، «گواهی هم‌اکنون فعال است»، یا «آماده نیست + فهرستِ موارد مسدودکننده»، به‌همراه دکمهٔ «اجرای دوبارهٔ آزمون». برایِ حالتِ «منتظر تأیید اپراتور»، همین پراب دقیقاً می‌گوید آیا صدور امکان‌پذیر است یا نه (مثلاً چون DNS هنوز به کارگاه اشاره نمی‌کند).
  
• بازگشت بعد از کنش‌های admin-post به زبانهٔ درست: پیام‌های موفقیتِ «درخواست SSL» و «پیش‌گرم» در زبانهٔ «تنظیمات» مصرف می‌شدند ولی کاربر به داشبورد (زبانهٔ پیش‌فرض) هدایت می‌شد و پیام دیده نمی‌شد — اکنون همهٔ کنش‌ها به زبانهٔ «تنظیمات» برمی‌گردند و پیام همان‌جا نمایش داده می‌شود.
  



پوشش آزمون


• آزمون دودی به ۱۶۶ بررسی رسید؛ ۱۲ بررسی تازه برای رأیِ آمادگیِ TLS (هر شاخهٔ `tls_verdict`) و تطبیقِ SAN گواهی (شامل وایلدکارت)؛ `php -l` پاک و `kwp_validate` سبز.
  



0.3.2





اصلاح‌شده


• ذخیرهٔ تنظیمات دیگر شناسهٔ داخلی مشتری را پاک نمی‌کند: فیلترِ پاک‌سازی وقتی برگهٔ «تنظیمات» ذخیره می‌شود، مقدار `customer_id` را از حالت ذخیره‌شده حفظ می‌کند (همان الگوی بازگشتی که دیگر فیلدهای فعال‌سازی داشتند). پیش از این هر ذخیرهٔ سادهٔ تنظیمات، شناسه را به خالی برمی‌گرداند و داشبورد را در حالت دائمی «فعال نشده» می‌انداخت، حتی وقتی لایسنس در تب‌های دیگر فعال دیده می‌شد.
  
• هم‌رایی وضعیت در همهٔ زبانه‌ها: «مشاور وضعیت» و فرم فعال‌سازی حالا فقط وقتی سایت را فعال می‌داند که شناسهٔ مشتریِ موتور هم ذخیره شده باشد — نه صرفاً وضعیت و توکن. در همین حالتِ ناقص، فرم فعال‌سازی دوباره نمایش داده می‌شود تا با درج کلید تازه، وضعیت در یک مرحله بازسازی شود.
  
• فعال‌سازی دوباره (چندباره) شناسهٔ مشتری و توکن تازه را از موتور می‌گیرد و داشبورد را بازیابی می‌کند.
  



پوشش آزمون


• آزمون دودی به ۱۵۴ بررسی رسید؛ سه بررسی تازه برای حفظ `customer_id` در ذخیرهٔ تنظیمات و حالت «بدون مشتری = فعال نشده»؛ `php -l` پاک و `kwp_validate` سبز.
  



0.3.1





اصلاح‌شده


• فعال‌سازی دومین‌محور (بستن #34): هویت سایت دیگر شناسهٔ مشتری نامرتب نیست — همان دامنهٔ خود سایت است. مسیر پلتفرم حالا به شکل `imedge.khaleghi.info/{license-domain}/…` ساخته می‌شود و فیلد «Customer ID» از رابط کاربری حذف شد (شناسهٔ داخلی فقط برای داشبورد متریک‌ها می‌ماند).
  
• پروتکل فعال‌سازی: پلاگین فعال‌سازی را با `{key, domain}` می‌فرستد؛ موتور وقتی دامنه زیرمجموعهٔ لایسنس نباشد با `403` رد می‌کند و دامنهٔ متعارف را برمی‌گرداند که پلاگین به‌عنوان `license_domain` ذخیره می‌کند (فقد: دامنهٔ `home_url()`).
  
• همهٔ درخواست‌های مدیریت (گرم‌کردن، پیش‌گرم، وضعیت) هدر `X-ImEdge-Domain` را می‌فرستند و پارامتر `customer` از بدنه/کوئری حذف شد — اسکوپ از روی توکنِ سایت تعیین می‌شود؛ خلوت بودن فیلد مشتری دیگر چیزی را مسدود یا گیج نمی‌کند.
  
• پیام موفقیت فعال‌سازی و وضعیت لایسنس، دامنهٔ سایت را در صدر نمایش می‌دهند نه شناسهٔ نامرتب.
  
• درخواست‌های `imedge-precache` از همان توکن بدون `customer` استفاده می‌کنند؛ موتور جدید مشتری را از توکن و دامنه بازشناسی می‌کند.
  



پوشش آزمون


• آزمون دودی به ۱۵۱ بررسی رسید؛ `php -l` روی همهٔ فایل‌ها پاک و `kwp_validate` سبز. موتور روی سرور تولید با مسیرهای دومین‌محور (MISS→HIT) تأیید شد.
  



0.3.0





اصلاح‌شده


• گرم‌کردن دقیق همان واریانت‌هایی که مرورگرها واقعاً درخواست می‌کنند (بستن #16): پیش‌گرم و گرم‌کردن رویدادی به‌جای نردبان ثابت روی فایل اصلی، حالا مسیرهای مشتق واقعی را از `wp_get_attachment_metadata()` می‌سازد — هر اندازهٔ ثبت‌شدهٔ قالب در عرض خودش، به‌همراه اصل در عرض طبیعی (کاندید full در `srcset`) و در سقف `max_src_width` اگر ست شده باشد. دیگر بودجهٔ گرم‌کردن صرف نردبان روی مسیر اصلی نمی‌شود؛ شمارندهٔ تبدیل‌های موتور با خواستهٔ واقعی مرورگر هم‌سو می‌شود.
  
• توافق فرمت با مرورگر: هر آیتم گرم‌کردن، هدر `Accept` مرورگرمانند را حمل می‌کند (`image/avif,image/webp,image/,/*;q=0.8`) تا موتور همان فرمتی را توافق کند که مرورگر می‌گیرد. پیش از این، نبودِ Accept به مبنای JPEG می‌رسید در حالی که مرورگر AVIF می‌خواست — حتی روی همان مسیر، کلید کش متفاوت می‌شد.
  
• داشبورد: هدف «تصاویر × ۹» ← «اندازه‌های مشتق کنونی (تخمینی)» که از نمونهٔ ۵۰۰ تایی کتابخانه، میانگین واریانت‌های واقعی هر تصویر را می‌شمارد و به کل کتابخانه بسط می‌دهد. پیام «Precache X واریانت برای Y تصویر» حالا واریانت‌ها را جدا از تصاویر می‌شمارد (هر آیتم = یک عرض).
  
• برگهٔ «مشاور سلامت»، اندازه‌های آزموده‌شده را از همان سطوحی انتخاب می‌کند که Precache می‌سازد (نه دو عرض دل‌خواه روی مسیر اصلی).
  
• متن‌های «نردبان پهنا» به «سطوح/اندازه‌های مشتق» هماهنگ شد.
  



افزوده‌شده


• `Precache::warm_items( $id )` — ساخت آیتم‌های حجیم از فرادادهٔ پیوست (مسیر مشتق + عرض خودش + `Accept`)، با بازگشت به نردبان کلاسیک برای تصاویر بدون فراداده.
  



پوشش آزمون


• آزمون دودی به ۱۴۹ بررسی رسید؛ `php -l` روی همهٔ فایل‌ها پاک.
  



0.2.1





اصلاح‌شده


• فعال‌سازی لایسنس حالا واقعاً ذخیره می‌شود: فیلترِ پاک‌سازی تنظیمات وردپرس توکن تازه را از ورودی می‌خواند (به‌جای اینکه دوباره از مقدار خالی ذخیره‌شده بخواند و پس‌بدهد) — پیش از این `update_option()` ناخواسته نادیده گرفته می‌شد و فعال‌سازی ظاهراً موفق، توکن را پاک می‌کرد.
  
• پس از فعال‌سازی، به زبانهٔ «تنظیمات» که پیام نتیجه مصرف می‌شود هدایت می‌شود؛ اکنون پیام موفقیت دیده می‌شود.
  
• برچسب‌های فریبنده در هر سه زبانه واضح شدند:
  
- «گرم‌شده از کتابخانه» ← «پوشش گرم‌کردن»، با «از هدف (تخمینی)» و توضیح اینکه ساخته‌شده از زمان نصب شمرده می‌شود و می‌تواند از هدف کنونی بیشتر باشد؛ «هدف: تصاویر کنونی × ۹ (تخمینی)» نردبان دقیق را نشان می‌دهد.
- «سقف ۵۰۰» ← روشن شد که شمارش تصویرها کل واقعی است و فقط تخمین بایت از ۵۰۰ تصویر نخست نمونه می‌گیرد.
- «دادهٔ سرو‌شده / بایت کم‌شده/دور سرو ردشده» ← «پهنای باند ذخیره‌شده / بایت ذخیره‌شده / سرو شده از کش».
- کلید «Enable» ← «Enable rewriting» با توضیح؛ «۰ غیرفعال می‌کند» ← «۰ = بدون سقف».
- «گرم کردن کش» ← «Precache»؛ ارجاع‌های سلامت از «Warm action» به «Precache» هماهنگ شدند.

• متن پیشرفت کش پیش‌گرم در جاوااسکریپت هم ترجمه‌پذیر شد (از رشتهٔ ترجمه‌شده استفاده می‌کند، نه انگلیسی سخت‌کد).
  
• حذف ورود اشکال‌زدایی فعال‌سازی که توکن سایت را در error_log می‌نوشت.
  



پوشش آزمون


• آزمون دودی به ۱۴۱ بررسی رسید؛ همهٔ بسته‌ها و «بررسی‌ها» سبز.
  



0.2.0





افزوده‌شده


• داشبورد بازطراحی‌شده با سه سنجهٔ دایره‌ای (گرم‌شدن کتابخانه، دادهٔ ارسالی، سلامت هدر) به‌همراه اعداد واقعی از متریک‌های موتور: واریانت‌های ساخته‌شده، واریانت‌های ممکن، تصویرهای کتابخانه، بایت‌های ذخیره‌شده، چرخه‌های پرشده و میانگین تأخیر.
  
• واریانت‌های امکان‌پذیر از تعداد تصویرهای کتابخانه × ۹ (نردبان پیش‌فرض) محاسبه می‌شود؛ سقف بررسی روی نخستین ۵۰۰ تصویر.
  
• پیش‌گرم‌شدن صف‌بندی‌شدهٔ کل کتابخانه («Precache library»): یک کلیک، رتبه‌بندی توسط احتمال سرو شدن (تصویرهای صفحهٔ اصلی، تصویرهای شاخص، محتوای تازه، جدیدترین آپلود)، ارسال پیمان‌ای به‌صورت دسته‌ای تا سقف بودجهٔ امروز، و پیگیری زندهٔ پیشرفت با نوار مترقی از طریق `admin-ajax`.
  
• گرم‌کردن خودکار رویدادمحور: انتشار/به‌روزرسانی نوشته، تصویرهای پیوست را بدون دخالت کاربر گرم می‌کند (در حد بودجه).
  
• تأمین توکن سایت با کلید فعال‌سازی: فعال‌سازی با کلید مجوز، توکن مدیریت اختصاصی مبدأ را تأمین می‌کند (با ذخیرهٔ هش‌شده) — جایگزین توکن دستی.
  
• برگهٔ مشاور سلامت (`Advisor`): نمره‌دهی زندهٔ هدرهای ارسالی از نمونهٔ واقعی کتابخانه با توصیه‌های رفع.
  
• بازسازی حرفه‌ای رابط مدیر + ناوبری زبانه‌ای که داشبورد را نخست نشان می‌دهد؛ برندینگ یکپارچه با موتور.
  
• اشتراک‌گذاری جزئیات متریک‌های موتور بین داشبورد و برگهٔ سلامت.
  



اصلاح‌شده


• اصلاح مسیرهای مبدأ برای تطابق رجیستری موتور: «پیش‌گرم‌کردن» و «گرم‌کردن رویدادمحور» پیشوند نشانی بارگذاری (`/wp-content/uploads/…`) را در مسیر می‌فرستادند تا موتور بتواند مبدأ را تشخیص دهد — پیش از این همهٔ کارهای صف با `registry: no origin matches path` شکست می‌خوردند.
  
• دکمهٔ «Precache library» پس از پایان یک کار، دوباره نمایش داده می‌شود (نه فقط هنگام خالی بودن صف)؛ کار تمام‌شده با خطا، برچسب کهربایی «پایان یافت با خطا» می‌گیرد نه سبز فریب‌دهندهٔ «انجام شد».
  
• ارجاع سراسری `WP_Query` در فضای نام به نمونهٔ درون‌فضای‌نام تغییر کرد (رفع خطای احتمالی تداخل قالب).
  



پوشش آزمون


• آزمون دودی خودبسنده به ۱۳۹ بررسی رسید: متریک‌ها، `UrlBuilder`، `Rewriter`، نردبان گرم‌کردن، رتبه‌بندی گنجینهٔ `Precache` (با مسیرهای جدید دارای پیشوند)، و پاک‌شدن/نگهداری وضعیت.
  



0.1.3





افزوده‌شده


• تنظیم «Max src width»: سقف اختیاری برای عرض `src` تک‌تصویرها (`w=`) تا اندازه‌های بزرگ قالب دانلودهای بی‌رویه نسازند؛ `srcset` نردبان کامل را حفظ می‌کند و `0` یعنی بدون سقف. پوشش آزمون دودی: ۳۴ بررسی.
  



0.1.2





اصلاح‌شده


• انتشار نگهداری بدون تغییر رفتاری: همگام‌سازی سه‌طرفهٔ نسخه (`Version:` هدر، `IMEDGE_VERSION` و `khaleghi.json` همگی `0.1.2`) و افزودن `.distignore` تا `tests/` و `.git` در بستهٔ انتشار قرار نگیرند.
  



0.1.1





اصلاح‌شده


• رفع خطای مرگبار هنگام بارگذاری افزونه: `declared( 'ABSPATH' )` (تابع ناموجود) به `defined( 'ABSPATH' )` بازگردانده شد؛ پیش‌تر هر بارگذاری پیش از اجرای `define`ها متوقف می‌شد.
  



افزوده‌شده


• `UrlBuilder`: انتخاب میزبان بر پایهٔ تنظیمات (دامنهٔ سفارشی مقدم بر میزبان پلتفرم)، محافظ یکنواخت (فقط نشانی‌های زیر `wp-content/uploads` سایت بازنویسی می‌شوند؛ نشانی‌های خارجی/`data:` دست‌نخورده می‌مانند)، و ساخت `srcset` با نگاشت عرض هر کاندید به `w=`.
  
• `Rewriter`: احترام به `imedge_is_active()` در همهٔ فیلترها، افزودن `w=` به کاندیدهای `srcset`، و بازنویسی `` سخت‌کدشده در `the_content` (ویژگی‌های `src`/`srcset`/`data-src`) با حفظ `alt` و ابعاد اصلی.
  
• `Settings`: فیلد دامنهٔ سفارشی و ابزار «Test Connection» (بررسی `/health` موتور و پروب مبدأ بارگذاری‌ها؛ `404` = مجاز، `403` = بدون مجوز).
  
• هنر پلتفرم: `icon-128`، `icon-256`، `banner-772x250` و `banner-1544x500`.
  
• آزمون دودی خودبسنده: `tests/smoke.php` (۲۵ بررسی، بدون نیاز به وردپرس).
  



0.1.0





افزوده‌شده


• ساخت افزونهٔ ImEdge (نسخهٔ اولیه): `imedge-wordpress.php` با هدر وردپرس (`Version: 0.1.0`، WP 6.0+، PHP 7.4+)، فضای نام `Khaleghi\ImEdge`، دسترسی به تنظیمات (`IMEDGE_OPTION`)، بوت‌استرپ ایمن.
  
• سازندهٔ نشانی (`includes/UrlBuilder.php`) — ساخت نشانی موتور (`imedge.khaleghi.info`) با پارامترهای `w=` و `format=`.
  
• بازنویس پیوست و محتوا (`includes/Rewriter.php`) — فیلتر `wp_get_attachment_image_src`/`wp_calculate_image_srcset`/`wp_get_attachment_url`؛ `the_content` برای `` سخت‌کدشده.
  
• صفحهٔ تنظیمات (`includes/Settings.php`) — ثبت دستی مبدأ + بررسی اتصال (Test Connection).
  
• پوشهٔ `lang/` برای ترجمهٔ فارسی (`fa_IR`) و انگلیسی (`en_US`).
  
• `docs/` (تولیدشده ت��سط kwp): `DOCUMENTATION.md`، `INSTALLATION.md`، `FAQ.md`، `CHANGELOG.md`، `ADDITIONAL-INFORMATION.md`، `OTHER-NOTES.md`.
  



اصلاح‌شده


• هیچ تغییر مخرب در پایگاه داده — بازنویسی در زمان رندر، نه جایگزینی.
  
• تصاویر اصلی مهاجرت نمی‌شوند؛ `alt` و ابعاد حفظ می‌شوند.
  
• مجوز/ثبت‌نام دستی برای نسخهٔ ۱: اپراتور مبدأ را در تنظیمات موتور اضافه می‌کند؛ افزونه بررسی اتصال ارائه می‌دهد؛ `403` موتور در مبدأ نامعلن، دروازهٔ واقعی است (API مجوز پیش‌نیاز نیست).
  
• ترجمهٔ فارسی (`fa_IR`) برای `en_US` فعلاً ارائه می‌شود؛ تکمیل `fa_IR` در کار بعدی.
  
• تصاویر (`assets/icon-256`، `assets/banner-772x250`) هنوز ساخته نشده‌اند؛ `kwp_assets_fix` نیاز به تصویر منبع دارد.
  



محدودیت شناخته‌شده


• ثبت دارایی / API متاداده (به تعویق افتاده در P2).
  
• حفظ انیمیشن (سیاست S0: فریم اول).
  
• `dpr` / `rotate` در پارامترهای URL افزونه (موتور آن‌ها را مدیریت می‌کند؛ افزونه عبور می‌دهد).