Mixpost على سيرفرك: تقويم نشر لفريق التسويق

إذا كان فريق التسويق في شركتك يكتب المنشورات في ملف مشترك، ثم ينسخها شخص واحد إلى كل منصة في وقتها، فأنت تحتاج تقويم نشر Content Calendar يرى فيه الجميع ما سوف ينشر ومتى. وفي مقال المقارنة من هذه السلسلة رأينا أن Mixpost من البدائل مفتوحة المصدر لأدوات الجدولة التجارية، وأن نسخته المجانية Lite تعمل على سيرفرك بترخيص MIT. وفي هذا الدليل سوف نشغل Mixpost Lite في Docker خطوة بخطوة، ونكتب فيه منشورات عربية ونجدولها، ثم نختبر ما يهم الفريق فعلاً: من يستطيع أن يفعل ماذا، وماذا يحدث عندما يفشل النشر. وسوف ترى أن بعض النتائج ليست مما تذكره صفحة المنتج.

المواضيع في سلسلة التسويق عبر وسائل التواصل:

• التسويق عبر وسائل التواصل Social Media: خطة وقياس
• جدولة منشورات التواصل: Buffer وبدائله مفتوحة المصدر
• Mixpost على سيرفرك: تقويم نشر لفريق التسويق (الموضوع الحالي)

دليلجدولة منشورات التواصل: Buffer وبدائله مفتوحة المصدرمقارنة Buffer وHootsuite وLater وSprout Social مع Postiz وMixpost بالتسعير والموافقة والاستضافة والعربية، وما تكلفه الاستضافة الذاتية فعلاً.دليلالتسويق عبر وسائل التواصل Social Media: خطة وقياسكيف تختار المنصة التي فيها جمهورك بأرقام هيئة الاتصالات، وتضع تقويم نشر يتحمله فريق صغير، وتقيس ما يجلب الزيارات والعملاء فعلاً.

وفي هذا الدليل سوف نتناول:

• ما تقدمه نسخة Lite وما تحجزه نسخة Pro.
• التثبيت في Docker بإصدارات مثبتة، ولماذا لم نستخدم قاعدة البيانات التي في التوثيق.
• تأمين حساب المدير الافتراضي، ومشكلة تظهر بعد إعادة التشغيل.
• ربط الحسابات وما يحتاجه كل منها، والطريقة التي اختبرنا بها دون حساب حقيقي.
• كتابة منشورات عربية والتقويم.
• المستخدمون والأدوار في Lite.
• ماذا يحدث عندما تفشل المنصة في الرد.
• النسخ الاحتياطي والاستعادة والتحديث.

ماذا في Lite وماذا في Pro؟

بحسب صفحة الأسعار كما ظهرت في 25 أكتوبر 2026، فإن Lite مجانية، وتنشر في صفحات Facebook وحسابات Mastodon وحسابات X فقط، وفيها التقويم ومكتبة الوسائط والتحليلات الأساسية ونسخ المنشور Post versions والوسوم Labels. وأما Pro فسعرها 299 دولاراً بدفعة واحدة لنطاق واحد مع تحديثات سنة، وتضيف بقية المنصات وسير الموافقة Approval flow وسجل نشاط المنشور Post activity وتعدد اللغات Multilingual وصندوق الردود والـ API. وآخر إصدار من Lite في المستودع هو 2.6.0 بتاريخ 16 مارس 2026، ونشرت Docker Image بالوسم v2.6.0 في 22 أكتوبر 2026.

وهذا يعني أنك إذا كنت تنشر في LinkedIn أو Instagram أو TikTok فإن Lite لا تكفيك أصلاً، وأن الموافقة قبل النشر ليست فيها، وقد ناقشنا أهمية الموافقة والسجل للجهات في مقال أدوات النشر المشترك.

مكونات التجربة

Mixpost تطبيق Laravel، وتجمع الـ Image الرسمية داخل Container واحد كل ما يحتاجه التطبيق: nginx وphp-fpm للواجهة، وLaravel Horizon لطوابير النشر Queue، ومهمة مجدولة Cron Job كل دقيقة تفحص المنشورات التي حان وقتها. ويحتاج بجانبه قاعدة بيانات MySQL وRedis، والشكل التالي يبين ذلك:

المتطلبات

• سيرفر Linux عليه Docker Engine وإضافة Compose، وذاكرة 2 GB على الأقل، فالخدمات الثلاث استهلكت معاً قرابة 870 MiB بعد التجربة: 318 للتطبيق و532 لـ MySQL و24 لـ Redis.
• مساحة قرص قرابة 3 GB للـ Images وحدها، فـ Image التطبيق وحدها 1.82 GB.
• نطاق فرعي مثل social.example.com وشهادة TLS، لأن المنصات لا تقبل عنوان رجوع Callback غير آمن عند ربط الحسابات.
• لكل منصة تريد النشر فيها: تطبيق مطور مسجل في Facebook أو X، أو حساب في خادم Mastodon.

التثبيت

ننشئ مجلداً للتطبيق، ثم ملف .env بقيم مولدة، فالمفتاح APP_KEY يشفر مفاتيح الحسابات والخدمات المخزنة في قاعدة البيانات، كما سوف نرى في قسم النسخ الاحتياطي:

mkdir -p /opt/mixpost && cd /opt/mixpost
cat > .env <<EOF
APP_NAME=Mixpost
APP_KEY=base64:$(openssl rand -base64 32)
APP_DEBUG=false
APP_DOMAIN=social.example.com
APP_URL=https://social.example.com
DB_HOST=mysql
DB_DATABASE=mixpost_db
DB_USERNAME=mixpost_user
DB_PASSWORD=$(openssl rand -hex 16)
REDIS_HOST=redis
EOF
chmod 600 .env

وهذا ملف compose.yaml الذي شغلناه:

name: mixpost

services:
  mixpost:
    image: inovector/mixpost:v2.6.0
    env_file: .env
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - storage:/var/www/html/storage/app
      - logs:/var/www/html/storage/logs
    depends_on:
      mysql:
        condition: service_healthy
      redis:
        condition: service_healthy
    restart: unless-stopped

  mysql:
    image: mysql:8.4.11
    environment:
      MYSQL_DATABASE: ${DB_DATABASE}
      MYSQL_USER: ${DB_USERNAME}
      MYSQL_PASSWORD: ${DB_PASSWORD}
      MYSQL_RANDOM_ROOT_PASSWORD: "yes"
    volumes:
      - mysql:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      retries: 10
      timeout: 5s
    restart: unless-stopped

  redis:
    image: redis:7.2.16
    command: redis-server --appendonly yes --replica-read-only no
    volumes:
      - redis:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      retries: 5
      timeout: 5s
    restart: unless-stopped

volumes:
  storage:
  logs:
  mysql:
  redis:

في الإعداد أعلاه لاحظ التالي:

• الإصدارات مثبتة. فـ صفحة التثبيت الرسمية تستخدم inovector/mixpost:latest وredis:latest، وتستخدم لقاعدة البيانات mysql/mysql-server:8.0، وهذه الـ Image بحسب صفحتها في Docker Hub لم تحدث منذ 18 يناير 2023، لذلك استخدمنا Image الرسمية mysql:8.4.11 من سلسلة MySQL 8.4 طويلة الدعم LTS، وعمل التطبيق معها دون تعديل.
• المنفذ مربوط على 127.0.0.1 فقط، والوصول من الخارج يكون عبر الـ Reverse Proxy مع TLS.
• كلمة مرور root لقاعدة البيانات عشوائية ولا نحتاجها، فالتطبيق يستخدم مستخدماً خاصاً بقاعدته.

الآن نشغل الخدمات ونتابع السجل:

docker compose up -d
docker compose logs -f mixpost

والمخرج سوف يكون كما يلي عندما يكتمل التشغيل الأول:

  2025_01_19_172922_create_mixpost_lite_v2_tables ............... 21.24ms DONE
  2026_10_22_081857_create_job_batches_table ................... 171.41ms DONE
  2026_10_22_081859_create_mixpost_tables ........................... 12s DONE

Cache settings has been cleared!
Cache services has been cleared!
User [email protected] created successfully!

                - Email: [email protected]
                - Password: changeme

------- Mixpost has started! -------

تأمين حساب المدير الافتراضي

كما رأيت في المخرج، ينشئ السكربت مستخدماً بالبريد [email protected] وكلمة المرور changeme. والتصرف الطبيعي أن تدخل من الواجهة وتفتح صفحة الملف الشخصي Profile فتغير البريد إلى بريدك وكلمة المرور إلى كلمة قوية، وهذا ما فعلناه، ثم أعدنا تشغيل الـ Container، فظهر في السجل مرة أخرى:

User [email protected] created successfully!
                - Email: [email protected]
                - Password: changeme

وجدول المستخدمين بعد إعادة التشغيل أصبح فيه مستخدمان، كلاهما بصلاحيات كاملة:

id  name           email                   created_at
1   فريق التسويق   [email protected]   2026-10-25 09:37:47
2   Admin          [email protected]       2026-10-25 09:48:54

والسبب في سكربت البداية نفسه، فهو يبحث عن مستخدم بالبريد [email protected]، فإذا لم يجده أنشأه بكلمة المرور الافتراضية. أي أن كل من يغير بريد المدير ثم يعيد التشغيل أو يحدث الإصدار، يترك باباً مفتوحاً بكلمة مرور منشورة في التوثيق. والحل الأنسب أن تترك المستخدم [email protected] موجوداً وتغير كلمة مروره من سطر الأوامر، ثم تنشئ لنفسك مستخدماً آخر ببريدك:

docker compose exec mixpost php artisan mixpost-auth:password [email protected]

والأمر يسألك عن كلمة المرور الجديدة دون أن يعرضها، والمخرج سوف يكون كما يلي:

Password for [email protected] updated successfully!

وبعد ذلك أعدنا التشغيل مرتين ولم ينشأ مستخدم جديد، وفشل الدخول بكلمة المرور changeme.

إعدادات الوقت والتنبيهات

من صفحة Settings اختر المنطقة الزمنية Timezone، وفيها (GMT+03:00) Riyadh، ونظام 24 ساعة، وأول يوم في الأسبوع الأحد، ثم بريداً يصله تنبيه عندما ينقطع ربط حساب. وبعد الحفظ أصبح التقويم يبدأ بالأحد، والأوقات تعرض بتوقيت الرياض وتخزن في قاعدة البيانات بتوقيت UTC، فالمنشور المجدول الساعة 09:00 في الرياض خزن بقيمة 06:00:00. ولاحظ أن التنبيه بالبريد يحتاج إعداد SMTP في .env بالمتغيرات MAIL_HOST وMAIL_USERNAME وما بعدها، وإن لم يكن عندك خادم إرسال فقد شرحنا الإرسال عبر Amazon SES.

ربط الحسابات: ماذا يحتاج كل منها؟

في صفحة Social Accounts لن تجد Facebook ولا X حتى تضيف بيانات تطبيقك في صفحة Services، وهي:

• Facebook: معرف التطبيق App ID والسر App secret من تطبيق تنشئه في حساب مطور Meta، وإصدار Graph API، والنسخة Lite تنشر في صفحات Facebook فقط.
• X: مفاتيح تطبيق من بوابة مطوري X. ولاحظ أن الـ API في X صارت بالدفع حسب الاستخدام، فبحسب صفحة الأسعار في 25 أكتوبر 2026 كل طلب لإنشاء منشور بسعر 0.015 دولار، والمنشور الذي فيه رابط بسعر 0.200 دولار، وهذه التكلفة تدفعها أنت لـ X مباشرة لأن التطبيق تطبيقك.
• Mastodon: لا يحتاج إعداداً مسبقاً، فعند الإضافة يسألك عن اسم الخادم، ثم يسجل Mixpost تطبيقاً على ذلك الخادم آلياً، ثم يحولك إلى صفحة الدخول في Mastodon لتوافق.
• Unsplash وTenor: مفاتيح اختيارية لمكتبة الصور والصور المتحركة داخل المحرر.

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

كتابة منشور عربي

من زر Create Post نختار الحساب، ونكتب في المحرر، ويظهر بجانبه معاينة Preview بشكل المنصة، وعداد للأحرف المتبقية بحسب حد المنصة. وكتبنا منشوراً فيه كلمات إنجليزية ورمز تعبيري ووسمان، أحدهما عربي:

وما وجدناه:

• الاتجاه: المحرر والمعاينة وقائمة المنشورات والتقويم كلها من اليسار إلى اليمين، فيظهر السطر العربي محاذى إلى اليسار وتنتقل علامات الترقيم في أول السطر وآخره إلى غير مكانها، مثل النقطتين في «سؤال للمطورين:». والنص المخزن صحيح، والمشكلة في العرض فقط، ولكنها تجعل مراجعة المنشور قبل النشر أصعب على الفريق.
• الوسم العربي: المعاينة لونت #PostgreSQL ولم تلون #قواعد_البيانات، فلا تعتمد على المعاينة لتعرف هل سوف يعمل الوسم العربي في المنصة.
• العداد: النص 127 حرفاً والعداد عرض 373 من حد Mastodon البالغ 500، أي أنه يعد الحرف العربي والرمز التعبيري حرفاً واحداً بشكل صحيح.
• الواجهة نفسها: بالإنجليزية فقط، فتعدد اللغات في Pro.

التقويم

جدولنا ثلاثة منشورات في أيام مختلفة من زر SCHEDULE، وتركنا منشوراً رابعاً مسودة Draft بتاريخ 31 أكتوبر، فظهر التقويم الشهري كما يلي:

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

المستخدمون والأدوار

لا توجد في Lite صفحة لإدارة المستخدمين، فالمستخدم الجديد ينشأ من سطر الأوامر، والأمر يسأل عن الاسم والبريد وكلمة المرور:

docker compose exec mixpost php artisan mixpost-auth:create

User [email protected] created successfully!

وجدول المستخدمين نفسه لا يحتوي عموداً للدور أو الصلاحية، فكل مستخدم يرى كل شيء ويستطيع كل شيء. ولنتأكد، أدخلنا من حساب الإدارة بيانات تطبيق Facebook تجريبية في صفحة Services، ثم دخلنا بالمستخدم [email protected] وفتحنا نفس الصفحة وضغطنا على أيقونة العين:

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

ماذا يحدث إذا فشل النشر؟

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

[2026-10-25 10:07:05] production.ERROR: cURL error 6: Could not resolve host: mastodon.example (see https://curl.se/libcurl/c/libcurl-errors.html) for https://mastodon.example/api/v1/statuses
[2026-10-25 10:14:09] production.ERROR: cURL error 6: Could not resolve host: mastodon.example (see https://curl.se/libcurl/c/libcurl-errors.html) for https://mastodon.example/api/v1/statuses

ولكن قائمة المنشورات عرضت المنشور الأول بحالة Published وبعلامة خضراء:

وفي قاعدة البيانات أخذ المنشوران الحالة 2، وهي PUBLISHED في الكود، مع وقت نشر، والمنشور المجدول تحول إلى Published بعد ثماني ثوان من موعده، وخانة الأخطاء ومعرف المنشور في المنصة فارغتان:

id  status  scheduled_at          published_at
7   2       2026-10-25 10:06:43   2026-10-25 10:07:05
9   2       2026-10-25 10:14:00   2026-10-25 10:14:08

post_id  account_id  provider_post_id  errors
7        1           NULL              NULL
9        1           NULL              NULL

والسبب في طريقة كتابة مهمة النشر: عندما ترد المنصة برسالة خطأ يسجل Mixpost الخطأ على المنشور ويجعل حالته Failed، أما عندما لا يصل الطلب إلى المنصة أصلاً، كخطأ في DNS أو انقطاع الشبكة، فتفشل المهمة نفسها في الطابور، ولا يسجل خطأ على المنشور، فتنتهي المجموعة بحالة Published. والمهمة الفاشلة تظهر فقط في لوحة Horizon على المسار /horizon/failed:

ولم نختبر حالة رد المنصة بخطأ، لأن ذلك يحتاج حساباً حقيقياً، فما سبق يخص فشل الاتصال فقط. ولكنه كاف لقاعدة عملية: لا تعتمد على كلمة Published في Mixpost، وراجع صفحة Failed Jobs في Horizon يومياً أو راقب ملف storage/logs/laravel.log، وتأكد من المنشورات المهمة في المنصة نفسها.

الوصول عبر نطاق مع TLS

التطبيق يستمع على 127.0.0.1:8080، فضع أمامه Reverse Proxy يصدر الشهادة، وتأكد أن APP_URL في .env يبدأ بـ https:// لأن روابط الرجوع التي يسجلها Mixpost عند المنصات تبنى منه. وإذا كنت تستخدم Nginx Proxy Manager فقد شرحنا إضافة النطاق والشهادة في دليل Nginx Proxy Manager. ولم نختبر إصدار الشهادة في هذه التجربة لأنها تحتاج نطاقاً عاماً.

التحقق من النجاح

• صفحة System ثم Status تعرض Horizon بحالة Active، وSchedule بعبارة «Ran 0 minute(s) ago»، وفي تجربتنا عرضت أيضاً PHP 8.3.36 وLaravel 12.70.1 وMySQL 8.4.11.
• الدخول بالبريد [email protected] وكلمة المرور changeme يفشل.
• بعد docker compose restart mixpost يبقى عدد المستخدمين كما هو.
• منشور تجريبي في حساب حقيقي يظهر في المنصة، وصفحة /horizon/failed فارغة.

النسخ الاحتياطي والاستعادة

تحتاج ثلاثة أشياء: قاعدة البيانات، وVolume الملفات المرفوعة، وملف .env. والأخير لا يقل أهمية عن القاعدة، فمفاتيح الحسابات وأسرار التطبيقات مشفرة بالمفتاح APP_KEY. ولنتأكد، شغلنا التطبيق بمفتاح آخر وحاولنا قراءة مفتاح الحساب وإعدادات الخدمة، فكان المخرج:

Illuminate\Contracts\Encryption\DecryptException: The MAC is invalid.
Illuminate\Contracts\Encryption\DecryptException: The MAC is invalid.

أي أن نسخة قاعدة البيانات دون APP_KEY الصحيح تعني إعادة ربط كل الحسابات وإدخال أسرار كل التطبيقات من جديد. والأوامر التالية تأخذ النسخة، واسم الـ Volume يبدأ باسم المشروع في compose.yaml:

mkdir -p backup
docker compose exec -T mysql sh -c 'exec mysqldump --single-transaction --no-tablespaces -u"$MYSQL_USER" -p"$MYSQL_PASSWORD" "$MYSQL_DATABASE"' > backup/mixpost-db.sql
docker run --rm --entrypoint tar -v mixpost_storage:/data:ro -v "$PWD/backup":/backup inovector/mixpost:v2.6.0 czf /backup/mixpost-storage.tar.gz -C /data .
cp .env backup/env.backup

ولاحظ أننا استخدمنا Image التطبيق نفسها لتشغيل tar حتى لا ننزل Image إضافية. وللاستعادة نوقف التطبيق ونعيد إنشاء القاعدة ونحملها ثم نشغله:

docker compose stop mixpost
docker compose exec -T mysql sh -c 'mysql -u"$MYSQL_USER" -p"$MYSQL_PASSWORD" -e "DROP DATABASE mixpost_db; CREATE DATABASE mixpost_db;"'
docker compose exec -T mysql sh -c 'exec mysql -u"$MYSQL_USER" -p"$MYSQL_PASSWORD" "$MYSQL_DATABASE"' < backup/mixpost-db.sql
docker compose start mixpost

وبعد الاستعادة عاد المستخدمون الثلاثة والمنشورات السبعة، وعاد التطبيق للعمل بعد 44 ثانية من التشغيل.

التحديث إلى إصدار أحدث

1. اقرأ صفحة الإصدارات لترى هل في الإصدار الجديد ترحيل Migration لقاعدة البيانات.
2. خذ نسخة احتياطية بالأوامر السابقة.
3. غير الوسم في compose.yaml، ثم docker compose pull mixpost وdocker compose up -d mixpost. وسكربت البداية ينفذ php artisan migrate --force في كل تشغيل.
4. تذكر أن إنشاء Container جديد يعيد تنفيذ chown على كل الملفات، فخطط لتوقف بضع دقائق، وفي تجربتنا استغرق إنشاء Container جديد بعد تغيير .env سبع دقائق حتى عادت الواجهة.
5. بعد التحديث تحقق أن المستخدم [email protected] ما زال بكلمة مرورك وليس changeme.

مشكلات شائعة وحلولها

• السجل فارغ والواجهة لا ترد بعد التشغيل الأول: عملية chown ما زالت تعمل كما ذكرنا، انتظرها.
• ظهر مستخدم Admin جديد: غيرت بريد [email protected] ثم أعدت التشغيل، فغير كلمة مرور المستخدم الجديد بالأمر mixpost-auth:password واتركه.
• المنشور Published ولم يظهر في المنصة: افتح /horizon/failed، فالغالب أن الطلب لم يصل إلى المنصة.
• Facebook أو X لا يظهران في Add account: أضف بيانات التطبيق في Services وفعل خانة Active.
• خطأ The MAC is invalid: المفتاح APP_KEY تغير، فأعد المفتاح الأصلي من النسخة الاحتياطية.
• المسودات لا تظهر في التقويم: هذا سلوك Lite، فراجعها من Posts ثم Drafts.

الخلاصة

• Mixpost Lite تقويم نشر مجاني على سيرفرك لصفحات Facebook وMastodon وX، ويحتاج قرابة 870 MiB من الذاكرة مع MySQL وRedis.
• استخدم إصدارات مثبتة، وmysql:8.4.11 بدل Image قاعدة البيانات القديمة في التوثيق.
• لا تغير بريد [email protected]، وغير كلمة مروره من سطر الأوامر، وإلا عاد بكلمة changeme بعد إعادة التشغيل.
• النص العربي يحفظ ويعد صحيحاً، ولكن المحرر والمعاينة والتقويم من اليسار إلى اليمين، والوسم العربي لا يلون في المعاينة.
• لا أدوار في Lite، وكل مستخدم يرى أسرار التطبيقات ويستطيع حذف الحسابات.
• عند فشل الاتصال بالمنصة ظهر المنشور Published، فراقب Horizon ولا تعتمد على الحالة وحدها.
• انسخ .env مع قاعدة البيانات، فبدون APP_KEY لا تقرأ مفاتيح الحسابات.

دليلجدولة منشورات التواصل: Buffer وبدائله مفتوحة المصدرمقارنة Buffer وHootsuite وLater وSprout Social مع Postiz وMixpost بالتسعير والموافقة والاستضافة والعربية، وما تكلفه الاستضافة الذاتية فعلاً.دليلالتسويق عبر وسائل التواصل Social Media: خطة وقياسكيف تختار المنصة التي فيها جمهورك بأرقام هيئة الاتصالات، وتضع تقويم نشر يتحمله فريق صغير، وتقيس ما يجلب الزيارات والعملاء فعلاً.دليلأدوات النشر المشترك لحسابات الجهة دون مشاركة كلمة المرورما الذي تقدمه أدوات النشر المشترك للجهة في الأدوار والموافقة وسجل من نشر، وما الذي اكتشفناه عند تشغيل Postiz على سيرفرنا.

سجل التحديثات

• أكتوبر 2026: كتابة الدليل واختباره على Mixpost Lite 2.6.0 (inovector/mixpost:v2.6.0) مع MySQL 8.4.11 وRedis 7.2.16 في Docker Engine 29.8.0، دون ربط حساب حقيقي في أي منصة.