
لتصحيح برامج PHP غالبًا ما تستخدم Xdebug . ومع ذلك ، لا تعد الميزات القياسية لـ IDE و Xdebug كافية دائمًا. يمكن حل بعض المشكلات باستخدام وكيل Xdebug - pydbgpproxy ، ولكن لا يزال غير كامل. لذلك ، قمت بتنفيذ وكيل PHP Xdebug استنادًا إلى إطار amphp غير المتزامن.
تحت القصاصة ، سوف أخبرك ما هو الخطأ في pydbgpproxy ، وما الذي ينقصها ولماذا لم أقوم بتعديلها. سأشرح أيضًا كيفية عمل وكيل PHP Xdebug وإظهار كيفية تمديده باستخدام مثال.
Pydbgpproxy مقابل PHP Xdebug proxy
وكيل Xdebug هو خدمة وسيطة بين IDE و Xdebug (طلبات الوكلاء من Xdebug إلى IDE والعكس بالعكس). في معظم الأحيان يتم استخدامه لتصحيح الأخطاء متعددة المستخدمين . هذا عندما يكون لديك خادم ويب واحد ، والعديد من المطورين.
وكوكيل ، عادة ما يتم استخدام pydbgpproxy. لكن لديه بعض المشاكل:
- لا توجد صفحة رسمية ؛
- من الصعب العثور على مكان لتنزيله ؛ اتضح أنه يمكن القيام بذلك هنا - فجميع بيثون عميل تصحيح الأخطاء عن بُعد ؛
- لم أجد المستودع الرسمي ؛
- نتيجة للفقرة السابقة ، ليس من الواضح مكان إحضار طلب السحب ؛
- الوكيل ، كما يوحي الاسم ، مكتوب في Python ، وهو ما لا يعرفه جميع مطوري PHP ، مما يعني أن توسيعه يمثل مشكلة ؛
- استمرار للفقرة السابقة: إذا كان هناك أي كود في PHP ، وسوف تحتاج إلى استخدامه في البروكسي ، فيجب أن يتم نقله إلى Python ، ويكون ازدواج الكود دائمًا غير جيد جدًا.
البحث عن وكيل Xdebug المكتوب بلغة PHP على GitHub وعلى الإنترنت لم يعط أي نتائج. لذلك كتبت وكيل PHP Xdebug . تحت غطاء محرك السيارة ، وأنا استخدم إطار غير متزامن amphp .
أهم مزايا وكيل PHP Xdebug عبر pydbgpproxy:
- تمت كتابة بروكسي PHP Xdebug بلغة مألوفة لمطوري PHP ، مما يعني:
- من الأسهل حل المشاكل فيه ؛
- من الأسهل التوسع ؛
- يحتوي وكيل PHP Xdebug على مستودع عام ، مما يعني:
- يمكنك شوكة والانتهاء من احتياجاتك.
- يمكنك إرسال طلب سحب مع ميزة مفقودة أو حل لمشكلة.
كيفية العمل مع وكيل PHP Xdebug
تركيب
يمكن تثبيت بروكسي PHP Xdebug كاعتماد ديف عبر الملحن :
composer.phar require mougrim/php-xdebug-proxy --dev
ولكن إذا كنت لا ترغب في سحب تبعيات إضافية إلى مشروعك ، فيمكن تثبيت وكيل PHP Xdebug كمشروع من خلال الملحن نفسه:
composer.phar create-project mougrim/php-xdebug-proxy cd php-xdebug-proxy
بروكسي PHP Xdebug قابل للمد ، لكن ext-dom مطلوب افتراضيًا (يتم تمكين الامتداد افتراضيًا في PHP) لتحليل XML و amphp / log للتسجيل غير المتزامن:
composer.phar require amphp/log '^1.0.0'
إطلاق

يبدأ الوكيل كما يلي:
bin/xdebug-proxy
سيبدأ الوكيل بالإعدادات الافتراضية:
Using config path /path/to/php-xdebug-proxy/config [2019-02-14 10:46:24] xdebug-proxy.NOTICE: Use default ide: 127.0.0.1:9000 array ( ) array ( ) [2019-02-14 10:46:24] xdebug-proxy.NOTICE: Use predefined ides array ( 'predefinedIdeList' => array ( 'idekey' => '127.0.0.1:9000', ), ) array ( ) [2019-02-14 10:46:24] xdebug-proxy.NOTICE: [Proxy][IdeRegistration] Listening for new connections on '127.0.0.1:9001'... array ( ) array ( ) [2019-02-14 10:46:24] xdebug-proxy.NOTICE: [Proxy][Xdebug] Listening for new connections on '127.0.0.1:9002'... array ( ) array ( )
من السجل يمكنك أن ترى الوكيل الافتراضي:
- يستمع إلى
127.0.0.1:9001
لاتصالات تسجيل الدخول IDE ؛ - يستمع إلى
127.0.0.1:9002
للاتصالات Xdebug ؛ - يستخدم
127.0.0.1:9000
كمعرف افتراضي IDE و IDE محدد مسبقًا مع مفتاح idekey.
ترتيب
إذا كنت ترغب في تكوين منافذ الاستماع ، وما إلى ذلك ، يمكنك تحديد المسار إلى مجلد الإعدادات. فقط انسخ مجلد التكوين :
cp -r /path/to/php-xdebug-proxy/config /your/custom/path
هناك ثلاثة ملفات في مجلد الإعدادات:
بعد نسخ الملفات ، يمكنك تحرير الوكيل وتشغيله:
bin/xdebug-proxy --configs=/your/custom/path/config
تصحيح الأخطاء
تمت كتابة العديد من المقالات حول كيفية تصحيح التعليمات البرمجية باستخدام Xdebug. سوف نلاحظ النقاط الرئيسية.
في php.ini ، يجب أن تكون الإعدادات التالية في المقطع [xdebug]
(قم [xdebug]
إذا كانت تختلف عن الإعدادات القياسية):
- idekey = idekey
- remote_host = 127.0.0.1
- remote_port = 9002
- remote_enable = في
- remote_autostart = في
- remote_connect_back = متوقف
ثم يمكنك تشغيل رمز PHP الذي تم تصحيحه:
php /path/to/your/script.php
إذا قمت بكل شيء بشكل صحيح ، فسيبدأ التصحيح من نقطة الإيقاف الأولى في IDE. تصحيح الأخطاء في وضع php-fpm بواسطة العديد من المطورين هو خارج نطاق هذه المقالة ، ولكن تم وصفه ، على سبيل المثال ، هنا .
ميزات الوكيل التمديد
كل ما درسناه أعلاه ، pydbgpproxy قادر أيضًا على درجة أو أخرى.
الآن دعونا نتحدث عن الأكثر إثارة للاهتمام في وكيل PHP Xdebug. يمكن توسيع الوكلاء باستخدام المصنع الخاص بك (الذي تم إنشاؤه في config factory.php
، انظر أعلاه). يجب أن يقوم المصنع بتنفيذ واجهة Factory\Factory
.
الأقوى هم الذين يعدون الطلب. يمكنهم تعديل الطلبات من Xdebug إلى IDE والعكس. لإضافة أداة Factory\DefaultFactory::createRequestPreparers()
استعلام ، يجب عليك تجاوز الأسلوب Factory\DefaultFactory::createRequestPreparers()
. تقوم الطريقة بإرجاع صفيف من الكائنات التي تقوم RequestPreparer\RequestPreparer
واجهة RequestPreparer\RequestPreparer
. عند إجراء طلب من Xdebug إلى IDE ، يتم تنفيذها بالترتيب المباشر ؛ وعند عكس طلب من IDE إلى Xdebug ، يتم عكسه.
يمكن استخدام معالجات الاستعلام ، على سبيل المثال ، لتغيير المسارات إلى الملفات (في نقاط التوقف والملفات القابلة للتنفيذ).
تصحيح الملفات المكتوبة
من أجل إعطاء مثال على المحضر ، سأقوم بعمل استطرادي صغير. في اختبارات الوحدة ، نستخدم mocks لينة ( GitHub ). تسمح لك برامج Soft-mocks باستبدال الوظائف والطرق الثابتة والثوابت وما إلى ذلك في الاختبارات ، وهي بديلاً لجهاز runkit و uopz . هذا يعمل عن طريق إعادة كتابة ملفات PHP على الطاير. وبالمثل ، لا يزال AspectMock يعمل.
لكن الميزات القياسية لـ Xdebug و IDE تتيح لك تصحيح إعادة الكتابة (ذات مسار مختلف) ، بدلاً من الملفات الأصلية.
دعونا نلقي نظرة فاحصة على مشكلة تصحيح الأخطاء باستخدام mocks لينة في الاختبارات. أولاً ، خذ الحالة التي يتم فيها تنفيذ رمز PHP محليًا.
تظهر الصعوبات الأولى في مرحلة تحديد نقاط التوقف (نقاط التوقف). في IDE ، يتم تثبيتها في الملفات الأصلية ، وليس في الملفات المعاد كتابتها. لوضع نقطة توقف عبر IDE ، تحتاج إلى العثور على الملف الفعلي المعاد كتابته. تتفاقم المشكلة بحقيقة أنه في كل مرة يتم فيها تغيير الملف الأصلي ، يتم إنشاء ملف جديد معاد كتابته ، أي لكل محتوى ملف فريد سيكون هناك ملف فريد معاد كتابته.
يمكن حل هذه المشكلة عن طريق استدعاء الدالة xdebug_break()
، التي تشبه إعداد نقطة توقف. في هذه الحالة ، ليست هناك حاجة للبحث عن ملف معاد كتابته.
الآن اعتبر الموقف أكثر تعقيدًا: يتم تشغيل التطبيق على جهاز بعيد.
في هذه الحالة ، يمكنك تحميل المجلد بالملفات المعاد كتابتها ، على سبيل المثال ، من خلال SSHFS. إذا كانت المسارات المحلية والبعيدة إلى المجلد مختلفة ، فأنت لا تزال بحاجة إلى تسجيل التعيينات في IDE.
بطريقة أو بأخرى ، تختلف هذه الطريقة قليلاً عن الطريقة المعتادة وتتيح لك تصحيح الملفات المنسوخة فقط ، وليس الملفات الأصلية. ولكن ما زلت أريد تحرير وتصحيح نفس الملفات الأصلية.
تخطت AspectMock المشكلة عن طريق تمكين وضع التصحيح دون القدرة على تعطيله:
public function init(array $options = []) { if (!isset($options['excludePaths'])) { $options['excludePaths'] = []; } $options['debug'] = true; $options['excludePaths'][] = __DIR__; parent::init($options); }
في مثال اختبار بسيط ، يكون وضع تصحيح الأخطاء أبطأ بنسبة 20 بالمائة ، لكن ليس لدي اختبارات AspectMock كافية لتقديم تقدير أكثر دقة لمدى بطئه. إذا كان لديك العديد من الاختبارات على AspectMock ، سأكون سعيدًا إذا كنت تشارك المقارنة في التعليقات.
باستخدام Xdebug مع mocks لينة

الآن وبعد أن أصبحت المشكلة واضحة ، فكر في كيفية حلها باستخدام وكيل PHP Xdebug. الجزء الرئيسي في RequestPreparer\SoftMocksRequestPreparer
.
في مُنشئ الفصل الدراسي ، حدد المسار إلى البرنامج النصي لتهيئة soft-mocks وقم بتشغيله (من المفترض أن mocks الناعمة متصلة كتبعية ، ولكن يمكن تمرير أي مسار إلى المُنشئ):
public function __construct(LoggerInterface $logger, string $initScript = '') { $this->logger = $logger; if (!$initScript) { $possibleInitScriptPaths = [

لإعداد طلب من Xdebug إلى IDE ، تحتاج إلى استبدال المسار إلى الملف الذي تمت إعادة كتابته بالملف الأصلي:
public function prepareRequestToIde(XmlDocument $xmlRequest, string $rawRequest): void { $context = [ 'request' => $rawRequest, ]; $root = $xmlRequest->getRoot(); if (!$root) { return; } foreach ($root->getChildren() as $child) {

لإعداد طلب من IDE إلى Xdebug ، يجب استبدال المسار إلى الملف الأصلي بمسار المسار الذي تمت إعادة كتابته:
public function prepareRequestToXdebug(string $request, CommandToXdebugParser $commandToXdebugParser): string {
لكي يعمل أداة إعداد الاستعلام ، عليك إنشاء فئة المصنع الخاصة بك وإما أن Factory\DefaultFactory
من Factory\DefaultFactory
، أو تقوم بتطبيق واجهة Factory\Factory
. بالنسبة Factory\SoftMocksFactory
يبدو Factory\SoftMocksFactory
كما يلي:
class SoftMocksFactory extends DefaultFactory { public function createConfig(array $config): Config {
هنا تحتاج إلى فئة التكوين الخاصة بك حتى تتمكن من تحديد مسار البرنامج النصي init soft-mocks. ما هو عليه ، يمكنك أن ترى في Config \ SoftMocksConfig .
لم يتبق سوى القليل: لإنشاء مصنع جديد والإشارة إلى المسار إلى البرنامج النصي init-mocks. كيف يتم ذلك يمكن أن ينظر إليها في softMocksConfig
.
واجهة برمجة التطبيقات غير المحظورة
كما كتبت أعلاه ، يستخدم وكيل PHP Xdebug amphp تحت الغطاء ، مما يعني أنه يجب استخدام واجهة برمجة تطبيقات غير محظورة للعمل مع I / O. يحتوي Apmphp بالفعل على العديد من المكونات التي تقوم بتطبيق API غير المحظورة. إذا كنت ستقوم بتمديد بروكسي PHP Xdebug واستخدامه في وضع متعدد المستخدمين ، فاحرص على استخدام واجهات برمجة التطبيقات غير المحظورة.
النتائج
لا يزال بروكسي PHP Xdebug مشروعًا شابًا إلى حد ما ، لكن في Badoo يتم استخدامه فعليًا لتصحيح الاختبارات باستخدام mocks لينة.
وكيل PHP Xdebug:
- يستبدل pydbgpproxy في تصحيح الأخطاء متعدد المستخدمين ؛
- يمكن أن تعمل مع لينة السخرية.
- يمكن توسيعها:
- يمكنك استبدال المسارات إلى الملفات القادمة من IDE ومن Xdebug ؛
- يمكن جمع الإحصاءات: في وضع التصحيح ، يتوفر على الأقل السياق القابل للتنفيذ عند تصحيح الأخطاء (قيم المتغيرات وسطر التعليمات البرمجية القابل للتنفيذ).
إذا كنت تستخدم وكيل Xdebug لأي شيء آخر غير تصحيح الأخطاء متعدد المستخدمين ، فقم بمشاركة قضيتك ووكيل Xdebug الذي تستخدمه في التعليقات.
إذا كنت تستخدم pydbgpproxy أو بعض وكيل Xdebug الآخر ، فجرّب وكيل PHP Xdebug ، وتحدث عن مشاكلك ، وشارك طلبات السحب. لنقم بتطوير المشروع معًا! :)
سكرتير خاص شكرا لزميلي يفغيني مخروف ويعرف أيضا باسم eZH لفكرة وكيل smdbgpproxy !
الروابط مرة أخرى
- وكيل PHP Xdebug - وكيل Xdebug ، الذي تمت مناقشته في المقالة ؛
- يمكن تنزيل pydbgpproxy هنا - فجميع بيثون عميل تصحيح الأخطاء عن بُعد ؛
- amphp - إطار PHP غير متزامن غير مانع ؛
- أدوات وهمية
شكرا لاهتمامكم!
سأكون سعيدًا بالتعليقات والاقتراحات.
رينات اخميديف مطور PHP
محدث : نشرت ترجمة المقال إلى اللغة الإنجليزية.