Product Updates إضافة Statnive · Parhum Khoshbakht

248 اختبارًا، 22 بوابة إصدار، بدون اختصارات: كيف نُصدر Statnive

تشغّل معظم plugins WordPress أداة linter واحدة وتعتبر ذلك كافيًا. يمرّ Statnive عبر 5 طبقات من التحقّق الآلي — من hooks ما قبل الـ commit إلى بوابات الامتثال لـ WordPress.org — قبل أن يُشحن أي إصدار. إليك بالضبط ما نفحصه ولماذا. (الأرقام اعتبارًا من v0.4.9.)

قبل أن تثبّت أي plugin، أنت تثق بكود شخص آخر

كل plugin WordPress تفعّله يحصل على وصول كامل إلى قاعدة بياناتك ولوحة الإدارة وبيانات زوارك. تعرض معظم صفحات الـ plugin تقييمًا بالنجوم وتاريخ «آخر تحديث». هذه ليست معلومات كافية لاتّخاذ قرار ثقة.

بنينا Statnive ليكون plugin التحليلات الذي نثق به على مواقعنا الخاصة. يمرّ هذا المقال عبر خط أنابيب الجودة الدقيق الذي يجتازه كل سطر من كود Statnive قبل أن يصل إلى تثبيت WordPress لديك. لا ادّعاءات مبهمة — فحوصات محدّدة وأرقام حقيقية وتحفّظات صادقة بشأن ما يستطيع الاختبار الآلي وما لا يستطيع رصده.

الأرقام الرئيسية (اعتبارًا من v0.4.9): 248 اختبار وحدة PHP، و31 قسم امتثال لـ WordPress.org، و22 بوابة إصدار متخصّصة (5 ثابتة + 17 grep امتثال)، و3 إصدارات PHP مستهدفة، وميزانية حجم tracker بـ 5KB مفروضة على كل بناء على الإطلاق.

الطبقة 1: hook ما قبل الـ commit — لا شيء يدخل المستودع دون فحص

قبل أن يدخل الكود حتى مستودع Git لدينا، يشغّل hook ما قبل الـ commit فحصين على كل ملف مهيّأ:

لتغييرات PHP:

  1. PHPCS (PHP CodeSniffer) يتحقّق من الملفات المهيّأة مقابل WordPress Coding Standards — مجموعة القواعد ذاتها التي يستخدمها WordPress core. يلتقط هذا الإفلات غير الآمن للمخرجات والتعقيم المفقود وأنماط الكود غير القياسية.
  2. PHPUnit يشغّل مجموعة اختبارات الوحدة الكاملة. يجب أن تنجح كل الاختبارات الـ 248. أي فشل واحد يحجب الـ commit.

لتغييرات TypeScript/JavaScript:

  1. Vitest يشغّل كل اختبارات مكوّنات React. لا يمكن لواجهة لوحة التحكم أن تتراجع دون أن تُلتقَط هنا.

hook ما قبل الـ commit سريع عمدًا — يعمل في أقل من 5 ثوانٍ على جهاز مطوّر. الهدف ليس استبدال CI، بل التقاط الأخطاء الأكثر شيوعًا قبل إهدار رحلة ذهاب وإياب إلى GitHub. عمليًا، تلتقط هذه البوابة الواحدة نحو 80% من المشكلات قبل أن تغادر حتى لابتوب المطوّر.

الطبقة 2: التكامل المستمرّ — 6 وظائف متوازية على كل push

كل push إلى فرع التطوير أو الفرع الرئيسي، وكل pull request، يُشغّل خط أنابيب GitHub Actions CI بـ 6 وظائف متوازية:

الوظيفةما تفحصهلماذا تهمّ
Lint (PHP 8.2، 8.3، 8.4)PHPCS + PHPStan level 6معايير الترميز وسلامة الأنواع الثابتة عبر 3 إصدارات PHP
Unit Tests (PHP 8.2، 8.3، 8.4)مجموعة PHPUnitصحّة المنطق عبر 3 إصدارات PHP
Minimum Floor Smoke (PHP 8.0)Syntax lint + إقلاع autoloaderيثبت أن الـ plugin يُحمَّل على إصدار PHP الأدنى المعلَن
Tracker Buildبناء Vite + فحص حجم gzipيفرض ميزانية 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 لدينا.

ميزانية tracker الـ 5KB

لـ tracker JavaScript الذي يجمع مشاهدات الصفحة على موقعك حدّ حجم صلب: 5120 بايت مضغوطًا. كل بناء يقيس المخرَج ويُفشل خط الأنابيب إذا تجاوز الـ tracker تلك الميزانية. هذا ليس عشوائيًا — أظهرت مقارنة أدائنا أن حجم الـ tracker يرتبط مباشرةً بأثر LCP. تُجبرنا الميزانية على إبقاء المسار الحرج في الحدّ الأدنى وتأجيل الميزات غير الجوهرية إلى نص ثانوي async.

# From our CI workflow — the tracker size check
- 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
    fi

PHPStan على المستوى 6

PHPStan أداة تحليل ثابت تجد الأخطاء دون تشغيل الكود. يلتقط المستوى 6 (من 10) عدم تطابق الأنواع، والمتغيّرات غير المعرَّفة، وأنواع الإرجاع غير الصحيحة، ومسارات الكود الميتة. نشغّله مع امتداد phpstan-wordpress، الذي يفهم توقيعات hooks في WordPress، وأنواع إرجاع الـ filters، وعقود طرق $wpdb. مع فرض $wpdb->prepare()، هذا هو دفاعنا الأساسي ضدّ حقن SQL — يضع المحلّل الثابت علامة على أي استعلام يربط مدخلات المستخدم بدلًا من استخدام عبارات معدّة.

الطبقة 3: الامتثال لـ WordPress.org — 22 بوابة إصدار

هنا يتباين خط أنابيب جودة Statnive عن معظم plugins WordPress. ما وراء الـ linting والاختبار القياسي، نشغّل 22 بوابة إصدار مبنية لغرض محدّد (5 ثابتة + 17 grep امتثال) تفرض إرشادات plugin WordPress.org — القواعد ذاتها التي يفحصها فريق المراجعة يدويًا أثناء التقديم.

يكتشف معظم مطوّري الـ plugin هذه القواعد عند رفض تقديمهم. أتمتْنا فحصها بحيث تُلتقط الانتهاكات على كل commit:

بوابات الأمن

حراس ABSPATH — يجب أن يفحص كل ملف PHP defined('ABSPATH') قبل التنفيذ. يمنع هذا الوصول المباشر إلى ملفات الـ plugin عبر URL، الذي قد يسرّب مسارات الخادم أو ينفّذ كودًا خارج سياق WordPress. تفحص بوابتنا كل ملف .php في شجرة المصدر وتفشل إذا كان أي ملف يفتقر إلى الحارس.

أنماط محظورة — فحص آلي يحجب دوال PHP الخطرة التي يرفضها WordPress.org صراحةً: eval() وexec() وshell_exec() وsystem() وpassthru() وcurl_init(). كما يلتقط علامات PHP القصيرة، وjson_encode() خام (يجب استخدام wp_json_encode())، ومسارات wp-content المُرمَّزة بشدّة.

امتثال WP API — يفحص أن جميع النصوص وأوراق الأنماط تستخدم نظام enqueue الخاص بـ WordPress بدلًا من علامات <script> أو <link> المُرمَّزة بشدّة. يفحص أيضًا الوصول غير المعقَّم إلى المتغيّرات العامة ($_GET و$_POST و$_REQUEST) — وهو أحد أهمّ أسباب رفض WordPress.org لتقديمات الـ plugin.

بوابات السلامة

اتّساق Readme والإصدار — يجب أن يتطابق إصدار الـ plugin في ثلاثة أماكن: Stable tag في readme.txt، ورأس statnive.php، وثابت PHP STATNIVE_VERSION. عدم التطابق يعني أن WordPress سيُظهر رقم إصدار خاطئ — مربك للمستخدمين وعلامة حمراء للمراجعين. تتحقّق هذه البوابة أيضًا من عدد الـ tags (حدّ أقصى 5)، وطول الوصف القصير (حدّ أقصى 150 حرفًا)، ووجود ملف LICENSE، وقسم الإفصاح عن الخدمات الخارجية.

التحقّق من ZIP التوزيع — يبني ملف ZIP الفعلي الذي سيُرفع إلى WordPress.org، ثم يتحقّق من محتوياته. يجب أن تكون الملفات المطلوبة موجودة (statnive.php، readme.txt، LICENSE، src/Plugin.php، مصدر tracker غير مصغَّر). يجب أن تكون الملفات المحظورة غائبة (node_modules/، .git/، composer.json، tests/، phpunit، ملفات الإعداد). يجب أن يبقى حجم ZIP تحت 25MB.

تكافؤ الرأس — يتحقّق أن جميع حقول رأس الـ plugin الـ 11 المطلوبة موجودة ومتّسقة. يفحص أن إصدار Tested up to لـ WordPress في حدود إصدارَين ثانويَّين من الإصدار الثابت الحالي — قيمة قديمة تشير إلى plugin غير مصان ويمكن أن تؤثّر على ترتيب البحث في WordPress.org.

بوابات البنية

حواجز البنية — تفحص الأنماط التي تشير إلى انتهاكات السياسة: مكالمات HTTP «اتّصال هاتفي» داخل hooks التفعيل (لا ينبغي أن يرى المستخدمون طلبات شبكية عند تفعيل plugin)، وhooks المحدّث الذاتي المخصّص (WordPress.org يتعامل مع التحديثات)، وقواعد بيانات MaxMind GeoIP المضمّنة (يجب على المستخدمين توفير مفتاح ترخيصهم الخاص).

حدّ المجانية/المدفوعة — يجب ألّا يحتوي إصدار WordPress.org المجاني على كود يقيّد عبر التراخيص. تفحص هذه البوابة عن أنماط مثل isPro() وcheckLicense() وtrial_expires وpremium_only — لتضمن أن بناء .org مجاني فعلًا، لا تجربة مشلولة.

تدقيق الخدمات الخارجية — يستخرج كل نطاق https:// مُشار إليه في كود مصدر PHP، ثم يتحقّق أن كلّ واحد موثَّق في قسم External Services في readme.txt. أي اتصال خارجي غير موثَّق يُفشل البناء. هكذا نضمن الشفافية حول مكان تدفّق بياناتك.

احصل على Statnive: كود يمكنك الوثوق به

كل فحص موصوف في هذا المقال يعمل تلقائيًا على كل تغيير. لا يضطرّ أي إنسان إلى تذكّر تشغيل فحص الأمن أو فحص اتّساق الإصدار — خط الأنابيب يفرض ذلك. ثبّت Statnive من WordPress.org وانظر إلى النتيجة: تحليلات سريعة وخاصّة على خادمك.

الطبقة 4: WordPress Plugin Check — أكثر صرامة من المطلوب

Plugin Check (PCP) أداة رسمية من فريق WordPress.org تشغّل الفحوصات الآلية ذاتها التي يستخدمها فريق المراجعة. تضبط معظم الـ plugins PCP بحيث يفشل فقط على الأخطاء.

Statnive يفشل على الأخطاء وعلى التحذيرات.

هذا اختيار متعمَّد. غالبًا ما تشير تحذيرات PCP إلى مشكلات مشروعة — استخدام دوال مهجورة، فجوات في إمكانية الوصول، مخاوف أداء — لا تحجب التقديم تقنيًا، لكنها تُفسد جودة الـ plugin بمرور الوقت. بمعاملة التحذيرات كأخطاء، نلتقط مشكلات تشحنها plugins أخرى.

تشتغل بوابة PCP على دليل التوزيع المبني (لا على شجرة المصدر)، باستخدام PHP 8.0 — الحدّ الأدنى المعلَن. هذا يعني أننا نختبر بالضبط ما سيثبّته المستخدمون، على أقدم إصدار PHP ندعمه.

الطبقة 5: بوابة الإصدار — 31 قسمًا قبل شحن أي إصدار

قبل الإصدار، تجمع البوابة الكاملة كل ما سبق في قرار نجح-أو-فشل واحد:

بوابات الاختبار الثابتة (يجب أن تنجح كلّها):

البوابةالفحصالأداة
S-1WordPress Coding StandardsPHPCS
S-2تحليل الأنواع الثابتPHPStan level 6
S-3اختبارات وحدة + تكامل PHPPHPUnit
S-4اختبارات مكوّنات ReactVitest
S-5Plugin Check الرسميPCP (أخطاء + تحذيرات)

بوابات grep الامتثال (17 فحص نمط آلي):

البواباتما تفرضه
C-1حرّاس ABSPATH على كل ملف PHP
C-2التحقّق من ملف الترخيص
C-3، C-4لا اتّصال هاتفي على التفعيل، لا paywalls خفية
C-5بنية readme، تكافؤ الإصدار، إفصاح الخدمات الخارجية
C-6لا وصول غير معقَّم إلى المتغيّرات العامة
C-7لا قواعد بيانات GeoIP مضمّنة
C-8، C-9، C-10لا محدّث مخصّص، لا مكتبات core مضمّنة، لا CDN خارجي
C-11، C-12تنظيف cron عند التعطيل، وجود دالّة uninstall
C-13بنية دليل أصول SVN
C-14سلامة وحجم ZIP
C-15إنشاء جداول قاعدة البيانات يتبع تنسيق dbDelta
C-16جميع السلاسل الموجَّهة للمستخدم مدوَّلة
C-17hooks WordPress Privacy API مسجَّلة

ما وراء البوابات الآلية، يتضمّن كل إصدار مراجعة يدوية تغطّي ميزانيات الأداء، والتوافق مع المتصفّحات، وإمكانية الوصول (WCAG 2.2 AA)، ووضوح UX الإدارة، وسلامة الترقية/الترحيل، ومعالجة الأعطال. تمتدّ القائمة الكاملة عبر 31 قسمًا في 3 مستويات شدّة:

  • CRITICAL — بوابات آلية تحجب خط أنابيب الإصدار
  • RELEASE BLOCKER — فحوصات يدوية يجب أن تنجح قبل وسم نسخة
  • QUALITY GATE — معايير نلتزم بها لأنفسنا، تُراجع لكنّها استشارية

الأمن والخصوصية: مُتَحقَّق بهما عبر خط الأنابيب، لا مجرّد وعد

تسرد كثير من plugins التحليلات ميزات الأمن والخصوصية في صفحة تسويقها. نُفضّل أن نُظهر كيف تُفرض هذه الوعود ميكانيكيًا:

كل استعلامات SQL تستخدم عبارات معدَّة. يضع امتداد WordPress في PHPStan علامة على أي استدعاء طريقة $wpdb يربط مدخلات المستخدم بدلًا من استخدام $wpdb->prepare(). يُلتقط هذا في وقت التحليل الثابت — قبل أن يعمل الكود أبدًا.

لا cookies ولا localStorage ولا fingerprinting. تفحص بوابات الامتثال عن دوال إعداد cookies وواجهات تخزين المتصفّح. تتحقّق مجموعة اختبار الوحدة من أن حمولة الـ tracker تحتوي فقط على معرّفات زائر مجزَّأة وغير قابلة للعكس.

Salts يومية متغيّرة. ينتج الزائر ذاته تجزئة مختلفة كل يوم، مما يمنع التتبّع عبر الأيام. يغطّي هذا اختبارات وحدة مخصّصة تتحقّق من تفرّد التجزئة عبر تناوب الـ salt.

توقيعات HMAC على حمولات الـ tracker. تُوقَّع كل إصابة مشاهدة صفحة بمفتاح مولَّد من الخادم. يُختبَر التحقّق من التوقيع في مجموعة الوحدة — تُرفض الحمولات غير الصحيحة أو المُعبَث بها.

شفافية الخدمات الخارجية. تستخرج بوابة CI كل نطاق خارجي من كود المصدر وتتحقّق من ظهوره في إفصاح readme.txt. إذا أضاف مطوّر مكالمة HTTP إلى نطاق جديد، يفشل البناء حتى يُوثَّق النطاق.

ما لا يستطيع الاختبار الآلي التقاطه

نؤمن بالشفافية بشأن القيود، لا فقط بالقدرات.

تتحقّق الاختبارات الآلية من أن الكود يتصرّف بشكل صحيح في ظل ظروف معروفة. ولا تستطيع التقاط:

  • الالتباس الدقيق في UX — رسم بياني في لوحة التحكم صحيح تقنيًا لكنّه مضلِّل لمستخدمين غير تقنيّين
  • حالات أداء حدّية — استعلام سريع مع 1000 صفّ لكنّه يتدهور عند 100,000. لدينا اختبارات حمل k6 للمسارات الحرجة، لكنها لا تستطيع تغطية كل شكل بيانات
  • تعارضات نظام WordPress — تفاعلات plugin أو theme تظهر فقط على إعدادات استضافة معيّنة. نختبر مقابل WP 6.4 حتى trunk، لكن نظام WordPress يضمّ أكثر من 60,000 plugin
  • ثغرات يوم الصفر — لا قدر من التحليل الثابت يمنع استغلال نواقل هجوم غير معروفة سابقًا

نخفّف هذه الفجوات بمراجعة يدوية على كل إصدار، ومستودع GitHub علني يستطيع أي شخص فيه تدقيق الكود، ومراقبة نشطة لمنتديات دعم WordPress.org بحثًا عن تقارير من تثبيتات في العالم الحقيقي.

لماذا نشرنا هذا

تُظهر الأبحاث أن أكثر من 50% من مطوّري plugins WordPress لا يرقّعون الثغرات المُبلَّغ عنها قبل الإفصاح العلني. تذهب plugins سنوات دون تحديثات. ليس لدى المستخدمين طريقة لتمييز plugin مصان بشكل جيد عن آخر مهجور سوى تقييمات النجوم وتاريخ «آخر تحديث».

نعتقد أن نظام WordPress يستحقّ إشارات أفضل. نشر خط أنابيب الجودة لدينا هو إحدى الطرق لرفع المستوى — لأنفسنا (الآن وقد أصبح علنيًا، لا يمكننا تخطّي الفحوصات بصمت) وللنظام (يستطيع مطوّرو plugins آخرون اعتماد ممارسات مماثلة).

إذا كنت تقيّم plugins تحليلات لموقع WordPress الخاص بك، نشجّعك على سؤال كل مرشّح: كيف تختبرون؟ ما الفحوصات التي تشتغل قبل الإصدار؟ هل يمكنني رؤية إعداد CI؟

قاعدة كود Statnive بأكملها مفتوحة المصدر على GitHub. كل ملف workflow، كل اختبار، كل بوابة امتثال موصوفة في هذا المقال قابلة للتدقيق العلني.

جرّب Statnive

كل هذه الهندسة موجودة لخدمة هدف واحد: منحك تحليلات يمكنك الوثوق بها على خادم WordPress الخاص بك. لا نقل بيانات إلى أطراف ثالثة، ولا cookies، ولا نصوص تتبّع تبطئ موقعك.

ثبّت Statnive مجانًا من WordPress.org — بياناتك تبقى على خادمك، مُتَحقَّق منها بـ 248 اختبارًا و22 بوابة إصدار على كل إصدار.

Get Statnive Free