إذا كنت لا تزال تشغل Drupal 7 في الإنتاج، فلن أتحلى باللطف: أنت تعيش على الوقت المستعار. وصل Drupal 7 إلى نهاية حياته الرسمية في 5 يناير 2025، بعد عمليات تمديد متعددة تعود إلى موعد نوفمبر 2021 الأصلي. هذا يعني عدم وجود رقع أمان إضافية، وعدم وجود دعم مجتمعي، وعدم الادعاء بأن الهجرة يمكن أن تنتظر حتى الربع القادم. لقد ساعدت عدة فرق مؤسسية في هذا الوضع بالذات على مدار السنوات القليلة الماضية، والفرق التي انتظرت حتى اللحظة الأخيرة دفعت فاتورة أعلى دائماً — من حيث المال والإجهاد والديون التقنية. هذا الدليل يحتوي على كل شيء أتمنى أن أتمكن من تسليمه لكل نائب رئيس هندسة لا يزال يشغل Drupal 7.

جدول المحتويات

Drupal 7 End of Life 2025: Migration Guide for Enterprise Teams

ماذا تعني نهاية حياة Drupal 7 فعلياً

دعنا نكون دقيقين حول ما تعنيه "نهاية الحياة" بالفعل، لأنني رأيت الكثير من الارتباك هنا:

  • لا مزيد من تحديثات الأمان. فريق أمان Drupal لن يصدر مستشارات أو رقع لـ Drupal 7 الأساسي أو الوحدات المساهمة. إذا تم اكتشاف ثغرة SQL injection حرجة غداً، فأنت وحدك.
  • لا مزيد من إصلاحات الأخطاء. أي شيء معطل يبقى معطلاً.
  • مشرفو الوحدات المساهمة ينتقلون. معظمهم بالفعل. لم تشهد العديد من وحدات Drupal 7 الشهيرة تحديثاً منذ سنوات.
  • سيتخلى موفرو الاستضافة عن الدعم. أعلنت Pantheon و Acquia و Platform.sh جميعها جداول زمنية لإيقاف بيئات استضافة Drupal 7. قامت Acquia بتمديد دعم Drupal 7 حتى 2026 للعملاء الحاليين، لكن هذا إضافة مدفوعة وليست حلاً طويل الأجل.
  • ستتفاقم مشاكل التوافق مع PHP. تم بناء Drupal 7 لـ PHP 5.x. يعمل على PHP 8.1 مع رقع، لكن PHP 8.1 نفسه ينتهي في ديسمبر 2025. ستكون تكدس برنامج غير مدعوم على برنامج غير مدعوم.

يجب أن تكون مخاطر الأمان وحدها كافية لتحفيز الإجراء. إذا كانت منظمتك تتعامل مع أي شكل من أشكال PII أو البيانات المالية أو معلومات الصحة، فإن تشغيل Drupal 7 غير الملبي هو مسؤولية الامتثال. PCI DSS و HIPAA و SOC 2 — كلهم يطلبون منك الحفاظ على برنامج معروم ومدعوم.

لماذا استمرت الفرق المؤسسية في التأخير

لقد أجريت هذه المحادثة عشرات المرات. الأسباب دائماً نوع من الآتي:

  1. "موقع Drupal 7 الخاص بنا يعمل بشكل جيد." فعلاً. حتى لا يعمل. الكود لن يتوقف عن العمل في 6 يناير، لكن ملف تعريف المخاطر يتغير بشكل جذري.
  2. "الهجرة إلى Drupal 8/9/10 ليست ترقية بسيطة." هذا صحيح فعلاً. بخلاف مسار ترقية Drupal 6→7، فإن الانتقال من Drupal 7 إلى Drupal الحديث هو في الأساس إعادة بناء. الهندسة معمارية مختلفة بشكل أساسي — قائمة على Symfony، إدارة التكوين، قوالب Twig. الوحدات المخصصة الخاصة بك لن تنقل.
  3. "لدينا 15 سنة من المحتوى والوظائف المخصصة." مواقع Drupal 7 المؤسسية تميل إلى أن تكون مخصصة بشدة. وحدات مخصصة، تكوينات Views، هياكل تصنيف معقدة، تكاملات مع الأنظمة الموروثة. نطاق الهجرة كبير حقاً.
  4. "لم يتم الموافقة على الميزانية." الإجابة الأكثر صراحة، والأكثر شيوعاً.

لم يختف أي من هذه الأسباب، لكن الموعد النهائي وصل. لذا دعنا نتحدث عن ما يجب فعله حقاً.

خيارات الهجرة الخاصة بك في 2025

لديك أربع طرق واقعية للمضي قدماً. كل واحد له مقابلات. دعني أفصلها بصراحة.

الخيار الجدول الزمني نطاق التكلفة الأفضل لـ مستوى المخاطرة
Drupal 10/11 6-18 شهر $200K-$1M+ الفرق المستثمرة في نظام بيئة Drupal متوسط
واجهة أمامية بدون رأس + النهاية الخلفية Drupal 4-12 شهر $150K-$600K الفرق التي تريد UX حديثة مع CMS مألوف متوسط
هجرة CMS بدون رأس 3-9 أشهر $100K-$500K الفرق المستعدة لترك Drupal تماماً متوسط-عالي
بائع الدعم الممتد فوري $30K-$100K/سنة الفرق التي تحتاج إلى 6-18 شهر إضافي لتخطيط منخفض (قصير الأجل)

Drupal 7 End of Life 2025: Migration Guide for Enterprise Teams - architecture

الخيار 1: الهجرة إلى Drupal 10/11

Drupal 10 هو الإصدار المستقر الحالي اعتباراً من 2025، مع إطلاق Drupal 11 في منتصف 2024 واكتساب القبول. إذا كانت فريقك تعرف Drupal، ونموذج محتواك صلب، وتريد البقاء في النظام البيئي، فهذا هو المسار الأكثر مباشرة.

لكن "مباشرة" لا تعني "سهلة".

ما تتضمنه الهجرة فعلاً

يوفر Drupal Migrate API الذي يمكن أن يسحب المحتوى من قاعدة بيانات Drupal 7 إلى موقع Drupal 10/11. في خبرتي، يتعامل مع حوالي 60-70٪ من هجرة نموذجية. الباقي هو مكونات هجرة مخصصة لـ:

  • أنواع الحقول المخصصة
  • مراجع الكيانات المعقدة
  • Paragraphs (إذا استخدمت وحدة Paragraphs)
  • الملفات والأصول الإعلامية
  • الأسماء المستعارة للعناوين وعمليات إعادة التوجيه
  • حسابات المستخدمين والأدوار

يجب إعادة كتابة الوحدات المخصصة الخاصة بك. ليس منقول — تمت إعادة كتابته. يستخدم Drupal 10/11 معمارية مختلفة تماماً. إذا كان لديك وحدة مخصصة تربط hook_node_view()، فأنت الآن تكتب مشتركي الأحداث والمكونات الإضافية.

// Drupal 7 - hook-based
function mymodule_node_view($node, $view_mode, $langcode) {
  if ($node->type == 'article') {
    $node->content['custom_field'] = array(
      '#markup' => '<div>' . custom_logic($node) . '</div>',
      '#weight' => 10,
    );
  }
}

// Drupal 10/11 - OOP, Symfony-based
namespace Drupal\mymodule\EventSubscriber;

use Drupal\core_event\NodeViewEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class NodeViewSubscriber implements EventSubscriberInterface {
  public static function getSubscribedEvents() {
    return [NodeViewEvent::class => 'onNodeView'];
  }
  
  public function onNodeView(NodeViewEvent $event) {
    $node = $event->getNode();
    if ($node->bundle() === 'article') {
      // Your logic here
    }
  }
}

طبقة قوالب Twig أيضاً مختلفة تماماً عن PHPTemplate. كل قالب مخصص يحتاج إلى إعادة بناء.

جدول زمني واقعي

بالنسبة لموقع متوسط الحجم (500-5000 صفحة، 10-20 نوع محتوى، 5-10 وحدات مخصصة)، توقع 9-15 شهراً. يتضمن ذلك الاكتشاف، نمذجة المحتوى، التطوير، هجرة المحتوى، ضمان الجودة، والإطلاق.

الخيار 2: الذهاب بدون رأس مع واجهة أمامية حديثة

هنا حيث يصبح الأمر مثيراً للاهتمام، وبصراحة، إنه النهج الذي أوصي به في أغلب الأحيان للفرق المؤسسية في 2025. احتفظ بـ Drupal كنهاية خلفية لمحتواك (مرقي إلى Drupal 10/11)، لكن بناء الواجهة الأمامية مع إطار عمل JavaScript حديث.

يحتوي Drupal 10/11 على دعم JSON:API ممتاز مدمج في النوى. يمكنك فضح محتواك كبيانات منظمة واستهلاكه مع Next.js أو Astro أو أي إطار عمل أمامي.

لماذا يعمل هذا النهج بشكل جيد

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

لقد بنينا عدة واجهات أمامية Drupal بدون رأس مع Next.js و Astro، وتحسينات الأداء كبيرة. رأى أحد العملاء أن Largest Contentful Paint الخاص به انخفض من 4.2 ثانية إلى 0.8 ثانية بعد الانتقال إلى واجهة أمامية Next.js مع ISR (إعادة توليد ثابتة متدرجة).

// صفحة Next.js تجلب من JSON:API الخاص بـ Drupal
export async function getStaticProps({ params }) {
  const res = await fetch(
    `${process.env.DRUPAL_BASE_URL}/jsonapi/node/article?filter[field_slug]=${params.slug}&include=field_image,field_tags`
  );
  const data = await res.json();
  
  return {
    props: {
      article: data.data[0],
      included: data.included,
    },
    revalidate: 60, // ISR: regenerate every 60 seconds
  };
}

حزمة next-drupal (التي تحتفظ بها Chapter Three) تجعل هذا أسهل حتى مع الدعم المدمج لوضع المعاينة والمصادقة ورسم خريطة نوع المحتوى.

الحبس

تحتاج لا تزال إلى هجرة Drupal 7 إلى Drupal 10/11 على الواجهة الخلفية. أنت لا تتجنب هذا العمل. لكنك تفصل الواجهة الخلفية عن إعادة بناء الواجهة الأمامية، مما يعطيك مرونة أكثر في تسلسل.

الخيار 3: الانتقال إلى CMS بدون رأس بالكامل

في بعض الأحيان، يكون الحل الصحيح هو ترك Drupal تماماً. إذا كانت فريقك لا تمتلك خبرة قوية في Drupal، إذا كنت تواجه صعوبات في توظيف مطوري Drupal (وأنت تفعل — انكمش مجموعة مواهب Drupal بشكل كبير منذ 2020)، أو إذا كان نموذج محتواك قد تجاوز ما يفعله Drupal جيداً، فقد يكون CMS بدون رأس هو الحل الصحيح.

أهداف الهجرة الشهيرة

CMS الأسعار (2025) الأفضل لـ محتوى API منحنى التعلم
Contentful $300-$2,500+/mo فرق تحريرية كبيرة GraphQL + REST متوسط
Sanity $99-$949+/mo (مؤسسة مخصصة) فرق تقودها المطورون GROQ + GraphQL منخفض-متوسط
Storyblok $109-$449+/mo احتياجات التحرير البصري REST + GraphQL منخفض
Strapi (محلي) مجاني (محلي) / $29+/mo (سحابة) الفرق التي تريد السيطرة REST + GraphQL متوسط
Payload CMS مجاني (محلي) / $35+/mo (سحابة) فرق موجهة نحو TypeScript REST + GraphQL متوسط

نعمل مع عدة من هذه من خلال ممارسة تطوير CMS بدون رأس الخاصة بنا. يعتمد الخيار الصحيح على المهارات التقنية لفريقك وتعقيد المحتوى والميزانية.

هجرة المحتوى من Drupal 7 إلى CMS بدون رأس

هذا أسهل فعلاً من الهجرة إلى Drupal 10/11 بطرق ما. أنت لست مقيداً بإطار عمل الهجرة الخاص بـ Drupal. النهج النموذجي:

  1. تصدير محتوى Drupal 7 عبر Drush أو استعلامات قاعدة البيانات المباشرة
  2. تحويل البيانات إلى نموذج محتوى CMS الهدف باستخدام البرامج النصية (Python و Node.js كلاهما يعمل بشكل جيد)
  3. استيراد عبر API إدارة CMS
  4. التحقق من المراجع والوسائط والعلاقات وإصلاحها
# تصدير محتوى Drupal 7 البسيط عبر قاعدة البيانات
import mysql.connector
import json

db = mysql.connector.connect(
    host="localhost",
    user="drupal",
    password="yourpassword",
    database="drupal7_db"
)

cursor = db.cursor(dictionary=True)
cursor.execute("""
    SELECT n.nid, n.title, n.created, n.changed, n.status,
           fdb.body_value, fdb.body_summary
    FROM node n
    LEFT JOIN field_data_body fdb ON n.nid = fdb.entity_id
    WHERE n.type = 'article' AND n.status = 1
    ORDER BY n.created DESC
""")

articles = cursor.fetchall()

with open('articles_export.json', 'w') as f:
    json.dump(articles, f, default=str, indent=2)

print(f"Exported {len(articles)} articles")

الجزء الصعب ليس التصدير. إنها رسم خريطة نموذج محتوى Drupal 7 (مع نظام الحقول والمراجع بين الكيانات وحدود التصنيف وParagraphs) إلى هياكل بيانات CMS جديدة. خطط لأن يستغرق هذا وقتاً كبيراً في التحليل.

الخيار 4: بائعو الدعم الممتد (شراء الوقت)

إذا كنت تحتاج حقاً إلى المزيد من الوقت — وأحياناً تفعل، خاصة مع دورات الميزانية والأولويات التنظيمية — فإن بائعي الدعم الممتد يمكنهم إبقاء موقع Drupal 7 الخاص بك مصروفاً بينما تخطط.

البائعون الرئيسيون الذين يقدمون دعم Drupal 7 الممتد

  • Tag1 Consulting — واحدة من الأكثر رسوخاً. يقومون بنقل رقع الأمان وتوفير الصيانة المستمرة. تختلف الأسعار حسب تعقيد الموقع ولكن توقع $30K-$80K/سنة.
  • Acquia — توفر دعم Drupal 7 الممتد من خلال منصتهم، حالياً حتى 2026 لعملاء المؤسسات.
  • mySociety / مساهمو D7 LTS — دعم ممتد يقوده المجتمع من خلال برنامج Drupal 7 Extended Support.

هذه استراتيجية جسر شرعية، وليست حلاً طويل الأجل. كنت أحده بـ 12-18 شهراً كحد أقصى. كل شهر تبقى فيه على Drupal 7 يزيد من تعقيد الهجرة كلما اتسعت الفجوة بين D7 والمنصات الحديثة.

تخطيط الهجرة: إطار عمل خطوة بخطوة

هنا الإطار الذي أستخدمه مع كل هجرة مؤسسية. إنه ليس براقاً، لكنه يعمل.

المرحلة الأولى: التدقيق (2-4 أسابيع)

  • تدقيق المحتوى: كم عدد أنواع المحتوى؟ كم عدد العقد لكل نوع؟ ما هو تعقيد نموذج المحتوى؟ هل تستخدم Paragraphs أو Field Collections أو Entity Reference؟
  • تدقيق الوحدة: قم بإدراج كل وحدة مساهمة ومخصصة. صنفها كـ: لديها معادل D10، تحتاج إلى استبدال مخصص، يمكن التخلص منها. أستخدم drush pm:list --status=enabled وأقارنها مع drupal.org.
  • تدقيق التكامل: ما هي الأنظمة الخارجية التي يتحدث معها Drupal؟ بوابات الدفع وأنظمة إدارة العلاقات مع العملاء والتسويق الآلي ومزودو خدمات المصادقة الموحدة؟
  • خط أساس حركة المرور والأداء: وثق مقاييس الأداء الحالية. ستحتاج إلى هذه للمقارنة.
  • تدقيق دور المستخدم: كم عدد سير العمل التحريري الموجود؟ ما الأذونات التي تهم؟

المرحلة الثانية: قرار المعمارية (2-3 أسابيع)

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

المرحلة الثالثة: إثبات المفهوم (3-6 أسابيع)

قبل الالتزام بهجرة كاملة، بناء إثبات المفهوم الذي يغطي:

  • نوعا إلى ثلاثة أنواع محتوى مهاجرة إلى المنصة الجديدة
  • سير عمل تحريري معقد للغاية تم إعادة إنتاجه
  • تكامل حرج واحد متصل
  • معايير الأداء على المكدس الجديد

هنا حيث ستكتشف الأشياء التي لم يذكرها أحد أثناء التدقيق. هناك دائماً شيء ما.

المرحلة الرابعة: الهجرة الكاملة (3-12 شهر)

هذا هو العمل الفعلي. أولويات وحشية. ليس كل شيء من Drupal 7 بحاجة إلى القدوم. في خبرتي، يمكن حذف 20-30٪ من المحتوى والوظائف على موقع Drupal 7 المؤسسي النموذجي أثناء الهجرة.

المرحلة الخامسة: ضمان الجودة والإطلاق (2-4 أسابيع)

عمليات إعادة التوجيه حرجة. كل عنوان URL على موقع Drupal 7 الخاص بك له قيمة بحث يحتاج إلى إعادة توجيه 301 إلى الموقع الجديد. استخدم تصدير وحدة path_redirect و globalredirect كنقطة انطلاق، ثم قم بفحص الموقع القديم باستخدام Screaming Frog لبناء خريطة إعادة توجيه كاملة.

استراتيجية هجرة المحتوى

استراتيجية هجرة المحتوى تستحق قسماً خاصاً بها لأنها حيث تذهب معظم الهجرات في اتجاه خاطئ.

مشكلة حقل الجسم

حقول الجسم Drupal 7 عادة ما تكون فوضى من HTML. ستجد أنماط مضمنة وعناوين صور بشفرة ثابتة وإطارات مضمنة وأحياناً PHP خام (إذا قام شخص ما بتفعيل وحدة مرشح PHP — رعب أمان حقيقي). قبل الهجرة، تحتاج إلى اتخاذ قرار: تنظيفها أم نقل الفوضى؟

التوصية الخاصة بي: تنظيفها. اكتب برامج نصية للتحويل التي:

  • تزيل الأنماط المضمنة
  • تحول علامات <img> إلى مراجع وسائط مناسبة
  • إصلاح الروابط الداخلية لاستخدام هيكل العنوان الجديد
  • تحول رموز WYSIWYG المضمنة إلى الصيغة الجديدة

هجرة الوسائط

تتعامل مواقع Drupal 7 مع الوسائط بطرق مختلفة تماماً. البعض يستخدم وحدة Media (1.x أو 2.x)، بعضها يستخدم حقول ملفات عادية، بعضها يستخدم رموز وسائط مضمنة في حقول الجسم. رسّم خريطة لكل نمط معالجة الوسائط قبل أن تبدأ في كتابة كود الهجرة.

إذا كنت تنتقل إلى CMS بدون رأس، فستحتاج أيضاً إلى تحديد مكان وجود ملفات الوسائط. معظم أنظمة إدارة المحتوى بدون رأس لديها إدارة أصول مدمجة، أو يمكنك استخدام DAM مثل Cloudinary أو imgix.

محتوى متعدد اللغات

إذا كان موقع Drupal 7 الخاص بك يستخدم i18n أو entity_translation أو content_translation، فإن تعقيد الهجرة يتضاعف تقريباً. كان نظام Drupal 7 متعدد اللغات... دعنا نقول "إبداعياً". هياكل البيانات غير متسقة وتتطلب رسم خريطة دقيق.

تقديرات التكلفة والجدول الزمني

سأعطيك أرقاماً حقيقية بناءً على المشاريع التي كنت متورطاً فيها أو لدي معرفة مباشرة بها.

تعقيد الموقع هجرة Drupal 10/11 هجرة CMS بدون رأس واجهة أمامية بدون رأس + النهاية الخلفية Drupal
صغير (5-10 أنواع محتوى، <1K صفحة، 2-3 وحدات مخصصة) $80K-$150K، 3-6 أشهر $60K-$120K، 2-4 أشهر $100K-$180K، 3-6 أشهر
متوسط (10-20 نوع محتوى، 1K-10K صفحة، 5-10 وحدات مخصصة) $200K-$500K، 6-12 شهر $150K-$350K، 4-8 أشهر $200K-$450K، 5-10 أشهر
كبير (20+ نوع محتوى، 10K+ صفحة، 10+ وحدات مخصصة، متعدد اللغات) $500K-$1.5M+، 12-24 شهر $300K-$800K، 6-14 شهر $400K-$1M+، 8-18 شهر

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

هل تريد الحصول على تقدير أكثر تحديداً لحالتك؟ نقوم بتقييمات الهجرة التي تعطيك صورة واضحة عن النطاق والتكلفة.

الأخطاء الشائعة التي رأيت الفرق تقترفها

محاولة إعادة الإنشاء 1:1. موقع Drupal 7 الخاص بك تراكم 10+ سنوات من الفوضى. لا تهاجر كل ذلك. استخدم الهجرة كفرصة للتبسيط.

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

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

اختيار منصة بناءً على الميزات، وليس قدرة الفريق. أفضل CMS هو الذي يمكن لفريقك الحفاظ عليه فعلاً. إذا لم تكن لديك خبرة Drupal، فإن الهجرة إلى Drupal 10/11 بدون التوظيف لها تعد نفسك لتكرار هذا الوضع في غضون 5 سنوات.

تشغيل أنظمة متوازية لفترة طويلة. حدد موعد قطع صعب. تشغيل القديم والجديد بالتوازي مكلف ومربك.

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

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

ماذا يحدث إذا استمررت في تشغيل Drupal 7 بعد نهاية الحياة؟ الموقع الخاص بك لن يتوقف فجأة عن العمل. لكنك لن تتلقى رقع أمان، مما يعني أن أي ثغرات حديثة التطور ستبقى غير معالجة إلى أجل غير مسمى. هذا خطر حقيقي — مواقع Drupal هدف متكرر للهجمات الآلية. ستواجه أيضاً مشاكل توافق متزايدة حيث تتقدم إصدارات PHP وموفرو الاستضافة يتخلون عن دعم إصدارات PHP الأقدم. بالنسبة لأي منظمة لديها متطلبات الامتثال (PCI أو HIPAA أو SOC 2 أو GDPR)، فإن تشغيل برنامج غير مدعوم هو انتهاك مباشر.

هل يمكنني الترقية مباشرة من Drupal 7 إلى Drupal 11؟ نعم، يدعم Migrate API الهجرة المباشرة من Drupal 7 إلى Drupal 10 أو 11. أنت لا تحتاج للمرور عبر Drupal 8 و 9. ومع ذلك، هذا ليس "ترقية" بالمعنى التقليدي — إنه إعادة بناء موقعك على منصة جديدة مع هجرة المحتوى. لا تنقل المواضيع والوحدات المخصصة والتكوينات الخاصة بك بشكل مباشر.

كم من الوقت تستغرق هجرة Drupal 7 النموذجية؟ بالنسبة لموقع متوسط الحجم، خطط لـ 6-12 شهراً من بداية الإطلاق. يمكن إجراء المواقع الأصغر ذات الوظائف المخصصة المحدودة في 3-4 أشهر. يمكن أن تستغرق المواقع الكبيرة والمعقدة التي تحتوي على محتوى متعدد اللغات وتكاملات واسعة وتخصيص ثقيل 12-24 شهراً. ستعطيك مرحلة التدقيق تقديراً أكثر دقة لحالتك المحددة.

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

ما هو الخيار الأرخص للهجرة من Drupal 7؟ الدعم الممتد من بائع مثل Tag1 ($30K-$80K/سنة) هو الخيار الأرخص قصير الأجل، لكنه لا يحل المشكلة الأساسية. للهجرة الفعلية، الانتقال إلى CMS بدون رأس مثل Sanity أو Storyblok مع واجهة أمامية ثابتة يميل إلى أن يكون الطريق الأكثر فعالية من حيث التكلفة للمواقع الأبسط، بدءاً من حوالي $60K-$120K. تحقق من صفحة التسعير الخاصة بنا لمزيد من التفاصيل حول كيفية بنية مشاريع الهجرة.

هل سيتأثر ترتيب SEO الخاص بي بالهجرة؟ يمكنهم أن يكونوا، لكن التخطيط السليم يقلل التأثير. العوامل الحرجة هي: الحفاظ على هياكل العناوين (أو تطبيق عمليات إعادة توجيه 301 مناسبة لكل عنوان URL مفهرس)، والحفاظ على البيانات الوصفية والعلامات البنية، والتأكد من أن الموقع الجديد يحمل بسرعة مماثلة على الأقل (يفضل أسرع)، وتقديم ملفات sitemaps محدثة إلى Google Search Console. لقد رأيت هجرات منفذة بشكل جيد تؤدي إلى تحسينات SEO بسبب سرعة صفحة أفضل وتجربة محمول. لقد رأيت أيضاً هجرات سيئة التنفيذ تنهار حركة المرور بنسبة 50٪ لأن شخصاً ما نسي عمليات إعادة التوجيه.

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

هل يجب أن أفكر في WordPress كهدف هجرة؟ WordPress هو خيار قابل للحياة للمواقع الأبسط، لكنني أكون حذراً في حالات الاستخدام المؤسسي. إذا كان موقع Drupal 7 الخاص بك يحتوي على أنواع محتوى معقدة أو أذونات دقيقة أو سير عمل تحريري متطور، فسيبدو WordPress مثل الخطوة للخلف. نموذج محتوى WordPress (المنشورات والصفحات والأنواع المخصصة) أبسط من نظام كيانات Drupal. بالنسبة لفرق المؤسسات، سأنظر بجدية أكبر إلى Drupal 10/11 أو CMS حقيقي بدون رأس. وقال أن WordPress مع ACF Pro وواجهة أمامية بدون رأس يمكن أن تعمل بشكل جيد للمواقع الموجهة للتسويق.