PHP 8.2: ماذا يعني ذلك بالنسبة إلى WordPress والإضافات والمطورين؟

نشرت: 2022-12-14

ظهر PHP 8.2.0 لأول مرة في 8 ديسمبر 2022. كتحديث رئيسي ، فإنه يجلب تحسينات في الأداء ، وبناء جملة أبسط ، وأمان أكبر من النوع مع أنواع فارغة وخطأ وصحيحة كأنواع قائمة بذاتها. أحد أكبر التغييرات التي من المحتمل أن تتحدى مطوري WordPress هو إدخال فئات للقراءة فقط ، والتي لا تسمح بالخصائص الديناميكية.

يتم إهمال الخصائص الديناميكية وسوف ينتج عنها خطأ فادح في PHP 9 أو ربما PHP 10. في حين أنه من المحتمل أن يكون مؤلمًا - خاصة بالنسبة لـ WordPress core - يعد الإهمال ميزة أساسية وهدية للمطورين من PHP.

دعنا نلقي نظرة على التطور الأخير لـ PHP وكذلك كيف يحافظ مطورو WordPress على التوافق مع الإصدارات السابقة مع الاستفادة من الميزات الجديدة عندما يستفيد المستخدمون النهائيون منها أكثر من غيرهم.

مواكبة تطور PHP في WordPress

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

على عكس WooCommerce ، الذي يتطلب حدًا أدنى من PHP 7.4 ، يوصي WordPress الأساسي حاليًا فقط باستخدام PHP 7.4 أو أعلى. وهي "تعمل أيضًا مع" PHP 5.6.20 ، والتي وصلت إلى تاريخ انتهاء عمرها في نهاية عام 2018. ويلاحظ مشروع WordPress ذلك ويحذر من أن استخدام إصدارات PHP غير المدعومة "قد يعرض موقعك لثغرات أمنية". (متطلبات WordPress.org)

لحسن الحظ ، فقط 5.1٪ من مواقع WordPress تستخدم PHP 5.6 حاليًا ، و 2٪ فقط تستخدم إصدارًا أقدم. 20٪ يستخدمون PHP 7.0 إلى 7.3 ، وأكبر مجموعة (56.7٪) تستخدم PHP 7.4. (إحصائيات WordPress.org)

لسوء الحظ ، بلغ PHP 7.4 تاريخ EOL الخاص به في نهاية نوفمبر 2022. يتبقى لـ PHP 8.0 أقل من عام لدعمه الأمني ​​الرسمي خلال معظم عام 2023. الإصدار الحالي والمدعوم بشكل نشط ، PHP 8.1 ، سيتقادم في النهاية من 2024. سيحصل PHP 8.2 ، الذي حصل للتو على أول إصدار مستقر له ، على دعم أمني حتى ديسمبر 2025.

هذه دورة إصدار سريعة ، وليس من المستغرب أن يكافح نظام WordPress البيئي لمواكبة ذلك. مع تشغيل أكثر من نصف الويب على WordPress ، فهي سفينة كبيرة لا يمكنها الدوران بسرعة. إنه عمل موازنة أكثر بكثير من سباق نحو حافة النزيف. الانتقال إلى PHP 8 يحمل العديد من الفوائد ، مع ميزات كبيرة لتحسين الأداء مثل تجميع PHP في وقت التشغيل (JIT) في وقت التشغيل لتنفيذ أسرع مع استخدام أقل للذاكرة.

المفاضلة بين التوافق العكسي والاستقرار والتفكير المستقبلي والابتكار

لطالما شكلت المفاضلة بين تقديم الطعام لأكبر عدد ممكن من المستخدمين والحفاظ على العملة باستخدام PHP معضلة لمطوري WordPress والمضيفين وشركات المنتجات. تواجه الوكالات والمستقلون الذين لديهم عملاء على المدى الطويل والمواقع القديمة نفس المشكلة: قد يؤدي تحديث الحد الأدنى من المتطلبات إلى إجبار العملاء الحاليين على إجراء تغييرات كبيرة على مواقعهم أو رؤيتها معطلة.

من ناحية أخرى ، تتمثل فوائد البقاء على اطلاع دائم مع PHP في تحسين الأمان والأداء وأحدث مفاهيم وقدرات البرمجة للمطورين. من ناحية أخرى ، فإن الميزة الرئيسية لتأخير الحد الأدنى المطلوب من PHP هي وجود قاعدة عملاء سعيدة (وإن كانت راضية). إنها حالة "ادفع لي الآن أو ادفع لي لاحقًا". في مرحلة ما ، عليك أن تمزق العصابة.

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

يتضمن تحديد أولويات التوافق مع الإصدارات السابقة أعمال صيانة عالية أيضًا. يعد دعم قاعدة مستخدمين كبيرة جدًا ومتنوعة أمرًا رائعًا للمستخدم النهائي ، ولكنه يعني أنه يتعين على المطورين الحفاظ على عمل التعليمات البرمجية الخاصة بهم مع العديد من البيئات المختلفة. "أحب دعم إصدارات PHP القديمة حيث تتم إضافة ميزات جديدة" - قال أي مطور على الإطلاق!

إنها ليست مجرد لغة PHP القديمة التي يجب أن تقلق بشأنها - إنها أيضًا قواعد بيانات قديمة وعشرات الأشكال الأخرى في حزمة WordPress. تظهر حالات Edge وتربك حتى الخبراء عندما يكون هناك مجموعة واسعة من بيئات خادم WordPress ذات العناصر المتقادمة.

أفضل وقت لرفع الحد الأدنى من متطلبات PHP

يعد إصدار iThemes Security Pro 7.2 مثالاً جيدًا على رفع الحد الأدنى لمتطلبات PHP لمنتج WordPress لتقديم كل من الابتكار والاستقرار للعملاء الحاليين.

اعتبارًا من الإصدار 7.2 ، تطلب iThemes Security Pro إصدار PHP 7.3 أو أعلى ويدعم ما يصل إلى 8.1. تم اتخاذ قرار تحديث متطلبات PHP الخاصة بـ iThemes Security Pro لتطبيق إطار عمل WebAuthn. تطلب التنفيذ مكتبات تحتاج PHP 7.3+ لإدارة التشفير والمفاتيح العامة. تعد ميزات 2FA ، ومفتاح المرور ، وتسجيل الدخول البيومتري المقدمة في iThemes Security Pro 7.2 نتيجة مباشرة لهذا القرار. في الوقت الذي يتم فيه كسر كلمات المرور الواضحة ، قام فريق iThemes Security بإحضار تسجيل الدخول بدون كلمة مرور إلى WordPress لأول مرة كتجربة مصادقة المستخدم الأساسية.

كان من الممكن بناء هذه الميزات عن طريق إعادة كتابة مكتبات WebAuthn للتوافق مع الإصدارات القديمة من PHP. بالطبع ، سيكون هذا المزيد من العمل وإنشاء رمز إضافي للمحافظة عليه. كانت الدورة الأكثر حكمة هي مواكبة مجتمع PHP بوتيرة معتدلة من خلال اعتماد التبعيات التي تتطلب PHP 7.3 أو أعلى. كان معظم المستخدمين هناك بالفعل. لهذا السبب قرر فريق تطوير iThemes Security رفع الحد الأدنى من متطلبات PHP للمستخدمين الجدد والحاليين.

بالنسبة إلى منتجات WordPress التي تم استثمارها بكثافة في محرر كتلة Gutenberg ، مثل GiveWP ، يمكن أن تكون إدارة التغيير أكثر صعوبة. قد يكون الاستقرار ومعدل التغيير البطيء في نواة WordPress محبطين لمطوري PHP الخلفيين ، لكنه يسمح لمطوري JavaScript / React للواجهة الأمامية بدفع النظام الأساسي إلى الأمام.

يشير Jason Adams ، مدير التطوير في GiveWP ، إلى أنه ليس من الضروري أن يكونوا متوافقين مع الإصدارات السابقة لأنهم يستطيعون ترحيل المستخدمين عبر الإصدارات مع تطور محرر الموقع. ومع ذلك ، علق قائلاً: "لا يوجد شيء مثل الترحيل لـ PHP". في النهاية ، سيتعين عليهم التكيف مع بنية PHP 9 وبعيدًا عن الميزات التي تم إيقافها مؤخرًا في PHP 8.2.

لا يوجد "وقت مناسب" واحد لكل منتج عبر نظام WordPress البيئي لتحديث الحد الأدنى من متطلبات PHP. قال لي آدامز: "إنها ليست مشكلة يمكنك حلها فلسفيًا". يعتمد الأمر حقًا على استدعاء الحكم بناءً على عدد المستخدمين الذين سيتأثرون سلبًا بالتغيير. إذا كان 90٪ أو أكثر على PHP 7.2 أو 7.4 ، فإن رفع الحد الأدنى من المتطلبات إلى هذا المستوى يكون قابلاً للتطبيق.

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

تدفع إشعارات الإيقاف التطوير إلى الأمام

طرح WordPress.com للتو PHP 8.2 كخيار لخطط الأعمال والتجارة الإلكترونية الخاصة به مع تنشيط ميزات الاستضافة ، وفي النظام البيئي WordPress.org ، من غير المرجح أن تتعطل التعليمات البرمجية القديمة المصممة جيدًا أو تصبح غير آمنة مع إصدار PHP الرئيسي التالي إطلاق سراح. على الرغم من أن قاعدة الشفرة الأساسية لـ WordPress.org تقدم رسميًا دعمًا "تجريبيًا" فقط لـ PHP 8.0 ، إلا أنها تعمل بشكل جيد مع أحدث إصدارات PHP ، وكذلك الإضافات المدعومة جيدًا. لن يلقوا أخطاء فادحة أو تحليل. من المفترض ألا ترى الكثير من التحذيرات عند تشغيل تصحيح الأخطاء. قد ترى الكثير من إشعارات الوظائف المهملة ، وهي ليست أخطاء - حتى الآن.

إن الإحباطات الناتجة عن دورة إصدار PHP السريعة لها علاقة كبيرة بالمطورين الذين يتورطون في الأعشاب التي تعيد بناء كودهم ويلعبون اللحاق بالجوانب المهملة في PHP. قد يترك هذا العمل المهم لهم وقتًا أقل للاستكشاف والابتكار بمفاهيم وإمكانيات جديدة يوفرها أحدث إصدار من PHP.

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

تشير إشعارات الإيقاف إلى الأشياء التي تعمل الآن ولكنها ستتوقف في الإصدارات المستقبلية من PHP. هذا مفيد لك إذا كنت مطورًا ، كما يشرح Brent Roose. إذا اهتم المطورون بهذه الإشعارات ، فسيكون لديهم متسع من الوقت للتعرف على أي رمز تم إيقافه. ولا ينبغي أن يكون مانعًا لتحديثات الإصدار الطفيفة.

يقول تيموثي جاكوبس ، المطور الرئيسي في iThemes Security و WordPress Core Committer ، إنه من الجيد أن يكون لديك تحذيرات من الإهمال. إنهم يدفعون المطورين إلى الأمام لتبني رمز "أكثر صحة" و "أقل هشاشة" والذي سيكون على نحو متزايد آمنًا ، وفعالاً ، ومقاومًا للخطأ ، وقدرة بشكل أفضل على التعامل مع الحالات المتطورة. في طريقة العرض هذه ، فإن إشعارات E_DEPRECATED التي تملأ سجل الأخطاء الخاص بك هي "مثل نظام الإنذار المبكر بأن الأشياء ستتعطل في المستقبل ، لكنها لم يتم كسرها الآن."

العمل بدون الخصائص الديناميكية بعد PHP 8.2

إن الأساس المنطقي لنيكيتا بوبوف للتخلص التدريجي من الخصائص الديناميكية في PHP 9 هو مثال جيد على الدافع التطوري لـ PHP نحو كود أكثر مرونة واتفاقيات البرمجة:

الدافع لهذا التغيير ذو شقين: لمنع الأخطاء (بسبب الأخطاء المطبعية أو إعادة التسمية) في الحالة الشائعة ، وجعل الاستخدامات المتعمدة صريحة. تكمن المشكلة الأساسية في أن القراءة من خاصية غير موجودة تُصدر تشخيصًا يجعل المشكلة واضحة على الفور ، في حين أن الكتابة إلى خاصية غير موجودة تكون صامتة تمامًا. لا تعطي PHP أي إشارة على الإطلاق إلى أن المبرمج قد ارتكب خطأ.

يعد فيديو Brent Roose الذي يبلغ مدته دقيقتين حول التطور من PHP 5.6 إلى 8.2 توضيحًا مرئيًا رائعًا وبسيطًا لمدى تقدم PHP من 2014 إلى الوقت الحاضر. باستخدام مثال كائن بسيط لنقل البيانات ، يوضح Roose كيف يتقلص كود PHP 5.6 بشكل كبير إلى كتلة برمجية أبسط وأقل حجمًا وأكثر أناقة بشكل عام في الطريق إلى PHP 8.2.

كما يشير Roose في نصائحه للتعامل مع الخصائص الديناميكية (التي تم إهمالها في PHP 8.2) ، يجب أن يكون لدى المطورين الكثير من المدرج لتحديث التعليمات البرمجية الحالية قبل أن تتحول تحذيرات الإهمال إلى أخطاء فادحة. ومع ذلك ، سوف يتضاءل هذا المدرج بسرعة ، ويعتبر WordPress حالة خاصة. لدى Tonya Mork اقتراح مقبول في Trac للتعامل مع إهمال الخصائص الديناميكية غير المعروفة في WordPress core. تشعر هي وجولييت رايندرز فولمر بالقلق من أن مطوري WordPress لن يكون لديهم الوقت الكافي لإعادة بناء الكود الخاص بهم ، ناهيك عن التحديات الخاصة للحفاظ على التوافق مع مشروع عمره عشرين عامًا. كان مورك ورينديرس فولمر وسيرجي بيريوكوف الأبطال المجهولين إلى حد كبير في هذه المهمة الشاقة.

في مناقشتهم للخصائص الديناميكية والطرق السحرية في PHP 8.2 ، أشار Mork و Reinders Folmer إلى أن جذور WordPress في PHP 3 و 4 تبقيها في عالم برمجة إجرائي قوي بينما تستمر PHP في التقدم كلغة موجهة للكائنات. يحتاج المطورون الأساسيون إلى اكتشاف طريقة للحفاظ على سلوك الكود القديم في PHP اليوم دون كسر التوافق مع الإصدارات السابقة "ولا يزالون يجعلون الكود أفضل وأكثر أمانًا ويخفف من إهمال الخصائص الديناميكية لـ PHP 8.2" ، على حد تعبير Reinders Folmer. "نحن في الواقع نجعل حياتنا صعبة للغاية مع قاعدة عدم [التوافق مع الإصدارات السابقة] الخاصة بـ [WordPress]" ، تلاحظ في الفيديو.

يجيب مورك: "هناك سبب وجيه لذلك" - "إنه للمستخدمين. يثق المستخدمون في قدرتهم على الضغط على هذا الزر والترقية ، وأننا فكرنا في التوافق مع الإصدارات السابقة ، وأننا أعطيناه الأولوية. إنه حجر الزاوية بالنسبة لنا ... حتى يتمتع المستخدمون بالثقة للترقية. "

كل التطوير هو صيانة ...

إنه تحدٍ فريد لمحاولة نسخ PHP "الحديثة" للخلف للعمل مع الإصدارين الرئيسيين السابقين من PHP من أجل الحفاظ على التوافق مع الإصدارات السابقة في WordPress core. يتمتع مطورو المكونات الإضافية بمهمة أسهل بكثير تتمثل في تحديث التعليمات البرمجية الخاصة بهم بطرق يمكنها الاستفادة من الميزات الجديدة ، مثل فئات القراءة فقط في PHP 8.2 وإيقاف الخصائص الديناميكية. الكثير من هذا العمل هو إلى حد كبير شكل من أشكال الصيانة أيضًا.

من الناحية المعمارية ، فإن التغييرات PHP 8+ تجلب التركيز على مفاهيم البرمجة مثل الثبات. هياكل البيانات غير القابلة للتغيير "لا تعمل بطبيعتها على إصلاح مشكلات الأمان" ، ولكنها تساعد بالفعل كود المطورين على أن تكون أقل عرضة للخطأ وأكثر صحة ، وفقًا لجاكوبس:

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

أفضل سبب للحفاظ على الكود وفقًا لمعيار إصدارات PHP المدعومة بشكل نشط هو تقليل مخاطر الأمان. يوفر PHP 8.2 وسائل راحة مفيدة و "حواجز حماية" من وجهة نظر آدامز ولكن القليل من شأنه أن يثير المبرمجين أو يُنظر إليه على أنه يغير قواعد اللعبة. قد يكون شيء مثل السمة #[\SensitiveParameter] أكثر أهمية من الناحية العملية لأنه يسمح بتصفية البيانات الحساسة من تتبعات المكدس التي تنتقل غالبًا إلى خدمات الجهات الخارجية. تم تقديم السمات في PHP 8 ، وهي عبارة عن اختيار آدمز لآخر ابتكار لفت انتباهه لتمكين شيء لم يكن بإمكانك فعله سابقًا: "وصف شيئًا ما [مثل الفئات والمتغيرات والأساليب وما إلى ذلك] من منظور ميتا."

الاستفادة من الميزات الجديدة في PHP 8.0 إلى 8.2 والإصدارات المستقبلية هو المكان الذي يمكن أن يتألق فيه إبداع المطورين ، ولكن ببساطة دعم هذه الإصدارات ، بحيث لا تنفصل المكونات الإضافية ونواة WordPress عنها ، يعد أمرًا عمليًا وحيويًا.

... وكل أعمال الصيانة فن

لدى جيف أتوود منشور مدونة قديم ولكنه رائع بعنوان "الفن النبيل لبرمجة الصيانة" قرأته مؤخرًا ، وذلك بفضل النشرة الإخبارية لـ Kale Davis's Hacker. كتب أتوود: "يُنظر إلى برمجة الصيانة على نطاق واسع على أنها أعمال تنظيف". ذكرني هذا بالفنانة ميريل لادرمان يوكليس ، التي لطالما صدمتني "بيان الصيانة الفني" الخاص بها باعتباره وثيق الصلة بالبرمجة وتطوير الويب:

نظامان أساسيان: التطوير والصيانة. حموضة كل ثورة: بعد الثورة ، من الذي سيجمع القمامة صباح الاثنين؟ [...] أنظمة التطوير هي أنظمة ردود فعل جزئية مع مجال كبير للتغيير. أنظمة الصيانة هي أنظمة ردود فعل مباشرة مع مساحة صغيرة للتغيير.

كانت Laderman Ukeles فنانة شابة وأمًا جديدة في عام 1969 عندما كتبت البيان وأعلنت أن الصيانة هي الفن. لقد شعرت بالإحباط من كيفية تقسيم الأعمال الفنية المتطورة والعمل رفيع المستوى عن العمل الذي يجعلها ممكنة: الأبوة والأمومة ، وتعليم المهارات الفنية والتقاليد ، أو مجرد تقديم عرض فني. قامت بعمل معرض لا يُنسى حول نفسها بصفتها بواب متحف. ثم أمضت معظم حياتها المهنية (المستمرة) كفنانة مقيمة بإدارة الصرف الصحي في مدينة نيويورك. كان أول مشروع لها في هذا الدور هو تقديم الشكر شخصيًا لجميع عمال الصرف الصحي البالغ عددهم 8500 "لإبقاء نيويورك على قيد الحياة".

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

في محادثة مع Andy Hunt ، قال Dave Thomas ، "كل البرمجة هي برمجة صيانة لأنك نادرًا ما تكتب كودًا أصليًا. …. تقضي معظم وقتك في وضع الصيانة. لذا يمكنك أيضًا أن تقضم الرصاصة وتقول ، "أنا أواصل العمل من اليوم الأول." يجب أن تنطبق التخصصات التي تنطبق على الصيانة على الصعيد العالمي. " وافق هانت ، "إنها أول 10 دقائق فقط يكون فيها الرمز الأصلي عندما تكتبه في المرة الأولى. هذا هو."

يميل أتوود في النهاية نحو وجهة النظر هذه ولكنه يعكس وجهة نظر مطور WordPress الشائعة التي سمعتها من جيسون آدامز وتيموثي جاكوبس. الفن الخاص لتطوير / صيانة ووردبريس؟

"إنه عمل متوازن."

أفضل مكون إضافي لأمن WordPress لتأمين وحماية WordPress الآن بخصم 35٪!

يعمل WordPress حاليًا على تشغيل أكثر من 40 ٪ من جميع مواقع الويب ، لذلك أصبح هدفًا سهلاً للمتسللين ذوي النوايا الخبيثة. يزيل المكون الإضافي iThemes Security Pro التخمين من أمان WordPress لتسهيل حماية موقع WordPress الخاص بك وحمايته. يشبه الأمر وجود خبير أمان بدوام كامل بين الموظفين الذين يراقبون ويحمون موقع WordPress الخاص بك باستمرار.

وفر 35٪ الآن!