لقد قمت بترحيل حوالي 40 مشروعًا إلى Sanity خلال السنوات الثلاث الماضية. كان البعض عبارة عن سباقات نظيفة لمدة أسبوعين. أما البعض الآخر فتحول إلى معاناة لمدة ثلاثة أشهر جعلتني أشكك في اختياري الوظيفي. لا يكون الفرق تقريبًا أبدًا بسبب نظام إدارة المحتوى المصدر — بل يأتي من التحضير وقرارات نمذجة المحتوى والصراحة حول ما تقدمت عليه فعلاً.

هذا هو الدليل الذي تمنيت أن أملكه عندما بدأت بإجراء ترحيلات نظام إدارة المحتوى. يغطي الانتقال من WordPress و Contentful و Drupal إلى عالم Sanity المدعوم بـ GROQ. سأكون صريحًا حول المكان الذي يتفوق فيه Sanity، والمكان الذي قد يسبب لك الإحباط، وكيف تبدو جداول الزمن الفعلية.

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

دليل ترحيل Sanity: الانتقال من WordPress أو Contentful أو Drupal

لماذا تنتقل الفرق إلى Sanity في 2025

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

تصل مواقع WordPress إلى حدود التوسع حول 50,000+ جزء محتوى مع أنواع منشورات مخصصة معقدة. يبدأ نموذج تسعير Contentful في الضغط في المستوى العام — رأينا فرقًا تواجه فواتير بقيمة 3,500+ دولار شهريًا لما يعادل واجهة برمجة تطبيقات محتوى. فرق Drupal لا تستطيع العثور على المطورين بعد الآن، أو على الأقل على من يريدون العمل مع قوالب PHP في 2025.

نموذج تسعير Sanity أكثر قابلية للتنبؤ بشكل حقيقي لمعظم الفرق. الطبقة المجانية تغطي حتى 100 ألف طلب واجهة برمجة تطبيقات شهريًا و 500 ألف أصل. خطة Growth بسعر 99 دولارًا شهريًا لكل مشروع توفر 2.5 مليون طلب واجهة برمجة تطبيقات و 1 مليون أصل. للمقارنة، خطة Team من Contentful تبلغ 300 دولار شهريًا وقد تتجاوز طبقة Contentful Premium بسهولة 2,000 دولار شهريًا.

لكن إليك رأيي الصريح: إذا كان نظام إدارة المحتوى الحالي يعمل بشكل جيد وكان فريقك منتجًا، فلا تقم بالترحيل فقط لأن Sanity أحدث أو أكثر برودة. الترحيلات دائمًا تكلف أكثر مما تعتقد.

تدقيق ما قبل الترحيل: الخطوة التي يتخطاها الجميع

قبل أن تكتب سطر واحد من كود الترحيل، تحتاج إلى تدقيق المحتوى. ليس فحصًا سريعًا — تدقيق فعلي. إليك كيف يبدو:

جرد المحتوى

وثّق كل نوع محتوى وكل حقل وكل علاقة. أستخدم جدول بيانات بهذه الأعمدة:

  • اسم نوع المحتوى
  • إجمالي العناصر
  • الحقول (مع الأنواع)
  • العلاقات مع أنواع المحتوى الأخرى
  • مرفقات الوسائط (العدد والحجم الإجمالي)
  • الوظائف المخصصة (رموز قصيرة وودجات وتضمينات)
  • آخر تاريخ تعديل
  • لا تزال ذات صلة؟ (نعم/لا/ربما)

ستندهش من مدى كثرة المحتوى الميت. في أحد ترحيلات WordPress، كان لدى العميل 12,000 منشور. بعد التدقيق، كان لا يزال هناك 4,200 فقط ذات صلة. هذا أقل 65٪ من المحتوى الذي يجب ترحيله واختباره والتحقق من صحته.

خريطة تبعيات تقنية

قائمة كل مكون إضافي أو وحدة أو تكامل يستخدمه نظام إدارة المحتوى الحالي. لكل واحد منها، حدد:

  1. هل يمكن لـ Sanity التعامل مع هذا بشكل أصلي؟
  2. هل هناك مكون إضافي Sanity له؟
  3. هل نحتاج إلى بناء حل مخصص؟
  4. هل يمكننا إسقاط هذا تمامًا؟

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

تقييم جاهزية الفريق

استوديو Sanity مبني على React. محررو المحتوى لديك سيحتاجون إلى تدريب. المطورون لديك سيحتاجون إلى تعلم GROQ (أو استخدام GraphQL، رغم أن GROQ هو حيث يتفوق Sanity حقًا). ميزانية 1-2 أسبوع لتدريب الفريق — ليس كخيار اختياري، بل كعنصر في السطر.

ترحيل WordPress إلى Sanity

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

ما الذي ينقل بنظافة

  • المنشورات والصفحات (محتوى أساسي)
  • الفئات والوسوم
  • الصور المميزة
  • بيانات المؤلف
  • الحقول المخصصة الأساسية (ACF و Meta Box)

ما الذي يصبح فوضوي

  • كتل Gutenberg: يحتاج كل نوع كتلة إلى كتلة مخصصة Portable Text أو نوع كائن Sanity مقابل. إذا كان لديك 15+ كتل Gutenberg مخصصة، فميزانية وقت كبير هنا.
  • الرموز القصيرة: تحتاج هذه إلى تحليل وتفسير وتحويل إلى تعليقات Portable Text أو كتل مخصصة. رموز WPBakery و Elementor قصيرة مؤلمة بشكل خاص.
  • محتوى توليده المكون الإضافي: منتجات WooCommerce وبيانات Yoast SEO وحقول مكرر ACF — كل واحد يتطلب منطق ترحيل مخصص.
  • مكتبة الوسائط: WordPress تخزن أحجام صور متعددة. Sanity يتعامل مع تحويلات الصور على الفور، لذلك تحتاج فقط إلى الأصلية. لكن إيجاد الأصول في مجلد wp-uploads فوضوي؟ أوقات ممتعة.

نهج سكريبت الترحيل

عادة ما أستخدم سكريبت Node.js يصل إلى REST API لـ WordPress ويكتب إلى API الطفرة Sanity:

import { createClient } from '@sanity/client'
import fetch from 'node-fetch'

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

const WP_API = 'https://yoursite.com/wp-json/wp/v2'

async function migratePosts(page = 1) {
  const res = await fetch(`${WP_API}/posts?per_page=100&page=${page}`)
  const posts = await res.json()
  const totalPages = res.headers.get('x-wp-totalpages')

  const transaction = sanity.transaction()

  for (const post of posts) {
    transaction.createOrReplace({
      _id: `wp-post-${post.id}`,
      _type: 'post',
      title: post.title.rendered,
      slug: { current: post.slug },
      publishedAt: post.date,
      // Body requires HTML-to-Portable-Text conversion
      body: await convertToPortableText(post.content.rendered),
    })
  }

  await transaction.commit()
  console.log(`Migrated page ${page} of ${totalPages}`)

  if (page < totalPages) {
    await migratePosts(page + 1)
  }
}

دالة convertToPortableText هي حيث تعيش 80٪ من التعقيد. أستخدم حزمة @sanity/block-tools مع jsdom لتحليل HTML. إنها تتعامل مع HTML الأساسي بشكل جيد، لكن العناصر المخصصة والرموز القصيرة تحتاج معالجات فردية.

جدول زمني واقعي

لموقع WordPress نموذجي يحتوي على 500-2,000 منشور وحقول مخصصة قياسية وعدد قليل من أنواع المنشورات المخصصة: 4-8 أسابيع شاملة نمذجة المحتوى وسكريبت الترحيل والتحقق من البيانات وتدريب المحررين.

دليل ترحيل Sanity: الانتقال من WordPress أو Contentful أو Drupal - العمارة

ترحيل Contentful إلى Sanity

ترحيل Contentful-إلى-Sanity هو في الواقع أسلس مسار ترحيل من الثلاثة. لماذا؟ لأن كلا النظامين يستخدمان محتوى منظمًا مع نماذج ذهنية متشابهة. محتويتك بالفعل في نظام إدارة محتوى بدون رأس مع أنواع محتوى وحقول محددة.

الفروقات الرئيسية التي يجب الانتباه لها

الميزة Contentful Sanity
النص الغني النص الغني (JSON) Portable Text (JSON)
نمذجة المحتوى واجهة الويب مخططات محددة في الكود
لغة الاستعلام GraphQL / REST GROQ (+ GraphQL)
التوطين مدمج في مستوى الحقل مكون إضافي أو مخصص
المراجع روابط (دخول/أصل) مراجع مع أنواع
Webhooks نعم نعم
معالجة الأصول CDN مدمج Sanity CDN + نقطة ساخنة/قص
التسعير (المستوى الأوسط) ~$300/شهر (Team) $99/شهر (Growth)

تحويل النص الغني

Contentful Rich Text و Sanity Portable Text كلاهما مستند إلى JSON، وهو أمر رائع. لكن لديهم هياكل مختلفة. ستحتاج إلى كتابة محول:

function contentfulRichTextToPortableText(richTextField) {
  return richTextField.content.map(node => {
    switch (node.nodeType) {
      case 'paragraph':
        return {
          _type: 'block',
          style: 'normal',
          children: node.content.map(mapInlineContent),
        }
      case 'heading-2':
        return {
          _type: 'block',
          style: 'h2',
          children: node.content.map(mapInlineContent),
        }
      case 'embedded-entry-block':
        // Map to your custom Portable Text type
        return mapEmbeddedEntry(node)
      // ... handle all node types
    }
  }).filter(Boolean)
}

رسم الخريطة من نوع المحتوى إلى المخطط

أنواع محتوى Contentful تُرسم خريطة بشكل مباشر إلى أنواع وثائق Sanity ونوع الكائن. أكبر تحول هو أن مخططات Sanity محددة في الكود (JavaScript/TypeScript)، وليس في واجهة ويب. هذا في الواقع ميزة ضخمة — نموذج المحتوى الخاص بك يعيش في التحكم في الإصدار.

استخدم Contentful Management API لتصدير نموذج المحتوى، ثم اكتب سكريبت ينشئ ملفات مخطط Sanity:

contentful space export --space-id YOUR_SPACE_ID --export-dir ./export

جدول زمني واقعي

لـ Contentful space بـ 10-20 نوع محتوى و 5,000-10,000 إدخال: 3-5 أسابيع. إنها أسرع لأنك تفكر بالفعل في محتوى منظم.

ترحيل Drupal إلى Sanity

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

التحديات الخاصة بـ Drupal

  • أنواع محتوى بـ 50+ حقل: Drupal يجعل من السهل إضافة حقول. سهل جدا. رأيت أنواع محتوى بـ 80 حقل، نصفها غير مستخدم.
  • مراجع شروط التصنيف: نظام تصنيف Drupal مرن لكن يمكنه إنشاء تسلسلات هرمية متعددة التنسيق تحتاج إلى تسطيح لـ Sanity.
  • وحدة الفقرات: إذا كان الموقع يستخدم Drupal Paragraphs (ومعظم مواقع Drupal الحديثة تستخدمه)، فإن كل نوع فقرة يصبح نوع كتلة Portable Text أو نوع كائن Sanity. هذه هي أكبر مهمة واحدة.
  • كيانات الوسائط: نظام الوسائط في Drupal 9/10 أكثر تعقيدًا من نظام WordPress. أنواع وسائط متعددة وكيانات وسائط قابلة لإعادة الاستخدام وتكوينات حقول الملفات — كل منها يحتاج إلى تعيين.
  • محتوى متعدد اللغات: نظام الترجمة Drupal متطور. Sanity لا يملك توطينًا مدمجًا على نفس المستوى — ستحتاج إلى مكون إضافي @sanity/document-internationalization أو نهج على مستوى الحقل.

نهج الترحيل

أفضل استخدام وحدة JSON:API من Drupal (المضمنة في Drupal core منذ 9.x) كطبقة الاستخراج:

async function fetchDrupalContent(type, page = 0) {
  const limit = 50
  const offset = page * limit
  const url = `${DRUPAL_URL}/jsonapi/node/${type}?page[limit]=${limit}&page[offset]=${offset}&include=field_image,field_paragraphs`

  const res = await fetch(url, {
    headers: { Authorization: `Basic ${DRUPAL_AUTH}` },
  })
  return res.json()
}

بالنسبة لمواقع Drupal 7 الأقدم بدون JSON:API، قد تحتاج إلى الاستعلام من قاعدة البيانات مباشرة. مخطط قاعدة بيانات Drupal 7... تجربة. جداول field_data_* ستطاردك في أحلامك.

جدول زمني واقعي

ترحيلات Drupal تختلف كثيرًا. موقع Drupal 10 مباشر بـ 5-10 أنواع محتوى: 5-8 أسابيع. موقع Drupal 7 قديم بـ 30+ نوع محتوى و Paragraphs ومحتوى متعدد اللغات: 8-16 أسبوع. أنا لا أبالغ.

نمذجة المحتوى: الحصول على المخططات الصحيحة

إليك الشيء الذي لن تخبرك به معظم أدلة الترحيل: لا تكرر نموذج المحتوى القديم الخاص بك في Sanity. هذه فرصتك لإصلاح سنوات من الديون المتراكمة.

أخطاء نمذجة شائعة

  1. إنشاء خريطة حقل 1:1: فقط لأن WordPress كان لديه حقل مخصص "subtitle" لا يعني أن Sanity يحتاج واحد. ربما يجب أن يكون جزءًا من كائن "بطل" منظم.
  2. الإفراط في دمج الكائنات: Sanity تسمح لك بدمج الكائنات بعمق. مقاومة الرغبة. المخططات المسطحة أكثر أو أقل أسهل في الاستعلام مع GROQ وأسهل على المحررين للعمل بها.
  3. تجاهل قوة Portable Text: لا تنسخ فقط HTML في حقل نص واحد. ابتكر أنواع كتل مخصصة تطابق أنماط المحتوى الخاصة بك. كتلة "callout" و كتلة "مقطع رمز" و كتلة "صورة مع تسمية توضيحية" — هذه تحسن حياة المحررين.

عملية تصميم المخطط

أتبع هذا الترتيب:

  1. تدقيق المحتوى الموجود (تم في المرحلة السابقة)
  2. تحديد أنماط المحتوى الفعلية (وليس ما فرضه نظام إدارة المحتوى)
  3. تصميم المخططات على الورق/السبورة البيضاء أولاً
  4. بناء المخططات في الكود
  5. استيراد دفعة اختبار صغيرة (50-100 عنصر)
  6. يقوم المحررون باختبار تجربة Studio
  7. التكرار على المخططات قبل الترحيل الكامل

الخطوات 5-7 حرجة وغالباً ما يتم تخطيها. كتبنا المزيد عن نماذج نمذجة المحتوى في عمل تطوير CMS بدون رأس.

استراتيجيات وأدوات ترحيل البيانات

الأدوات الأساسية

  • @sanity/client: عميل JavaScript الرسمي لقراءة/كتابة بيانات Sanity
  • @sanity/block-tools: تحويل HTML إلى Portable Text
  • sanity dataset import/export: أدوات CLI لعمليات مجموعة بيانات كاملة
  • ndjson: Sanity تستخدم JSON مفصولة بأسطر جديدة للاستيراد — تعرف على الراحة بها
  • jsdom أو htmlparser2: لتحليل HTML أثناء تحويل النص الغني

معمارية الترحيل

أنظم كل ترحيل كخط أنابيب بأربع مراحل:

استخراج → تحويل → تحميل → التحقق

كل مرحلة عبارة عن سكريبت منفصل. هذا مهم لأنك ستقوم بتشغيل الترحيل عدة مرات — عادة 5-10 مرات قبل عملية الترحيل الكاملة للإنتاج. وجود مراحل منفصلة يعني أنه يمكنك إعادة تشغيل الأجزاء التي تحتاج إلى إصلاح فقط.

# استخراج
node scripts/extract-wordpress.js > data/raw-posts.ndjson

# تحويل
node scripts/transform-posts.js < data/raw-posts.ndjson > data/sanity-posts.ndjson

# تحميل
sanity dataset import data/sanity-posts.ndjson production --replace

# التحقق
node scripts/validate-migration.js

التعامل مع الأصول

الصور والملفات هي دائما الجزء الأبطأ. خط أنابيب أصول Sanity جيد، لكن تحميل 10,000 صورة يستغرق وقتًا. نصائح:

  • حمّل الأصول أولاً، احتفظ بخريطة من عناوين URL القديمة إلى معرفات أصول Sanity الجديدة
  • استخدم التحميلات المتزامنة (لكن احترم حدود المعدل — 25 req/sec لخطة Growth)
  • تحقق من أبعاد الصورة والصيغ قبل التحميل
  • لا تقم بترحيل أحجام الصور المصغرة — Sanity ينشئ هذه على الفور عبر شبكة صورها

التكاليف المخفية التي لا يتحدث أحد عنها

دعني أكون صريحًا معك بشأن التكاليف التي لا تظهر في تقدير الترحيل النموذجي.

إعادة التوجيهات

إذا كنت تغير واجهة المستخدم الخاصة بك (وأنت على الأرجح إذا كنت تنتقل إلى CMS بدون رأس)، فأنت بحاجة إلى رسم خريطة إعادة التوجيه. كل. عنوان. URL واحد. بالنسبة لـ SEO، هذا غير قابل للتفاوض. موقع بـ 5,000 صفحة يحتاج 5,000 قاعدة إعادة توجيه. الأدوات مثل إعادة التوجيه next.config.js أو ملف _redirects من Vercel يمكنها التعامل مع هذا، لكن يجب على شخص ما بناء الخريطة.

ترحيل بيانات SEO الوصفية

بيانات Yoast SEO من WordPress. بيانات وحدة Metatag من Drupal. حقول SEO من Contentful. كل هذا يحتاج أن يأتي. عناوين وصفية مخصصة ووصفات ويصور Open Graph وعناوين URL قانونية والبيانات المنظمة — إنه مشروع داخل المشروع.

تدريب المحررين والتوثيق

ميزانية 2-4 أيام على الأقل. استوديو Sanity بديهي، لكنه مختلف عما يعرفه محررو الأخبار الخاصة بك. عادة ما ننشئ توثيق Studio مخصص مع لقطات شاشة وننسخ ثلاثة إلى خمسة مقاطع فيديو.

تطوير الواجهة الأمامية

هذا هو الفيل في الغرفة. ترحيل المحتوى إلى Sanity هو نصف المشروع فقط. تحتاج أيضًا إلى واجهة أمامية تستهلك المحتوى. سواء كنت تستخدم Next.js أو Astro أو إطار عمل آخر، فإن بناء الواجهة الأمامية غالباً ما يكون 50-70٪ من التكلفة الإجمالية للمشروع. تحقق من عملنا مع Next.js و Astro إذا كنت تقيم خيارات الواجهة الأمامية.

مقارنة جدول الزمن والميزانية

بناءً على المشاريع التي أكملناها في 2024-2025:

مسار الترحيل حجم المحتوى التعقيد جدول الزمن نطاق الميزانية
WordPress → Sanity < 1,000 صفحة منخفض 3-5 أسابيع $8K-$15K
WordPress → Sanity 1,000-10,000 صفحة متوسط 6-10 أسابيع $15K-$35K
WordPress → Sanity 10,000+ صفحة عالي 10-16 أسبوع $35K-$75K
Contentful → Sanity < 5,000 إدخال منخفض-متوسط 3-5 أسابيع $7K-$18K
Contentful → Sanity 5,000-20,000 إدخال متوسط 5-8 أسابيع $18K-$40K
Drupal → Sanity < 2,000 عقدة متوسط 5-8 أسابيع $12K-$25K
Drupal → Sanity 2,000-15,000 عقدة عالي 8-14 أسبوع $25K-$60K
Drupal 7 → Sanity أي عالي جداً 10-20 أسبوع $35K-$90K

ملاحظة: تغطي هذه النطاقات ترحيل المحتوى فقط. تطوير الواجهة الأمامية إضافي. تواصل معنا على /pricing للحصول على تقديرات خاصة بالمشروع.

تشمل هذه الأرقام نمذجة المحتوى وسكريبت الترحيل والتحقق من البيانات والتدريب الأساسي للمحررين. إنها لا تشمل تطوير الواجهة الأمامية أو التصميم أو الصيانة المستمرة.

قائمة التحقق بعد الترحيل

إليك قائمة التحقق التي أستخدمها في كل ترحيل:

  • تم ترحيل جميع أنواع المحتوى والتحقق منها
  • جميع المراجع/العلاقات سليمة
  • تم تحميل وربط جميع الصور والملفات بشكل صحيح
  • محتوى النص الغني يتم عرضه بشكل صحيح (تحقق من التنسيق المنقطع)
  • إعادة التوجيهات في مكانها واختبرت
  • تم ترحيل بيانات SEO الوصفية (العناوين والأوصاف وبيانات OG)
  • تم إعادة إنشاء خريطة الموقع XML
  • تم تحديث وحدة التحكم في البحث بالخريطة الجديدة
  • تتبع التحليلات المحفوظ
  • تم إنشاء حسابات المحرر وتعيين الأذونات
  • اكتمل تدريب المحرر
  • معاينة المحتوى (وضع المسودة) تعمل
  • Webhooks مكونة لتشغيل البناء
  • تم أرشفة نسخة احتياطية من بيانات نظام إدارة المحتوى المصدر
  • تم التخطيط لتغييرات DNS (إن أمكن)
  • تم قياس خط الأساس للأداء
  • تم إعداد مراقبة 404 أول 30 يومًا

تلك النقطة الأخيرة مهمة. بغض النظر عن مدى شمول رسم خريطة إعادة التوجيه، فستسقط بعض عناوين URL. راقب 404 بعدوانية أول شهر.

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

كم من الوقت يستغرق ترحيل WordPress النموذجي إلى Sanity؟ بالنسبة لموقع WordPress قياسي يحتوي على أقل من 2,000 منشور وحقول مخصصة واضحة، توقع 4-8 أسابيع. يتضمن ذلك نمذجة المحتوى وسكريبت الترحيل والتحقق من البيانات وتدريب المحررين. يمكن للمواقع ذات كتل Gutenberg المعقدة أو WooCommerce أو المحتوى متعدد اللغات أن تستغرق 10-16 أسبوع. حجم المحتوى أقل أهمية من تعقيد أنواع المحتوى الخاصة بك.

هل يمكنني الترحيل من Contentful إلى Sanity دون فقدان البيانات؟ نعم، وهذا هو في الواقع أنظف مسار ترحيل بين الثلاثة التي أغطيها هنا. كلا النظامين يستخدمان محتوى منظم قائم على JSON لذا الخريطة مباشرة نسبياً. النص الغني يحتاج إلى تحويل من صيغة Contentful إلى Portable Text، والمراجع تحتاج إلى إعادة خريطة، لكن لا يجب أن تفقد أي بيانات. أوصي بتشغيل الترحيل مقابل مجموعة بيانات التدريج أولاً والقيام بمقارنة محتوى شاملة قبل الانقطاع.

ماذا يحدث لتصنيفات SEO الخاصة بي أثناء ترحيل نظام إدارة المحتوى؟ هذا هو السؤال الذي يبقي مديري التسويق مستيقظين في الليل. إذا تعاملت مع إعادة التوجيهات بشكل صحيح وحافظت على هيكل عنوان URL حيث أمكن، وقمت بترحيل جميع بيانات SEO الوصفية، يجب أن تري تأثيرًا بسيطًا. وثائق Google الخاصة تقول أن الترحيلات المعاد توجيهها بشكل صحيح قد ترى انخفاضًا مؤقتًا من 2-4 أسابيع قبل التعافي. الكلمة الرئيسية هي "بشكل صحيح". تخطي رسم خريطة إعادة التوجيه وستدمر التصنيفات الخاصة بك. رأينا ذلك يحدث.

هل Sanity أرخص من Contentful للاستخدام العام؟ في معظم الحالات، نعم — أحيانًا بشكل كبير. خطة Growth من Sanity بسعر 99 دولار/شهر تغطي ما تحتاجه لخطة Team من Contentful بقيمة 300 دولار/شهر. على نطاق واسع، يصبح الفرق أكبر. لم يتم الإعلان عن تسعير Contentful Premium بشكل علني لكنه عادة ما يبلغ حوالي 2,000-4,000 دولار+/شهر. تسعير Sanity Enterprise مخصص أيضًا لكن بشكل عام يأتي أقل بكثير للاستخدام المعادل. الفرق الحقيقي في التكلفة في استدعاءات API — حدود Sanity المضمنة أكثر كرماً.

هل يجب أن أقوم بترحيل موقع Drupal 7 الخاص بي إلى Sanity أو ترقية إلى Drupal 10 أولاً؟ انتقل مباشرة إلى Sanity. الترحيل من Drupal 7 إلى Drupal 10 يقارب الكثير عمل كالترحيل إلى CMS مختلف تماماً — تغيرت العمارة هذا الكثير بين الإصدارات. إذا كنت بالفعل تستثمر في ترحيل رئيسي، قد تذهب مباشرة إلى النظام الأساسي الذي تريد أن تكون عليه على المدى الطويل. الاستثناء الوحيد: إذا كان فريقك مستثمراً بعمق في النظام البيئي Drupal وفقط يريد التحديث، فإن Drupal 10 مع واجهة أمامية بدون رأس هو مسار صالح.

هل أحتاج إلى إعادة بناء واجهتي الأمامية عند الترحيل إلى Sanity؟ إذا كنت تأتي من CMS أحادي الكتلة مثل WordPress أو Drupal، نعم — ستحتاج إلى واجهة أمامية جديدة لأن Sanity بدون رأس. هذا عادة الجزء الأكبر من المشروع. إذا كنت تأتي من Contentful، فيمكنك غالباً إعادة استخدام الواجهة الأمامية الموجودة مع استدعاءات API معدلة، خاصة إذا كنت تستخدم بالفعل Next.js أو إطار عمل مشابه. نتعامل مع ترحيل CMS وبناء الواجهة الأمامية كمشاريع متكاملة.

هل يمكنني تشغيل نظام إدارة المحتوى القديم و Sanity بالتوازي أثناء الترحيل؟ بالتأكيد، وأوصي به. قم بتشغيل كلا النظامين لمدة 2-4 أسابيع بعد الترحيل الأولي. يمكن للمحررين الاستمرار في العمل في نظام إدارة المحتوى القديم بينما تقوم بالتحقق من البيانات في Sanity. فقط تجميد المحتوى في النظام القديم قبل عملية الترحيل النهائية — لا تريد مطاردة هدف متحرك. تقوم بعض الفرق بتعيين تاريخ "تجميد المحتوى" 48 ساعة قبل الانقطاع النهائي.

ما هو أكبر خطأ تقوم به الفرق أثناء ترحيل Sanity؟ محاولة نسخ هيكل نظام إدارة المحتوى القديم بالضبط في Sanity. أرى هذا باستمرار. تأتي الفرق من WordPress وتحاول بناء مخططات بشكل WordPress في Sanity — أنواع "صفحة" عامة مع تخطيطات مرنة بدلاً من أنواع محتوى مصممة بهدف. قوة Sanity هي المحتوى المنظم. استخدم الترحيل كفرصة لنمذجة المحتوى بشكل صحيح. اقضِ أسبوعًا إضافيًا على نمذجة المحتوى. سيوفر عليك أشهر من الألم لاحقاً. إذا كنت تريد إرشادات حول هذا، تواصل معنا — نمذجة المحتوى هي أحد الأشياء التي نقضي عليها معظم الوقت في مشاريع الترحيل.