ترحيل Drupal University إلى Next.js

تعتمد جامعة Harvard على Drupal. كذلك تفعل Yale وPrinceton وStanford وDuke. وكذلك جامعتك. تعرف دورة الترقية: D7 إلى D8 كان إعادة بناء كاملة. D8 إلى D9 تطلب عملاً كبيراً. D9 إلى D10 كسر الوحدات المساهمة. D10 إلى D11 قادم أواخر 2026 مع Symfony 7 وTwig 4. بتكلفة ترحيل Drupal واحد آخر، يمكن لجامعتك الانتقال إلى Next.js + Supabase وعدم مواجهة ترحيل CMS قسري مرة أخرى.

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

النظام البيئي لـ Drupal في التعليم العالي

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

أنواع المحتوى الخاصة بالتعليم العالي

مثيل Drupal الخاص بك ربما يحتوي على أكثر من 10 أنواع محتوى مخصصة مبنية للتعليم العالي:

• البرنامج — معلومات الدرجات والشهادات والدورات مع ساعات الدراسة والرسوم والطريقة والنتائج الوظيفية
• هيئة التدريس — ملفات شخصية مع اهتمامات البحث والمنشورات والدورات التي تدرسها وساعات المكتب
• القسم — الهيكل الهرمي (School of Engineering → قسم علوم الحاسوب → مختبر AI)
• الحدث — التقويم الأكاديمي والأحداث العامة والتخرج والأحداث الخاصة بالقسم
• الأخبار — أخبار الجامعة وأخبار الأقسام والإعلانات البحثية والبيانات الصحفية
• الصفحة — مئات صفحات المحتوى الأساسي (حول، القبول، المساعدة المالية)
• المنشور — الأوراق البحثية والتقارير والمستندات السياسية مع روابط DOI
• طلب وظيفة — مناصب هيئة التدريس ومناصب الموظفين والعمل الطلابي
• ملف شخصي — مدخلات دليل الموظفين للموظفين غير الأكاديميين
• شهادة — قصص النجاح الخاصة بالطلاب والخريجين

كل واحد يتم ربطه بجدول Supabase مع تصميم علائقي مناسب. تحصل البرامج على degree_level وsubject_area_id وdelivery_mode وtuition وcareer_outcomes كـ JSONB. تحصل هيئة التدريس على department_id foreign key وpublications كـ JSONB وresearch_areas كمصفوفة. تستخدم الأقسام parent_id للهرمية ذات المرجعية الذاتية.

هذا ليس تفريغ محتوى مسطح. إنه مخطط علائقي مناسب يجعل بيانات الاستعلام عنها بطرق لم تستطع Drupal Views تحقيقها.

Drupal Views → Next.js Server Components

تعتمد مواقع الجامعات بشكل كبير على Drupal Views للقوائم القابلة للتصفية. يصبح كل واحد منها صفحة Next.js أسرع وأكثر مرونة:

• البحث عن البرنامج — Drupal View التصفية حسب الموضوع ومستوى الدرجة والحرم الجامعي → صفحة Next.js /programs مع Supabase query وحالة التصفية المستندة إلى URL. يقوم الطلاب المحتملون بالتصفية حسب مجال الاهتمام والحصول على نتائج فورية.
• دليل هيئة التدريس — Drupal View التصفية حسب القسم ومجال البحث → صفحة Next.js /faculty مع البحث النصي الكامل والتصفية حسب القسم مقابل Supabase.
• تقويم الأحداث — Drupal View التصفية حسب التاريخ والقسم والنوع → صفحة Next.js /events مع تصفية نطاق التاريخ وتصدير iCal.
• موجز الأخبار — Drupal View التصفية حسب القسم والفئة → صفحة Next.js /news مع ISR بحيث تظهر المقالات الجديدة في غضون 60 ثانية من النشر.
• لوحة الوظائف — Drupal View التصفية حسب القسم ونوع الاستخدام → صفحة Next.js /careers سحب من Supabase مع منطق تاريخ الإغلاق.

الفرق: ينشئ Drupal Views تحميلات صفحة كاملة عند كل تغيير تصفية. مكونات خادم Next.js مع Supabase تُرجع نتائج مصفاة في أقل من 100 ميلي ثانية بدون تحميل صفحة كامل.

Drupal Taxonomy → Supabase Relations

تتم معالجة مفردات تصنيف Drupal إلى جداول علائقية مناسبة:

• مجالات الموضوع vocabulary → جدول subject_areas وprograms.subject_area_id FK
• الأقسام vocabulary → جدول departments مع parent_id للهرمية
• مواقع الحرم الجامعي vocabulary → جدول campuses وprograms.campus_id FK
• مجالات البحث vocabulary → جدول research_areas + جدول join faculty_research_areas
• أنواع الأحداث vocabulary → عمود event_type enum أو جدول البحث

تصبح حقول Entity Reference في Drupal foreign keys مناسبة. علاقات المراجع المتعددة (faculty ↔ research areas) تحصل على جداول join. يصبح نموذج البيانات صريحاً بدلاً من إخفاؤه خلف Entity API في Drupal.

Paragraphs + Layout Builder → كتل المكونات

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

نخزن هذه كـ JSONB في عمود Supabase pages.blocks:

[
  {"type": "hero", "title": "...", "subtitle": "...", "image": "...", "cta_url": "..."},
  {"type": "stats", "items": [{"number": "15:1", "label": "Student-Faculty Ratio"}]},
  {"type": "program_cards", "program_ids": [12, 45, 78]},
  {"type": "faculty_spotlight", "faculty_id": 234}
]

تقوم سجل مكون Next.js بتصيير كل نوع كتلة. يدير المحررون الكتل من خلال Payload CMS أو واجهة المسؤول المخصصة. نفس المرونة مثل Paragraphs، تقديم أسرع، وعدم إعادة بناء ذاكرة التخزين المؤقت Drupal في الانتظار.

مواقع أقسام متعددة الصفحات

تدير الجامعات الكبيرة 15-30 موقع فرعي Drupal — School of Business وSchool of Engineering وCollege of Arts & Sciences — كل واحد على عمليات تثبيت Drupal منفصلة أو multisite Drupal. هذا كابوس تشغيلي: تحديثات الوحدات عبر 20 موقع، مواضيع غير متسقة، البنية التحتية المكررة.

نوحد كل شيء في تطبيق Next.js واحد مع طرق /departments/[slug]. يحصل كل قسم على قسمه الخاص مع هوية فرعية للعلامة التجارية (ألوان لهجة مخصصة ضمن نظام تصميم الجامعة). يحتوي كل قسم على صفحات وأخبار وأحداث وهيئة تدريس.

المفتاح: Supabase Row Level Security (RLS). يرى محررو الأقسام ويحررون المحتوى حيث department_id يطابق قسمهم المعين. لا يستطيع محرر ويب School of Business تحرير محتوى الهندسة عن طريق الخطأ. تفرض RLS هذا على مستوى قاعدة البيانات — وليس في كود التطبيق وليس في أذونات CMS. إنها هيكلية.

بوابة الطلاب وتكامل SSO

يقوم موقع Drupal الحالي بمصادقة الطلاب عبر CAS أو Shibboleth، والاتصال بموفر الهوية (ADFS أو Okta أو Shibboleth يدار من قبل الجامعة). يرى الطلاب محتوى شخصياً: متطلبات برنامجهم ومعلومات المستشار وموارد خاصة بالقسم.

يدعم Supabase Auth نطاق SAML 2.0 نطاقاً. نقوم بتكوين موفر الهوية بالجامعة كموفر SAML في Supabase. التدفق:

1. ينقر الطالب على "Sign In" على موقع Next.js
2. إعادة التوجيه إلى جامعة IdP (Shibboleth/ADFS/Okta)
3. يقوم الطالب بالمصادقة مع بيانات اعتماد الجامعة
4. يرسل IdP تأكيد SAML مرة أخرى إلى Supabase
5. تصدر Supabase JWT مع دور الطالب والقسم
6. تتحكم سياسات RLS في البيانات التي يرونها

لا توجد كود مصادقة مخصص. لا توجد مشاكل إدارة الجلسات. يحمل JWT المطالبات، وقراءة Supabase RLS لهم.

ترحيل دور المستخدم

تعين أدوار Drupal في الجامعات — Site Admin وWeb Editor وDepartment Editor وFaculty وStudent وAlumni — إلى جدول user_roles في Supabase مع تعيينات الدور لكل مستخدم. تشير سياسات RLS إلى هذه الأدوار:

• Site Admin: قراءة/كتابة كاملة على جميع الجداول
• Department Editor: read/write حيث department_id = auth.jwt()->department_id
• Faculty: تحديث ملفهم الشخصي، إضافة منشورات
• Student: قراءة فقط على المحتوى العام، بيانات لوحة معلومات مخصصة

ترحيل التعليم العالي من 7 مراحل

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

زحف Screaming Frog لكل عنوان URL. تحليل حركة Google Search Console لتحديد صفحاتك ذات القيمة العالية. جرد نوع المحتوى عبر جميع المواقع الفرعية. تدقيق الدمج: ما يتصل بـ Drupal؟ Banner؟ PeopleSoft؟ Canvas؟ Slate؟ أساسي الوصول مع درجات Lighthouse وأي شكاوى ADA موجودة.

المرحلة 2: تصميم الهندسة والمخطط (1 أسبوع)

مخطط Supabase مع الجداول والعلاقات وسياسات RLS. هيكل طريق Next.js. هرمية الملاحة. القرار بشأن واجهة المسؤول: Payload CMS للمحررين غير التقنيين أو لوحة معلومات Supabase مخصصة. معمارية التكامل لـ SSO وعمليات سحب بيانات SIS وـ webhooks CRM.

المرحلة 3: تصدير البيانات من Drupal (1-2 أسبوع)

D8/D9/D10: تصدير JSON:API عبر /jsonapi/node/program?page[limit]=50 مع الترقيم من خلال كل نوع محتوى. D7: استعلامات MySQL مباشرة مقابل جداول حقل Drupal. تصدير الوسائط من الأنظمة public:// وprivate:// المرئية. الملف الشخصي للمستخدم وتصدير الخصومات. استخراج هيكل القائمة.

المرحلة 4: البناء (3-8 أسابيع)

تطبيق Next.js مع جميع قوالب الصفحات. جداول Supabase مليئة بالبيانات المحولة وسياسات RLS نشطة. البحث عن البرنامج مع المرشحات المتعددة. دليل هيئة التدريس مع البحث. أقسام الأقسام. بوابة الطالب مع SSO. واجهة المسؤول. جميع التكاملات — سحب بيانات SIS و webhooks CRM وحجز جولة الحرم الجامعي.

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

تحويل صادرات Drupal إلى نصوص إدراج Supabase. استيراد جميع أنواع المحتوى. تحميل الوسائط إلى Supabase Storage أو Vercel Blob. إعادة كتابة عناوين URL الوسائط في المحتوى. فحص العينات 10٪ من كل نوع محتوى. اختبر كل عامل تصفية والبحث ومسار الملاحة.

المرحلة 6: تعيين الإعادة الموجهة (1 أسبوع)

هذا حرج للجامعات. يحتوي نطاق .edu الخاص بك على آلاف الروابط الخلفية من مؤسسات تعليمية أخرى ومواقع حكومية وقواعد بيانات البحث. فقدان هذه الروابط الخلفية كارثي لسلطة SEO. نقوم بتعيين كل عنوان URL Drupal — الأسماء المستعارة ومسارات النظام (/node/1234) وعناوين URL الموقع الفرعي — إلى طرق Next.js الجديدة. يتم تنفيذه عبر middleware Next.js للحصول على سعة إعادة توجيه غير محدودة.

المرحلة 7: الإطلاق والمراقبة (مستمر)

قطع DNS. تقديم خريطة الموقع الجديد إلى Google Search Console. مراقبة 404 يومياً لأول 30 يوماً. تدريب الموظفين على Payload CMS أو المسؤول المخصص. تدريب إداري القسم. تدريب سير عمل تحديث هيئة التدريس الذاتي. 30 يوم hypercare مع مراقبة يومية والتحقق الأسبوعي مع فريق الويب لديك.

التسعير

نوع المؤسسة	الصفحات	النطاق	الجدول الزمني	الاستثمار
كلية المجتمع	أقل من 500	البحث عن البرنامج والدليل الأساسي والأخبار	6–8 أسابيع	50-80 ألف دولار
جامعة متوسطة الحجم	500–2,000	البحث عن البرنامج ودليل هيئة التدريس وأقسام الأقسام والأحداث	8–12 أسابيع	80-150 ألف دولار
جامعة كبيرة	2,000+	متعدد الحرم الجامعي وأقسام فرعية وبوابة طلاب و SSO و i18n	10–16 أسابيع	120-200 ألف دولار

لماذا الآن: ساعة D11 تدق

يصل Drupal 11 أواخر 2026 مع Symfony 7 وTwig 4. الجامعات على D10 تواجه قرار الترحيل في الأشهر القادمة 6-12. يعمل ترحيل D10 إلى D11 بحد أدنى 30-60 ألف دولار — وستواجه D12 في 3-4 سنوات أخرى.

يعمل ترحيل Next.js + Supabase 50-200 ألف دولار حسب النطاق، لكن التكلفة الإجمالية للملكية لمدة 5 سنوات أقل من البقاء على Drupal. لا توجد ترقيات قسرية. لا توجد كسور وحدة مساهمة. لا يوجد نصائح أمان Drupal تتطلب رقع طوارئ. ينقسم إطار العمل الخاص بك في الجدول الزمني الخاص بك وليس Drupal.

بتكلفة ترحيل Drupal واحد آخر، اجعله آخر واحد لك.