في أوائل عام 2024، توجهت جامعة حكومية كبيرة إلينا بمشكلة أصبحت شائعة بشكل مؤلم في التعليم العالي: كان تثبيت Drupal 7 الخاص بهم يقترب من نهاية عمره، وكان بوابة الطلاب الخاصة بهم تنهار تحت الحمل أثناء فترات التسجيل، وكان محرك البحث عن البرامج — الأداة الأكثر أهمية للتحويل على موقعهم — يستغرق أكثر من 8 ثوان لإرجاع نتائج البحث. كان لديهم 40,000 طالب نشط، وأكثر من 200 برنامج أكاديمي، وفترة ستة أشهر قبل انتهاء دعم أمان Drupal 7 بشكل فعلي. لا ضغط على الإطلاق.

هذه قصة كيف أننا هاجرنا كل شيء إلى Next.js مع خادم CMS بدون رأس، وقللنا أوقات تحميل الصفحات بنسبة 73%، وسلمناه في الموعد المحدد. سأشارك قرارات العمارة التي اتخذناها (والتي كادت أن نخطئ فيها)، والعملية الفعلية للهجرة، ومقاييس الأداء، والدروس التي تنطبق على أي هجرة CMS على نطاق واسع.

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

حالة دراسة: هجرة بوابة جامعة من Drupal إلى Next.js

نقطة البداية: ما الذي كنا نعمل معه

دعني أرسم الصورة. كان الوجود الرقمي للجامعة مبنياً على Drupal 7، تم إطلاقه في الأصل حوالي عام 2014. على مدى العقد الماضي، تراكم لديه:

  • حوالي 12,000 عقدة محتوى عبر البرامج والدورات وملفات تعريف أعضاء هيئة التدريس والمقالات الإخبارية والأحداث
  • أكثر من 200 صفحة برنامج أكاديمي لكل منها علاقات تصنيف معقدة (مستوى الدرجة والقسم والكلية وصيغة التقديم وحالة الاعتماد)
  • محرك بحث برامج مخصص مبني كبحث قائم على Drupal Views مع فلاتر مكشوفة — وظيفي لكن بطيء
  • بوابة طلاب مع وصول مصرح به لأدوات الإرشاد والتدقيق في الدرجات وروابط التسجيل واللوحات الشخصية
  • 47 وحدة Drupal مخصصة، 19 منها لم تعد مدعومة
  • 3 طبقات موضوع مختلفة مكدسة فوق بعضها من إعادة تصميم متتالية

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

كانت Core Web Vitals خشنة:

المقياس Drupal 7 (قبل) الهدف
LCP 6.2 ثانية < 2.5 ثانية
FID 380 مللي ثانية < 100 مللي ثانية
CLS 0.31 < 0.1
TTFB 2.8 ثانية < 0.8 ثانية
تحميل محرك البحث عن البرامج 8.4 ثانية < 1.5 ثانية

مشهد أصحاب المصلحة

مشاريع الويب الجامعية فريدة من نوعها بسبب عدد أصحاب المصلحة. كنا نعمل مع:

  • IT المركزية — مسؤولة عن تكامل SSO والامتثال الأمني والاستضافة
  • التسويق والاتصالات — تمتلك العلامة التجارية واستراتيجية المحتوى والتحليلات
  • مكتب المسجل — يمتلك بيانات البرنامج ونظام معلومات الطلاب (SIS)
  • الكليات والأقسام الفردية — لكل منها محررو محتوى خاص بهم (أكثر من 80 شخصاً لديهم وصول CMS)
  • حكومة الطلاب — الذين دافعوا بقوة عن تصميم الهاتف أولاً (بحق)

استغرق الحصول على محاذاة من كل هذه المجموعات الثلاثة أسابيع الأولى من المشروع. أجرينا sprint تصميم لتحديد الأولويات المشتركة وغير القابلة للتفاوض.

لماذا Next.js (ولماذا ليس Drupal 10)

السؤال الواضح: لماذا لا نقوم بترقية Drupal 10 ببساطة؟ كان فريق IT الخاص بالجامعة قد بدأ بالفعل في هذا المسار قبل ستة أشهر من الاتصال بنا. تخلوا عنه بعد اكتشاف أن 23 من أصل 47 وحدة مخصصة لم يكن لها مكافئ Drupal 10 وستحتاج إلى إعادة كتابة كاملة.

بدت الحسابات الفعلية هكذا:

العامل هجرة Drupal 10 إعادة بناء Next.js
الجدول الزمني المقدر 8-10 أشهر 6 أشهر
إعادة كتابة الوحدات المخصصة 23 وحدة غير متطبق (إعادة بناء كواجهات برمجية/مكونات)
إعادة تدريب محرر المحتوى معتدل (واجهة إدارة جديدة) معتدل (CMS جديد)
سقف الأداء تحسن متوسط تحسن درامي
مرونة الاستضافة LAMP التقليدية/مشابهة نشر الحافة، CDN أولاً
مجموعة توظيف المطورين تتقلص (متخصصو Drupal) النمو (React/Next.js)
تكلفة الصيانة طويلة الأجل حوالي 180,000 دولار سنوياً حوالي 95,000 دولار سنوياً

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

اخترنا Next.js تحديداً (على Gatsby أو Remix أو Astro) لعدة أسباب:

  1. التصيير الهجين — يمكن أن تكون صفحات البرنامج مُنتجة بشكل ثابت، بينما كانت بوابة الطلاب تحتاج إلى تصيير من جانب الخادم مع المصادقة
  2. مسارات API — يمكننا بناء middleware لتكامل SIS دون خدمة خلفية منفصلة
  3. Incremental Static Regeneration (ISR) — بيانات البرنامج تتغير أسبوعياً وليس كل ساعة. ISR بنافذة إعادة التحقق لمدة ساعة واحدة كان مثالياً
  4. فريق الجامعة يعرف React — سيحتفظون بهذا بعد التسليم

إذا كنت تزن خيارات مماثلة، فإن صفحة قدرات تطوير Next.js الخاصة بنا تغطي التفاصيل التقنية لما نبنيه عادة.

قرارات العمارة

اختيار CMS بدون رأس

قمنا بتقييم خمس خيارات CMS بدون رأس مقابل متطلبات الجامعة: 80+ محرر محتوى، علاقات محتوى معقدة، أذونات قائمة على الأدوار، وطراز تسعير معقول لكل مقعد.

هبطنا على Sanityلهذا المشروع. العوامل الرئيسية:

  • استعلامات GROQ تعاملت مع العلاقات التصنيفية المعقدة بين البرامج والأقسام والكليات بشكل أفضل بكثير من GraphQL لهذه الحالة الاستخدام
  • التعاون في الوقت الفعلي — يمكن لعدة محررين العمل في نفس الوقت دون تضاربات
  • المكونات المدخلة المخصصة — بنينا خريطة متطلبات البرنامج مباشرة في الاستوديو
  • التسعير — كان خطة Enterprise بحوالي 949 دولار/شهر ضمن الميزانية، وكانت التكلفة لكل مستخدم قابلة للتنبؤ

استغرق نمذجة المحتوى حوالي أسبوعين. حددنا 14 نوع مستند و 8 أنواع مرجعية. كان مخطط البرنامج وحده يحتوي على 34 حقل، بما في ذلك البيانات المنظمة لرموز schema.org EducationalOrganization و Course.

لمزيد من المعلومات حول نهجنا في معمارية CMS، راجع صفحة تطوير CMS بدون رأس الخاصة بنا.

البنية الأساسية

نشرنا على Vercel لواجهة Next.js الأمامية (خطة Enterprise، مطلوبة لامتثال FERPA ومتطلبات SSO). تستخدم مسارات بوابة الطلاب المصرح بها تصيير من جانب الخادم مع إدارة الجلسات من خلال CAS (خدمة المصادقة المركزية) SSO الموجودة بالفعل في الجامعة.

تدفق البيانات يبدو هكذا:

[Sanity CMS] → [Next.js on Vercel] → [CDN Edge]
                    ↕
           [University SIS API]
                    ↕
           [CAS SSO / LDAP]

يتم إعادة إنتاج صفحات البرنامج الثابتة في وقت الإنشاء وإعادة التحقق كل ساعة عبر ISR. يستخدم محرك البحث عن البرامج مزيجاً من البيانات المجلوبة مسبقاً (محملة في العميل في وقت الإنشاء كفهرس JSON) والتصفية في الوقت الفعلي — لا حاجة لاستدعاء الخادم لعمليات البحث.

طبقة API

قام نظام معلومات الطلاب (Ellucian Banner، إذا كنت فضولياً — إنها دائماً Banner) بفضح واجهة برمجية SOAP. نعم، في عام 2024. قمنا ببناء طبقة ترجمة باستخدام مسارات Next.js API التي استهلكت نقاط نهاية SOAP وعرضت نقاط نهاية REST نظيفة للواجهة الأمامية:

// /app/api/programs/[programId]/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { fetchFromBanner } from '@/lib/banner-client';
import { transformProgramData } from '@/lib/transforms';

export async function GET(
  request: NextRequest,
  { params }: { params: { programId: string } }
) {
  const bannerData = await fetchFromBanner(
    'PROGRAM_DETAIL',
    { programCode: params.programId }
  );
  
  const program = transformProgramData(bannerData);
  
  return NextResponse.json(program, {
    headers: {
      'Cache-Control': 'public, s-maxage=3600, stale-while-revalidate=86400',
    },
  });
}

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

حالة دراسة: هجرة بوابة جامعة من Drupal إلى Next.js - العمارة

محرك البحث عن البرامج: إعادة بناء الميزة الأساسية

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

النهج القديم (ولماذا كان بطيئاً)

استخدمت نسخة Drupal Views مع فلاتر مكشوفة. أدى كل تغيير مرشح إلى جولة خادم كاملة، أعادت استعلام قاعدة البيانات، وأعادت تصيير الصفحة بالكامل. مع 200+ برنامج و 6 أبعاد تصنيف (مستوى الدرجة والكلية والقسم وصيغة التقديم ومجال الاهتمام والبحث عن الكلمات الرئيسية)، كان الاستعلام مكلفاً.

النهج الجديد

قمنا بإنشء فهرس بحث مسبق في وقت الإنشاء. تم سلسلة جميع 200+ برنامج في ملف JSON يبلغ حوالي 180 كيلوبايت (مضغوط إلى 22 كيلوبايت) يتم شحنه مع الصفحة. يحدث التصفية بالكامل من جانب العميل باستخدام hook مخصص:

// hooks/useProgramSearch.ts
import { useMemo, useState } from 'react';
import Fuse from 'fuse.js';
import { Program, ProgramFilters } from '@/types';

const fuseOptions = {
  keys: [
    { name: 'title', weight: 0.4 },
    { name: 'description', weight: 0.2 },
    { name: 'keywords', weight: 0.3 },
    { name: 'department', weight: 0.1 },
  ],
  threshold: 0.3,
};

export function useProgramSearch(programs: Program[]) {
  const [filters, setFilters] = useState<ProgramFilters>({});
  const fuse = useMemo(() => new Fuse(programs, fuseOptions), [programs]);

  const results = useMemo(() => {
    let filtered = programs;

    if (filters.degreeLevel) {
      filtered = filtered.filter(p => p.degreeLevel === filters.degreeLevel);
    }
    if (filters.college) {
      filtered = filtered.filter(p => p.college === filters.college);
    }
    if (filters.deliveryFormat) {
      filtered = filtered.filter(p => 
        p.deliveryFormats.includes(filters.deliveryFormat!)
      );
    }
    if (filters.searchQuery) {
      const fuseResults = fuse.search(filters.searchQuery);
      const fuseIds = new Set(fuseResults.map(r => r.item.id));
      filtered = filtered.filter(p => fuseIds.has(p.id));
    }

    return filtered;
  }, [programs, filters, fuse]);

  return { results, filters, setFilters };
}

استخدمنا Fuse.js للبحث النصي الغامض والتصفية العادية في JavaScript للجوانب. النتيجة: تظهر نتائج البحث في أقل من 50 مللي ثانية. لا توجد مؤشرات تحميل. لا استدعاءات خادم. يمكن للمستخدمين النقر على المرشحات بأسرع ما يريدون.

يرتبط كل نتيجة برنامج بصفحة تفاصيل مُنتجة بشكل ثابت مع رموز schema.org الكاملة، مما يحسن بشكل كبير ظهور الجامعة في ميزات البحث ذات الصلة بالتعليم من Google.

هجرة بوابة الطلاب

كانت بوابة الطلاب الجزء الأكثر صعوبة. كانت تتطلب المصادقة والتخصيص والبيانات في الوقت الفعلي من Banner. لم نستطع إنتاج أي منها بشكل ثابت.

سير عمل المصادقة

تستخدم الجامعة CAS للدخول الموحد عبر جميع الأنظمة المؤسسية. دمجنا CAS مع Next.js باستخدام سير عمل مصادقة مخصص:

  1. مستخدم غير مصرح يضرب /portal → يتم إعادة التوجيه إلى تسجيل الدخول CAS
  2. CAS يعيد التوجيه مرة أخرى مع تذكرة الخدمة
  3. مسار API الخاص بنا يتحقق من التذكرة مقابل خادم CAS
  4. نحن ننشئ JWT موقع مخزن في ملف تعريف ارتباط httpOnly
  5. الطلبات اللاحقة تستخدم JWT لإدارة الجلسات

استخدمنا next-auth (الآن Auth.js) مع موفر CAS مخصص كتبناه من الصفر، لأنه لا يوجد موفر CAS مدعوم في ذلك الوقت.

ميزات البوابة

تضمنت بوابة الطلاب:

  • لوحة معلومات شخصية مع تواريخ التسجيل القادمة والمعالجات ومعلومات الإرشاد
  • ملخص تدقيق الدرجات تم سحبه من Banner في الوقت الفعلي
  • روابط سريعة إلى نظام إدارة التعلم (Canvas) والبريد الإلكتروني والمكتبة
  • موارد خاصة بالبرنامج بناءً على التخصص المعلن للطالب

تستخدم جميع صفحات البوابة تصيير من جانب الخادم. نحن نخزن مؤقتاً لاستجابات واجهة برمجية Banner بشكل قوي (TTL 30 ثانية لمعظم نقاط النهاية، TTL 5 دقائق لتدقيقات الدرجات) لتجنب إرهاق نظامهم.

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

كانت هجرة 12,000 عقدة محتوى من Drupal إلى Sanity تتطلب نهجاً منهجياً. بنينا خط أنابيب هجرة مخصص:

# خط أنابيب الهجرة المبسط
1. تصدير عقد Drupal → JSON عبر أوامر Drush المخصصة
2. تحويل JSON → صيغة مستند Sanity عبر نصوص Node.js
3. معالجة ملفات الوسائط → التحميل إلى CDN Sanity
4. استيراد المستندات → Sanity Migration API
5. التحقق → فحوصات مؤتمتة للمراجع المنقطعة

كانت هجرة الوسائط أكثر الأجزاء مملة. يخزن إدارة الملفات في Drupal الملفات بمسارات داخلية ومراجع قاعدة بيانات. كتبنا نص برمجي يقوم بـ:

  1. تنزيل كل ملف من دليل ملفات Drupal
  2. تحميله إلى خط أنابيب أصول Sanity
  3. تعيين معرفات ملفات Drupal القديمة إلى مراجع أصول Sanity الجديدة
  4. تحديث جميع محتوى النص الغني للإشارة إلى مراجع الأصول الجديدة

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

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

طبقنا فترة تجميد محتوى على مرحلتين:

  • الأسابيع 1-20: يعمل محررو المحتوى في Drupal بشكل طبيعي. نهاجر لقطات إلى التحضير أسبوعياً.
  • الأسابيع 21-23: إدخال مزدوج. يدخل المحتوى الجديد في Drupal و Sanity. تم تدريب المحررين على CMS الجديد.
  • الأسبوع 24: التحويل الكامل. يصبح Drupal للقراءة فقط، ثم يختفي.

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

الجدول الزمني لمدة 6 أشهر

الشهر المرحلة المسلمات الرئيسية
الشهر 1 الاكتشاف والعمارة محاذاة أصحاب المصلحة، اختيار CMS، إعداد البنية الأساسية، نمذجة المحتوى
الشهر 2 التطوير الأساسي نظام التصميم، قوالب الصفحة، صفحات تفاصيل البرنامج، التنقل
الشهر 3 محرك البحث عن البرامج والبحث فهرس البحث، واجهة التصفية، خط أنابيب بيانات البرنامج، رموز SEO
الشهر 4 بوابة الطلاب تكامل CAS، طبقة Banner API، لوحة المعلومات، عرض تدقيق الدرجات
الشهر 5 هجرة المحتوى والتدريب نصوص الهجرة، تدريب المحررين (6 جلسات)، ضمان جودة التحضير
الشهر 6 ضمان الجودة والأداء والإطلاق اختبار الحمل، تدقيق إمكانية الوصول، تجميد المحتوى، تحويل DNS

كان فريقنا 4 مطورين و 1 مصمم و 1 مدير مشروع. قدمت الجامعة مالك منتج مخصص بالإضافة إلى ارتباط IT لعمل تكامل Banner/CAS.

واجهنا عقبتان رئيسيتان:

  1. الشهر 3: كانت واجهة برمجية SOAP الخاصة بـ Banner تحتوي على حد معدل غير موثق وهو 100 طلب/دقيقة. تم تصميم محرك البحث عن البرامج الخاص بنا للجلب على دفعات من جميع بيانات البرنامج أثناء الإنشاء. اضطررنا إلى تنفيذ نظام قائمة انتظار ونشر الإنشاء عبر دفعات متعددة.

  2. الشهر 5: وجد تدقيق إمكانية الوصول 34 انتهاكاً من WCAG 2.1 AA. كانت معظمها موروثة من التصميم (تباين لون غير كافٍ على الأزرار الثانوية، مؤشرات التركيز المفقودة على فلاتر محرك البحث عن البرامج). قضينا 8 أيام غير مخطط لها على المعالجة.

نتائج الأداء

إليك ما بدت عليه الأرقام بعد الإطلاق:

المقياس Drupal 7 (قبل) Next.js (بعد) التحسن
LCP 6.2 ثانية 1.1 ثانية أسرع بـ 82%
FID / INP 380 مللي ثانية 45 مللي ثانية أسرع بـ 88%
CLS 0.31 0.02 أفضل بـ 94%
TTFB 2.8 ثانية 0.12 ثانية أسرع بـ 96%
تحميل محرك البحث عن البرامج 8.4 ثانية 0.8 ثانية أسرع بـ 90%
درجة Lighthouse 34 97 +63 نقطة
وقت الإنشاء (كامل) غير متطبق 4 دقائق 12 ثانية —
تكلفة الاستضافة الشهرية حوالي 2,400 دولار حوالي 1,100 دولار أقل بـ 54%

لكن الأرقام التي كانت أكثر أهمية للجامعة كانت هذه:

  • زيادة استخدام محرك البحث عن البرامج بـ 156% في الفصل الدراسي الأول بعد الإطلاق
  • انخفضت معدل الارتداد على الهاتف المحمول من 67% إلى 31%
  • زيادة حركة البحث العضوي إلى صفحات البرنامج بـ 43% خلال 4 أشهر (رموز schema.org + تحسينات Core Web Vitals)
  • انخفضت تذاكر الدعم المتعلقة بالبوابة بـ 62% — إلى حد كبير لأن الصفحات تحميل موثوق
  • صفر انقطاع أثناء التسجيل بالخريف — لأول مرة في ثلاث سنوات

الدروس المستفادة

1. ابدأ تكامل CAS/SSO مبكراً

جدولنا تكامل CAS للشهر 4. كان يجب أن نبدأ بدليل مفهوم في الشهر 1. تتحرك فرق IT الجامعية بعناد (اقرأ: بطء) من خلال مراجعات الأمان. استغرق الحصول على الموافقة على معمارية SSO ثلاثة أسابيع من الذهاب والإياب مع مكتب الأمان الخاص بهم.

2. نمذجة المحتوى هي العمارة

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

3. تدريب المحررين مبكراً وليس قبل الإطلاق

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

4. Banner هو Banner

إذا كنت تعمل مع Ellucian Banner (واحتمالاً أنك تعمل في التعليم العالي)، فامنح وقتاً إضافياً لعمل تكامل API. التوثيق نادر، ونقاط نهاية SOAP غير متسقة، وقد قامت كل مؤسسة بتخصيص نموذج Banner الخاص بها بشكل مختلف. كانت طبقة الترجمة الخاصة بنا ضرورية.

5. ميزانية إمكانية الوصول من اليوم الأول

كانت انتهاكاتنا الـ 34 من WCAG في الشهر 5 قابلة للوقاية في الغالب. نحن الآن نشغل فحوصات axe-core في خط أنابيب CI الخاص بنا في كل طلب سحب. إذا كنت تبني لجامعة عامة، فإن امتثال WCAG 2.1 AA ليس اختياراً — إنه متطلب قانوني بموجب القسم 508.

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

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

كم من الوقت يستغرق هجرة موقع جامعة من Drupal إلى Next.js؟ بالنسبة لموقع بهذا الحجم — 12,000 عقدة محتوى، 200+ برنامج، بوابة طلاب مصرح بها — ستة أشهر واقعي مع فريق مخصص من 4-6 أشخاص. يمكن غالباً إنجاز مواقع المؤسسات الأصغر (أقل من 2,000 صفحة، بدون بوابة) في 3-4 أشهر. يتم تحديد الجدول الزمني بشكل أقل من خلال بناء الواجهة الأمامية وأكثر من خلال هجرة المحتوى ومحاذاة أصحاب المصلحة والتكامل مع الأنظمة المؤسسية مثل Banner أو PeopleSoft.

ما هو أفضل CMS بدون رأس للمواقع الجامعية؟ يعتمد على حجم فريق التحرير والراحة التقنية. اخترنا Sanity لهذا المشروع بسبب التعاون في الوقت الفعلي ونمذجة المحتوى المرنة ولغة استعلام GROQ. Contentful و Storyblok أيضاً خيارات قوية. بالنسبة للجامعات التي تضم فريق محتوى كبير جداً (100+ محرر)، يمكن أن تكون نموذج سير العمل والأذونات في Contentful مفيدة. بالنسبة للفرق الأصغر التي تريد المزيد من التخصيص، تميل Sanity إلى الفوز.

هل يمكن لـ Next.js التعامل مع بوابات الطلاب المصرح بها؟ بالتأكيد. يدعم Next.js تصيير من جانب الخادم للصفحات المصرح بها، وتجعل مكونات خادم App Router من الواضح بشكل مباشر جلب بيانات مخصصة للمستخدم دون كشفها لحزمة العميل. قمنا بالتكامل مع CAS (خدمة المصادقة المركزية) باستخدام Auth.js مع موفر مخصص. تعاملت البوابة مع 40,000 طالب بدون مشاكل الأداء.

كم يكلف هجرة Drupal إلى Next.js لجامعة؟ يتراوح مشروع بهذا الحجم — محرك البحث عن البرامج وبوابة الطلاب و 200+ برنامج والهجرة الكاملة للمحتوى وإعداد CMS والتدريب — عادة من 250,000 دولار إلى 450,000 دولار اعتماداً على التعقيد. ومع ذلك، فإن المدخرات طويلة الأجل كبيرة. قللت هذه الجامعة تكاليف الصيانة السنوية من حوالي 180,000 دولار إلى 95,000 دولار، مما يعني أن المشروع يدفع نفسه خلال 3-4 سنوات حتى عند الطرف الأعلى من نطاق الميزانية.

ماذا يحدث للـ SEO أثناء هجرة CMS كبيرة الحجم؟ هذا قلق شرعي. طبقنا خريطة إعادة توجيه شاملة (أكثر من 2,400 إعادة توجيه 301)، حافظنا على جميع هياكل عناوين URL الموجودة حيث كان ذلك ممكناً، وأضفنا بيانات منظمة schema.org التي كان موقع Drupal يفتقدها. انخفضت حركة البحث العضوية حوالي 8% في أول أسبوعين بعد الإطلاق (طبيعي لأي هجرة كبيرة)، ثم تعافت وتجاوزت خط الأساس بـ 43% خلال أربعة أشهر.

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

كيف تتعامل مع هجرة المحتوى من Drupal إلى CMS بدون رأس؟ نستخدم نصوص برمجية Node.js مخصصة تصدر محتوى Drupal عبر أوامر Drush، تحول البيانات لمطابقة مخطط CMS الجديد، تتعامل مع هجرة ملفات الوسائط، وتستورد كل شيء عبر API الهجرة الخاصة بـ CMS. عادة ما تعمل العملية 3 مرات: مرة للاختبار الأولي، ومرة لتحديث التحضير، ومرة للتحويل النهائي. المحتوى النصي الغني مع الوسائط المدمجة هو الجزء الأصعب — تحتاج إلى إعادة تعيين كل مرجع ملف داخلي.

هل يمكنك تشغيل Drupal و Next.js في نفس الوقت أثناء الهجرة؟ نعم، وننصح به. أثناء هجرتنا، استمر Drupal في خدمة موقع الإنتاج بينما كنا نبني واختبار نسخة Next.js على مجال التحضير. استخدمنا فترة ثلاثة أسابيع من الإدخال المزدوج حيث دخل المحتوى في كلا النظامين. كان التحويل النهائي عبارة عن مفتاح DNS استغرق حوالي 15 دقيقة، مع إبقاء Drupal في الوضع للقراءة فقط لمدة 30 يوماً كخطة احتياطية.