ترحيل CMS بدون توقف: دليل تحويل WordPress إلى Next.js

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

هذه هي الخطة التي نستخدمها في Social Animal لعمليات الإنتاج. إنها ليست نظرية — بل مبنية من هجرات حقيقية كان الإيراد الفعلي على المحك. نحن نتحدث عن مواقع التجارة الإلكترونية التي تحقق 50 ألف دولار يومياً، وناشري المحتوى الذين لديهم ملايين مشاهدات الصفحة شهرياً، ومواقع تسويق SaaS حيث تعني 5 دقائق من التوقف أن يتصل الرئيس التنفيذي برقمك.

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

• لماذا عدم التوقف مهم أكثر مما تعتقد
• نظرة عامة على بنية الهجرة
• المرحلة 1: هجرة المحتوى وطبقة API
• المرحلة 2: بناء تطبيق Next.js
• المرحلة 3: إعداد النشر المتوازي
• المرحلة 4: تكوين النشر الأزرق والأخضر
• المرحلة 5: استراتيجية تبديل DNS
• المرحلة 6: قائمة التحقق من التبديل
• المرحلة 7: المراقبة بعد التبديل والعودة للنسخة السابقة
• أنماط الفشل الشائعة وكيفية منعها
• الأسئلة الشائعة

لماذا عدم التوقف مهم أكثر مما تعتقد

دعنا نضع بعض الأرقام على هذا. تظهر أبحاث Google من 2024 أن تأخير ثانية واحدة في تحميل الصفحة يكلف حوالي 7٪ من التحويلات. الآن تخيل أن موقعك قد اختفى تماماً. حتى لو كان لمدة 5 دقائق فقط.

إليك ما هو معرض للخطر فعلاً:

مدة التوقف	تأثير الإيراد (لموقع بـ 10 آلاف دولار/يوم)	تأثير SEO	تأثير ثقة المستخدم
5 دقائق	~35 دولار خسارة	ضئيل إذا كان معزولاً	منخفض
30 دقيقة	~208 دولار خسارة	قد يلاحظها Googlebot	معتدل
ساعتان	~833 دولار خسارة	أخطاء الزحف في GSC	مرتفع
24 ساعة	10،000+ دولار خسارة	خطر إلغاء الفهرسة	حاد

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

الهدف ليس مجرد عدم التوقف. إنه عدم وجود أي تغيير مرئي للمستخدمين والزواحف أثناء الانتقال.

نظرة عامة على بنية الهجرة

قبل أن ننتقل إلى المراحل، دعنا نلقي نظرة على البنية التي نستهدفها. النمط الأساسي هو تشغيل كلا النظامين بالتوازي، ثم نقل حركة المرور بشكل ذري.

                    ┌─────────────────┐
                    │   Cloudflare /   │
                    │   Load Balancer  │
                    └────────┬────────┘
                             │
                    ┌────────┴────────┐
                    │  Traffic Router  │
                    │  (weight-based)  │
                    └────┬───────┬────┘
                         │       │
              ┌──────────┴──┐ ┌──┴──────────┐
              │  WordPress  │ │   Next.js   │
              │  (Blue)     │ │   (Green)   │
              │  Origin     │ │   on Vercel │
              └──────────┬──┘ └──┬──────────┘
                         │       │
              ┌──────────┴──┐ ┌──┴──────────┐
              │  MySQL DB   │ │ Headless CMS │
              │             │ │ (Sanity/etc) │
              └─────────────┘ └─────────────┘

الفكرة الرئيسية: لا تقوم بهجرة واجهة أمامية فقط. أنت تهجر طبقة المحتوى وطبقة التصيير وطبقة التسليم — ويمكن هجرة كل واحدة بشكل مستقل.

المرحلة 1: هجرة المحتوى وطبقة API

هذا هو المكان الذي تبدأ فيه معظم الفرق بشكل خاطئ. يحاولون بناء واجهة Next.js أولاً ثم يعرفون المحتوى لاحقاً. لا تفعل ذلك. ابدأ بالمحتوى.

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

يحتاج محتوى WordPress الخاص بك إلى منزل جديد. الاختيار مهم جداً لتعقيد الهجرة:

نظام إدارة المحتوى	سهولة الهجرة من WP	مزامنة حية ممكنة	التسعير (2025)	الأفضل لـ
Sanity	عالية (يتم تعيين المحتوى المنظم جيداً)	نعم، عبر webhooks	مستوى مجاني، ثم 99 دولار/شهر	نماذج محتوى معقدة
Contentful	متوسط (يتطلب تعيين الحقول)	نعم	300 دولار/شهر للفريق	فرق المؤسسات
Strapi	عالية (نموذج مدعوم بقاعدة بيانات مماثل)	نعم	مستضاف ذاتياً مجاني، Cloud من 29 دولار/شهر	التحكم الكامل
WordPress REST API	غير قابل للتطبيق (احتفظ برأس بدون جسم)	متزامن بالفعل	تكاليف الاستضافة الموجودة	الفوز السريع
Payload CMS	عالية	نعم	مستضاف ذاتياً مجاني	فرق موجهة للمطورين

نغطي اختيار نظام إدارة المحتوى بدون رأس بعمق على صفحة قدرات تطوير نظام إدارة المحتوى بدون رأس، لكن الإصدار المختصر: بالنسبة لمعظم هجرات WordPress، يوفر Sanity أو Payload CMS أفضل مسار للهجرة.

إعداد مزامنة المحتوى

هنا الجزء الحرج: أثناء مرحلة التشغيل المتوازي، يحتاج المحتوى إلى أن يكون موجوداً في كلا النظامين. لديك استراتيجيتان:

الاستراتيجية أ: هجرة لمرة واحدة + تجميد انقل كل المحتوى إلى نظام إدارة المحتوى الجديد، ثم جمّد تحرير WordPress. يعمل هذا على المواقع الصغيرة لكن ينهار عندما يحتاج المحررون إلى الاستمرار في النشر.

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

// مثال: معالج webhook لـ WordPress يقوم بالمزامنة مع Sanity
// يعمل هذا كدالة بدون خادم (Vercel/AWS Lambda)

import { createClient } from '@sanity/client';

const sanity = createClient({
  projectId: process.env.SANITY_PROJECT_ID,
  dataset: 'production',
  token: process.env.SANITY_WRITE_TOKEN,
  apiVersion: '2025-01-01',
  useCdn: false,
});

export async function POST(request) {
  const payload = await request.json();
  const { post_id, post_title, post_content, post_status } = payload;

  if (post_status !== 'publish') return new Response('Skipped', { status: 200 });

  try {
    await sanity.createOrReplace({
      _id: `wp-${post_id}`,
      _type: 'post',
      title: post_title,
      body: convertGutenbergToPortableText(post_content),
      migratedFrom: 'wordpress',
      wpId: post_id,
      _updatedAt: new Date().toISOString(),
    });

    return new Response('Synced', { status: 200 });
  } catch (error) {
    console.error('Sync failed:', error);
    return new Response('Sync error', { status: 500 });
  }
}

ستحتاج أيضاً إلى الجانب الخاص بـ WordPress. نستخدم المكون الإضافي البسيط الذي يطلق على save_post:

// wp-content/plugins/headless-sync/headless-sync.php
add_action('save_post', function($post_id, $post) {
    if (wp_is_post_revision($post_id)) return;
    
    wp_remote_post(SYNC_ENDPOINT_URL, [
        'body' => json_encode([
            'post_id' => $post_id,
            'post_title' => $post->post_title,
            'post_content' => $post->post_content,
            'post_status' => $post->post_status,
        ]),
        'headers' => [
            'Content-Type' => 'application/json',
            'X-Sync-Secret' => SYNC_SECRET,
        ],
    ]);
}, 10, 2);

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

المرحلة 2: بناء تطبيق Next.js

لن أغطي عملية بناء Next.js الكاملة هنا — هذا يستحق مقالته الخاصة (وقد حققنا خبرة عميقة في تطوير Next.js). لكن هناك مخاوف خاصة بالهجرة مهمة لعدم التوقف.

تكافؤ عناوين URL غير قابل للتفاوض

يجب أن يحل كل عنوان URL موجود على موقع WordPress الخاص بك إلى نفس المحتوى على موقع Next.js الخاص بك. كل واحد. واحد.

هذا يعني:

• /blog/my-post-slug/ يجب أن يعمل (بما في ذلك الشرطة المائلة اللاحقة إذا استخدم WordPress واحداً)
• /category/technology/ يجب أن يعمل أو يعيد توجيه
• /wp-content/uploads/2024/03/image.jpg يجب أن يعيد توجيه إلى CDN الموارد الجديد
• /feed/ يجب أن تعود صحيحة RSS/Atom
• عناوين URL التصفح مثل /blog/page/2/ يجب أن تعمل

بناء نص تدقيق عناوين URL مبكراً:

# تصدير جميع عناوين URL الخاصة بـ WordPress باستخدام WP-CLI
wp post list --post_type=post,page --post_status=publish \
  --fields=ID,post_name,post_type,guid --format=csv > urls.csv

# احصل أيضاً على عمليات إعادة التوجيه من أي مكون إضافي SEO
wp db query "SELECT * FROM wp_redirection_items" --format=csv > redirects.csv

ثم تحقق منها ضد بناء Next.js الخاص بك:

// validate-urls.mjs
import { readFileSync } from 'fs';
import { parse } from 'csv-parse/sync';

const urls = parse(readFileSync('./urls.csv'), { columns: true });
const NEXT_BASE = 'https://staging.yoursite.com';

for (const row of urls) {
  const res = await fetch(`${NEXT_BASE}/${row.post_name}/`, {
    redirect: 'manual'
  });
  
  if (res.status >= 400) {
    console.error(`BROKEN: /${row.post_name}/ → ${res.status}`);
  }
}

خط الأساس للأداء

قبل التبديل، يجب أن يكون موقع Next.js الخاص بك سريعاً على الأقل مثل WordPress. يبدو واضحاً، لكنني رأيت فرقاً تثير حماسة المكدس الجديد بحيث تنسى قياس الأداء.

التقط Core Web Vitals من موقع WordPress الخاص بك باستخدام بيانات CrUX أو Lighthouse CI، ثم طابق أو تفوق عليها. إذا كان موقع WordPress الخاص بك يحتوي على LCP بـ 2.1 ثانية وموقع Next.js الخاص بك بـ 3.4 ثانية، فأنت غير جاهز.

المرحلة 3: إعداد النشر المتوازي

الآن نصل إلى البنية الأساسية التي تجعل عدم التوقف ممكناً.

التشغيل المتوازي

كلا النظامين يعملان في نفس الوقت، ويخدمان حركة المرور الحقيقية. لكن واحد فقط هو "الأساسي" في أي وقت معين.

بالنسبة إلى Next.js على Vercel (الإعداد الأكثر شيوعاً لدينا)، ستنشر تطبيق Next.js الخاص بك إلى مجال مخصص مثل next.yoursite.com أو استخدم عنوان URL المعاينة الخاص بـ Vercel. يستمر موقع WordPress في التشغيل على yoursite.com.

# إذا كنت تستخدم Nginx كوكيل عكسي
# هذا هو تكوين التشغيل المتوازي

upstream wordpress {
    server wordpress-origin.internal:80;
}

upstream nextjs {
    server next-yoursite.vercel.app:443;
}

server {
    listen 443 ssl;
    server_name yoursite.com;

    # أثناء التشغيل المتوازي: انعكس حركة المرور على كليهما,
    # لكن فقط قدم الاستجابات من WordPress
    location / {
        mirror /mirror;
        proxy_pass http://wordpress;
    }

    location = /mirror {
        internal;
        proxy_pass https://nextjs$request_uri;
    }
}

يرسل هذا التكوين الانعكاسي كل طلب إلى الخادم الخلفي لكن يعيد فقط استجابة WordPress. تحصل على حركة مرور حقيقية تصيب تطبيق Next.js الخاص بك دون أن يراه المستخدمون. تحقق من سجلات Next.js الخاصة بك بحثاً عن أخطاء و 404s والاستجابات البطيئة.

المراقبة الاصطناعية

أنشئ مراقبة تتحقق باستمرار من أن كلا النظامين يعودان بمحتوى متكافئ:

// canary-check.mjs — يعمل كل 5 دقائق عبر cron
const CRITICAL_URLS = [
  '/',
  '/blog/',
  '/about/',
  '/contact/',
  '/blog/most-popular-post/',
];

for (const path of CRITICAL_URLS) {
  const [wpRes, nextRes] = await Promise.all([
    fetch(`https://yoursite.com${path}`),
    fetch(`https://next.yoursite.com${path}`),
  ]);

  if (wpRes.status !== nextRes.status) {
    alert(`Status mismatch on ${path}: WP=${wpRes.status} Next=${nextRes.status}`);
  }

  // مقارنة علامات العنوان كفحص تكافؤ المحتوى
  const wpTitle = (await wpRes.text()).match(/<title>(.*?)<\/title>/)?.[1];
  const nextTitle = (await nextRes.text()).match(/<title>(.*?)<\/title>/)?.[1];

  if (wpTitle !== nextTitle) {
    alert(`Title mismatch on ${path}`);
  }
}

شغل هذا لمدة أسبوع على الأقل بدون تنبيهات قبل الانتقال إلى التبديل.

المرحلة 4: تكوين النشر الأزرق والأخضر

النشر الأزرق والأخضر يعني وجود بيئتي إنتاج متطابقتين — الأزرق (WordPress الحالي) والأخضر (Next.js الجديد) — والتبديل بينهما بشكل ذري.

استخدام Cloudflare Workers لتوجيه حركة المرور

هذا هو النهج المفضل لدينا لأنه يمنحك تبديل حركة مرور فوري وعالمي بدون تأخير انتشار DNS.

// Cloudflare Worker لتوجيه النشر الأزرق والأخضر
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // اقرأ البيئة النشطة من متجر KV
    const activeEnv = await env.CONFIG.get('active_environment') || 'blue';
    
    // اختياري: توجيه canary يعتمد على النسبة المئوية
    const canaryPercent = parseInt(await env.CONFIG.get('canary_percent') || '0');
    const useGreen = activeEnv === 'green' || 
                     (canaryPercent > 0 && Math.random() * 100 < canaryPercent);
    
    const origin = useGreen
      ? 'https://next-yoursite.vercel.app'
      : 'https://wp-origin.yoursite.com';
    
    const originUrl = new URL(url.pathname + url.search, origin);
    
    const response = await fetch(originUrl, {
      method: request.method,
      headers: {
        ...Object.fromEntries(request.headers),
        'Host': new URL(origin).hostname,
        'X-Forwarded-Host': url.hostname,
      },
      body: request.method !== 'GET' ? request.body : undefined,
    });
    
    const newResponse = new Response(response.body, response);
    newResponse.headers.set('X-Served-By', useGreen ? 'green-nextjs' : 'blue-wordpress');
    
    return newResponse;
  }
};

جمال هذا النهج: التبديل من WordPress إلى Next.js هو كتابة متجر KV واحدة. لا تغييرات DNS. لا انتشار. فوري.

# التبديل إلى الأخضر (Next.js)
curl -X PUT "https://api.cloudflare.com/client/v4/accounts/{account_id}/storage/kv/namespaces/{namespace_id}/values/active_environment" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  --data "green"

# العودة إلى الأزرق (WordPress) إذا حدث شيء خاطئ
curl -X PUT "https://api.cloudflare.com/client/v4/accounts/{account_id}/storage/kv/namespaces/{namespace_id}/values/active_environment" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  --data "blue"

توجيه Canary

لا تنقل 100٪ من حركة المرور في المرة الواحدة. ابدأ بـ canary:

1. 1٪ حركة مرور إلى Next.js — شاهد الأخطاء لمدة ساعة واحدة
2. 10٪ حركة مرور — راقب لمدة ساعتين
3. 50٪ حركة مرور — راقب لمدة 4 ساعات
4. 100٪ حركة مرور — راقب لمدة 24 ساعة
5. إيقاف تشغيل WordPress — بعد أسبوع واحد بـ 100٪

المرحلة 5: استراتيجية تبديل DNS

إذا لم تتمكن من استخدام Cloudflare Workers (أو حل توجيه الحواف المماثل)، ستحتاج إلى التعامل مع التبديل على مستوى DNS. هذا أصعب لأن TTL ينتشر.

تحضير DNS قبل التبديل

قبل التبديل بـ 48 ساعة على الأقل:

1. خفض TTL لـ DNS إلى 60 ثانية (من الـ 3600 أو 86400 النموذجية)
2. انتظر انقضاء TTL القديم
3. تحقق من أن TTL المنخفضة نشطة: dig yoursite.com +short يجب أن يُظهر TTL ~60

# تحقق من TTL الحالي
dig yoursite.com A +noall +answer
# يجب أن يُظهر شيئاً مثل:
# yoursite.com.  60  IN  A  76.76.21.21

تبديل DNS

بـ TTL بـ 60 ثانية، تحديث عنوان DNS الخاص بك A/CNAME يعني الانتشار العالمي في حوالي 5-10 دقائق (بعض المحللات تتجاهل TTLs المنخفضة، لكن معظمها يحترمها في 2025).

# إذا كنت تنتقل إلى Vercel
# حدّث CNAME للإشارة إلى cname.vercel-dns.com
# أو حدّث سجلات A إلى عناوين IP الخاصة بـ Vercel: 76.76.21.21

المشكلة: توقيت شهادة SSL

هنا شيء يلدغ الناس. عند تبديل DNS إلى Vercel (أو أي مضيف جديد)، يجب توفير شهادة SSL لمجالك على المضيف الجديد قبل التبديل. وإلا، تحصل على نافذة حيث لا يعمل HTTPS.

على Vercel، أضف مجالك المخصص في إعدادات المشروع قبل تبديل DNS. سيحاول Vercel توفير الشهادة عبر تحدي HTTP-01 أو DNS-01. إذا كنت تستخدم DNS المحمي بـ Cloudflare، قد تحتاج إلى تعطيل الوكيل مؤقتاً (سحابة برتقالية → سحابة رمادية) لتوفير الشهادة للعمل.

المرحلة 6: قائمة التحقق من التبديل

هذه هي قائمة التحقق التي نستخدمها في يوم التبديل. اطبعها. تحقق من كل مربع.

قبل التبديل (T-24 ساعة)

• جميع المحتوى متزامن ومتحقق منه في نظام إدارة المحتوى الجديد
• تحقق من تكافؤ عنوان URL يمرر 100٪
• تم توفير شهادة SSL على المضيف الجديد
• تم تأكيد TTL الخاص بـ DNS بـ 60 ثانية
• تم توثيق واختبار إجراء العودة للنسخة السابقة
• جميع عمليات إعادة التوجيه من مكون WordPress SEO الإضافي مهاجرة إلى next.config.js أو middleware الحافة
• robots.txt و sitemap.xml يتم إنشاؤها بشكل صحيح على Next.js
• تم التحقق من تتبع التحليلات على Next.js (GA4، GTM، إلخ)
• تم اختبار إرسالات النماذج من النهاية إلى النهاية
• تم التحقق من خلاصة RSS
• تم التحقق من علامات OpenGraph على الصفحات الرئيسية
• تم اختبار صفحة 404

التبديل (T-0)

• أخبر أصحاب المصلحة: "بدء الهجرة"
• ضبط canary على 1٪ → راقب 30 دقيقة
• الزيادة إلى 10٪ → راقب ساعة واحدة
• تحقق من Google Search Console من أجل أخطاء الزحف
• الزيادة إلى 50٪ → راقب ساعتين
• الزيادة إلى 100٪
• إرسال خريطة الموقع المحدثة إلى Google Search Console
• التحقق من أن Googlebot يمكنه الوصول إلى جميع الصفحات الحرجة (استخدم أداة فحص عنوان URL)
• اختبر جميع النماذج وتدفقات التجارة الإلكترونية وتدفقات المصادقة

بعد التبديل (T+24 ساعة)

• راقب Core Web Vitals في لوحة معلومات CrUX
• تحقق من Google Search Console لمشاكل التغطية
• تحقق من أن جميع بيانات التحليلات تتدفق بشكل صحيح
• أصل WordPress لا يزال قيد التشغيل (احتفظ به لمدة أسبوعين على الأقل)
• قم بتشغيل زحف موقع ويب كامل مع Screaming Frog ضد الموقع الجديد

المرحلة 7: المراقبة بعد التبديل والعودة للنسخة السابقة

ما يجب مراقبته

أنشئ لوحات معلومات في أداة المراقبة الخاصة بك (نستخدم مزيجاً من Vercel Analytics و Datadog و Google Search Console) تتبع:

• معدلات الخطأ: أي استجابات 5xx؟ أي ارتفاع في 4xx؟
• أوقات الاستجابة: P50، P95، P99 كمون
• Core Web Vitals: LCP، FID/INP، CLS
• Search Console: إحصائيات الزحف، تقرير التغطية، حالة الفهرسة
• مقاييس الأعمال: معدل التحويل، معدل الارتداد، صفحات/الجلسة

خطة العودة للنسخة السابقة

يجب أن تكون النسخة السابقة أمراً واحداً. ليس عملية بـ 15 خطوة. أمر واحد.

باستخدام نهج Cloudflare Worker:

# العودة للنسخة السابقة بأمر واحد
wrangler kv:key put --namespace-id=$NS_ID "active_environment" "blue"

باستخدام التبديل المستند إلى DNS:

# العودة للنسخة السابقة من DNS المكتوبة مسبقاً عبر API الخاصة بـ Cloudflare
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records/{record_id}" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"content": "old-wordpress-ip-address"}'

احتفظ بـ WordPress قيد التشغيل لمدة أسبوعين على الأقل بعد التبديل. لا تكن بطلاً. اللحظة التي تغلق فيها WordPress هي اللحظة التي تكتشف فيها صفحة نسيتها هجرتها.

أنماط الفشل الشائعة وكيفية منعها

بعد القيام بهذا عشرات المرات، إليك الإخفاقات التي أراها في كثير من الأحيان:

1. مكونات WordPress المنسية مع مسارات الواجهة الأمامية يقوم مكون نموذج الاتصال بإنشاء نقاط نهاية /wp-json/contact-form-7/. هذا التثبيت WooCommerce لديه /my-account/ و /cart/. قم بتعيين مسافة عنوان URL لكل مكون إضافي.

2. عناوين URL المشفرة بـ wp-content في المحتوى الصور في المحتوى الخاص بك تشير إلى /wp-content/uploads/. تحتاج إلى عمليات إعادة توجيه أو قاعدة إعادة كتابة تشير إلى CDN الموارد الجديد.

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/wp-content/uploads/:path*',
        destination: 'https://cdn.yoursite.com/uploads/:path*',
        permanent: true,
      },
    ];
  },
};

3. نسيان خرائط XML Google Search Console موجهة إلى /sitemap.xml. تطبيق Next.js الخاص بك يحتاج إلى إنشاء واحد. استخدم next-sitemap أو قم ببنائه في معالجات المسار الخاصة بالتطبيق.

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

5. تسمم ذاكرة تخزين مؤقت CDN أثناء الانتقال إذا كان Cloudflare يخزن الاستجابات مؤقتاً، قد تقدم صفحات WordPress المتقادمة بعد التبديل إلى Next.js. امسح ذاكرة التخزين المؤقت لـ CDN فوراً بعد التبديل.

# امسح ذاكرة التخزين المؤقت Cloudflare بالكامل بعد التبديل
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything": true}'

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

بالنسبة للمواقع المبنية بأطر عمل أخرى، نقوم أيضاً بـ هجرات مستندة إلى Astro التي يمكن أن تكون أسرع حتى بالنسبة للمواقع الثقيلة بالمحتوى التي لا تحتاج إلى الكثير من التفاعل.

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

ما مدة هجرة WordPress إلى Next.js عادةً؟ بالنسبة لموقع بتعقيد متوسط (100-500 صفحة، أنواع منشورات مخصصة، بعض الوظائف الديناميكية)، خطط لـ 8-12 أسبوعاً من النهاية إلى النهاية. تستغرق مرحلة هجرة المحتوى والتشغيل المتوازي 3-4 أسابيع وحدها. التبديل الفعلي، إذا قمت بعمل التحضيرات، يستغرق حوالي 4 ساعات من العمل النشط. لا تدع أحداً يخبرك أن هذا يمكن القيام به في عطلة نهاية الأسبوع.

هل يمكنني استخدام WordPress كنظام إدارة محتوى بدون رأس بدلاً من الهجرة؟ بالتأكيد، وبالنسبة لبعض الفرق هذا هو الخيار الصحيح. تحتفظ بـ WordPress كنظام إدارة محتوى، واستخدم REST API أو WPGraphQL لإرسال المحتوى إلى Next.js، وفقط هاجر الواجهة الأمامية. هذا يقلل خط زمني الهجرة بشكل كبير لأنك تتخطى مرحلة هجرة المحتوى بالكامل. المقايضة هي أنك لا تزال تحتفظ بتثبيت WordPress مع كل تحديثات الأمان والتحديثات.

ماذا يحدث لترتيب SEO الخاص بي أثناء الهجرة؟ مع هجرة صفرية التوقف بشكل صحيح، يجب أن يبقى ترتيبك مستقراً. أكد John Mueller من Google أن تغيير نظام إدارة المحتوى الخاص بك لا يجب أن يؤثر على الترتيبات إذا ظل المحتوى وعناوين URL وعناصر تحسين محركات البحث التقنية معادلة. أكبر المخاطر هي عناوين URL المعطوبة (التي تسبب 404s) وتغيير هياكل الارتباطات الداخلية والأداء المتدهورة. يعالج كتيبنا بشكل محدد جميع الثلاثة.

كيف أتعامل مع نماذج WordPress في Next.js؟ لديك عدة خيارات: استخدم خدمة نموذج مثل Formspree أو Basin، بناء مسارات API في Next.js تتعامل مع الإرسالات مباشرة، أو استخدام ميزات النماذج الخاصة بنظام إدارة المحتوى بدون رأس (Sanity لا تحتوي على نماذج أصلية، لكن Payload CMS تفعل). بالنسبة للنماذج المعقدة مع المنطق الشرطي، نحن عادةً نبني مسارات API مخصصة واستخدم React Hook Form في الواجهة الأمامية.

هل يجب أن أستخدم Vercel أو Netlify أو الاستضافة الذاتية لنشر Next.js؟ بالنسبة لمعظم الفرق، Vercel هي أقل مسار مقاومة لـ Next.js. تم بناؤها بواسطة نفس الفريق، والميزات مثل ISR و middleware و image optimization تعمل بشكل أفضل هناك. خطة Vercel Pro بـ 20 دولار/مستخدم/شهر تغطي معظم احتياجات الإنتاج. إذا كان لديك متطلبات امتثال محددة أو تحتاج إلى البقاء على AWS، يمكنك الاستضافة الذاتية مع وضع الإخراج standalone. يعمل Netlify أيضاً لكنه تاريخياً تخلف عن دعم ميزات Next.js.

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

كيف أهاجر عمليات إعادة توجيه WordPress إلى Next.js؟ صدر عمليات إعادة التوجيه الخاصة بك من أي مكون WordPress تستخدمه (Redirection، Yoast، RankMath). حولها إلى تنسيق إعادة توجيه Next.js في next.config.js. بالنسبة للمواقع التي تحتوي على مئات عمليات إعادة التوجيه، استخدم middleware بدلاً من ذلك — إنها أكثر كفاءة ويمكنها التعامل مع مطابقة الأنماط. كن على علم بأن عمليات إعادة التوجيه next.config.js لها حد عملي يبلغ حوالي 1000 مدخل على Vercel قبل معاناة أوقات البناء.

هل يمكنني العودة إلى WordPress إذا حدث شيء خاطئ بعد التبديل؟ نعم، وهذا غير قابل للتفاوض. احتفظ بمثيل WordPress قيد التشغيل لمدة أسبوعين على الأقل بعد التبديل. مع نهج Cloudflare Worker الموضح في هذه المقالة، العودة للنسخة السابقة هي استدعاء API واحد يسري عملياً في جميع أنحاء العالم في ثوانٍ. مع التبديل المستند إلى DNS، تستغرق العودة للنسخة السابقة 1-10 دقائق حسب انتشار TTL. لا تقم أبداً بإيقاف تشغيل النظام القديم حتى تكون واثقاً من استقرار النظام الجديد.