التطوير المحلي باستخدام zinnector dev

يقوم zinnector dev بتشغيل WordPress حقيقي على جهازكم الخاص، حيث يخدم الإضافات والقوالب الموجودة في مشروعكم، مع إصدار PHP تختارونه. تشرح هذه المقالة بيئتي التشغيل اللتين يمكنه استخدامهما، وكيفية اختيار الإصدارات، وما الذي يتم تقديمه ومن أين، وأين توجد بيئة التشغيل على القرص — حتى يكون ما تختبرونه محلياً هو ما تقومون بنشره بالضبط.

بيئتا التشغيل، ولماذا كلتاهما حقيقية

Playground هي البيئة الافتراضية. يقوم WordPress Playground بترجمة PHP برمجياً إلى WebAssembly وتشغيلها داخل Node، وبذلك يتمكن أي جهاز محمول لا يحتوي إلا على Node من تشغيل WordPress في غضون ثوانٍ. أي إصدار PHP من 5.2 إلى 8.5 متاح للاستخدام. تتضمن هذه البيئة مجموعة صغيرة من ملحقات PHP (intl، وredis، وmemcached كما تم قياسها في البنية الحالية)، وهو ما يكفي لمعظم أعمال الإضافات والقوالب.

يقوم Docker بتشغيل حاويات php-fpm وMariaDB أصلية. هذه البيئة أبطأ، وتتطلب وجود عفريت Docker وحوالي 1.2 غيغابايت من صور الحاويات، وتدعم إصدارات PHP من 7.4 إلى 8.5 — لكنها تشغل PHP أصلياً مع مجموعة الملحقات الكاملة، بما في ذلك imagick وgd. إنها الخيار الصائب عندما يتطلب اختباركم ملحقاً لا تشتمل عليه بنية WebAssembly.

zinnector dev                       # playground
zinnector dev --runtime docker      # native PHP + MariaDB

لا يتم الرجوع تلقائياً إلى Docker في الخفاء أبداً. فالمطور الذي يعتقد أنه يعمل على WebAssembly بينما هو في الواقع على Docker يكون قد تلقى نتيجة غير صحيحة من أداة تحاول المساعدة، ولهذا يجب طلبها صراحةً بالاسم.

اختيار إصدارات PHP وWordPress

zinnector dev --php 8.1 --wp 6.7    # develop against a specific pair
zinnector dev --port 9401           # when 9400 is taken
zinnector dev --no-login            # do not sign in to wp-admin automatically
zinnector dev --verbose             # show the runtime's own output

تأتي الإعدادات الافتراضية من ملف zinnector.json داخل المشروع — وهي php وwordpress وruntime وport — والتي يكتبها أمر zinnector new ويجب عليكم تضمينها في نظام التحكم بالإصدار (commit)، حتى يعمل جميع من في المشروع على نفس الإصدارات. كما تتفوق أي راية محددة في سطر الأوامر على الملف في عملية التشغيل تلك.

الإصدار الذي تعلنون عنه والإصدار الذي يعمل بالفعل حقيقتان مختلفتان. يُشغّل zinnector dev --once بيئة التشغيل، ثم يطبع ما تبلّغ عنه فعلياً — إصدار PHP، وإصدار WordPress، والملحقات المحملة — ثم يتوقف. ويستخدم zinnector check --probe نفس القياس عند مقارنة مشروعكم بحصة الاستضافة.

ما الذي يتم تقديمه من مشروعكم

تقوم بيئة التشغيل بربط أدلة مشروعكم wp-content/plugins وwp-content/themes وwp-content/mu-plugins مباشرةً، بحيث يظهر الملف الذي تحفظونه مباشرة عند إعادة التحميل التالية. والأدلة الموجودة التي لا تحتوي على محتوى حقيقي لا يتم ربطها عن قصد: فرَبْط مجلد themes/ فارغ فوق قوالب بيئة التشغيل الخاصة سيترك WordPress بدون أي قالب على الإطلاق، مما يؤدي إلى ظهور صفحة خطأ 500 فارغة بدلاً من موقعكم. ولهذا السبب يحتفظ الهيكل الأساسي بالأدلة الفارغة باستخدام .gitkeep ولهذا لا تحجب أي شيء حتى تضعوا قالباً بداخلها.

أين توجد بيئة التشغيل

يتم تنزيل بيئة تشغيل WordPress عند الاستخدام الأول بدلاً من شحنها مع واجهة سطر الأوامر (CLI) — فالحزمة التي تتضمن جميع بنيات PHP تبلغ حوالي 570 ميغابايت، والمطور الذي يقتصر عمله على استعراض المواقع لا ينبغي أن يتحمل تنزيلها. يتم الاحتفاظ بها في الذاكرة المؤقتة الخاصة بـ Zinnector®، في المسار ~/.cache/zinnector/runtimes/playground/<version> (أو أينما يشير ZINNECTOR_CACHE_DIR)، ولا يتم تخزينها أبداً في مشروعكم، لذا لا يمكن أن ينتهي بها المطاف في مستودعكم أو ضمن الشجرة التي يقيسها zinnector push. ويتم إجراء التنزيل بواسطة أداة npm الخاصة بكم، حيث يتم تشغيلها كـ node npm-cli.js — وليس عبر مفسر الأوامر (shell) إطلاقاً.

يتم تثبيت إصدار بيئة التشغيل ليتطابق مع إصدار CLI، بحيث يشغّل أي مطورين يعملان على مشروع واحد بنيات PHP المتطابقة. يقوم zinnector dev --reset-runtime بحذف بيئة التشغيل المثبتة وإعادة تثبيتها من جديد، وهو الحل لبيئة التشغيل التي تم تثبيتها ولكنها تأبى الإقلاع.

على Node 26 أو الأحدث

تعمل أداة CLI نفسها على أي إصدار من Node بدءاً من 24 فما فوق. ومع ذلك، فإن الوحدة الأصلية لبيئة التشغيل لا توفر ملفات ثنائية مبنية مسبقاً إلا لإصداري Node 24 و25 فقط (اعتباراً من سبتمبر 2026). وبدلاً من ترجمة أي شيء برمجياً — وهو ما يتطلب تثبيت Visual Studio على Windows — تقوم Zinnector® بجلب إصدار Node 24 لبيئة التشغيل وحدها، بحجم حوالي 30 ميغابايت، والتحقق منه مقابل المجاميع الاختبارية (checksums) التي ينشرها nodejs.org، وحفظه في الذاكرة المؤقتة نفسها. توضح رسالة التثبيت ذلك عند انطباق هذه الحالة. ولا يطرأ أي تغيير على إصدار Node الخاص بكم.

مواضيع ذات صلة

• دليل البدء · النشر · مرجع الأوامر · استكشاف الأخطاء وإصلاحها