# ورقة بحثية: الموديلات كسرت ملفات PHP قديمة كانت تعمل أثناء تحديثها إلى PHP 8.3

> **المغزى:** المغزى: درجة التحديث تقيس شكل الكود الجديد لا بقاء سلوكه، وفي أغلب الملفات كان خيار عدم فعل شيء أكثر أمانًا من أي موديل.

- المصدر: المغزى (https://almaghza.com/a/2026-10-30-llm-legacy-php-modernization-breaks/)
- التاريخ: 19 جمادى الأولى - 30 أكتوبر 2026 (2026-10-30)
- القسم: برمجيات
- الوسوم: PHP، WordPress، Refactoring، arXiv، نماذج اللغة الكبيرة

جرّبت ورقة بحثية جديدة، قُدّمت في 29 أكتوبر 2026 بعنوان «When Modernization Breaks Working Code»، خمسة موديلات على 100 ملف PHP من WordPress 4.0. وكان المطلوب تحديث الملفات إلى PHP 8.3 دون أن يتغير سلوكها. والباحثون هم Afridi Mahmud وAbid Hasan Khondaker وSadif Ahmed وMd Nafiu Rahman وRifat Shahriyar.

قبل أي تعديل، كان 83 ملفًا من الملفات الأصلية يجتاز كل الاختبارات. وبعد أفضل موديل صار العدد 59. أي أن التحديث نفسه كسر عملًا كان يعمل. وكسر كل موديل بين 32 و51 ملفًا سليمًا، ولم يُصلح أكثر من 10. أما أداة Rector، وهي أداة تحديث قائمة على قواعد ثابتة لا على موديل، فكسرت 7 ملفات وأصلحت 6.

والرقم الذي يفسّر النتيجة أن 37 ملاحظة فقط، أي 7%، كانت تحتاج فعلًا إلى تغيير كي تعمل على PHP 8.3. وفي الملفات السليمة التي لم تكن تحتاج إلى شيء، كسرت الموديلات بين 36% و60% منها، بينما كسرت Rector نسبة 8%. وكان أكثر أنواع الفشل شيوعًا أن الملف لا يُحمَّل أصلًا، وغالبًا بسبب type declarations ترفضها PHP نفسها.

ولاحظت الورقة أن الموديل صاحب أعلى درجة في «التحديث» لم يكن الأكثر أمانًا. فالدرجة تقيس مدى حداثة شكل الكود، لا بقاءه على ما كان يفعله. ولذلك تقترح الورقة قياس أي تحديث آلي مقارنةً بخيار «عدم فعل شيء»، لأنه أحيانًا يكون أفضل الخيارات المتاحة.

ويعني ذلك الكثير لسوق فيها قدر كبير من كود PHP وWordPress القديم، كما هو حال كثير من المشاريع في المنطقة العربية. فتسليم ترقية كاملة إلى agent قد يعطي كودًا يبدو أحدث ويعمل أقل.

وللمنهج حدود معلنة: رأت الموديلات ملفًا واحدًا في كل مرة، دون سياق المشروع ودون تشغيل فعلي. وجرى التقييم بـ 630 اختبار سلوك مخفيًا و511 ملاحظة من Rector.

## المصادر

- [الورقة على arXiv](https://arxiv.org/abs/2610.40269)
- [موقع أداة Rector](https://getrector.com/)