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

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

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

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

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

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

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

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

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

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

مشهد المساهمين

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

  • 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 وحدة N/A (إعادة بناء كواجهات برمجية / مكونات)
إعادة تدريب محرر المحتوى معتدل (واجهة إدارة جديدة) معتدل (CMS جديد)
سقف الأداء تحسين متوسط تحسن درامي
مرونة الاستضافة LAMP تقليدي / ما شابه ذلك نشر الحافة، CDN أولاً
مجموعة توظيف المطورين آخذة في الانكماش (متخصصو Drupal) تنمو (React/Next.js)
تكلفة الصيانة طويلة الأجل ~$180K/سنة ~$95K/سنة

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

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

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

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

قرارات الهندسة المعمارية

اختيار نظام إدارة المحتوى بدون رأس

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

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

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

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

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

البنية التحتية

قمنا بالنشر على Vercel لواجهة Next.js (خطة الإنتربرايز، مطلوبة لامتثال 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. قمنا ببناء طبقة ترجمة باستخدام مسارات API Next.js التي استهلكت نقاط نهاية 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٪ من كل حركة البحث العضوي وكانت نقطة الدخول #1 للطلاب المتقدمين. كان الحصول على هذا بشكل خاطئ ليس خياراً.

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

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

النهج الجديد

قمنا بـ pre-build فهرس البحث عند وقت الإنشاء. تم تسلسل جميع 200+ برنامج إلى ملف JSON حجمه ~180KB (مضغوط إلى ~22KB) الذي يأتي مع الصفحة. يحدث الفلترة بالكامل من جانب العميل باستخدام 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 ملي ثانية. بدون spinners التحميل. بدون استدعاءات الخادم. يمكن للمستخدمين سحق المرشحات بأسرع ما يمكن.

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

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

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

تدفق المصادقة

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

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

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

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

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

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

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

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

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

# pipeline هجرة مبسط
1. Export Drupal nodes → JSON عبر أوامر Drush المخصصة
2. Transform JSON → صيغة وثيقة Sanity عبر برامج النصوص النصية Node.js
3. Process media files → تحميل إلى Sanity CDN
4. Import documents → Sanity Migration API
5. Validate → الفحوصات الآلية للمراجع المكسورة

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

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

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

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

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

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

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

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

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

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

واجهنا مشكلتين رئيسيتين:

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

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

نتائج الأداء

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

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

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

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

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

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

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

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

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

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

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

4. Banner هو Banner

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

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

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

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

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

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

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

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

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

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

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

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

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