ماذا يغيّر «انتهاء الدعم» بالنسبة إلى متجر على 2.4.6
بحسب جدول دورة الحياة الذي تنشره أدوبي، انتهى الدعم القياسي للإصدار 2.4.6 في 11 أغسطس 2026. ومنذ ذلك التاريخ لا يتلقى المتجر الذي بقي على 2.4.6 إصلاحات الجودة ولا الإصلاحات الأمنية ضمن الدعم القياسي.
وتوفّر أدوبي سنة من الدعم الممتد حتى 31 أغسطس 2027. لا تكلفة إضافية عليه، لكنه مخصص لعملاء Adobe Commerce على الإصدارين 2.4.6 و2.4.7.
لذلك لم يعد السؤال لدى الوكالة «هل نرقّي؟» بل «إلى أي إصدار، وبأي إجراء، وفي أي تاريخ؟». المتجر الإلكتروني يحمل كتالوجًا ومدفوعات وطلبات: لا تُغيَّر بنيته مساء الجمعة مباشرة على الإنتاج.
ماذا يعني غياب الدعم عمليًا
- لا إصلاحات قياسية بعد الآن — لم تعد إصلاحات الجودة والأمان للإصدار 2.4.6 تصدر ضمن الدعم القياسي؛ والدعم الممتد وحده، المخصص لـ Adobe Commerce، يمدّ هذا الترتيب.
- اشتراط PCI — تذكر صفحة أدوبي عن الترقيات أنه يجب على التجار أن يكونوا على آخر تصحيح أو تصحيح أمني للامتثال لمعيار PCI. والبنية المجمّدة تخرج عن هذا الإطار.
- بنية تشيخ حول ماجنتو — تشير أدوبي إلى أن MySQL 8.0 بلغ نهاية دعمه في 30 أبريل 2026 وأن Elasticsearch 7.17 بلغها في 15 يناير 2026، وتوصي بالانتقال إلى MariaDB وOpenSearch.
- إضافات يجب إعادة تقييمها — يجب فحص كل إضافة من طرف ثالث على الإصدار المستهدف قبل تحديد أي موعد. تكفي إضافة واحدة معطِّلة لتأخير الجدول كله.
- مهلة لا وجهة — يمنح الدعم الممتد وقتًا لا هدفًا: فالإصدار 2.4.7 نفسه يخرج من الدعم القياسي في مايو 2027.
- مجموعة متاجر بسرعات مختلفة — إذا كان لعملائك متاجر على 2.4.6 و2.4.7 و2.4.8 فأنت بحاجة إلى جدول متابعة واحد، لا إلى ذاكرة لكل عميل.
قراءة جدول أدوبي دون الخطأ في النطاق
تعرّف صفحة سياسة دورة الحياة لدى أدوبي الدعم القياسي بأنه فترة ثلاث سنوات من تاريخ التوفر العام. ويشمل إصلاحات الجودة والإصلاحات الأمنية والمساندة.
انتبه إلى النطاق: هذا الجدول مكتوب لـ Adobe Commerce ولا يذكر Magento Open Source. إذا كان عملاؤك على Open Source فلا تعتمد هذه المواعيد على أنها مواعيدهم. تحقق منها لدى أدوبي، وافترض في الأثناء الحالة غير المواتية، أي إصدارًا لم يعد يتلقى إصلاحات. ولا يعطي هذا المقال عمدًا أي تاريخ لنهاية الدعم الخاص بـ Open Source.
مواعيد الدعم المقروءة من صفحة أدوبي (Adobe Commerce)
مرّر الجدول أفقيًا
| الإصدار | نهاية الدعم القياسي | نهاية الدعم الممتد |
|---|---|---|
| 2.4.6 | 11 أغسطس 2026 | 31 أغسطس 2027 |
| 2.4.7 | 31 مايو 2027 | 31 مايو 2028 |
| 2.4.8 | 31 مايو 2028 | غير مذكورة في الصفحة |
| 2.4.9 | 31 مايو 2029 | غير مذكورة في الصفحة |
اختيار الإصدار المستهدف: 2.4.7 أم 2.4.8 أم 2.4.9
الإصدار 2.4.9 متاح منذ 12 مايو 2026 ويمتد دعمه القياسي حتى 31 مايو 2029: إنه الهدف الذي يمنح أطول مدة. أما 2.4.7 فيخرج من الدعم القياسي في مايو 2027؛ والتوقف عنده يعني تكرار العملية نفسها قبل ذلك. ويقدّم 2.4.8 مرحلة وسطى حتى مايو 2028.
لا يحسم الجدول الزمني وحده. معياران أثقل منه. الأول قائمة إضافات العميل: إضافة بلا نسخة متوافقة مع 2.4.9 تفرض إما تصحيحًا وإما مرحلة أدنى. والثاني فجوة بنية الخادم، وهي تكبر مع كل إصدار يُتخطى ويُقرأ حجمها في الجدول التالي.
بنية خادم 2.4.9: ما يتغير قبل أن يبدأ Composer
لا تدعم أدوبي إلا التركيبات المذكورة في صفحة متطلبات النظام. والملاحظة في تلك الصفحة صريحة: يُختبر 2.4.9 مع MariaDB 12.3، لذا تُرقّى قاعدة البيانات قبل ماجنتو.
يقارن الجدول بين 2.4.6-p15 و2.4.9 لتركيب محلي كما تصفه صفحة أدوبي لـ Adobe Commerce. أما لـ Open Source فتأكد من كل سطر في المصدر نفسه قبل طلب خادم أو إعادة ضبطه.
المتطلبات المحلية المقروءة من صفحة أدوبي
مرّر الجدول أفقيًا
| المكوّن | 2.4.6-p15 | 2.4.9 |
|---|---|---|
| PHP | 8.2 أو 8.1 | 8.5 |
| Composer | 2.2.26 فما فوق | 2.10 |
| OpenSearch | 2.19 أو 3 | 3 |
| MariaDB | 10.11 | 12.3 |
| MySQL | غير مدعوم | 8.4 |
| Valkey | 8.1 | 9.0 |
| RabbitMQ | 4.3 | 4.3 |
| nginx | 1.30 | 1.30 |
| Varnish | 8 | 9 |
تلفت هذا الجدول نقطة واضحة: لا يوجد إصدار PHP مشترك بين 2.4.6 و2.4.9. أي أن PHP يتغير مع الشيفرة في الوقت نفسه، وتنتقل قاعدة البيانات من MariaDB 10.11 إلى 12.3. ليست هذه ترقية تصحيح، بل ترحيل لبنية كاملة. وتُجرَّب على جهاز منفصل بالإصدارات نفسها المستهدفة قبل تنفيذها على الإنتاج.
خطة انقطاع محدود: بنية موازية وبيئة تجريبية أولًا
الأسلم ألا تلمس بيئة الإنتاج القائمة. أنشئ بيئة ما قبل الإنتاج بالإصدارات المستهدفة في الجدول، واستعد فيها نسخة من قاعدة البيانات والوسائط، وأعد الترقية من أولها إلى آخرها وقِس زمن كل خطوة. إذا اتسعت التجربة لنافذة يقبلها التاجر، أعدتها كما هي على الإنتاج.
وإلا فجهّز بنية إنتاج ثانية، وأعد مزامنة قاعدة البيانات قبل التحويل مباشرة، ووجّه الزيارات إليها في اللحظة الأخيرة. ينحصر الانقطاع في التحويل نفسه الذي تضعه في ساعات الهدوء، وتبقى البنية الأصلية سليمة للتراجع.
يبقى السؤال الذي تطرحه كل وكالة: من يتحمل علاقة العميل والمخاطرة؟ علاقتك بالتاجر والإجراء يبقيان لديك. أما البنية التحتية فتتوفر لك فيها خوادم منفصلة لما قبل الإنتاج والإنتاج، وصلاحية root لمواءمة PHP ومحرك البحث وقاعدة البيانات، ولقطات قبل كل ترقية.
إجراء الترقية بواسطة Composer، يُجرَّب أولًا في بيئة ما قبل الإنتاج
تثبيت نقطة الانطلاق
خذ لقطة للخادم ونسخة مصدّرة من قاعدة البيانات قبل أي أمر. سجّل الإصدار الدقيق بالأمر
bin/magento --versionوقائمة الحزم بالأمرcomposer show.مواءمة البنية
ثبّت على البنية المستهدفة الإصدارات المذكورة في الجدول: PHP وComposer وOpenSearch وMariaDB. تحقق منها بالأمرين
php -vوcomposer --versionقبل المتابعة.تفعيل وضع الصيانة
نفّذ
bin/magento maintenance:enable. في بيئة ما قبل الإنتاج هو عادة تُكرَّر لقياس مدة الانقطاع الفعلية.إيقاف cron وتفريغ الطوابير
أزل cron بالأمر
bin/magento cron:removeثم فرّغ المستهلكين بالأمرbin/magento cron:run --group=consumers. انتظر انتهاء المعالجة، وتتابعها بالأمرps aux | grep 'bin/magento queue'.حفظ ملف Composer
انسخ الملف بالأمر
cp composer.json composer.json.bak. إنه شبكة أمانك إذا سار حلّ التبعيات في اتجاه خاطئ.طلب الإصدار المستهدف
استعمل
composer require-commerceلاcomposer require:composer require-commerce magento/product-community-edition <الإصدار المستهدف> --no-update. وفي Adobe Commerce تكون الحزمةmagento/product-enterprise-edition. يفترض هذا الأمر أن الإضافةmagento/composer-root-update-pluginمثبتة كما تشترط متطلبات أدوبي.تحديث التبعيات
نفّذ
composer updateواقرأ المخرجات حتى آخرها: يظهر فيها تعارض الإضافات قبل وقوع أي ضرر. والإضافة التي تحدّ من إصدار ماجنتو تُصلَح هنا لا على الإنتاج.التنظيف ثم الترحيل
احذف محتوى
var/cache/وvar/page_cache/وgenerated/code/ثم نفّذbin/magento setup:upgrade. وبحسب نمط النشر لديك، أعد بعدهاbin/magento setup:di:compileوbin/magento setup:static-content:deploy؛ فالصفحة التي رجعنا إليها من أدوبي لا تفصّل هذين الأمرين، فاتّبع إجراءك المعتاد.إعادة الفتح والتحقق
نفّذ
bin/magento maintenance:disableوأعد تثبيت cron بالأمرbin/magento cron:installوأعد تشغيل Varnish إن كان مستعملًا. ثم تجوّل في المتجر: الكتالوج والبحث والسلة ودفعة تجريبية ورسائل الطلب.
خطّط للتراجع قبل إطلاق الترقية
اللقطة تستعيد حالة الخادم كاملة، أما نسخة قاعدة البيانات الاحتياطية فتستعيد البيانات فقط: الفرق موضح في اللقطة مقابل النسخ الاحتياطي للـ VPS. جرّب الاستعادة في بيئة ما قبل الإنتاج قبل موعد الترقية.
لا يكون التراجع نظيفًا إلا ما دام لم يُسجَّل أي طلب على البنية الجديدة. وبعد ذلك يجب إعادة تلك الطلبات يدويًا: حدّد سلفًا اللحظة التي لا رجوع بعدها.
استكشاف الأخطاء: الأخطاء التي تتكرر أثناء الترقية
تأتي هذه الرسائل من وثائق أدوبي ومن Composer. لكل منها علاج، ولا يجوز علاج أي منها على الإنتاج.
رسائل الخطأ وعلاجها
Your requirements could not be resolved to an installable set of packages— يرفض Composer التركيبة المطلوبة. إما أن PHP على الجهاز خارج الإصدارات المدعومة للهدف، وإما أن إضافة من طرف ثالث تحدّ من ماجنتو. نفّذcomposer why-not magento/product-community-edition <الإصدار المستهدف>لمعرفة المعطِّل.- تحذير بشأن قيم الجذر المتعارضة — بلا خيار يحتفظ Composer بقيمك المخصصة ويعرض تحذيرًا. يتيح
--interactive-root-conflictsمراجعتها واحدة واحدة؛ ويستبدل--force-root-updatesقيمك بقيم أدوبي، فلا يُستعمل إلا في مشاريع بلا تخصيص. We're sorry, an error has occurred while generating this email— تفيد أدوبي بإعادة ضبط مالك الملفات وأذوناتها بصلاحية root ثم تفريغvar/cache/وvar/page_cache/وgenerated/code/قبل إعادة تحميل المتجر.- الحزمة
magento/inventory-composer-installerغائبة — عند الترقية من 2.3 إلى 2.4.6-p13 تطلب أدوبي تنفيذcomposer require magento/inventory-composer-installerأولًا، لأن الحزمة مفقودة في ذلك الإصدار.
تحويل الترقية إلى روتين على كامل المجموعة
نجاح الترقية في متجر واحد لا قيمة كبيرة له ما لم يصبح روتينًا. احتفظ بجدول لكل عميل يضم إصدار ماجنتو وتصحيحه وPHP وقاعدة البيانات ومحرك البحث وقائمة الإضافات وتاريخ آخر تجربة في بيئة ما قبل الإنتاج. وتوصي أدوبي بالترقية في كل دورة تصحيحات: هذا الإيقاع هو ما يمنعك من الوقوع في الاستعجال نفسه بعد سنتين.
تجد بقية مواعيد المجموعة في جدول نهاية الدعم 2027، وقائمة التحقق الخاصة بـ PHP في نهاية دعم PHP 8.2: دليل الترحيل. اجمع الثلاثة في جدول صيانة واحد.
أجرِ جردًا للمتاجر التي ما زالت على 2.4.6 مع نسخة كل منها (Adobe Commerce أو Open Source) وإضافاتها. اختر الهدف، وهو 2.4.9 في أغلب الحالات. أنشئ بيئة ما قبل الإنتاج بإصدارات الجدول، وجرّب الإجراء ودوّن مدة كل خطوة. ثم أبلغ التاجر بموعد التحويل ونافذته ونقطة اللارجوع. وما بعد ذلك لم يعد ارتجالًا بل عملية مخططة.
