Payload CMS 2026: لماذا استحوذت عليه Figma — وهل تتبنّاه؟

دليل Payload CMS: الإعداد والواجهات البرمجية والنشر في 2026

Payload نظام إدارة محتوى مفتوح المصدر، مبني بلغة TypeScript بشكل أصيل، ويعيش داخل تطبيق Next.js الخاص بك -- لا بجانبه، ولا في حاوية منفصلة، بل حرفياً داخل مجلد /app نفسه. إذا آذاك يوماً نظام CMS مستضاف يفرض رسوماً على كل مقعد أو يحجب محتواك خلف واجهات برمجية ملكية، فإن Payload يستحق دراسة جادة.

لكن عام 2026 جاء بمفاجأة: استحوذت Figma على Payload، وأوقفت Payload Cloud تسجيل مستخدمين جدد، وأصبح المطورون مضطرين لإيجاد حلول استضافة بأنفسهم. يغطي هذا الدليل كل شيء من التثبيت الأول حتى النشر في بيئة الإنتاج، مع أمثلة برمجية حديثة لـ Payload 3 وآراء صريحة حول نقاط القوة والضعف.

ما هو Payload CMS؟ (ولماذا يحبه المطورون)

Payload نظام إدارة محتوى مفتوح المصدر وإطار عمل تطبيقات، مبني بـ TypeScript بشكل أصيل ويعمل داخل تطبيق Next.js. على خلاف منصات CMS المستضافة، يمنحك Payload ضبطاً أولياً قائماً على الكود، وثلاث واجهات برمجية مدمجة (REST وGraphQL وLocal)، ولوحة إدارة قابلة للتخصيص الكامل -- كل ذلك من قاعدة كود واحدة. وفقاً لـ توثيق Payload الرسمي، صُمِّم ليكون "أفضل طريقة لبناء خلفية حديثة."

بدأ المشروع عام 2021 بوصفه نظام CMS مبنياً على Node.js وExpress. جاء Payload 2 في 2023 بدعم محسّن لـ TypeScript. ثم غيّر Payload 3 قواعد اللعبة كلياً: انتقل نظام CMS إلى داخل تطبيق Next.js. لا عملية خادم منفصلة. لا نشر منفصل. يتشارك CMS والواجهة الأمامية نفس بيئة تشغيل Next.js، ونفس المسارات، ونفس خط بناء المشروع.

هذه بنية مختلفة فعلاً عما تقدمه Sanity أو Strapi أو Contentful. ولها تداعيات حقيقية على طريقة البناء والنشر والتفكير في طبقة المحتوى.

فلسفة الكود أولاً

معظم منصات CMS تمنحك واجهة رسومية لتحديد نموذج المحتوى. انقر "إضافة حقل"، اختر "نص"، سمِّه "العنوان". Payload يقلب هذا: تُعرَّف كل شيء في ملفات TypeScript. مخططك هو كود. يعيش في نظام التحكم بالإصدارات. تراجعه في طلبات السحب.

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

بنية Payload 3 -- أصيل في Next.js

لا يعمل Payload 3 بجانب تطبيق Next.js، بل يعمل بداخله. لوحة الإدارة في /app/(payload)/admin، ومسارات الواجهة البرمجية في /app/(payload)/api، وصفحات الواجهة الأمامية موجودة في المشروع ذاته. إذا استخدمت Next.js في بيئة الإنتاج من قبل، ستشعر بالألفة فوراً.

الميزات الرئيسية التي تميّز Payload

تشمل الميزات البارزة في Payload: المجموعات لنمذجة المحتوى، وطبقة الواجهة البرمجية الثلاثية (REST وGraphQL وLocal)، والتحكم في الوصول القائم على الأدوار بدقة على مستوى الحقل، والمصادقة المدمجة، ومحرر النص المنسق Lexical، والمعاينة المباشرة للتحرير البصري. إليك ما يعنيه كل ذلك عملياً في قاعدة الكود.

المجموعات والـ Globals والحقول

المجموعات هي الوحدة الأساسية لنمذجة المحتوى في Payload. فكّر فيها كجداول قواعد البيانات، لكنها معرَّفة بالكامل في TypeScript. كل مجموعة تحصل على نقاط نهاية REST وGraphQL خاصة بها، وعرض لوحة إدارة خاصة بها، وقواعد تحكم في الوصول خاصة بها -- كل ذلك مولَّد من ملف ضبط واحد.

// collections/Posts.ts
import type { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
    defaultColumns: ['title', 'status', 'updatedAt'],
  },
  versions: {
    drafts: true,
    maxPerDoc: 10,
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    { name: 'content', type: 'richText' },
    {
      name: 'status',
      type: 'select',
      defaultValue: 'draft',
      options: ['draft', 'published', 'archived'],
    },
    { name: 'author', type: 'relationship', relationTo: 'users' },
    { name: 'publishedAt', type: 'date' },
  ],
}

تعمل الـ Globals بشكل مشابه لكن للبيانات الفردية -- إعدادات الموقع، وضبط التنقل، ومحتوى التذييل. نسخة واحدة، لا عرض قائمة مجموعة، فقط مستند واحد قابل للتحرير.

طبقة الواجهة البرمجية الثلاثية (REST وGraphQL وLocal)

هنا يتفوق Payload فعلاً على كل نظام CMS مفتوح المصدر آخر. تحصل على ثلاث طرق للاستعلام عن محتواك، كل منها محسَّن لسياق مختلف:

• Local API: استعلامات جانب الخادم بدون أي تكلفة HTTP. استدعِ نظام CMS مباشرةً في مكونات خادم Next.js. لا رحلة شبكية، لا تكلفة تسلسل. في اختباراتنا، قلّل Local API أوقات تحميل الصفحة بحوالي 40 مللي ثانية مقارنةً باستدعاءات REST على الخادم نفسه.
• REST API: نقاط نهاية مولَّدة تلقائياً للعملاء الخارجيين وتطبيقات الجوال وعمليات التكامل مع أطراف ثالثة.
• GraphQL API: استعلامات مرنة للواجهات الأمامية التي تحتاج إلى تشكيل طلبات البيانات بدقة.

إليك شكل استدعاء Local API في مكون خادم Next.js:

// app/(frontend)/blog/[slug]/page.tsx
import { getPayload } from 'payload'
import config from '@payload-config'

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const payload = await getPayload({ config })

  const post = await payload.find({
    collection: 'posts',
    where: { slug: { equals: params.slug }, status: { equals: 'published' } },
    depth: 2,
  })

  return <article>{/* render post.docs[0] */}</article>
}

لا استدعاء fetch. لا عنوان URL للواجهة البرمجية. لا رمز مصادقة. أنت تستعلم قاعدة بياناتك مباشرةً من مكون خادم، وTypeScript يمنحك أماناً كاملاً للأنواع على الاستجابة. هذا يصعب التفوق عليه.

التحكم في الوصول والمصادقة

نظام التحكم في الوصول في Payload قائم على الدوال. بدلاً من ضبط الصلاحيات في لوحة تحكم، تكتب دوال TypeScript تُرجع true أو false. على مستوى الحقل، أو المجموعة، أو العملية -- أنت من يحدد الدقة.

// Example: Only published posts are publicly readable
access: {
  read: ({ req }) => {
    if (req.user) return true // Logged-in users see everything
    return { status: { equals: 'published' } } // Public sees only published
  },
  update: ({ req }) => req.user?.role === 'admin',
  delete: ({ req }) => req.user?.role === 'admin',
}

المصادقة مدمجة: رموز JWT، ورموز التحديث، وتدفق نسيان كلمة المرور، والتحقق من البريد الإلكتروني. لا تحتاج إلى Clerk أو NextAuth إلا إذا أردتهما تحديداً. بالنسبة لمعظم المشاريع، مصادقة Payload أكثر من كافية.

محرر النص المنسق Lexical

يستخدم Payload Lexical، إطار النص المنسق من Meta (الفريق نفسه خلف Draft.js، لكن أفضل). يمكنك إضافة كتل مخصصة وعناصر مضمّنة وأوامر slash. يُسلسِل المحرر إلى تنسيق JSON منظم يمكنك تحويله إلى HTML أو مكونات React.

هذا مهم لأن معظم محررات نصوص CMS إما بسيطة جداً (textarea عادي) أو معتمة جداً (WYSIWYG يولّد HTML غير متوقع). Lexical يمنحك مخرجاً منظماً وقابلاً للتنبؤ تتحكم فيه بالكامل.

المعاينة المباشرة والتحرير البصري

يشحن Payload 3 مع معاينة مباشرة: يرى المحررون تغييرات المحتوى تنعكس على الواجهة الأمامية الفعلية في الوقت الفعلي، جنباً إلى جنب مع لوحة الإدارة. هذه فجوة مهمة يملأها Payload مقارنةً بـ Strapi الذي لا يملك أي تحرير بصري.

ليست بالأناقة الكاملة لميزات التعاون الفوري في Sanity Studio -- التحرير البصري في Sanity هو الأفضل فعلاً في هذا المجال. لكن للفرق التي تحتاج معاينة بصرية "جيدة بما يكفي" دون دفع أسعار Sanity لكل مقعد، تؤدي تطبيق Payload الغرض.

الإصدارات والمسودات والحفظ التلقائي

يتضمن Payload إدارة مسودات مدمجة، وتاريخ الإصدارات، والحفظ التلقائي -- ميزات لا تذكرها أي من أبرز أدلة Payload. يمكنك تفعيل الإصدارات لكل مجموعة (فعلنا ذلك في مثال Posts أعلاه مع versions: { drafts: true }), وتحديد عدد أقصى للإصدارات، ومقارنة المراجعات في واجهة الإدارة.

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

البدء مع Payload CMS

لبدء مشروع Payload جديد، شغّل npx create-payload-app@latest، اختر قالباً (website أو blank)، اختر محوّل قاعدة البيانات (PostgreSQL أو MongoDB أو SQLite)، وستحصل على لوحة إدارة تعمل على localhost:3000/admin في أقل من دقيقتين. دليل التثبيت الرسمي يغطي الحالات الحدية.

التثبيت

تحتاج Node.js 18+ ومدير حزم. هذا كل شيء.

# Create a new Payload project
npx create-payload-app@latest my-cms

# The CLI asks you:
# - Project name
# - Template (website, blank, e-commerce)
# - Database (postgres, mongodb, sqlite)

cd my-cms
npm run dev
# Admin panel: http://localhost:3000/admin

قالب website هو أفضل نقطة بداية لمعظم المشاريع -- يشحن مع مدونة تعمل، ومجموعة صفحات، ورفع الوسائط، وواجهة أمامية. قالب blank للحالات التي تريد فيها البناء من الصفر.

بنية المشروع

بعد التثبيت، يبدو مشروعك كتطبيق Next.js قياسي مع Payload مضمَّناً:

my-cms/
  app/
    (frontend)/          # Your website pages
    (payload)/
      admin/             # Admin panel routes (auto-generated)
      api/               # REST + GraphQL endpoints
  collections/           # Your content model definitions
  globals/               # Singleton content (settings, nav)
  payload.config.ts      # Main Payload configuration
  payload-types.ts       # Auto-generated TypeScript types

ملف payload.config.ts هو قلب كل شيء:

// payload.config.ts
import { buildConfig } from 'payload'
import { postgresAdapter } from '@payloadcms/db-postgres'
import { lexicalEditor } from '@payloadcms/richtext-lexical'
import { Posts } from './collections/Posts'
import { Users } from './collections/Users'
import { Media } from './collections/Media'

export default buildConfig({
  admin: { user: Users.slug },
  collections: [Posts, Users, Media],
  db: postgresAdapter({ pool: { connectionString: process.env.DATABASE_URI } }),
  editor: lexicalEditor({}),
  secret: process.env.PAYLOAD_SECRET,
  typescript: { outputFile: './payload-types.ts' },
})

أول مجموعة لك

بعد تشغيل خادم التطوير، أنشئ مجموعة جديدة بإضافة ملف إلى /collections. يولّد Payload تلقائياً واجهة الإدارة ونقاط نهاية الواجهة البرمجية وأنواع TypeScript من ضبطك. إليك مجموعة Pages بسيطة:

// collections/Pages.ts
import type { CollectionConfig } from 'payload'

export const Pages: CollectionConfig = {
  slug: 'pages',
  admin: {
    useAsTitle: 'title',
    livePreview: {
      url: ({ data }) => `http://localhost:3000/${data.slug}`,
    },
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    {
      name: 'layout',
      type: 'blocks',
      blocks: [
        {
          slug: 'hero',
          fields: [
            { name: 'heading', type: 'text' },
            { name: 'subtitle', type: 'textarea' },
            { name: 'image', type: 'upload', relationTo: 'media' },
          ],
        },
      ],
    },
  ],
}

أضفه إلى مصفوفة collections في payload.config.ts، وأعد تشغيل خادم التطوير، وستحصل على أداة بناء صفحات وظيفية بالكامل مع واجهة إدارة بصرية. لا إضافات، لا تنزيلات من سوق.

خيارات قاعدة البيانات -- Postgres وMongoDB وSQLite

يدعم Payload ثلاثة محوّلات لقاعدة البيانات: PostgreSQL (الموصى به للإنتاج)، وMongoDB (للنماذج ذات المستندات الكثيفة أو الأكوام الموجودة مسبقاً على Mongo)، وSQLite (للتطوير المحلي والنمذجة الأولية فقط). نمط المحوّل يعني أن كود تطبيقك يبقى كما هو بغض النظر عن قاعدة البيانات التي تختارها.

إذا كنت تبدأ من الصفر، اختر PostgreSQL. يتعامل مع البيانات العلائقية بشكل أفضل (ومعظم بيانات CMS علائقية)، ولديه خيارات serverless ممتازة عبر Neon وSupabase، وهو ما يوصي به فريق Payload. راجع مقارنتنا بين PostgreSQL وMySQL لمزيد من السياق حول سبب هيمنة Postgres على تطوير التطبيقات الحديثة.

نصيحة احترافية: إذا كنت تنشر على Vercel، اقرن Payload مع Neon Postgres. يتعامل تجميع اتصالات Neon مع البدايات الباردة للـ serverless بشكل رشيق، وهذا مهم لأن Vercel تدور نسخاً جديدة من الدوال باستمرار.

الاستحواذ من Figma -- ماذا يعني للمطورين

استحوذت Figma على Payload في يونيو 2025. رخصة MIT وقاعدة الكود مفتوحة المصدر تبقيان دون تغيير. أوقفت Payload Cloud تسجيل مستخدمين جدد بينما يبني الفريق بديلاً، لكن الاستضافة الذاتية غير متأثرة. بالنسبة للمطورين، السؤال الأكبر ليس "هل Payload انتهى؟" -- بل "ماذا أفعل بشأن الاستضافة؟"

كنا نتابع Payload Cloud كخيار استضافة لمشروع عميل حين أُعلن عن الاستحواذ. إليك ما تعلمناه من التحوّل إلى الاستضافة الذاتية، وما يعنيه الاستحواذ فعلاً لمشاريعك.

في 17 يونيو 2025، أعلنت Figma عن الاستحواذ على مدونتها. نشر فريق Payload إعلانهم الخاص في اليوم نفسه. انضم الفريق بأكمله إلى Figma.

ما الذي تغيّر (وما الذي لم يتغير)

ما يبقى كما هو:

• رخصة MIT. لا يمكن سحبها. مستودع GitHub لا يزال نشطاً ومفتوحاً للمساهمات المجتمعية.
• قاعدة الكود. يعمل Payload 3 تماماً كما كان قبل الاستحواذ.
• الاستضافة الذاتية. يمكنك نشر Payload في أي مكان، إلى الأبد.

ما الذي تغيّر:

• أوقفت Payload Cloud تسجيل مستخدمين جدد. يمكن للعملاء الحاليين الاستمرار، لكن المشاريع الجديدة لا تستطيع استخدام الاستضافة المُدارة لـ Payload.
• انتقل تركيز الفريق. يبني فريق Payload الآن ما سيصبح على الأرجح "Figma CMS" -- سدّ الفجوة بين تصاميم Figma والمحتوى المباشر. التفاصيل تخمينية، لكن الاتجاه واضح.
• انتباه المجتمع. يقلق بعض المطورين من نمط "الاستحواذ ثم التخلي" الذي يطال المشاريع مفتوحة المصدر. رخصة MIT تخفف السيناريو الأسوأ، لكنه قلق مشروع.

هل لا تزال تختار Payload؟

بصراحة؟ نعم، مع تحفظات.

الإيجابي: موارد Figma تعني كفاءات هندسية أكبر خلف المشروع. رخصة MIT تعني أن السيناريو الأسوأ هو أن تفرعه. قاعدة الكود ناضجة وموثقة جيداً ومستخدمة في الإنتاج من قبل آلاف المشاريع.

المقلق: قد تتباعد حوافز Figma عن احتياجات مجتمع المصدر المفتوح بمرور الوقت. تجبرك الفجوة في Payload Cloud على إدارة الاستضافة بنفسك. وإذا كنت تكره المخاطر، فالغموض حول الاتجاه طويل الأمد حقيقي.

رأينا: إذا كنت مرتاحاً للاستضافة الذاتية (ويجب أن تكون -- إنها ليست صعبة)، يبقى Payload أفضل نظام CMS headless مفتوح المصدر وقائم على الكود متاحاً. لا تنتظر "Figma CMS". ابنِ بـ Payload 3 اليوم، وانشر ذاتياً، وامضِ قُدُماً.

كيفية نشر Payload CMS في 2026

مع إيقاف Payload Cloud لتسجيل مستخدمين جدد، خيارات النشر الرئيسية في 2026 هي: Vercel (أسرع إعداد، انتبه للبدايات الباردة)، وDocker على VPS (الأفضل للمحررين النشطين، EUR 7-45/شهر)، وRailway/Render/Fly.io (حاويات مُدارة)، وCloudflare Workers (الأرخص بحوالي $5-10/شهر). وفقاً لـ توثيق نشر Payload، أي استضافة Node.js تدعم Next.js ستعمل.

نشرنا Payload على كل من Vercel وVPS مبني على Docker. إليك ما فاجأنا: البدايات الباردة في Vercel جعلت لوحة الإدارة بطيئة للمحررين الذين يسجلون الدخول بضع مرات أسبوعياً فقط. الـ VPS، رغم أنه يتطلب إعداداً أكثر، وفّر تجربة تحريرية أفضل باستمرار.

Vercel (أسرع إعداد)

نشر بنقرة واحدة مع Neon Postgres وVercel Blob لرفع الملفات. أسرع مسار نحو الإنتاج.

المميزات: لا إدارة بنية تحتية، CDN ممتاز، مثالي للمواقع ذات النشاط التحريري الخفيف. العيوب: بدايات باردة للوحة الإدارة (3-5 ثوانٍ بعد التوقف)، استنفاد اتصالات Postgres تحت الاستعلامات الثقيلة، سقف مهلة 10 ثوانٍ قد يعطل العمليات الجماعية. الأفضل لـ: مواقع التسويق والمحافظ الشخصية والمدونات ذات التحرير غير المتكرر.

لمزيد من السياق حول نقاط قوة Vercel وقيوده، راجع مقارنتنا بين Vercel وNetlify.

Docker على VPS (الأفضل للإنتاج)

إعداد Docker Compose على Hetzner أو DigitalOcean أو AWS EC2. يتناسب هذا مع بنية Payload بشكل أفضل من serverless لأن Payload يتوقع عملية خادم مستمرة.

# docker-compose.yml
version: '3.8'
services:
  payload:
    build: .
    ports:
      - '3000:3000'
    environment:
      - DATABASE_URI=postgresql://payload:secret@db:5432/payload
      - PAYLOAD_SECRET=${PAYLOAD_SECRET}
      - NEXT_PUBLIC_SERVER_URL=https://your-domain.com
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=payload
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=payload

volumes:
  pgdata:

المميزات: خادم مستمر (لا بدايات باردة)، تكاليف متوقعة (EUR 7-45/شهر على Hetzner)، تحكم كامل في الكومة. العيوب: أنت من يدير الخادم وSSL والنسخ الاحتياطية والتحديثات. الأفضل لـ: الوكالات والفرق التحريرية النشطة وإعدادات multi-tenant والتطبيقات ذات الاستخدام الإداري الثقيل.

مقارنة استضافة تفصيلية من Build with Matija تغطي موفري VPS إضافيين وضبطهم.

الحاويات المُدارة (Railway وRender وFly.io)

إذا كان Docker على VPS يبدو عملاً تشغيلياً كثيراً، تقسّم منصات الحاويات المُدارة الفرق. Railway شائع بشكل خاص في مجتمع Payload -- لديهم قالب Payload يُنشَر بنقرة واحدة.

راجع مقارنتنا بين Railway وRender وFly.io للاطلاع على نظرة أعمق على هذه المنصات.

الأفضل لـ: الفرق التي تريد خوادم مستمرة دون إدارة البنية التحتية مباشرةً.

Cloudflare Workers (الأرخص)

الخيار الأحدث. أضاف Payload محوّل Cloudflare Workers الذي يعمل على دوال edge مع D1 (SQLite) أو Hyperdrive (وكيل Postgres). لا يزال تجريبياً نوعاً ما، لكن التكلفة لا تُبارى: ~$5-10/شهر لمعظم المشاريع.

الأفضل لـ: المشاريع الجانبية والمواقع الشخصية والنشر الاقتصادي حيث تكون مرتاحاً مع بنية تحتية أحدث وأقل اختباراً.

حكمنا: لمعظم مشاريع Payload في الإنتاج مع محررين نشطين، Docker على VPS هو الافتراضي الأفضل. أرخص مما تتوقع، يزيل مشاكل البدايات الباردة، ويمنحك تحكماً كاملاً. استخدم Vercel فقط إذا كان محرروك غير متكررين وتريد صفر عمليات تشغيل.

تكلفة Payload CMS -- الأرقام الحقيقية

Payload نفسه مجاني ومرخص بـ MIT. تكاليفك الفعلية هي الاستضافة و(اختيارياً) التطوير الاحترافي. إليك الأرقام بناءً على إعدادات واقعية وتفصيل التكاليف من Build with Matija.

للمقارنة: خطة Team في Contentful تبدأ بـ $300/شهر. خطة Team في Sanity بـ $99/شهر لكل مشروع. Strapi Cloud يبدأ بـ $29/شهر. $0 تكلفة برنامج Payload بالإضافة إلى $7-25/شهر استضافة يصعب الجدال معه -- خاصةً للوكالات التي تبني مشاريع عملاء حيث يدمّر التسعير لكل مقعد هوامش الربح.

Payload مقابل Sanity وStrapi وContentful -- مقارنة سريعة

اختر Payload إذا أردت تحكماً قائماً على الكود واستضافة ذاتية. اختر Sanity لأفضل تحرير بصري وتعاون فوري. اختر Strapi للحصول سريعاً على لوحة إدارة مع منظومة إضافات. اختر Contentful لبنية تحتية على مستوى المؤسسات مع ضمانات SLA. نحن نستخدم Sanity لـ techsy.io، لذا لدينا تجربة مباشرة في مقارنة هذه المنصات.

بنينا مشاريع قائمة على Payload لعملاء يحتاجون ملكية البيانات والاستضافة الذاتية، ونشغّل خط المحتوى الخاص بنا على Sanity. كلاهما ممتاز -- الاختيار الصحيح يعتمد على الكفاءة التقنية لفريقك وتفضيلات الاستضافة. إذا كنت تقيّم خيارات headless CMS لمشروع، يمكننا مساعدتك في الاختيار.

لمزيد من التعمق في كل منصة، راجع دليلنا: أفضل headless CMS في 2026.

متى لا تستخدم Payload CMS

تجنّب Payload إذا كان فريقك غير تقني ويحتاج واجهة رسومية شبيهة بـ WordPress، أو إذا كنت تحتاج استضافة سحابية مُدارة فورية دون عمل استضافة ذاتية، أو إذا أراد محرروك تحريراً بصرياً بمستوى Sanity Studio، أو إذا كنت تحتاج سوق إضافات للتوسع السريع. الصراحة بشأن القيود تبني ثقة أكبر من التظاهر بأنها غير موجودة.

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

• الفرق غير التقنية. Payload يتطلب معرفة TypeScript للضبط. إذا كان محررو عميلك لا يستطيعون لمس الكود ويحتاجون إلى تعديل نموذج المحتوى بأنفسهم، فـ WordPress أو Sanity خيارات أفضل.
• تحتاج استضافة مُدارة الآن. مع إيقاف Payload Cloud لمستخدمين جدد، يجب أن تستضيف ذاتياً. إذا كانت إدارة خادم (حتى إعداد Docker بسيط) أمراً رافضاً، فنهج الاستضافة السحابية لـ Contentful أو Sanity يزيل هذا العبء.
• تعاون تحريري مكثف. التعاون الفوري في Sanity Studio -- عدة محررين يعملون على نفس المستند في آنٍ واحد مع مؤشرات الحضور -- أكثر صقلاً مما يقدمه Payload. إذا كان لديك فريق تحريري كبير، Sanity يفوز هنا.
• التطوير القائم على الإضافات. Strapi لديه سوق إضافات أكبر. تحتاج إضافة SEO، أو مولّد خريطة موقع، أو تكامل بريد إلكتروني؟ Strapi لديه على الأرجح واحدة. منظومة Payload تنمو لكنها أصغر.
• لا تستخدم Next.js. Payload 3 مرتبط بنيوياً بـ Next.js. إذا كانت واجهتك الأمامية Astro أو Remix أو Nuxt أو SvelteKit، فأكبر ميزة في Payload (Local API في مكونات الخادم) لا تنطبق. ستحصل على REST وGraphQL، لكن عندها Strapi أو Directus قد تبدو أكثر طبيعية.

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

ما هو Payload CMS وكيف يعمل؟

Payload نظام إدارة محتوى مفتوح المصدر وإطار عمل تطبيقات مبني بـ TypeScript بشكل أصيل على Next.js. تُعرِّف نموذج محتواك في ملفات ضبط TypeScript، ويولّد Payload لوحة إدارة وREST API وGraphQL API وLocal API تلقائياً. يعمل داخل تطبيق Next.js كوحدة نشر واحدة.

هل Payload CMS مجاني للاستخدام؟

Payload مجاني تماماً بموجب رخصة MIT. البرنامج لا يكلف شيئاً للتنزيل أو الاستخدام أو التعديل. كانت Payload Cloud (الاستضافة المُدارة) بـ $35-199/شهر لكنها موقوفة حالياً لمستخدمين جدد إثر استحواذ Figma. الاستضافة الذاتية على VPS تكلف EUR 7-45/شهر حسب مزودك.

ماذا حدث بين Payload وFigma؟

استحوذت Figma على Payload في 17 يونيو 2025. انضم فريق Payload بأكمله إلى Figma. رخصة MIT مفتوحة المصدر ومستودع GitHub يبقيان دون تغيير. أوقفت Payload Cloud تسجيل مستخدمين جدد. الاستضافة الذاتية تستمر بشكل طبيعي. يبني الفريق على الأرجح منتج CMS متكامل مع Figma، لكن التفاصيل لم تُعلَن بعد.

ما قاعدة البيانات التي يستخدمها Payload CMS؟

يدعم Payload ثلاث قواعد بيانات من خلال نمط المحوّل: PostgreSQL (الموصى به للإنتاج، يعمل مع Neon وSupabase للـ serverless)، وMongoDB (جيد للنماذج ذات المستندات الكثيفة أو ترقيات Payload 2)، وSQLite (للتطوير المحلي وCI فقط). كود تطبيقك يبقى كما هو بغض النظر عن المحوّل الذي تختاره.

كيف أنشر Payload CMS في 2026؟

مع إيقاف Payload Cloud، انشر على Vercel مع Neon Postgres (الأسهل)، أو Docker على VPS مثل Hetzner (الأفضل للإنتاج مع محررين نشطين)، أو Railway أو Render (حاويات مُدارة)، أو Cloudflare Workers (الأرخص). لمعظم مواقع الإنتاج ذات النشاط التحريري المنتظم، يوفر VPS مبني على Docker أفضل تجربة.

هل Payload CMS أفضل من Strapi؟

Payload يتفوق في تجربة المطور TypeScript الأصيلة وتكامل Next.js وLocal API الفريدة للاستعلامات جانب الخادم بدون تكلفة. Strapi يتفوق في سوق الإضافات وتحرير المخطط بواجهة رسومية والتوافق مع أطر عمل أوسع. إذا كان فريقك يكتب TypeScript ويستخدم Next.js، Payload هو الخيار الأقوى. وإلا، قيّم Strapi.

ما هي Local API في Payload؟

Local API طبقة استعلام جانب الخادم تستدعي قاعدة بياناتك مباشرةً بدون أي تكلفة HTTP. بدلاً من إجراء استدعاءات REST أو GraphQL، تستورد Payload وتستعلم المجموعات مباشرةً في مكونات خادم Next.js. هذا يزيل رحلات الشبكة وتكاليف التسلسل، مما يؤدي إلى تحميل صفحات أسرع. لا يقدم أي نظام CMS headless آخر هذه الميزة.

هل يستطيع Payload CMS التعامل مع التطبيقات الكبيرة؟

يدعم Payload PostgreSQL مع تجميع الاتصالات (عبر Neon أو PgBouncer)، والتحكم في الوصول القائم على الأدوار بدقة على مستوى الحقل، وسير عمل المسودات والإصدارات، وبنيات multi-tenant. تستخدم المؤسسات والوكالات Payload في الإنتاج للتطبيقات الكثيفة بالمحتوى. استعلامات Local API بدون تكلفة تحسّن الأداء فعلاً على نطاق واسع.

كيف يقارن Payload بـ Sanity؟

Payload ذاتي الاستضافة وقائم على الكود ومرخص بـ MIT مع Local API للأداء جانب الخادم. Sanity مستضاف سحابياً مع تحرير بصري متفوق وتعاون فوري ولغة استعلام GROQ. Payload يمنحك مزيداً من التحكم في البنية التحتية وتكاليف أقل. Sanity يمنحك أدوات تحريرية أفضل وصفر إدارة استضافة.

ما هي عيوب Payload CMS؟

Payload يتطلب معرفة TypeScript للضبط، ولا يملك استضافة سحابية مُدارة لمستخدمين جدد منذ استحواذ Figma، ويوفر منظومة إضافات أصغر من Strapi، ومرتبط بنيوياً بـ Next.js في الإصدار 3. قد تجد الفرق غير التقنية صعوبة في نهج الكود أولاً، واستحواذ Figma يخلق بعض الغموض على المدى البعيد.