التحول إلى PHP 8.x في أربع خطوات - مقابلة مع جولييت ريندرز فولمر

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

في هذه المقالة ، سنتناول هذه الأسئلة (والمزيد) وننظر إلى العناصر التي ينطوي عليها الانتقال السلس إلى PHP 8.x لموقع WordPress أو المكون الإضافي أو القالب ، بما في ذلك خارطة الطريق.

سنفعل ذلك بناءً على مقابلة أجريناها مع خبيرة PHP Juliette Reinders Folmer. كرست معظم حياتها اليومية للبرمجة وكل ما يدور حولها ، مع التركيز بشكل أساسي على المشاريع مفتوحة المصدر ، بما في ذلك WordPress.

هل أنت مستعد لإجراء التبديل بسلاسة أيضًا؟ هل تشعر بالفضول بشأن خطتنا خطوة بخطوة؟ ثم دعونا نتعمق في الأمر!

PHP 8.x - ما الذي تغير

للحصول على نظرة عامة على التغييرات ، نوصي بالمقالات أدناه:

• ملاحظات إصدار PHP 8.0 و PHP 8.1
• دليل الترحيل لـ PHP 8.0 و PHP 8.1
• WordPress و PHP 8.0 والوضع الحالي
• الجديد في PHP 8.0 و PHP 8.1

بعد قراءة هذه المقالات ، سيتم إطلاعك بالكامل على ما تم تغييره في PHP 8.x وما عليك القيام به لتشغيل مشاريع PHP الخاصة بك دون أي مشاكل.

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

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

التحول إلى PHP 8.x: كيف تبدأ

يبدو التحول إلى PHP 8.x بسيطًا ، وهو كذلك من الناحية الفنية. يسمح لك العديد من المضيفين بتحديد إصدار PHP الذي تريد استخدامه لموقع الويب الخاص بك في لوحة الإدارة. في Kinsta ، يمكن تبديل إصدار PHP بنقرة واحدة في لوحة معلومات MyKinsta.

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

• إذا كنت قد أنشأت موقع WordPress الخاص بك باستخدام سمات ومكونات إضافية قياسية ، دون أن يكون لديك الكثير من المعرفة بلغة PHP ، فقم بتعيين مطور أو وكالة للتحقق مما إذا كان موقعك مناسبًا للتشغيل على PHP 8.x. هل تبحث عن طرف ثالث يمكنه مساعدتك في ذلك؟ ثم انظر إلى صفحة الشركاء الخاصة بنا التي تسرد العديد من الشركات الموثوقة التي يمكنها مساعدتك.
• إذا تم إنشاء موقع WordPress الخاص بك بواسطة جهة خارجية أو مطور أو وكالة ، فاتصل بهم للاستفسار عما إذا كان يمكن تشغيل موقعك على PHP 8.x.
• إذا كنت قد أنشأت موقع WordPress الخاص بك - باستخدام المظهر المخصص الخاص بك ، على سبيل المثال ، أو المكونات الإضافية المطورة ذاتيًا - فلدينا خريطة طريق لك أدناه.

إذا كان موقعك يندرج ضمن إحدى الفئتين الأوليين ، فنحن ندعوك بالتأكيد لقراءة بقية المقالة ، لكننا لا نوصيك ببدء اختبار توافق موقعك مع PHP 8 بنفسك. اتركها للمختصين.

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

في بيئة التدريج ، يمكنك تنشيط PHP 8.x ومعرفة ما إذا كان هذا التحديث يعمل بشكل جيد مع موقعك. من الممكن أيضًا العمل مع نسخة محلية من موقعك. باستخدام أداة التطوير DevKinsta المجانية الخاصة بنا ، يمكنك بسهولة استيراد موقعك من لوحة معلومات MyKinsta ، وبعد ذلك يمكنك تغيير إصدار PHP إلى 8.0 أو 8.1.

إذا كنت لا ترى أي مشاكل في بيئة التدريج ، فهذا لا يعني بالضرورة عدم وجود أي مشاكل في الواقع. ستخبرك خارطة الطريق أدناه بالسبب.

اختبار توافق PHP 8.x: خريطة الطريق

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

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

تمت مناقشة الأنواع التالية من الاختبارات في منشور المدونة هذا:

لنلقِ نظرة عن كثب على الأنواع المختلفة من الاختبارات التي يمكننا إجراؤها.

التحليل الثابت (أو الاختبار الثابت)

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

أدوات التحليل الساكن

يمكنك إجراء تحليل ثابت باستخدام أدوات متنوعة ، مثل:

• التوافق PHPC
• مزمور
• PHPStan

في وقت كتابة هذا التقرير ، لم يتم دعم جميع اختبارات PHP 8.1 في أحدث إصدار من توافق PHPC. يمكن أن تكون فحوصات PHP 8.1 في إصدار التطوير ، لذا تأكد من استخدامها (في الوقت الحالي) عند استخدام توافق PHPC لتحليل مشروعك ومعرفة الأخطاء / التوصيات الموجودة.

سيتم إصدار اختبارات PHP 8.1 قريبًا في إصدار رئيسي جديد. إذا كنت تريد أن تظل على اطلاع دائم بهذا الأمر ، وكان لديك حساب GitHub ، فافتح مستودع GitHub الخاص بتوافق PHPC وانتقل إلى Watch -> Custom -> Releases ، حيث يمكنك اختيار أن يتم إعلامك عند إصدار إصدار جديد.

يعد توافق PHPC ، الذي يختبر التوافق فقط لإصدار معين (أو مجموعة من الإصدارات) من PHP ، سهل الإعداد. تحصل على أفضل النتائج إذا قمت بتشغيل testVersion - على سبيل المثال ، 8.0+ (8.0 وما فوق) - ضمن توافق PHPC.

يجب أن تبحث عن الوظائف المهملة أو المحذوفة ، والقيم الافتراضية المتغيرة لمعلمات الوظيفة ، سواء كنت تستخدم concat بدون أقواس ، وما إذا كنت ستستخدم مطابقة كاسم وظيفة (حيث تم حجزها منذ PHP 8.0) ، إلخ.

يُعد Psalm و PHPStan إضافات جيدة ويمكنهما مساعدتك عن طريق إجراء فحوصات إضافية تتعلق بأنواع المتغيرات. الجانب السلبي لهذه الأدوات هو أن الأمر يتطلب الكثير من التكوين للحصول على تقارير عن PHP 8.0 و 8.1. حتى لو كانت ناجحة ، يمكنك توقع العديد من الإيجابيات الخاطئة. الإيجابيات الكاذبة هي الإشعارات التي يتم تقديمها بشكل خاطئ بسبب قيود التحليل الثابت.

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

ملخص:

• قم بإجراء تحليل ثابت باستخدام التوافق PHPC ، Psalm ، PHPStan
• حل جميع المشاكل المشروعة

وحدة التجارب

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

لا يكفي إجراء اختبارات الوحدة وحدها بالطبع. هم أيضا بحاجة إلى أن تدار. من الأفضل أتمتة اختبارات الوحدة باستخدام أدوات CI (التكامل المستمر) مثل Jenkins أو GitHub Actions أو Travis.

دعم إصدارات متعددة من PHP

بصفتك منشئ المكونات الإضافية ، إذا كنت تريد دعم العديد من إصدارات PHP ، فتأكد من تشغيل الاختبارات في CI مع جميع إصدارات PHP التي تدعمها.

بالطبع ، يمكنك أيضًا دعم الإصدارات الأحدث فقط ، فالاختيار متروك لك تمامًا.

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

للتغلب على هذا ، يمكنك استخدام PHPUnit Polyfills (كتبته جولييت وبرعاية Yoast). يتيح لك ذلك كتابة اختبارات غير مدعومة رسميًا لـ PHPUnit 9 (وبالتالي يمكن تشغيلها على PHP 8.x). ثم تجعل Polyfills اختباراتك تعمل في PHPUnit 4.x حتى 9.x ومع PHP 5.4 إلى PHP 8.1 (اعتبارًا من الآن). [/ إشعار]

الآن وبعد إجراء الاختبارات ، فإن الخطوة التالية هي التأكد من إصلاح المشكلات الموجودة في الاختبارات.

مدونة التغطية

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

عند القيام بذلك ، انتبه إلى تغطية التعليمات البرمجية لاختباراتك:

• لنفترض أن لديك وظيفة A وكتبت اختبارًا لها ، ووظيفة A وظائف استدعاء B و C و D كجزء من المنطق في الوظيفة.
• تمت كتابة اختبار الوظيفة A لاختبار منطق الوظيفة A ، ولكنه سيستدعي أيضًا الوظائف B و C و D أثناء الاختبار. بالنسبة للوظائف B و C و D ، فإنك عادةً ما تختبر فقط "المسار السعيد" - الموقف الذي يسير فيه كل شيء على ما يرام - وبالتالي ، لم يتم اختبار هذه الوظائف بشكل كامل بعد ، على الرغم من أن (جزءًا من) الكود في هذه الوظائف هو تم تنفيذه أثناء اختبار الوظيفة A.
• لكل اختبار من اختباراتك ، حدد الرمز الذي يتم اختباره على وجه التحديد. يمكنك القيام بذلك عن طريق إعطاء كل اختبارcovers بهذه الطريقة ، لا يتم "احتساب" B و C و D في حساب تغطية الكود ، مما يسمح لك بمعرفة أي جزء من الكود تغطيه الاختبارات.

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

"أثناء الاختبار ، تحتاج إلى التأكد من أن الوظيفة تقوم بما ينبغي أن تفعله ، ولكن أيضًا من أن الوظيفة لا تفعل ما لا ينبغي لها". - جولييت ريندرز فولمر انقر للتغريد

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

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

PHP تزداد صرامة

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

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

في كثير من الحالات ، يظل الاختبار هو الطريقة الوحيدة الموثوقة لتحديد ما يجب تعديله لدعم إصدار جديد.

يمكن اختبار الوحدة باستخدام أدوات مختلفة ، بما في ذلك:

• وحدة PHP
• سخرية
• بهات ،
• ستوري بلاير

العديد من هذه الأدوات مبنية على PHPUnit أو بالاشتراك معها.

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

اختبار التكامل

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

لذلك ، عندما تختبر رمز مكون إضافي أو سمة في سياق WordPress وتستخدم إصدارًا حقيقيًا ، فهذه ، حسب التعريف ، اختبارات تكامل.

WP Test Utils (تمت كتابته مرة أخرى بواسطة Juliette وبرعاية Yoast) هي أداة ممتازة لاختبار التكامل. يوفر WP Test Utils أدوات لكتابة اختبارات التكامل والوحدة ، حيث يتم "الاستهزاء" بـ WordPress باستخدام Brainmonkey and Mockery ، حيث تكون وظائف WordPress شائعة الاستخدام "مزيفة" بحيث تختبر الكود الخاص بك وليس رمز WordPress.

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

على سبيل المثال ، يستخدم WordPress 5.6 إلى 5.8 PHPUnit من 5 إلى 7 لاختبار PHP 5.6 إلى PHP 8.0 ، ولكن اعتبارًا من WordPress 5.9 ، يستخدم WordPress نفسه أيضًا PHPUnit Polyfills لدعم أوسع. يعمل WP Test Utils كجسر للتغلب على كل هذه الاختلافات.

هل تريد معرفة المزيد حول كيفية إجراء اختبارات التكامل ضد إصدارات مختلفة متعددة من WordPress ، بما في ذلك WordPress 5.9 وما فوق؟ ثم اقرأ عنها على موقع WordPress.

الاختبار اليدوي

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

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

على سبيل المثال ، موقع WordPress به 3 مكونات إضافية (A و B و C). من المحتمل أن يقوم المكون الإضافي B ، على سبيل المثال ، بإرجاع نوع متغير غير صحيح عبر مرشح ، والذي يريد المكون الإضافي C ، باستخدام نفس الفلتر ، العمل معه. يمكن أن يتسبب هذا بعد ذلك في حدوث خطأ فادح لأن النوع لم يعد هو المتوقع. ثم يُنظر إلى البرنامج المساعد C على أنه المذنب لرسالة الخطأ ، على الرغم من أن المكون الإضافي B هو الجاني الحقيقي.

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

مع هذا النوع من المشاكل ، عادةً ما يرى مالك الموقع رسالة تفيد بحدوث خطأ في آخر رمز تم تنفيذه (في هذه الحالة ، من المكون الإضافي C) ، على الرغم من أن المكون الإضافي C ليس بالضرورة سبب المشكلة.

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

توفر الاختبار للمكونات الإضافية المستخدمة

للمطورين وفرق التطوير: قبول الكود فقط عندما تكون الاختبارات متاحة. وبهذه الطريقة ، تتأكد من أنه يلزم إجراء اختبارات يدوية أقل ، مما يوفر لك الكثير من الوقت.

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

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

"كن لطيفًا مع نفسك في المستقبل ، من فضلك ؛-)" - جولييت ريندرز فولمر انقر للتغريد

دور مضيفي WordPress و PHP 8.x

بالنسبة لمالك الموقع العادي ، فإن التوجيه من مضيفك مرغوب فيه للغاية. ضع في اعتبارك ما يلي:

• التوثيق والتحديثات للعملاء بأن WordPress Core و / أو المكونات الإضافية و / أو السمات (في بعض الحالات) ليست متوافقة مع PHP عبر الإصدارات
• خيارات للاختبار (مثل العمل مع بيئة مرحلية)
• طرق الإبلاغ عن الخطأ والاتصال بالدعم

يفيد هذا أيضًا مضيف الويب ، حيث غالبًا ما يتصل مالكو المواقع بالمضيف للحصول على المساعدة عند ظهور المشاكل. في حالة التبديل إلى PHP 8.0 أو 8.1 ، يكون مالك الموقع مسؤولاً عن المشكلات المحتملة ، وكلما زادت المعلومات التي يتعين على المالك الاستعداد لها بشكل صحيح ، كان ذلك أفضل.

إن إتاحة PHP 8.0 أو 8.1 للعملاء كمضيف ويب هو شيء واحد ، ولكن عند القيام بذلك ، يجب أن يتأكدوا من خلق الوعي بين العملاء حتى يدركوا أن المشاكل قد تظهر. يوصى باختبار موقعك في بيئة مرحلية بإصدار مختلف عن الإصدار المباشر. (تحديد إصدارات PHP متاح افتراضيًا في Kinsta.)

الحد الأدنى من إصدار PHP لـ WordPress

أكثر من 15٪ من مواقع الويب تستخدم حاليًا إصدار PHP 7.0 أو أقل. يمكن ملاحظة ذلك في إحصائيات WordPress الرسمية. حوالي 83٪ من مواقع WordPress تستخدم حاليًا إصدار PHP 7.4 أو أقل. يرجى ملاحظة أن أي شيء أقل من أو يساوي الإصدار 7.4 لم يعد مدعومًا حاليًا بواسطة PHP. يمكن أن يؤدي استخدام إصدارات منتهية الصلاحية من PHP إلى حدوث مشكلات لأن التحديثات الأمنية لم تعد تصدر.

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

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

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

ملخص

للتبديل إلى PHP 8.0 أو أعلى لموقع الويب الخاص بك ، هناك العديد من الخطوات التي يجب عليك أنت أو المطور الخاص بك تنفيذها. تتضمن الخطوات المهمة ما يلي:

• التحليل الساكن
• وحدة التجارب
• اختبار التكامل
• الاختبار اليدوي

عند التبديل إلى PHP 8.x ، تأكد من اختبار كل شيء بشكل صحيح. هذه هي الطريقة الوحيدة لضمان تشغيل موقعك بشكل صحيح وسريع وآمن على إصدار PHP أحدث.

نشكر جولييت جزيل الشكر على مشاركتها في هذا المقال وعلى كل عملها على الأدوات المذكورة!

صورة لجولييت التقطت بواسطة جيب مورس واستخدمت بإذن.