141 آزمون، 31 بررسی انطباق، بدون میانبر: چگونه Statnive را عرضه میکنیم
بیشتر پلاگینهای WordPress یک linter اجرا میکنند و به همان بسنده میکنند. Statnive قبل از عرضه هر نسخه از 5 لایه راستیآزمایی خودکار عبور میکند — از hookهای pre-commit تا گیتهای انطباق WordPress.org. اینجا دقیقاً میگوییم چه چیزی را بررسی میکنیم و چرا.
قبل از نصب هر plugin، شما به کد شخص دیگری اعتماد میکنید
هر plugin WordPress که فعال میکنید، دسترسی کامل به پایگاه داده، پنل پیشخوان و دادههای بازدیدکنندگان شما را به دست میآورد. بیشتر صفحات plugin یک رتبهبندی ستارهای و یک تاریخ «آخرین بهروزرسانی» را نمایش میدهند. این برای تصمیمگیری اعتماد، اطلاعات کافی نیست.
ما Statnive را بهعنوان plugin تحلیلی ساختیم که خودمان روی سایتهای خودمان به آن اعتماد میکنیم. این پست از خط لوله کیفی دقیقی عبور میکند که هر خط کد Statnive قبل از رسیدن به نصب WordPress شما طی میکند. بدون ادعاهای مبهم — بررسیهای مشخص، اعداد واقعی و ملاحظات صادقانه درباره آنچه آزمون خودکار میتواند و نمیتواند بگیرد.
اعداد سرتیتر: 141 آزمون واحد PHP، 31 بخش انطباق WordPress.org، 10 گیت تخصصی CI، 3 هدف نسخه PHP و یک بودجه اندازه tracker 5KB که در هر build اعمال میشود.
لایه 1: hook pre-commit — هیچ چیز بدون بررسی وارد مخزن نمیشود
قبل از اینکه کد حتی وارد مخزن Git ما شود، یک hook pre-commit دو بررسی روی هر فایل staged اجرا میکند:
برای تغییرات PHP:
- PHPCS (PHP CodeSniffer) فایلهای staged را در برابر WordPress Coding Standards — همان مجموعه قواعدی که هسته WordPress استفاده میکند — اعتبارسنجی میکند. این escaping خروجی ناامن، sanitization گمشده و الگوهای کد غیراستاندارد را میگیرد.
- PHPUnit کل مجموعه آزمون واحد را اجرا میکند. همه 141 آزمون باید پاس شوند. یک شکست منفرد commit را مسدود میکند.
برای تغییرات TypeScript/JavaScript:
- Vitest همه آزمونهای component React را اجرا میکند. UI داشبورد نمیتواند رگرسیون کند بدون اینکه اینجا گرفته شود.
hook pre-commit عمداً سریع است — روی یک ماشین توسعهدهنده در کمتر از 5 ثانیه اجرا میشود. هدف جایگزینی CI نیست، بلکه گرفتن رایجترین اشتباهات قبل از هدر رفتن یک رفتوبرگشت به GitHub است. در عمل، این گیت منفرد حدود 80% از مسائل را قبل از خروج از لپتاپ توسعهدهنده میگیرد.
لایه 2: ادغام پیوسته — 6 شغل موازی روی هر push
هر push به شاخه development یا main ما، و هر pull request، یک خط لوله GitHub Actions CI با 6 شغل موازی را راهاندازی میکند:
| شغل | چه چیزی را بررسی میکند | چرا اهمیت دارد |
|---|---|---|
| Lint (PHP 8.2، 8.3، 8.4) | PHPCS + PHPStan سطح 6 | استانداردهای کدنویسی و ایمنی نوع ایستا در 3 نسخه PHP |
| Unit Tests (PHP 8.2، 8.3، 8.4) | مجموعه PHPUnit | درستی منطقی در 3 نسخه PHP |
| Minimum Floor Smoke (PHP 8.0) | lint syntax + boot autoloader | اثبات میکند plugin روی حداقل نسخه PHP اعلام شده بارگذاری میشود |
| Tracker Build | ساخت Vite + بررسی اندازه gzip | بودجه gzipped 5KB روی tracker تحلیلی را اعمال میکند |
چرا 4 نسخه PHP؟
سایتهای WordPress در دنیای واقعی روی PHP 8.0 تا 8.4 اجرا میشوند. تابعی که روی PHP 8.4 کار میکند ممکن است روی PHP 8.0 رفتار متفاوتی داشته باشد — مقادیر پارامتر پیشفرض، قواعد جبر نوع و ویژگیهای منسوخ همه در نسخهها متفاوت هستند. ما روی سه نسخهای که مجموعه آزمون کامل ما اجرا میشود (8.2، 8.3، 8.4) آزمون میکنیم و بهطور جداگانه راستیآزمایی میکنیم که کد تولید حداقل روی PHP 8.0 — حداقل اعلام شده در هدر plugin ما — تجزیه و boot شود.
بودجه tracker 5KB
JavaScript tracker که pageview ها را روی سایت شما جمعآوری میکند یک حد اندازه سخت دارد: 5,120 بایت gzipped. هر build خروجی را اندازه میگیرد و خط لوله را در صورت تجاوز tracker از آن بودجه شکست میدهد. این دلخواه نیست — benchmark عملکردی ما نشان داد که اندازه tracker مستقیماً با تأثیر LCP همبستگی دارد. بودجه ما را مجبور میکند مسیر بحرانی را حداقل نگه داریم و ویژگیهای غیرضروری را به یک اسکریپت ثانوی async موکول کنیم.
# از workflow CI ما — بررسی اندازه tracker
- name: Verify tracker size
run: |
MAX_SIZE=5120 # 5KB in bytes
GZIP_SIZE=$(gzip -c public/tracker/statnive.js | wc -c)
if [ "$GZIP_SIZE" -gt "$MAX_SIZE" ]; then
echo "::error::Tracker size (${GZIP_SIZE}B) exceeds limit (${MAX_SIZE}B)"
exit 1
fiPHPStan در سطح 6
PHPStan ابزار تحلیل ایستایی است که باگها را بدون اجرای کد پیدا میکند. سطح 6 (از 10) عدم تطابق نوع، متغیرهای تعریف نشده، انواع بازگشت نادرست و مسیرهای کد مرده را میگیرد. ما آن را با افزونه phpstan-wordpress اجرا میکنیم، که امضاهای hook WordPress، انواع بازگشت filter و قراردادهای متد $wpdb را درک میکند. ترکیب با اعمال $wpdb->prepare()، این دفاع اولیه ما در برابر تزریق SQL است — تحلیلگر ایستا هر کوئری که ورودی کاربر را به جای استفاده از statementهای آماده شده الحاق میکند را پرچمگذاری میکند.
لایه 3: انطباق WordPress.org — 10 گیت تخصصی
اینجا جایی است که خط لوله کیفی Statnive از بیشتر پلاگینهای WordPress فاصله میگیرد. فراتر از linting و آزمون استاندارد، ما 10 گیت انطباق هدفمند را اجرا میکنیم که دستورالعملهای plugin WordPress.org را اعمال میکنند — همان قواعدی که تیم بررسی بهصورت دستی در طول ارسال بررسی میکند.
بیشتر توسعهدهندگان plugin این قواعد را وقتی کشف میکنند که ارسالشان رد میشود. ما آنها را خودکار کردیم تا تخلفات در هر commit گرفته شوند:
گیتهای امنیت
ABSPATH Guards — هر فایل PHP باید قبل از اجرا defined('ABSPATH') را بررسی کند. این از دسترسی مستقیم به فایلهای plugin از طریق URL جلوگیری میکند، که میتواند مسیرهای سرور را افشا کند یا کد را خارج از زمینه WordPress اجرا کند. گیت ما هر فایل .php در درخت منبع را اسکن میکند و اگر هر فایلی فاقد guard باشد شکست میخورد.
Forbidden Patterns — یک اسکن خودکار توابع PHP خطرناک را که WordPress.org صریحاً رد میکند مسدود میکند: eval()، exec()، shell_exec()، system()، passthru() و curl_init(). همچنین short tagهای PHP، json_encode() خام (باید از wp_json_encode() استفاده شود) و مسیرهای wp-content هاردکد را میگیرد.
WP API Compliance — بررسی میکند که همه اسکریپتها و stylesheetها به جای تگهای <script> یا <link> هاردکد از سیستم enqueue WordPress استفاده میکنند. همچنین برای دسترسی به superglobalهای sanitize نشده ($_GET، $_POST، $_REQUEST) اسکن میکند — یکی از بالاترین دلایل رد ارسالهای plugin توسط WordPress.org.
گیتهای یکپارچگی
Readme & Version Consistency — نسخه plugin باید در سه مکان مطابقت داشته باشد: Stable tag در readme.txt، هدر statnive.php و ثابت PHP STATNIVE_VERSION. عدم تطابق به این معنی است که WordPress شماره نسخه اشتباه را نمایش میدهد — برای کاربران گیجکننده و برای بازبینها یک پرچم قرمز. این گیت همچنین تعداد tag (حداکثر 5)، طول توضیح کوتاه (حداکثر 150 کاراکتر)، حضور فایل LICENSE و بخش افشای External Services را اعتبارسنجی میکند.
Distribution ZIP Validation — فایل ZIP واقعی را که به WordPress.org آپلود میشود میسازد، سپس محتوای آن را اعتبارسنجی میکند. فایلهای مورد نیاز باید حضور داشته باشند (statnive.php، readme.txt، LICENSE، src/Plugin.php، منبع unminified tracker). فایلهای ممنوع باید غایب باشند (node_modules/، .git/، composer.json، tests/، phpunit، فایلهای پیکربندی). اندازه ZIP باید زیر 25MB باقی بماند.
Header Parity — همه 11 فیلد هدر plugin مورد نیاز را برای حضور و سازگاری اعتبارسنجی میکند. بررسی میکند که نسخه Tested up to WordPress در 2 نسخه minor از stable فعلی باشد — یک مقدار قدیمی نشانگر یک plugin غیرنگهداری شده است و میتواند بر رتبهبندی جستجوی WordPress.org تأثیر بگذارد.
گیتهای معماری
Architecture Blockers — برای الگوهایی که نشاندهنده تخلفات سیاست هستند اسکن میکند: تماسهای HTTP phone-home در hookهای فعالسازی (کاربران نباید درخواستهای شبکه را وقتی plugin را فعال میکنند ببینند)، hookهای auto-updater سفارشی (WordPress.org بهروزرسانیها را مدیریت میکند) و پایگاه دادههای MaxMind GeoIP بستهبندی شده (کاربران باید کلید مجوز خودشان را ارائه دهند).
Freemium Boundary — نسخه رایگان WordPress.org نباید کد گیتگذاری مجوز داشته باشد. این گیت برای الگوهایی مثل isPro()، checkLicense()، trial_expires و premium_only اسکن میکند — اطمینان حاصل میکند که build .org واقعاً رایگان است، نه یک نسخه آزمایشی فلج.
External Services Audit — هر دامنه https:// ارجاع شده در کد منبع PHP را استخراج میکند، سپس راستیآزمایی میکند که هر یک در بخش External Services در readme.txt مستند شده است. هر اتصال خارجی غیرمستند build را شکست میدهد. این روشی است که ما شفافیت درباره جریان دادههای شما را تضمین میکنیم.
Statnive را بگیرید: کدی که میتوانید به آن اعتماد کنید
هر بررسی توصیف شده در این پست بهطور خودکار در هر تغییر اجرا میشود. هیچ انسانی نباید به یاد بیاورد که اسکن امنیتی را اجرا کند یا سازگاری نسخه را بررسی کند — خط لوله آن را اعمال میکند. Statnive را از WordPress.org نصب کنید و نتیجه را ببینید: تحلیلگری سریع و خصوصی روی سرور خودتان.
لایه 4: WordPress Plugin Check — سختگیرتر از مورد نیاز
Plugin Check (PCP) یک ابزار رسمی از تیم WordPress.org است که همان بررسیهای خودکاری را اجرا میکند که تیم بررسی استفاده میکند. بیشتر پلاگینها PCP را تنها برای شکست در خطاها پیکربندی میکنند.
Statnive روی هم خطا و هم هشدار شکست میخورد.
این یک انتخاب عمدی است. هشدارهای PCP اغلب مسائل واقعی را پرچمگذاری میکنند — استفاده از تابع منسوخ، شکافهای دسترسپذیری، نگرانیهای عملکردی — که از نظر فنی ارسال را مسدود نمیکنند اما کیفیت plugin را با گذشت زمان تنزل میدهند. با برخورد با هشدارها بهعنوان خطاها، مسائلی را میگیریم که سایر پلاگینها با آنها عرضه میکنند.
گیت PCP روی پوشه توزیع ساخته شده (نه درخت منبع) با استفاده از PHP 8.0 — حداقل اعلام شده — اجرا میشود. این به این معنی است که ما دقیقاً همان چیزی را آزمون میکنیم که کاربران نصب میکنند، روی قدیمیترین نسخه PHP که پشتیبانی میکنیم.
لایه 5: گیت عرضه — 31 بخش قبل از عرضه هر نسخه
قبل از عرضه، گیت کامل همه چیز بالا را در یک تصمیم پاس یا شکست منفرد ترکیب میکند:
گیتهای آزمون ایستا (همه باید پاس شوند):
| گیت | بررسی | ابزار |
|---|---|---|
| S-1 | WordPress Coding Standards | PHPCS |
| S-2 | تحلیل نوع ایستا | PHPStan سطح 6 |
| S-3 | آزمونهای واحد + ادغام PHP | PHPUnit |
| S-4 | آزمونهای component React | Vitest |
| S-5 | Plugin Check رسمی | PCP (خطاها + هشدارها) |
گیتهای grep انطباق (17 بررسی الگوی خودکار):
| گیتها | چه چیزی را اعمال میکنند |
|---|---|
| C-1 | ABSPATH guards روی هر فایل PHP |
| C-2 | اعتبارسنجی فایل license |
| C-3، C-4 | بدون phone-home در فعالسازی، بدون paywall پنهان |
| C-5 | ساختار readme، برابری نسخه، افشای external services |
| C-6 | بدون دسترسی superglobal sanitize نشده |
| C-7 | بدون پایگاه دادههای GeoIP بستهبندی شده |
| C-8، C-9، C-10 | بدون updater سفارشی، بدون کتابخانههای هسته بستهبندی شده، بدون CDN خارجی |
| C-11، C-12 | پاکسازی cron در غیرفعالسازی، حضور تابع uninstall |
| C-13 | ساختار پوشه assets SVN |
| C-14 | یکپارچگی و اندازه ZIP |
| C-15 | ایجاد جدول پایگاه داده فرمت dbDelta را دنبال میکند |
| C-16 | همه رشتههای روی به کاربر بینالمللی شده هستند |
| C-17 | hookهای WordPress Privacy API ثبت شده |
فراتر از گیتهای خودکار، هر عرضه یک بررسی دستی شامل بودجههای عملکردی، سازگاری مرورگر، دسترسپذیری (WCAG 2.2 AA)، وضوح UX پیشخوان، ایمنی ارتقا/مهاجرت و مدیریت شکست را شامل میشود. چکلیست کامل 31 بخش در 3 سطح شدت را پوشش میدهد:
- CRITICAL — گیتهای خودکار که خط لوله عرضه را مسدود میکنند
- RELEASE BLOCKER — بررسیهای دستی که باید قبل از تگ کردن یک نسخه پاس شوند
- QUALITY GATE — استانداردهایی که خود را به آنها متعهد میدانیم، بررسی شده اما توصیهای
امنیت و حریم خصوصی: تأیید شده توسط خط لوله، نه فقط وعده داده شده
بسیاری از پلاگینهای تحلیلی ویژگیهای امنیت و حریم خصوصی را در صفحه بازاریابی خود فهرست میکنند. ما ترجیح میدهیم نشان دهیم چگونه آن وعدهها بهطور مکانیکی اعمال میشوند:
همه کوئریهای SQL از statementهای آماده شده استفاده میکنند. افزونه WordPress PHPStan هر فراخوانی متد $wpdb که ورودی کاربر را به جای استفاده از $wpdb->prepare() الحاق میکند را پرچمگذاری میکند. این در زمان تحلیل ایستا گرفته میشود — قبل از اجرای کد.
بدون کوکی، localStorage یا fingerprinting. گیتهای انطباق برای توابع تنظیم کوکی و APIهای ذخیرهسازی مرورگر اسکن میکنند. مجموعه آزمون واحد راستیآزمایی میکند که payload tracker فقط شناسههای بازدیدکننده هش شده و غیرقابل برگشت دارد.
Saltهای روزانه چرخشی. همان بازدیدکننده هر روز هش متفاوتی تولید میکند، که ردیابی بینروزی را جلوگیری میکند. این توسط آزمونهای واحد اختصاصی پوشش داده میشود که یکتایی هش را در چرخشهای salt راستیآزمایی میکنند.
امضاهای HMAC روی payloadهای tracker. هر pageview با یک کلید تولید شده توسط سرور امضا میشود. راستیآزمایی امضا در مجموعه واحد آزمون میشود — payloadهای نامعتبر یا دستکاری شده رد میشوند.
شفافیت سرویس خارجی. گیت CI هر دامنه خارجی را از کد منبع استخراج میکند و راستیآزمایی میکند که در افشای readme.txt ظاهر میشود. اگر یک توسعهدهنده تماس HTTP به یک دامنه جدید اضافه کند، build شکست میخورد تا دامنه مستند شود.
آنچه آزمون خودکار نمیتواند بگیرد
ما به شفافیت درباره محدودیتها معتقدیم، نه فقط قابلیتها.
آزمونهای خودکار راستیآزمایی میکنند که کد تحت شرایط شناخته شده درست رفتار میکند. آنها نمیتوانند بگیرند:
- سردرگمی ظریف UX — یک نمودار داشبورد که از نظر فنی درست است اما برای کاربران غیرفنی گمراهکننده است
- موارد لبه عملکرد — کوئری که با 1,000 ردیف سریع است اما در 100,000 تنزل مییابد. ما آزمونهای بار k6 برای مسیرهای بحرانی داریم، اما آنها نمیتوانند هر شکل داده را پوشش دهند
- تعارضات اکوسیستم WordPress — تعاملات plugin یا تم که فقط در پیکربندیهای میزبانی خاص ظاهر میشوند. ما در برابر WP 6.4 تا trunk آزمون میکنیم، اما اکوسیستم WordPress 60,000+ plugin دارد
- آسیبپذیریهای روز صفر — هیچ مقداری از تحلیل ایستا از سوءاستفاده از بردارهای حمله ناشناخته قبلی جلوگیری نمیکند
ما این شکافها را با بررسی دستی در هر عرضه، یک مخزن GitHub عمومی که هر کسی میتواند کد را بازرسی کند و نظارت فعال بر انجمنهای پشتیبانی WordPress.org برای گزارشها از نصبهای دنیای واقعی کاهش میدهیم.
چرا این را منتشر کردیم
تحقیقات نشان میدهد که بیش از 50% از توسعهدهندگان plugin WordPress آسیبپذیریهای گزارش شده را قبل از افشای عمومی patch نمیکنند. پلاگینها سالها بدون بهروزرسانی هستند. کاربران هیچ راهی برای تشخیص یک plugin بهخوبی نگهداری شده از یک plugin رها شده ندارند جز رتبهبندی ستارهای و تاریخ «آخرین بهروزرسانی».
ما فکر میکنیم اکوسیستم WordPress سزاوار سیگنالهای بهتر است. انتشار خط لوله کیفی ما یک راه برای بالا بردن میله است — هم برای خودمان (حالا که عمومی است، نمیتوانیم بهآرامی بررسیها را رد کنیم) و هم برای اکوسیستم (سایر توسعهدهندگان plugin میتوانند شیوههای مشابهی را اتخاذ کنند).
اگر در حال ارزیابی پلاگینهای تحلیلی برای سایت WordPress خود هستید، ما تشویق میکنیم از هر کاندیدا بپرسید: چگونه آزمون میکنید؟ چه بررسیهایی قبل از یک عرضه اجرا میشوند؟ آیا میتوانم پیکربندی CI را ببینم؟
کل codebase Statnive روی GitHub متنباز است. هر فایل workflow، هر آزمون، هر گیت انطباق توصیف شده در این پست بهطور عمومی قابل بازرسی است.
Statnive را امتحان کنید
همه این مهندسی برای یک هدف وجود دارد: ارائه تحلیلگری به شما که میتوانید روی سرور WordPress خودتان به آن اعتماد کنید. بدون انتقال داده شخص ثالث، بدون کوکی، بدون اسکریپتهای ردیابی که سایت شما را کند میکنند.
Statnive را رایگان از WordPress.org نصب کنید — دادههای شما روی سرور شما باقی میماند، تأیید شده توسط 141 آزمون و 31 بررسی انطباق در هر عرضه.