ووكومرس قد تشترط PHP 8.1: ما الذي يُقترح فعلًا
في 8 سبتمبر 2026 نشر فريق الهندسة في ووكومرس على مدونة المطورين اقتراحًا برفع الحد الأدنى لإصدار PHP إلى 8.1 ابتداءً من WooCommerce 11.5، وكان موعدها المستهدف حينها يناير 2027. ويشير تعليق بتاريخ 29 سبتمبر إلى إمكانية تأجيل ذلك إلى WooCommerce 11.6. نحن أمام اقتراح مطروح للنقاش وليس قرارًا منشورًا: فقد يتغير الإصدار المستهدف والجدول الزمني بل والمبدأ نفسه. لم يُعلن أي موعد قاطع للتحول، ولا يخترع هذا المقال موعدًا.
لماذا نهتم والأمر غير محسوم؟ لأن وثائق ووكومرس تذكر اليوم أنها تعمل مع PHP 7.4 وما فوقه، وتوصي بـ PHP 8.3 أو أحدث. الفجوة بين هذا الحد الأدنى وهذه التوصية كبيرة، وفيها تعيش متاجر عملاء كثيرة. وللاقتراح فضل واحد على الأقل: إنه يفرض سؤالًا ينبغي للوكالة أن تطرحه على أي حال، وهو أي إصدار PHP يعمل على كل متجر ومن يقرر تغييره.
ما الذي سيحدث لمتجر بقي على PHP 7.4 أو 8.0
بحسب التدوينة، يتوقف ووردبريس افتراضيًا عن عرض تحديث ووكومرس على المتاجر التي لا تستوفي الشرط الجديد. وتبقى هذه المتاجر على إصدارها الحالي وتواصل تلقي الإصدارات التصحيحية لفرعها. وتوضح التدوينة أيضًا أن PHP لن يُغيَّر نيابةً عن المالك، وأن التثبيتات القائمة لن تُعطَّل.
فالخطر على الوكالة ليس انقطاعًا مفاجئًا بل الصمت: متجر يتوقف عن تلقي الإصدارات الجديدة دون تنبيه، إلى أن يطلب العميل ميزة أو تشترط إضافة بنفسها إصدارًا حديثًا. لا شيء يتحول إلى اللون الأحمر ولا أحد يُنبَّه. ولهذا يفيد جرد الوضع مسبقًا بدل اكتشافه تحت ضغط طلب من العميل.
لماذا تستعد الآن حتى لو أُجّل التغيير أو أُلغي
- PHP 7.4 خارج الدعم أصلًا — تذكّر وثائق ووكومرس بأن PHP 7.4 بلغ نهاية عمره في نوفمبر 2022، كما خرج PHP 8.0 من دعم الأمان. والبقاء عليهما خطر مستقل عن ووكومرس.
- التوصية الرسمية تفوق الحد الأدنى — توصي ووكومرس بـ PHP 8.3 أو أحدث. والاكتفاء بـ 8.1 يعني التحضير لترحيل إضافي في وقت قريب.
- العيّنة ليست محفظتك — تقدّر التدوينة المتاجر المرصودة على PHP 7.4 بنحو 7 % وعلى PHP 8.0 بنحو 2 %، لكن هذا الرصد اختياري (opt-in): رتبة مقدار لا إحصاء شاملًا. والمواقع الموروثة من مزوّد سابق غالبًا ما تكون أكثر تأخرًا من المتوسط.
- الإضافات تحسم غالبًا قبل ووكومرس — تقول التدوينة نفسها إن رفع الحد الأدنى لا يضمن عمل كل إضافة أو قالب أو مقتطف برمجي. ويبقى الاختبار على نسخة ضروريًا.
- جدول تختاره أفضل من جدول يُفرض عليك — توزيع الترحيل متجرًا بعد متجر، بعيدًا عن مواسم البيع الكثيف، أقل كلفة من سلسلة طوارئ.
- العميل يرى الوكالة لا المنصة — إن علق متجر على فرعه فسيتوجه إليك. فالأفضل أن تكون قد نبّهته.
الخطوة الأولى: اعرف إصدار PHP في كل متجر
تُشرح الطريقة العامة لجرد الأسطول في مقال جرد إصدارات PHP ولن نكررها هنا. وبالنسبة إلى متجر ووكومرس تكفي في البداية ثلاث معلومات: إصدار PHP وإصدار WooCommerce وحالة الإضافات.
أوثق مصدر هو صفحة WooCommerce > الحالة (Status)، قسم «بيئة الخادم»، سطر «إصدار PHP»: وهي التي تشير إليها وثائق ووكومرس للتحقق من الحد الأدنى. وعبر SSH يعرض الأمر wp --info إصدار PHP الذي يستخدمه WP-CLI، ويعرض wp eval 'echo PHP_VERSION;' الإصدار الذي ينفذه ووردبريس فعليًا. انتبه: في سطر الأوامر قد يختلف ملف PHP التنفيذي عن ملف خادم الويب، فإذا اختلفا فصفحة الحالة هي المرجع. وفي cPanel يُختار الإصدار لكل نطاق كما يشرح دليل تغيير إصدار PHP لموقع.
سجّل النتيجة في جدول: المتجر، إصدار PHP، إصدار WooCommerce، الإضافات المعطِّلة، الحالة، تاريخ التحويل المخطط. عالج أولًا المتاجر على PHP 7.4 و8.0 ثم الباقي.
ترحيل متجر إلى إصدار PHP أحدث دون كسر الدفع
انسخ احتياطيًا ودوّن نقطة الانطلاق
انسخ الملفات وقاعدة البيانات احتياطيًا ثم تحقق من أن النسخة تُستعاد. دوّن إصدار PHP الحالي للنطاق: فهو طريق العودة.
اجرد الإضافات والقالب
يعطيك
wp plugin list --fields=name,status,version,updateالجرد. لكل إضافة وللقالب دوّن توافق PHP الذي يعلنه المطوّر (حقل «Requires PHP» أو ملاحظات الإصدار). حدّث أولًا ما يمكن تحديثه تحت إصدار PHP الحالي.أنشئ نسخة اختبار
الإصدار نفسه من ووكومرس والإضافات نفسها وقاعدة بيانات منسوخة. ضع بوابة الدفع في وضع الاختبار أو الصندوق الرملي، وأوقف إرسال الرسائل إلى عملاء حقيقيين.
غيّر إصدار PHP على النسخة
استهدف الإصدار الذي توصي به ووكومرس إذا دعمته كل الإضافات، وإلا فأعلى إصدار تقبله. على النسخة وحدها فعّل
define( 'WP_DEBUG_LOG', true );لقراءة الأخطاء دون عرضها على الزوار.أعد تشغيل مسار الطلب
مرّ بنقاط التحقق في الجدول أدناه من السلة إلى التأكيد، بما فيها استرداد المبلغ. أصلح أو استبدل أي إضافة تفشل قبل المتابعة.
حوّل بيئة الإنتاج
اختر وقتًا هادئًا ونبّه العميل وغيّر إصدار PHP للنطاق وأفرغ الذاكرات المؤقتة (الصفحة والكائنات وأوبكود) ثم أعد قراءة WooCommerce > الحالة لتأكيد الإصدار الفعلي.
راقب واحتفظ بطريق العودة
خلال الأيام التالية راقب سجل الأخطاء والطلبات الواردة والرسائل والإجراءات المجدولة. أبقِ الإصدار السابق في متناولك حتى يمر المتجر بدورة كاملة من الطلبات.
نقاط تحقق خاصة بالمتجر
مرّر الجدول أفقيًا
| نقطة التحقق | ما الذي قد ينكسر | كيف تتحقق |
|---|---|---|
| بوابات الدفع | وحدة غير متوافقة مع الإصدار الجديد: رفض الدفع أو صفحة بيضاء عند التأكيد | طلب تجريبي في الصندوق الرملي للبوابة من السلة إلى التأكيد |
| الويب هوك (webhooks) | إشعارات دفع لا تصل أو تُرفض وطلبات تبقى معلّقة | سجل التسليم لدى البوابة ثم حالة الطلب التجريبي |
| المهام المجدولة | إجراءات متكررة تفشل: تذكيرات ومزامنات واشتراكات | WooCommerce > الحالة > الإجراءات المجدولة وقائمة الإخفاقات؛ `wp cron event list` |
| رسائل الطلب | تأكيد العميل أو إشعار المتجر غائب أو مشوّه | طلب تجريبي ثم استلام الرسالتين |
| الإضافات التي تمسّ الطلبات | ميزة مخصصة تقرأ الطلبات أو تعدّلها فتتعطل | إنشاء طلب تجريبي وتعديله واسترداده؛ وإعادة قراءة التوافق المعلن لكل إضافة |
| المسار الكامل | خطأ فادح في خطوة نادرًا ما تُختبر (رمز خصم أو شحن أو حساب عميل) | مسار كامل برمز خصم وطريقتي شحن وحساب جديد |
من يتحمل ماذا: الوكالة والعميل والاستضافة
تحتفظ الوكالة بالعلاقة مع العميل وبالجدول الزمني: فهي تعلن نافذة الصيانة وتحسم الإضافات الواجب استبدالها وتعتمد الاستئناف. وتوفّر الاستضافة البنية التحتية: إصدارات PHP المتاحة واختيار الإصدار موقعًا بموقع وحسابات cPanel معزولة حتى لا يمسّ التحويل في متجر المتاجر الأخرى. وفي ServOrbit يُختار إصدار PHP لكل نطاق؛ ويمكن إضافة الترحيل المُساعَد والإدارة كخيارين، وهما غير مشمولين افتراضيًا.
وقاعدة بسيطة تتجنب سوء الفهم: اكتب قبل أي تدخل من يتحمل ماذا. إضافات العميل المدفوعة والقالب المخصص والاستضافة وبوابة الدفع: لكل منها مسؤول، ولا يمحو ترحيل PHP هذه الحدود.
ترتيب المرور الموصى به
جرّب الإجراء على متجر قليل الحساسية في المحفظة، ثم عالج المتاجر على PHP 7.4 و8.0، ثم الأكثر نشاطًا، وليس أبدًا في موسم بيع كثيف. قِس مدة كل ترحيل: فهذه المدة أساس عرض سعر نزيه للمتاجر التالية.
استكشاف الأخطاء: ما الذي ينكسر غالبًا بعد التغيير
بعد التحويل تتكرر الأعراض نفسها من متجر إلى آخر. هذه أكثرها شيوعًا مع أول إجراء لكل منها.
الأعراض الخمسة التي ينبغي معرفتها
- «There has been a critical error on this website» — رسالة ووردبريس حين تتسبب إضافة أو القالب في خطأ فادح تحت الإصدار الجديد. العلاج: أعد إصدار PHP السابق في cPanel ثم اقرأ سجل أخطاء النسخة لتحديد الإضافة وحدّثها أو استبدلها.
- طلبات عالقة «بانتظار الدفع» — إشعار البوابة لم يعد يصل أو يُرفض. العلاج: العودة إلى الإصدار السابق ثم فحص سجل الويب هوك لدى البوابة وتوافق PHP المعلن للوحدة.
- شاشة بيضاء عند الدفع — غالبًا إضافة دفع أو شحن. العلاج: العودة إلى الإصدار السابق ثم تعطيل الإضافات واحدة تلو الأخرى على النسخة حتى تظهر المسؤولة.
- رسائل الطلب غائبة — لم يُعَد اختبار الإرسال بعد التحويل. العلاج: طلب تجريبي وقراءة سجل البريد وفحص إضافة الإرسال.
- إجراءات مجدولة تفشل — مهام متكررة كانت تتعطل بصمت تحت الإصدار القديم تظهر للعلن، أو العكس. العلاج: افتح قائمة الإجراءات الفاشلة واقرأ الرسالة وحدّث الإضافة المعنية.
وماذا لو أُجّل التغيير أو أُلغي؟
تبقى الخطة مفيدة. فـ PHP 7.4 و8.0 خارج دعم الأمان أصلًا، والتوصية الرسمية أعلى من 8.1، والجرد الذي أعددته يخدم الاستحقاق القادم أيضًا، مثل قائمة التحقق لترحيل فرع PHP يبلغ نهاية عمره أو تقويم نهايات عمر الاستضافة.
تابع مدونة المطورين في ووكومرس ووثائقها: فهناك سيُنشر القرار، إن اتُّخذ، مع إصداره وتاريخه. وإلى ذلك الحين، الأفضل أن تملك قائمة محدّثة وإجراءً مجرَّبًا بدل أن تكتشف الموضوع يوم يتوقف متجر عن التحديث.
