كيف تحدّث إصدار PHP لموقعك بأمان دون أن ينهار؟

من بين كل قرارات الصيانة التي يؤجّلها أصحاب المواقع، تحديث إصدار PHP هو الأكثر تأجيلًا والأقل فهمًا. السبب نفسي أكثر منه تقني: التحديث يبدو تدخّلًا في «قلب» الموقع، وكل من جرّب ترقية أفسدت موقعه مرّة يحكي القصّة لعشرة آخرين، بينما لا أحد يحكي عن الترقيات التي مرّت بلا حادثة — وهي الغالبية الساحقة. النتيجة أن ملايين المواقع تعمل اليوم على إصدارات ماتت رسميًا منذ سنوات، تظنّ نفسها في أمان لأن «الموقع يعمل».

لكن «الموقع يعمل» ليست مقياسًا للأمان. الإصدار المنتهي يعمل تمامًا كما كان يعمل أمس، والفرق الوحيد أنه توقّف عن تلقّي الرقع الأمنية. هذا الدليل يأخذك خطوة بخطوة عبر العملية كاملةً: لماذا الإصدار القديم مشكلة حقيقية لا تخويفًا تسويقيًا، كيف تعرف إصدارك الحالي بدقّة، كيف تفحص توافق قالبك وإضافاتك قبل أن تلمس أي زرّ، كيف تختبر على بيئة منفصلة، كيف تبدّل الإصدار عمليًا من لوحة الاستضافة، وماذا تفعل بالضبط في كل سيناريو عطل محتمل — مع خطة تراجع جاهزة تجعل أسوأ الاحتمالات مسألة دقيقة واحدة.

لماذا يُعدّ إصدار PHP القديم خطرًا صامتًا على موقعك؟

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

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

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

الجدول التالي يلخّص حالة الإصدارات وقت كتابة هذا الدليل (منتصف 2026):

ما الفرق بين «الحد الأدنى الذي يعمل» و«الموصى به رسميًا»؟

هذا التمييز هو أكثر ما يُربك أصحاب المواقع، ويستحقّ فقرة صريحة. ووردبريس يعلن رقمين مختلفين تمامًا، وكثيرون يخلطون بينهما فيظنّون أنهم «متوافقون» بينما هم في الحقيقة على حافة الخطر.

الحد الأدنى المدعوم هو أقدم إصدار PHP سيقلع عليه ووردبريس دون أن يرفض التثبيت — وهو ما زال 7.4 حتى إصدارات 2026. لكن هذا الرقم قرار توافق تاريخي لا توصية أمنية: ووردبريس يشغّل نسبة هائلة من الويب، ورفع الحد الأدنى فجأة يكسر ملايين المواقع القديمة دفعة واحدة، لذلك يُرفع ببطء شديد. أن يقبل ووردبريس إصدارًا لا يعني أن ذلك الإصدار آمن؛ 7.4 انتهى عمره الافتراضي منذ أواخر 2022 ولا يتلقّى أي رقعة أمنية اليوم.

الحد الأدنى الموصى به هو ما يقوله فريق ووردبريس فعلًا لمن يسأل «ما الذي ينبغي أن أشغّل عليه موقعي؟» — وهو 8.3 فما فوق في توجيهات 2026. هذا هو الرقم الذي يجب أن تقيس نفسك عليه، لا الأول.

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

كم يكسب موقعك فعليًا من ترقية إصدار PHP؟

المكسب حقيقي وقابل للقياس، لكن الأرقام المتداولة تُقدَّم غالبًا بمبالغة تجارية. لنكن دقيقين: القفزة الكبرى في أداء PHP حدثت بين الإصدار 5.6 والإصدار 7.0 (تحسّن جذري في محرّك اللغة)، ثم قفزة ثانية أصغر لكنها ملموسة عند الانتقال إلى 8.x بفضل مترجم JIT وتحسينات متراكمة في إدارة الذاكرة والدوال الداخلية.

عمليًا، الانتقال من إصدارات ما قبل 8 إلى 8.x يعطي عادةً تحسّنًا في زمن معالجة الصفحة على الخادم يتراوح بين 15% و30%، وقد يتجاوز ذلك بكثير على مواقع ثقيلة الحسابات مثل متاجر ووكومرس ذات الكتالوجات الكبيرة. لكن انتبه لثلاثة قيود مهمّة:

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

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

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

إن كنت تقيس أثر الترقية، فقِس قبلها وبعدها بنفس الأداة وعلى نفس الصفحات وفي نفس الوقت من اليوم، وركّز على زمن الخادم لا على الدرجة الإجمالية. طريقة القياس الصحيحة ومعنى كل مؤشّر مشروحان في دليل مؤشّرات الويب الأساسية.

جاهز لإطلاق موقعك على استضافة سريعة؟

خطط استضافة wpressly على أقراص NVMe مع SSL مجاني ودعم عربي — اختر الخطة المناسبة لحجمك وانطلق اليوم.

اكتشف خطط الاستضافة

كيف تعرف إصدار PHP الحالي لموقعك؟

قبل أي شيء آخر، تحتاج رقمًا دقيقًا لا تخمينًا. هناك ثلاث طرق موثوقة، ولكلٍّ منها موضعها:

الطريقة الأولى: أداة «صحّة الموقع» في ووردبريس. انتقل إلى الأدوات ← صحّة الموقع ← معلومات ← الخادم، وستجد سطرًا باسم «إصدار PHP» يعرض الرقم الكامل. هذه أسرع طريقة وأسهلها، ولا تتطلّب أي صلاحية خارج لوحة ووردبريس نفسها. ميزتها الإضافية أنها تعرض معلومات مجاورة مهمّة: حدّ الذاكرة، وحدّ زمن التنفيذ، وحجم الرفع الأقصى، وقائمة إضافات PHP المفعّلة — وهي أرقام ستحتاجها لاحقًا عند التشخيص.

الطريقة الثانية: أداة PHP في لوحة الاستضافة. في cPanel تُسمّى غالبًا MultiPHP Manager (لتغيير الإصدار) وMultiPHP INI Editor (لتعديل إعداداته)، وفي لوحات أخرى قد تجدها باسم «PHP Selector» أو «إعدادات PHP». هذه الطريقة تخبرك بالإصدار وتسمح لك بتغييره في الشاشة نفسها، وهي المصدر الأدقّ لأنها تعرض ما يضبطه الخادم فعليًا لا ما يستنتجه ووردبريس. إن لم تكن معتادًا على التنقّل في اللوحة، فـدليل cPanel للمبتدئين يشرح مواضع الأقسام.

الطريقة الثالثة: ملف phpinfo() مؤقّت. أنشئ ملفًا باسم عشوائي — لا تسمّه info.php — بالمحتوى التالي وارفعه إلى مجلّد الموقع:

<?php
phpinfo();

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

انتبه أيضًا إلى نقطة يغفل عنها كثيرون: قد يختلف إصدار PHP بين الويب وسطر الأوامر. الرقم الذي يظهر عند تنفيذ php -v عبر SSH هو إصدار CLI الافتراضي للخادم، وقد يكون مختلفًا تمامًا عن الإصدار الذي يخدم موقعك عبر المتصفّح. اعتمد دائمًا على رقم الويب.

كيف تفحص توافق القالب والإضافات قبل الترقية؟

هنا يقع الفارق بين ترقية تمرّ بلا أثر وترقية تُسقط الموقع. الخبر الجيّد أن ووردبريس نفسه ومكوّناته الأساسية متوافقة مع الإصدارات الحديثة منذ زمن؛ المشكلة تأتي دائمًا من الطرف الثالث: قالب اشتريته قبل ستّ سنوات وتوقّف مطوّره، أو إضافة صغيرة تؤدّي مهمّة واحدة ولم تُحدَّث منذ 2019.

ابدأ بجرد صريح. افتح صفحة الإضافات وسجّل لكل إضافة ثلاثة أشياء: تاريخ آخر تحديث، هل تعلن توافقًا مع إصدار ووردبريس الحالي، وهل ما زال لها مطوّر نشط. الإضافة التي لم تُحدَّث منذ أكثر من سنتين هي مرشّح أول للمشاكل، وليس بالضرورة لأنها ستنكسر فورًا، بل لأنها لن تُصلَح إن انكسرت.

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

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

ما الترتيب الآمن للترقية من البداية إلى النهاية؟

كل ما سبق يتجمّع في مسار واحد لا يُختصر ولا تُقفز خطواته. هذه ليست بيروقراطية بل تسلسل مصمَّم بحيث تكتشف كل مشكلة في أرخص موضع ممكن:

1. نسخة احتياطية كاملة — ملفات وقاعدة بيانات معًا، ومحفوظة خارج الخادم لا عليه. تفاصيل الطرق والتحقّق من صلاحية النسخة في دليل النسخ الاحتياطي للمواقع.
2. فحص التوافق — الجرد والفحص الآلي كما في القسم السابق، وحذف غير المستخدَم.
3. الاختبار على بيئة اختبار — نسخة مطابقة للموقع الحيّ، تبدّل فيها الإصدار وتتصفّح كل شيء قبل أن تلمس الإنتاج.
4. التبديل على الموقع الحيّ — في وقت هدوء حركة المرور، لا يوم إطلاق حملة ولا ليلة الجمعة.
5. مراقبة سجلّ الأخطاء — لمدّة 48 ساعة على الأقل، لأن بعض المسارات (الدفع، النماذج، المهام المجدولة) لا تُستدعى إلا نادرًا.

وفوق هذه الخطوات الخمس، هناك خطوة سادسة جاهزة دائمًا: التراجع الفوري عند أي خطأ فادح.

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

كيف تختبر الترقية على بيئة اختبار أولًا؟

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

ما يجب أن تفعله تحديدًا داخل بيئة الاختبار بعد تبديل الإصدار فيها:

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

لا تكتفِ بجولة سريعة على الصفحة الرئيسية. الصفحة الرئيسية غالبًا أبسط صفحة في الموقع وأقلّها اعتمادًا على كود الطرف الثالث؛ المشاكل تسكن في شاشات الإعدادات وصفحات الدفع والنماذج.

كيف تبدّل الإصدار من لوحة الاستضافة عمليًا؟

بعد أن نجح الاختبار، التبديل على الحيّ هو أسهل خطوة في الدليل كلّه — لا تستغرق أكثر من دقيقة.

في cPanel: افتح MultiPHP Manager، اختر النطاق (أو النطاقات) من القائمة، ثم اختر الإصدار المطلوب من القائمة المنسدلة واضغط Apply. التغيير يسري فورًا على الطلبات الجديدة.

في لوحات أخرى (DirectAdmin، Plesk، CyberPanel، أو لوحة مخصّصة من مضيفك) الاسم يختلف — «PHP Selector»، «PHP Settings»، «إعدادات PHP» — لكن المنطق واحد: تختار النطاق، ثم الإصدار، ثم تحفظ.

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

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

ووردبريس أسرع وأكثر أمانًا بلا إعدادات

ووردبريس المُدار من wpressly: سرعة وكاش وحماية وتحديثات تلقائية مع دعم عربي — ركّز على محتواك لا على السيرفر.

جرّب ووردبريس المُدار

ماذا تراقب بعد التبديل مباشرة؟

الترقية لا تنتهي بالضغط على «حفظ». الساعات الأولى — والأيام القليلة التالية — هي فترة المراقبة الحقيقية، لأن كثيرًا من مسارات الكود لا تُنفَّذ إلا عند حدث معيّن.

راقب هذه المؤشّرات تحديدًا:

سجلّ أخطاء PHP. هو أهمّ مصدر معلومات لديك. تجده عادةً في قسم «سجلّات الأخطاء» في لوحة الاستضافة، أو كملفّ error_log داخل مجلّد الموقع، أو في wp-content/debug.log إن فعّلت تسجيل الأخطاء في ووردبريس. اقرأه بعد ساعة، ثم بعد يوم، ثم بعد ثلاثة أيام.

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

المهام المجدولة. النسخ الاحتياطي التلقائي، وإرسال النشرات، وتجديد الشهادات، ومزامنة المخزون — كلّها تعمل خلف الكواليس وقد تتعطّل دون أي علامة ظاهرة على الواجهة.

بوّابات الدفع والتكاملات الخارجية. أي مكتبة تتصل بخدمة خارجية قد تتأثّر بتغيّر إعدادات SSL أو الوحدات المحمّلة مع الإصدار الجديد.

زمن الاستجابة. قارن قياسك بعد الترقية بقياس ما قبلها؛ إن ساء بدل أن يتحسّن، فغالبًا السبب كاشٌ لم يُمسح أو وحدة PHP كانت مفعّلة في الإصدار القديم ولم تُفعّل في الجديد — مثل امتداد التخزين المؤقّت للكائنات.

ماذا تفعل إذا انهار الموقع بعد التبديل؟

لنفترض أسوأ الاحتمالات: بدّلت الإصدار وفتحت الموقع فوجدت كارثة. تنفّس — لديك زرّ تراجع، ولديك تشخيص واضح. الجدول التالي يربط كل عَرَض بمعناه وأول إجراء:

الشاشة البيضاء بعد التبديل

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

خطأ فادح باسم دالة محذوفة

رسالة من نوع Call to undefined function ... أو Uncaught Error: Call to a member function ... on null تعني أن الكود يستدعي شيئًا لم يعد موجودًا في الإصدار الجديد. الرسالة تخبرك بالملفّ بالضبط، ومسار الملفّ يخبرك بالمذنب: إن كان داخل wp-content/plugins/اسم-الإضافة/ فالإضافة هي السبب؛ وإن كان داخل wp-content/themes/ فالقالب. الإصلاح الصحيح: حدّث المكوّن، أو استبدله إن كان مهجورًا. الإصلاح الخاطئ: تعديل كود الإضافة يدويًا — سيُمحى مع أول تحديث ويحوّل موقعك إلى نسخة لا يمكن صيانتها.

إضافة قديمة تكسر لوحة الإدارة

هذه الحالة مربكة لأنك تفقد الأداة التي كنت ستستخدمها للإصلاح. الحلّ التقليدي يعمل دائمًا: اتّصل بالموقع عبر FTP أو مدير الملفات، وأعد تسمية مجلّد wp-content/plugins إلى plugins-off — هذا يعطّل كل الإضافات دفعةً واحدة. ستعود اللوحة للعمل فورًا. أعِد الاسم الأصلي، ثم فعّل الإضافات واحدة تلو الأخرى من داخل اللوحة حتى تنهار مجدّدًا — الإضافة الأخيرة التي فعّلتها هي المتّهم. طريقة الوصول للملفّات عبر FTP مشروحة في دليل رفع الملفات بـFileZilla.

تحذيرات deprecated تملأ الصفحة أو السجلّ

هذه أهمّ نقطة في القسم كلّه، ومصدر ذعر لا مبرّر له عند معظم المبتدئين. رسالة Deprecated: تقول: «هذه الصياغة ما زالت تعمل اليوم، لكنها ستُزال في إصدار مستقبلي». موقعك يعمل بشكل كامل. الفرق جوهري:

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

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

كيف تتراجع للإصدار السابق بأمان؟

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

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

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

كيف تبقي موقعك جاهزًا للترقية القادمة؟

الترقية التي أنجزتها اليوم ستتكرّر بعد سنة أو سنتين. الفرق بين من يعيشها كأزمة سنوية ومن يمرّرها في عشر دقائق هو عادات بسيطة:

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

لا تراكم الديون. الموقع الذي يُحدَّث أسبوعيًا يبقى دائمًا قريبًا من التوافق، والموقع المتروك ثلاث سنوات يحتاج ترقية قفزية عبر عدّة إصدارات دفعةً واحدة — وهي أصعب بكثير وأكثر عرضة للكسر.

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

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

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

جاهز لإطلاق موقعك على استضافة سريعة؟

خطط استضافة wpressly على أقراص NVMe مع SSL مجاني ودعم عربي — اختر الخطة المناسبة لحجمك وانطلق اليوم.

اكتشف خطط الاستضافة

الأسئلة الشائعة

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

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

ما الفرق بين تحذير deprecated والخطأ الفادح؟ تحذير الإهمال يعني أن صياغة ما ما زالت تعمل اليوم لكنها ستُزال مستقبلًا — موقعك يعمل بشكل كامل ولا شيء معطّل، والمطلوب منك إبلاغ المطوّر والتخطيط للتحديث دون استعجال. أمّا الخطأ الفادح فيوقف تنفيذ الصفحة تمامًا فتظهر شاشة بيضاء أو رسالة «حدث خطأ حرج»، ويستدعي تدخّلًا فوريًا أو تراجعًا. القاعدة العملية: إن كان الموقع يُعرض ويعمل فأنت أمام ضجيج، لا كارثة.

هل أستطيع تشغيل إصدار PHP مختلف لكل موقع في حسابي؟ يعتمد على مضيفك ولوحته. كثير من اللوحات الحديثة — cPanel عبر MultiPHP Manager مثلًا — تتيح إصدارًا مستقلًا لكل نطاق ونطاق فرعي، وهذا مثالي للترقية التدريجية موقعًا موقعًا. وبعض الخطط المبسّطة تضبط الإصدار على مستوى الحساب كلّه، فتتحرّك كل مواقعك معًا. اعرف أي الحالتين لديك قبل التبديل، لأنها تحدّد هل تفحص توافق موقع واحد أم كل مواقعك دفعةً واحدة.

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

هل أرقّي إلى أحدث إصدار مباشرة أم أتدرّج؟ إن كنت على إصدار حديث نسبيًا (8.x) فالانتقال المباشر إلى إصدار مدعوم أحدث آمن عادةً. أما إن كنت على إصدار قديم جدًا (5.6 أو 7.0) فالتدرّج أذكى: انتقل خطوة، اختبر، ثم خطوة أخرى — لأن القفزة الواحدة الكبيرة تجمع كل الأخطاء المحتملة دفعةً واحدة فيصعب عزل مصدر كل واحد منها. وفي الحالتين لا تستهدف بالضرورة أحدث إصدار صدر قبل أسابيع، بل الإصدار الأحدث ناقص واحد.

كيف أخفي رسائل الأخطاء عن الزوّار بعد الترقية؟ في بيئة الإنتاج يجب ألّا تُعرض الأخطاء للزوّار إطلاقًا، بل تُسجَّل في ملفّ فقط. الضبط الصحيح هو إبقاء تسجيل الأخطاء مفعّلًا مع إيقاف عرضها على الصفحة، ويتمّ ذلك عبر ثوابت التصحيح في ملفّ wp-config.php أو عبر إعدادات PHP في لوحة الاستضافة. راجع السجلّ يدويًا بشكل دوري، ولا تتركه ينمو بلا حدّ — فالسجلّات المنتفخة تستهلك مساحة حسابك وقد تصطدم بحدوده.

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

المصادر

• php.net — الإصدارات المدعومة رسميًا
• ووردبريس — ترقية إصدار PHP