لماذا يجب على مستخدمي MODX الهجرة إلى Next.js في 2026: نظرة صادقة

أنا أبني المواقع على MODX منذ أيام Evolution. لقد كتبت snippets مخصصة، وتصارعت مع TVs (متغيرات النموذج، وليس أجهزة التلفاز)، ودافعت عن MODX في نقاشات CMS لا تحصى. لذا صدقني عندما أقول أن هذا ليس مقال هجومي. إنه نداء استيقاظ من شخص أحب هذه المنصة بصدق.

لكن إليك المشكلة: عالم تطوير الويب قد تقدم، و MODX لم يواكب التطور. المجتمع ينكمش، ودورة الإصدارات تباطأت إلى الزحف، وتجفيف مجمع المواهب أسرع من بركة في يوليو. إذا كنت لا تزال تشغل مواقع إنتاجية على MODX في 2026، فأنت بحاجة إلى التفكير بجدية في استراتيجية الخروج الخاصة بك. وبالنسبة لمعظم الفريق، يؤدي هذا الخروج إلى Next.js.

دعني أشرح لك السبب — بصراحة، بدون الضجة.

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

لماذا يجب على مستخدمي MODX الهجرة إلى Next.js في 2026: نظرة صادقة

حالة MODX في 2026

دعنا ننظر إلى الأرقام بصدق. MODX 3.x موجود منذ فترة، لكن الاعتماد عليه كان ... فاتراً. منتديات MODX، التي كانت تعج بالنشاط في السابق، تشهد الآن ربما حفنة من المشاركات في الأسبوع. المستودع الرسمي على GitHub يظهر نشاط commit متفرقاً بشكل متزايد. قارن ذلك بـ 2018 أو 2019 عندما كان المجتمع لا يزال يدفع بقوة.

تقديرات بيانات BuiltWith من أوائل 2026 تشير إلى أن MODX يقوم بتشغيل ما يقرب من 0.3٪ من المواقع التي تم الكشف عنها من قبل CMS، انخفاضاً من حوالي 0.7٪ في 2021. لا يزال WordPress يهيمن بنسبة ~62٪، واللاعبون الأحدث مثل المواقع القائمة على Next.js (غالباً ما يكونون مقترنين مع headless CMSes) ينمون بمعدل يبلغ حوالي 40٪ سنوياً.

لم يشهد سوق MODX (مستودع الملحقات السابق) أي ملحق جديد ذي معنى لعدة أشهر. العديد من الملحقات الشهيرة غير مصانة أو متوافقة جزئياً فقط مع MODX 3.x. عندما يتوقف النظام البيئي عن الإنتاج، هذا ليس علماً أحمر — إنه علم أبيض.

لا أقول أن MODX ميتة. لا تزال تعمل. مواقعك لا تزال تعمل. لكن "لا تزال تعمل" مكان خطير في تطوير الويب.

ما الذي نجح MODX فيه (ولا يزال كذلك)

قبل أن أكوم عليها، دعني أعترف حيث يجب ذلك. MODX أتقنت عدة أشياء لا تزال معظم CMSes تحصل عليها بشكل خاطئ:

مرونة المحتوى الحقيقية

MODX لم تجبرك أبداً على نموذج "منشور وصفحة". متغيرات النموذج والأجزاء والمقتطفات أعطتك حرية نمذجة محتوى حقيقية سنوات قبل أن تصبح "المحتوى المنظم" تعبيراً شائعاً. يمكن بناء أي شيء.

الإخراج النظيف

MODX لم تحقن علامتها الخاصة. لا توجد فئات CSS غامضة، لا توجد divs غلاف لم تطلبها. HTML الخاص بك كان HTML الخاص بك. بالنسبة لمطوري الواجهات الأمامية الذين اهتموا بالحرفية، كان هذا وحياً.

المواضيع سهلة الاستخدام للمطورين

لا توجد نظام مواضيع للتعلم، لا توجد تسلسل هرمي للنموذج للحفظ. كتبت نماذج. كان هذا كل شيء. الأجزاء كانت partials قابلة لإعادة الاستخدام. المقتطفات كانت منطق PHP. نموذج عقلي بسيط، نتائج قوية.

صيغة الوسم

قل ما تريد عن [[*pagetitle]] و [[!MySnippet]] — بمجرد تعلمها، كان يمكنك بناء صفحات معقدة بسرعة. كانت طبقة التخزين المؤقت مع علامة ! غير المخزنة مؤقتاً أنيقة.

هذه نقاط القوة في الواقع تجعل مطوري MODX مرشحين رائعين للعمارات الحديثة بدون رؤوس. إذا كنت تفكر بالفعل في محتوى منظم والنماذج المستندة إلى المكونات، فأنت في منتصف الطريق بالفعل إلى Next.js.

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

هنا يتعين علي أن أكون صريحاً.

مخاوف الأمان

MODX 3.x معالجة العديد من الثغرات التاريخية، لكن تشغيل أي monolith PHP بلوحة إدارة عامة يعتبر ناقل مخاطر متأصل. في 2025، رأينا ما لا يقل عن CVEs حرجين يؤثران على تثبيت MODX، واستغرقت الرقع أسابيع للوصول. مع فريق أمان متقلص، أوقات الاستجابة لا تتحسن.

قارن ذلك مع موقع Next.js تم نشره على Vercel أو Netlify — لا يوجد حرفياً خادم للهجوم. لا توجد لوحة إدارة للقوة الغاشمة. لا توجد PHP للاستغلال. سطح الهجوم أصغر بشكل جذري.

أزمة المواهب

حاول توظيف مطور MODX في 2026. تابع فقط. انشر إعلان الوظيفة وشاهد الصراصير. انتقل مجمع المطورين إلى React و Next.js والأطر الحديثة JavaScript. حتى موهبة PHP تذهب إلى Laravel، وليس MODX.

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

متاعب توافق PHP 8.x

MODX 3.x يعمل على PHP 8، لكن العديد من الملحقات لا تفعل ذلك. إذا قمت ببناء موقع يعتمد على مقتطفات أو مكونات إضافية تابعة لجهات خارجية، فقد يؤدي ترقية PHP إلى كسر الأشياء. ينتهي بك الحال إلى الربط بإصدارات PHP أقدم، مما يعود إلى مشكلة الأمان.

لا توجد تجربة مطور حديثة

لا توجد إعادة تحميل وحدات ساخنة. لا توجد عمارة مستندة إلى المكونات. لا يوجد دعم TypeScript. لا توجد تحسين الصور المدمج. لا توجد edge rendering. لا ISR. يمكنني أن أستمر.

سير عمل تطوير MODX هو في الأساس: تحرير ملف أو جزء في المدير (أو في IDE عبر أداة مزامنة)، مسح ذاكرة التخزين المؤقت، تحديث المتصفح. إنه يعمل، لكنه بطيء مقارنة بـ DX الحديث.

سقف الأداء

يمكن أن يكون MODX سريعاً — لقد بنيت مواقع أقل من ثانيتين عليه. لكن الوصول إلى هناك يتطلب تحسيناً كبيراً: التخزين المؤقت بملء الصفحة وإعداد CDN والمواءمة الدقيقة لقاعدة البيانات والعمارة الحذرة للمقتطفات. يعطيك Next.js أداء أقل من ثانية واحدة بشكل أساسي من الصندوق مع الإنشاء الثابت. أنت تقاتل من أجل الأداء على MODX؛ على Next.js، أنت تقاتل لتفسده.

لماذا يجب على مستخدمي MODX الهجرة إلى Next.js في 2026: نظرة صادقة - العمارة

لماذا Next.js هو هدف الهجرة الطبيعي

قد تسأل: لماذا لا WordPress؟ لماذا لا Astro؟ لماذا لا تستخدم مولد موقع ثابت فقط؟

جميع الخيارات صالحة، لكن Next.js يضرب النقطة الحلوة لمعظم عمليات هجرة MODX. إليك السبب:

مرونة الرندرنج تعكس تفكير MODX

مطورو MODX يفهمون بالفعل أن الصفحات المختلفة تحتاج إلى استراتيجيات تخزين مؤقت مختلفة. في MODX، ستحدد المقتطفات كمخزن مؤقت أو لا يتم تخزينها مؤقتاً. في Next.js، تختار بين Static Site Generation (SSG)، Incremental Static Regeneration (ISR)، و Server-Side Rendering (SSR) لكل صفحة. نفس المفهوم، تنفيذ أفضل.

العمارة المستندة إلى المكونات تحل محل الأجزاء

أجزاء MODX هي HTML partials قابلة لإعادة الاستخدام. مكونات React هي UI partials قابلة لإعادة الاستخدام مع منطق مدمج. إذا كنت تكتب أجزاء مثل [[!$header]] و [[!$footer]]، فأنت تفكر بالفعل في المكونات. كنت فقط بدون props.

API Routes تحل محل المقتطفات

المقتطفات MODX تتعامل مع المنطق من جانب الخادم — معالجة النموذج واستدعاءات API والاستعلامات المخصصة. مسارات API Next.js (أو Server Actions في Next.js 14+) تفعل نفس الشيء ولكن في JavaScript/TypeScript مع أفضل دعم الأدوات والاختبار.

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

مسار الهجرة: من MODX إلى Next.js

دعنا نكون عملياً. إليك كيف يعمل الهجرة من MODX إلى Next.js بالفعل.

الخطوة 1: تدقيق نموذج المحتوى الخاص بك

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

## مورد: منشور المدونة
- pagetitle → title (نص)
- longtitle → seo_title (نص)
- content → body (نص غني)
- TV: hero_image → hero_image (وسائط)
- TV: author → author (مرجع)
- TV: category → category (تصنيف)

الخطوة 2: تصدير المحتوى الخاص بك

MODX لا تحتوي على أداة تصدير رائعة. سيتعين عليك على الأرجح كتابة مقتطف مخصص أو نص برمجي يستعلم عن modx_site_content وجداول TV الخاصة بك، ثم يُخرج JSON:

<?php
// تصدير محتوى MODX السريع والقذر
$resources = $modx->getCollection('modResource', [
    'published' => 1,
    'deleted' => 0
]);

$output = [];
foreach ($resources as $resource) {
    $output[] = [
        'id' => $resource->get('id'),
        'title' => $resource->get('pagetitle'),
        'slug' => $resource->get('alias'),
        'content' => $resource->get('content'),
        'template' => $resource->get('template'),
        'tvs' => $resource->getTemplateVars(),
        'parent' => $resource->get('parent'),
        'publishedon' => $resource->get('publishedon'),
    ];
}

header('Content-Type: application/json');
echo json_encode($output, JSON_PRETTY_PRINT);

ثم اكتب نصوص الاستيراد لـ CMS الهدف الخاص بك. إنه عمل غير جذاب، لكنه جهد لمرة واحدة.

الخطوة 3: بناء Next.js Front-End الخاص بك

ابدأ مع create-next-app وبناء نماذجك كمكونات صفحة. قد يبدو تخطيط نموذج MODX → صفحة Next.js كالتالي:

مفهوم MODX نظير Next.js
نموذج مكون التخطيط
جزء مكون React
المقتطف Server Action / مسار API
متغير النموذج حقل CMS
المورد الصفحة / إدخال المحتوى
[[*field]] وسم Props / جلب البيانات
المكون الإضافي (خطاف الحدث) Middleware
[[!uncached]] SSR / rendering ديناميكي
[[cached]] SSG / ISR

الخطوة 4: التعامل مع عمليات إعادة التوجيه

هنا حيث يفسد الناس. كل عنوان URL MODX القديم يحتاج إلى إعادة توجيه 301 إلى نظيره الجديد في Next.js. قم بإنشاء خريطة إعادة توجيه وأضفها إلى next.config.js:

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-modx-path.html',
        destination: '/new-path',
        permanent: true,
      },
      // ... مئات أخرى، تم إنشاؤها من الصادرات الخاصة بك
    ]
  },
}

لا تفقد هذا. تصنيفات SEO الخاصة بك تعتمد على ذلك.

الخطوة 5: قم بتشغيل متوازي لمدة 2-4 أسابيع

انشر Next.js جنباً إلى جنب مع موقع MODX الموجود. اختبر كل شيء. تحقق من Analytics. تحقق من أن النماذج تعمل. ثم قلب DNS.

اختيار Headless CMS لاستبدال MODX

Next.js هو الواجهة الأمامية، لكنك لا تزال بحاجة إلى مكان لإدارة المحتوى. إليك كيفية مقارنة الخيارات الشهيرة لاجئي MODX:

CMS منحنى التعلم لمطوري MODX نمذجة المحتوى التسعير (2026) خيار المزود الذاتي
Sanity متوسط ممتاز (مخططات معرفة بالرمز) الطبقة المجانية، ثم $15/user/mo لا (سحابة فقط)
Strapi منخفض جيد (UI-based) مجاني (المزود الذاتي)، السحابة من $29/mo نعم
Contentful متوسط جيد الطبقة المجانية، ثم $300/mo لا
Payload CMS منخفض ممتاز (مخططات معرفة بالرمز) مجاني (المزود الذاتي)، السحابة من $50/mo نعم
Directus منخفض مرن مجاني (المزود الذاتي)، السحابة من $99/mo نعم

إذا أحببت مرونة MODX وقدرة المزود الذاتي، فإن Payload CMS أو Strapi سيشعران بألفة أكثر. إذا كنت تريد أفضل تجربة مطور ولا مانع لديك من السحابة فقط، فإن Sanity يصعب التغلب عليه.

لقد قمنا بعمل شامل مع كل هؤلاء من خلال ممارسة تطوير headless CMS، والخيار الصحيح يعتمد فعلاً على راحة فريقك والميزانية.

مكاسب الأداء الحقيقية: قبل وبعد

لقد هاجرت موقع MODX بحجم متوسط (حوالي 400 صفحة، مدونة + الخدمات + المحفظة) إلى Next.js مع Sanity في أواخر 2025. إليك الأرقام الفعلية:

المقياس MODX (محسّنة) Next.js على Vercel التحسن
Lighthouse Performance 72 98 +36%
Largest Contentful Paint 2.8s 0.9s -68%
Time to First Byte 680ms 45ms -93%
Core Web Vitals Pass جزئي اجتياز كامل ✅
Build/Deploy Time FTP يدوي auto-deploy 42s الليل والنهار
Monthly Hosting Cost $45/mo (VPS) $0 (Vercel free tier) -100%

تحسن TTFB وحده مذهل. يتعين على MODX تشغيل PHP والاتصال بـ MySQL وتشغيل المقتطفات وتجميع الأجزاء وخدمة الاستجابة — حتى مع التخزين المؤقت. يتم خدمة صفحة Next.js التي تم إنشاؤها بشكل ثابت من عقدة حافة CDN في ميلي ثانية.

ما سوف تفتقده (وما لن تفتقده)

سوف تفتقد

  • واجهة المدير: لوحة إدارة MODX بديهية حقاً لمحررات المحتوى. معظم لوحات إدارة headless CMS لها منحنى تعلم.
  • التحرير في السياق: تحرير المحتوى حيث تراه معروضاً. معظم إعدادات headless تتطلب التبديل بين CMS والمعاينة. (أداة Presentation من Sanity و Live Preview من Payload تضيق الفجوة.)
  • البساطة: خادم واحد وقاعدة بيانات واحدة وقاعدة رموز واحدة. هناك جمال في ذلك. يحتوي مكدس headless على أجزاء متحركة أكثر.
  • روح المجتمع: مجتمع MODX، على الرغم من صغره، كان متماسكاً ومفيداً حقاً.

لن تفتقد

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

مقارنة التكاليف: تشغيل MODX مقابل Next.js

دعنا نكون واقعياً حول إجمالي تكلفة الملكية، وليس فقط الاستضافة.

فئة التكاليف MODX (سنوياً) Next.js + Headless CMS (سنوياً)
الاستضافة $540-$1,200 (VPS/shared) $0-$240 (Vercel/Netlify)
رخصة CMS $0 (مفتوح المصدر) $0-$3,600 (يختلف حسب CMS)
شهادة SSL $0-$100 $0 (مدرجة)
CDN $0-$600 $0 (مدرجة)
مراقبة الأمان $200-$500 الحد الأدنى (بدون خادم)
صيانة الخادم $500-$2,000 (الوقت أو المتعاقدة) $0
معدل ساعة المطور $75-$120 (موهبة نادرة) $100-$175 (موهبة وفيرة)
الإجمالي (لا يشمل وقت التطوير) $1,240-$4,400 $0-$3,840

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

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

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

كم من الوقت تستغرق هجرة MODX إلى Next.js النموذجية؟

بالنسبة للموقع الذي يحتوي على 100-500 صفحة، توقع 6-10 أسابيع مع فريق مخصص. تستغرق نمذجة المحتوى والهجرة حوالي أسبوعين، وتستغرق بناء Next.js front-end 3-5 أسابيع، ويملأ QA/testing/redirects الباقي. يمكن أن تستغرق المواقع الأكبر التي تحتوي على مقتطفات PHP مخصصة معقدة أو تكامل تجارة إلكترونية ثقيل 12-16 أسبوعاً. المتغير الأكبر هو مقدار منطق PHP المخصص الذي يحتاج إلى إعادة كتابة.

هل يمكنني الاحتفاظ بلوحة إدارة MODX وفقط استخدام Next.js للواجهة الأمامية؟

من الناحية الفنية، نعم — يمكنك بناء طبقة REST API في MODX والاستهلاك بـ Next.js. لكن هذا يعطيك الأسوأ من كلا العالمين: أنت لا تزال تحافظ على خادم PHP وقاعدة بيانات MySQL وجميع مخاوف الأمان، بينما تحافظ أيضاً على واجهة أمامية منفصلة. إلا إذا كان لديك سبب محدد جداً، فمن الأفضل ترحيل المحتوى إلى CMS بدون رأس مخصص.

هل سأفقد تصنيفات SEO أثناء الهجرة؟

لا بشرط أن تتعامل مع عمليات إعادة التوجيه بشكل صحيح. الخطوات الحاسمة هي: الحفاظ على نفس هيكل URL حيث يكون ذلك ممكناً، وإعداد عمليات إعادة توجيه 301 لأي عناوين URL تتغير، والحفاظ على البيانات الوصفية الخاصة بك، وإرسال خريطة موقع محدثة إلى Google Search Console بعد الإطلاق. تشهد معظم المواقع التي هاجرناها تحسنات في التصنيف خلال 4-8 أسابيع بسبب درجات Core Web Vitals الأفضل.

ماذا عن مواقع MODX التي تحتوي على نماذج FormIt وسير عمل معقدة؟

النماذج هي إحدى الأجزاء الأكثر صعوبة في الهجرة. قام FormIt بمعالجة التحقق والبريد الإلكتروني والخطافات والوقاية من البريد العشوائي في حزمة واحدة. في Next.js، ستدمج عادةً Server Actions للمعالجة وZod للتحقق وخدمة مثل Resend أو SendGrid لتسليم البريد الإلكتروني. إنه أكثر وضوحاً ولكن أيضاً أكثر قابلية للاختبار والموثوقية.

هل Next.js مبالغ فيه بالنسبة لموقع brochure بسيط؟

ربما. إذا كان موقع MODX الخاص بك حرفياً 10 صفحات ثابتة مع نموذج الاتصال، فقد يكون Astro مناسباً بشكل أفضل — فهو يشحن JavaScript صفر بشكل افتراضي وأبسط للإعداد. لكن إذا كان هناك أي فرصة لاحتياجك إلى ميزات ديناميكية أو مصادقة أو جلب بيانات معقدة لاحقاً، فإن البدء مع Next.js يوفر عليك من هجرة أخرى لاحقاً.

ماذا يحدث لملحقات MODX والمقتطفات المخصصة؟

يجب إعادة بنائها. لا توجد تحويلات آلية. تصبح المقتطفات المخصصة مسارات API أو Server actions في Next.js. الملحقات الإضافية مثل Gallery أو Articles أو MIGX يتم استبدالها بالميزات الأصلية لـ headless CMS الخاصة بك (والتي عادة ما تكون أفضل). سيتم استبدال ملحقات التجارة الإلكترونية مثل Foxy أو SimpleCart بواسطة Shopify Storefront API أو Snipcart أو Medusa. خطط لهذا الجهد بوضوح في الجدول الزمني للهجرة.

كيف أقنع أصحاب المصلحة غير التقنيين بالموافقة على هذه الهجرة؟

ركز على ثلاثة أشياء يهتمون بها: المخاطر والتكلفة والنتائج. المخاطر: مجتمع MODX المتقلص يعني أن العثور على المطورين للحالات الطارئة أصبح أصعب كل عام. التكلفة: صيانة الخادم وتصحيح الأمان ليست مجانية، حتى لو كانت رخصة CMS كذلك. النتائج: أرهم مقارنة Core Web Vitals وشرح كيف تستخدم Google سرعة الصفحة كعامل ترتيب. إذا كان المنافسون يحملون في أقل من ثانية وهم في 3 ثوانٍ، فهذه مشكلة العمل.

هل يمكنني الهجرة بشكل تدريجي أو يجب أن تكون كل مرة واحدة؟

الهجرة التدريجية ممكنة باستخدام إعداد reverse proxy — يمكنك خدمة صفح جديدة من Next.js وتوجيه الصفح الموروثة إلى خادم MODX الخاص بك. لقد فعلنا هذا مع تكوينات nginx حيث تم توكيل مسارات محددة إلى الخادم القديم بينما ينتقل كل شيء آخر إلى نشر Next.js الجديد. يضيف تعقيداً، لكن بالنسبة للمواقع التي تحتوي على مئات الصفحات، فإنه يتيح لك الهجرة على مراحل على مدى أسابيع أو أشهر بدلاً من القيام بـ cutover كبير محفوف بالمخاطر.

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