لماذا لا يغيّر تحديث التطبيق إصدار PHP
تحديث WordPress أو الأمر composer update أو إصدار جديد من Nextcloud يستبدل ملفات التطبيق. أما مفسّر PHP فهو برنامج مثبَّت داخل صورة Docker، مثل نظام Debian أو Alpine المحيط به. ما دامت الصورة لم تتغير، لم يتغير PHP، مهما بلغ عدد تحديثات التطبيق.
الفخ الثاني هو إعادة التشغيل. الأمر docker restart يعيد تشغيل الحاوية القائمة، أي الصورة نفسها. والأمر docker compose up -d لا يبحث عن إصدار أحدث إذا كانت صورة بهذا الاسم موجودة أصلاً على الخادم: فهو يعيد استخدام النسخة المحلية. وحده pull أو build --pull، متبوعاً بإعادة إنشاء الحاوية، يغيّر المفسّر.
تجدون الثغرتين وأوامر apt وdnf في دليلنا لتحديث PHP. موضوعنا هنا صورة Docker والدليل على أنها الصورة الصحيحة.
ستة عناصر يجب ألا تُخلط
- صورة السجل — ما يقدّمه Docker Hub أو سجلكم الخاص اليوم تحت وسم مثل
php:8.3-fpm. الوسم متحرك: يشير إلى محتوى مختلف بعد كل إعادة بناء. - الصورة المحلية — النسخة الموجودة على خادمكم، وتظهر بالأمر
docker image ls. لا تتغير إلا إذا سحبتم صورة أو بنيتموها. - الحاوية العاملة — تحتفظ بمعرّف الصورة التي أُنشئت منها، حتى لو صارت صورة أحدث تحمل الاسم نفسه.
- العملية التي تجيب — PHP-FPM أو Apache مع
mod_phpأو FrankenPHP. هي المكشوفة للعالم، والأمرphp -vلا يستجوبها. - الخدمات الأخرى — عامل الطوابير والمجدول وحاوية
cliللصيانة: لكل منها صورته، وبالتالي إصدار PHP الخاص به. - ذاكرة البناء المؤقتة — طبقة
FROMمحفوظة قد تعيد القاعدة القديمة دون أن يظهر أي خطأ.
قارنوا السجل والصورة المحلية والحاوية
اعرضوا الصور المحلية وتواريخها
docker image ls php(أوwordpressأوnextcloud). يبيّن العمودCREATEDمتى بُنيت الصورة. صورةphp:8.3-fpmأُنشئت قبل 21 أكتوبر 2026 لا تحتوي الإصلاح.اقرأوا صورة كل حاوية
يعرض
docker psفي العمودIMAGEالوسم المطلوب عند الإنشاء. وللحصول على المعرّف الحقيقي للصورة المستعملة، استجوبوا الحاوية:docker inspect --format '{{.Image}}' <الحاوية>.قارنوا مع الصورة الموجودة على القرص
docker image inspect --format '{{.Id}}' php:8.3-fpmيعيد معرّف الصورة التي تحمل هذا الاسم اليوم. إن اختلف عن معرّف الحاوية، فالحاوية تعمل على صورة أقدم من التي على القرص: لم يُعد إنشاؤها بعد آخر سحب.قارنوا مع السجل
ينتهي
docker pull php:8.3-fpmبسطرStatus: Downloaded newer image for …عند وصول صورة أحدث، أوStatus: Image is up to date for …في غير ذلك. في الحالة الثانية، إما أن نسختكم هي الأحدث فعلاً، وإما أن الوسم لم يُعَد نشره بعد: قارنوه بتاريخ الوسم في Docker Hub.
اقرأوا الإصدار الذي يخدمه الويب فعلاً
يستجوب php -v برنامج سطر الأوامر، لا العملية التي تجيب عن الطلبات. والثابت PHP_SAPI يبيّن أيّهما يتكلم: cli في سطر الأوامر، وfpm-fcgi مع PHP-FPM، وapache2handler مع Apache وmod_php. في صورة واحدة يتطابق الإصداران غالباً. ويظهر الفرق في ثلاث حالات شائعة مع Docker: الأمر docker compose run يشغّل حاوية جديدة، أي من أحدث صورة محلية، بينما خدمة الويب ما زالت على القديمة؛ أو حاوية cli للصيانة مبنية على وسم غير وسم خدمة الويب؛ أو وكيل عكسي يحوّل الطلبات إلى حاوية غير التي تفحصونها.
يبقى الطلب عبر HTTP أوثق دليل: يسلك طريق الزائر ويقرأ PHP_VERSION من العملية التي تجيب. ويُفحص ملف FPM التنفيذي بالأمر docker exec <الحاوية> php-fpm -v استكمالاً.
أثبتوا الإصدار المخدَّم، خدمة بخدمة
ضعوا ملف اختبار في المجلد المخدَّم
مثال مع خدمة
wordpressمن الصورة الرسمية، ومجلد الويب فيها/var/www/html(كيّفوا الخدمة والمسار مع منظومتكم):docker compose exec wordpress sh -c 'echo "<?php echo PHP_VERSION, \" \", PHP_SAPI;" > /var/www/html/v-check.php'استعلموا عنه عبر HTTP ثم احذفوه فوراً
curl -s https://your-domain.com/v-check.phpثمdocker compose exec wordpress rm /var/www/html/v-check.php. يعطي الجواب الإصدار متبوعاً بـ SAPI. قارنوه بالإصدارات المصحَّحة: 8.5.12 أو 8.4.27 أو 8.3.36 أو 8.2.35 بحسب الفرع. رقم أدنى لفرعكم يعني أن الإصلاح غير موجود.افحصوا ملف FPM التنفيذي في الحاوية
docker exec <الحاوية> php-fpm -vيعرض إصدار وSAPI للملف التنفيذي لـ FPM في تلك الحاوية بعينها. مع صورة Apache يكفي طلب HTTP في الخطوة السابقة: فـ Apache هو الذي يحمّلmod_php.لا تثقوا في docker compose run
ينشئ
docker compose runحاوية جديدة من الصورة المحلية. وقد يعلن الإصدار المصحَّح بينما حاوية الموقع لم تتحرك. افحصوا دائماً الحاوية التي تستقبل الزيارات.
الوسوم المتحركة والوسوم المثبَّتة: ما الذي يتقدم وحده
وسم الفرع مثل php:8.3-fpm يتقدم عند السحب التالي: فيشير حينها إلى الإصدار المصحَّح. والوسم الدقيق مثل php:8.3.36-fpm يبقى على إصداره، والإشارة بالبصمة (@sha256:…) لا تتحرك أبداً. توثيق docker image pull صريح: مع البصمة لا يجلب Docker أي إعادة بناء، بما فيها إصلاحات الأمان، حتى تغيّروا البصمة بأنفسكم.
وصلت الوسوم المصحَّحة للصورة الرسمية php إلى Docker Hub خلال نهار 21 أكتوبر 2026 ومسائه (بالتوقيت العالمي)، لنسخ FPM من الفروع 8.5 و8.4 و8.3 و8.2. أما صور WordPress الرسمية php8.3-fpm وphp8.4-fpm وphp8.3-apache فأُعيد نشرها في 22 أكتوبر 2026 فجراً (بالتوقيت العالمي)، وصور Nextcloud في اليوم نفسه. فالصورة المسحوبة قبل هذه اللحظات هي القديمة، ولو تطابق الاسم. تحققوا من هذه التواريخ في صفحة كل وسم. ويتلقى الفرع 8.2 إصلاحه لكنه ينتهي عمره في 31 ديسمبر 2026: خططوا لاستبداله.
أي كتابة تتقدم وأيها يبقى مجمَّداً
مرّر الجدول أفقيًا
| في ملف compose أو Dockerfile | هل يتقدم عند السحب التالي؟ | للحصول على PHP المصحَّح |
|---|---|---|
| `php:8.3-fpm` | نعم، يُعاد نشر الوسم | `pull` أو `build --pull` ثم إعادة إنشاء الحاوية |
| `php:8.3.36-fpm` | لا، إصدار دقيق | مصحَّح أصلاً؛ غيّروه يدوياً عند الإصلاح التالي |
| `php:8.3.<n>-fpm` مع n أقل من 36 | لا، إصدار دقيق | انتقلوا إلى وسم مصحَّح ثم أعيدوا البناء وإنشاء الحاوية |
| `wordpress:php8.3-fpm` | نعم، تعيد الجهة المشرفة نشره | `pull` ثم إعادة إنشاء الخدمة |
| `wordpress:<x.y>-php8.3-fpm` | نعم بالنسبة إلى PHP: تعيد الجهة المشرفة نشره | `pull` ثم إعادة إنشاء الخدمة |
| `php:8.3-fpm@sha256:…` | أبداً | استبدلوا البصمة ببصمة صورة مصحَّحة |
| `FROM php:8.3-fpm` في Dockerfile الخاص بكم | فقط إذا بنيتم مع `--pull` | `build --pull` ثم إعادة إنشاء الحاوية |
| `image: myregistry/app:latest` (صورتكم) | لا، هو آخر بناء لكم | أعيدوا البناء والنشر ثم السحب وإعادة الإنشاء |
الصورة الخاصة: التسلسل وما يغيّره كل خيار
لصورة تبنونها بأنفسكم انطلاقاً من FROM php:8.3-fpm، يتألف التسلسل من ثلاثة أوامر: docker compose build --pull --no-cache، ثم docker compose up -d --force-recreate، ثم فحص الإصدار المخدَّم. وكل منها يعالج فخاً محدداً.
الخيار --pull هو الذي يغيّر إصدار PHP: يطلب من Docker البحث عن إصدار أحدث من الصورة الأساسية بدل إعادة استعمال نسخة الخادم. من دونه يُحَلّ FROM بالنسخة المحلية فينجح البناء بالمفسّر القديم دون أي رسالة.
يعيد --no-cache تنفيذ كل الطبقات، ومنها apt-get وcomposer install، فيجدد مكتبات النظام والاعتماديات أيضاً. وهو غير لازم لتغيير PHP، لأن الطبقات التي تلي الصورة الأساسية تُعاد بناءً من تلقاء نفسها عندما تتغير. ويفيد حين تثبّت طبقة محفوظة حزمة تريدون تجديدها.
يعيد --force-recreate إنشاء الحاويات حتى لو رأى Compose أن إعدادها وصورتها لم يتغيرا. وبذلك يزول الشك في ما يعمل فعلاً.
إعادة بناء صوركم مع كل إصلاح جدول يجب الالتزام به لا إجراء لمرة واحدة. وعلى VPS بصلاحية root يكون هذا الجدول لكم، ويضع دليلنا لتثبيت Docker على VPS أساس العمل.
أعيدوا بناء صورة خاصة وإنشاءها
تأكدوا أن الوسم الأساسي مصحَّح
افتحوا صفحة وسمكم الأساسي في Docker Hub وتأكدوا أنه نُشر ابتداءً من 21 أكتوبر 2026. وإن كان
FROMيشير إلى إصدار دقيق أقدم، فغيّروه أولاً.أعيدوا البناء مع سحب القاعدة
docker compose build --pull --no-cache. دوّنوا الإصدار قبل العملية بواسطة ملف الاختبار، لتحصلوا على ما قبل وما بعد.أعيدوا إنشاء الحاويات
docker compose up -d --force-recreate. ويمكن لأمر واحد أن يجمع الخطوات الثلاث:docker compose up -d --build --pull always. أعيدوا إنشاء كل خدمة تستعمل الصورة: الويب وعامل الطوابير والمجدول.أثبتوا النتيجة
أعيدوا تشغيل ملف الاختبار، ثم قارنوا المعرّف الذي يعطيه
docker inspect --format '{{.Image}}' <الحاوية>بمعرّفdocker image ls. قد تحمل الصورة القديمة والجديدة الاسم نفسه: المعرّف وجواب HTTP وحدهما حجّة.
WordPress وNextcloud الرسميان: PHP يأتي من الوسم
يجمع وسم WordPress بين إصدار WordPress وإصدار PHP ونسخة، مثل php8.3-apache أو php8.3-fpm. فاسم الوسم هو الذي يحدد فرع PHP. وتغيير إصدار WordPress، أو ترك التحديثات التلقائية تعمل داخل وحدة البيانات، لا يمسّ هذا الفرع. وللحصول على PHP المصحَّح يجب سحب الوسم من جديد بالأمر docker compose pull ثم إعادة إنشاء الخدمة. ونسخة Apache هي الافتراضية وتحمّل PHP بصيغة mod_php: وهي التي يعدّها مشروع PHP الأكثر تعرضاً، مع استغلال مُثبَت قبل تنفيذ أي شيفرة تطبيق. عالجوها بأولوية.
يتبع Nextcloud المبدأ نفسه بنسختين: apache تضم Apache كاملاً، وfpm تحتاج خادم ويب أمامها. ويصف توثيق الصورة التحديث بأنه استبدال: اسحبوا الصورة، وارموا الحاوية القديمة، وشغّلوا الجديدة. شيفرة Nextcloud وبياناتكم تعيش في الوحدة /var/www/html التي لا يمسحها إعادة إنشاء الحاوية. راجعوا أيضاً دليلنا لاستضافة WordPress على VPS ودليل Nextcloud.
Laravel Octane وFrankenPHP: المحرك داخل الصورة
مع Octane وFrankenPHP لا يوجد PHP-FPM: خادم التطبيق يضمّ المفسّر في داخله. وصور FrankenPHP الرسمية مبنية على صور PHP الرسمية، ووسمها يجمع إصدار FrankenPHP وإصدار PHP والنظام، بالشكل dunglas/frankenphp:<version>-php8.4-trixie. يعيد المشروع بناءها مع كل إصدار، ويومياً عند الساعة 4 بالتوقيت العالمي إذا وُجدت صور PHP رسمية جديدة. ولا يصلكم الإصلاح في FROM dunglas/frankenphp إلا إذا أعدتم بناء صورتكم مع --pull.
فخ Octane الخاص هو العامل. يشغّل Octane التطبيق مرة واحدة ويبقيه في الذاكرة: والأمر php artisan octane:reload يعيد تشغيل العمال برفق لتحميل الشيفرة المنشورة. هذا هو الإجراء الصحيح بعد نشر الشيفرة، لكنه لا يستبدل المفسّر الذي يبقى مفسّر الصورة العاملة. والأمر ذاته مع kill -USR2 أو إعادة تحميل PHP-FPM في الحاوية القديمة: فهما يعيدان تشغيل الملفات نفسها، ملفات الصورة القديمة. ولتغيير PHP أعيدوا إنشاء الحاوية، بما فيها حاويات عمال الطوابير والمجدول. راجعوا دليلنا لـ Laravel Octane على VPS.
فخاخ البنية التحتية التي تعيد الصورة القديمة
- ذاكرة البناء في CI — قد تعيد ذاكرة الطبقات المستعادة طبقة
FROM. أضيفوا--pullإلى أمر البناء في CI، أو أبطلوا الذاكرة لهذه الخطوة. - سجل خاص أو مرآة — إذا كانت خوادمكم تسحب من سجل داخلي ينسخ الصور يدوياً أو بمهمة مجدولة، فتأكدوا أنه نسخ الوسم. وإلا أجاب
pullبـImage is up to dateبينما أعادت الجهة المشرفة النشر. - منظومة Portainer أو أداة تنسيق — تحديث المنظومة لا يعيد دائماً سحب الصورة. فعّلوا خيار إعادة السحب قبل إعادة النشر إن وفّرته أداتكم.
pull_policy: missing— هي القيمة الافتراضية في Compose دون قسمbuild: لا يسحب إلا إذا غابت الصورة عن الخادم. والوسمlatestوحده يُسحب في كل الحالات. استعملواalwaysأوdailyوweeklyلفحص السجل على فترات ثابتة.- خدمة منسية — الويب والعامل والمجدول وحاوية
cliالمبنية من ملفات Dockerfile منفصلة لكل منها قاعدته: صحّحوها جميعاً. - حاوية يتيمة — أمر
docker runمنسي أو مشروع Compose آخر قد يظل يجيب على منفذ. اعرضوا كل ما يعمل بالأمرdocker ps.
استكشاف الأخطاء: ما تلاحظونه وما يعنيه
مرّر الجدول أفقيًا
| ما تلاحظونه | السبب المحتمل | العلاج |
|---|---|---|
| يعرض `pull` الرسالة `Status: Image is up to date` لكن الإصدار يبقى قديماً | لم يُعَد نشر الوسم بعد، أو تسحبون إصداراً دقيقاً أو بصمة | قارنوا بتاريخ الوسم في Docker Hub ثم انتقلوا إلى وسم مصحَّح |
| `up -d` لا يغيّر شيئاً بعد السحب | لم يُعَد إنشاء الحاوية القائمة | `docker compose up -d --force-recreate` ثم قارنوا معرّفات الصور |
| ينتهي البناء في ثوانٍ مع القاعدة المحفوظة أصلاً | غياب `--pull`: أُعيد استعمال قاعدة الخادم | `docker compose build --pull` مع `--no-cache` إذا لزم تجديد حزم النظام أيضاً |
| يعلن `docker compose run` الإصدار المصحَّح والموقع يجيب بالقديم | ينشئ `run` حاوية جديدة ولم تُعَد إنشاء خدمة الويب | افحصوا عبر HTTP الحاوية التي تستقبل الزيارات ثم أعيدوا إنشاءها |
| الإصدار صحيح لكن عاملاً يتصرف كما كان | عامل طوابير أو Octane ما زال يعمل في حاوية قديمة | أعيدوا إنشاء كل الحاويات التي تستعمل الصورة، لا خدمة الويب فقط |
