> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# Mixpost على سيرفرك: تقويم نشر لفريق التسويق
- URL: https://arabroot.io/articles/mixpost-على-سيرفرك-تقويم-نشر-لفريق-التسويق/
- Published: 2026-10-25T05:12:00.000Z
- Updated: 2026-10-25T13:19:44.000Z
- Description: نشغل Mixpost Lite في Docker ونجدول منشورات عربية، ونختبر أمان حساب المدير والأدوار وما يحدث عندما يفشل النشر فعلاً.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, التسويق والمبيعات, الاستضافة الذاتية, Mixpost

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

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

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

[![](https://arabroot.io/content/images/2026/10/social-scheduling-tools-cover-cover.webp)دليلجدولة منشورات التواصل: Buffer وبدائله مفتوحة المصدرمقارنة Buffer وHootsuite وLater وSprout Social مع Postiz وMixpost بالتسعير والموافقة والاستضافة والعربية، وما تكلفه الاستضافة الذاتية فعلاً.](https://arabroot.io/articles/%D8%AC%D8%AF%D9%88%D9%84%D8%A9-%D9%85%D9%86%D8%B4%D9%88%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D9%88%D8%A7%D8%B5%D9%84-buffer-%D9%88%D8%A8%D8%AF%D8%A7%D8%A6%D9%84%D9%87-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1/)[![](https://arabroot.io/content/images/2026/10/social-media-marketing-cover-cover.webp)دليلالتسويق عبر وسائل التواصل Social Media: خطة وقياسكيف تختار المنصة التي فيها جمهورك بأرقام هيئة الاتصالات، وتضع تقويم نشر يتحمله فريق صغير، وتقيس ما يجلب الزيارات والعملاء فعلاً.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D9%82-%D8%B9%D8%A8%D8%B1-%D9%88%D8%B3%D8%A7%D8%A6%D9%84-%D8%A7%D9%84%D8%AA%D9%88%D8%A7%D8%B5%D9%84-social-media/)

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

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

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

بحسب [صفحة الأسعار](https://mixpost.app/pricing?ref=arabroot.io) كما ظهرت في 25 أكتوبر 2026، فإن Lite مجانية، وتنشر في صفحات Facebook وحسابات Mastodon وحسابات X فقط، وفيها التقويم ومكتبة الوسائط والتحليلات الأساسية ونسخ المنشور Post versions والوسوم Labels. وأما Pro فسعرها 299 دولاراً بدفعة واحدة لنطاق واحد مع تحديثات سنة، وتضيف بقية المنصات وسير الموافقة Approval flow وسجل نشاط المنشور Post activity وتعدد اللغات Multilingual وصندوق الردود والـ API. وآخر إصدار من Lite في [المستودع](https://github.com/inovector/mixpost?ref=arabroot.io) هو 2.6.0 بتاريخ 16 مارس 2026، ونشرت Docker Image بالوسم `v2.6.0` في 22 أكتوبر 2026.

وهذا يعني أنك إذا كنت تنشر في LinkedIn أو Instagram أو TikTok فإن Lite لا تكفيك أصلاً، وأن الموافقة قبل النشر ليست فيها، وقد ناقشنا أهمية الموافقة والسجل للجهات في [مقال أدوات النشر المشترك](https://arabroot.io/articles/%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%AD%D8%B3%D8%A7%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D9%88%D8%A7%D8%B5%D9%84-%D9%84%D9%84%D8%AC%D9%87%D8%A7%D8%AA/).

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

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

![المتصفح يصل إلى Container باسم mixpost فيه nginx وphp-fpm للواجهة وHorizon لطوابير النشر وcron كل دقيقة للمنشورات المجدولة وVolumes للملفات والسجلات، ويتصل بقاعدة بيانات MySQL 8.4.11 وبـ Redis 7.2.16، ويخرج طلب النشر من Horizon إلى واجهات المنصات API](https://arabroot.io/content/images/2026/10/mixpost-lab-01-lab-map.webp)

ثلاث Containers، والمفتاح APP\_KEY يشفر مفاتيح الحسابات المخزنة

## المتطلبات

- سيرفر 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` يشفر مفاتيح الحسابات والخدمات المخزنة في قاعدة البيانات، كما سوف نرى في قسم النسخ الاحتياطي:

```bash
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` الذي شغلناه:

```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:
```

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

- الإصدارات مثبتة. فـ [صفحة التثبيت الرسمية](https://docs.mixpost.app/lite/installation/docker?ref=arabroot.io) تستخدم `inovector/mixpost:latest` و`redis:latest`، وتستخدم لقاعدة البيانات `mysql/mysql-server:8.0`، وهذه الـ Image بحسب [صفحتها في Docker Hub](https://hub.docker.com/r/mysql/mysql-server?ref=arabroot.io) لم تحدث منذ 18 يناير 2023، لذلك استخدمنا Image الرسمية `mysql:8.4.11` من سلسلة MySQL 8.4 طويلة الدعم LTS، وعمل التطبيق معها دون تعديل.
- المنفذ مربوط على `127.0.0.1` فقط، والوصول من الخارج يكون عبر الـ Reverse Proxy مع TLS.
- كلمة مرور root لقاعدة البيانات عشوائية ولا نحتاجها، فالتطبيق يستخدم مستخدماً خاصاً بقاعدته.

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

```bash
docker compose up -d
docker compose logs -f mixpost
```

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

```text
  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 admin@example.com created successfully!

                - Email: admin@example.com
                - Password: changeme

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

⚠️

قد يبقى السجل فارغاً دقائق طويلة في التشغيل الأول قبل أن تظهر هذه الأسطر، والسبب أن سكربت البداية في الـ Image ينفذ `chown -R www-data:www-data /var/www/html` على كل ملفات التطبيق في كل تشغيل، وعلى قرص بطيء يأخذ هذا وقتاً طويلاً عند إنشاء Container جديد، أي في أول تشغيل وبعد كل تحديث أو تغيير في `.env`. لا توقف الـ Container ظناً أنه معلق، وتأكد بالأمر `docker compose exec mixpost ps aux` أن عملية `chown` ما زالت تعمل. وأما إعادة التشغيل العادية `docker compose restart` فكانت أسرع بكثير، وعادت الواجهة بعدها في 41 ثانية.

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

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

```text
User admin@example.com created successfully!
                - Email: admin@example.com
                - Password: changeme
```

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

```text
id  name           email                   created_at
1   فريق التسويق   marketing@example.com   2026-10-25 09:37:47
2   Admin          admin@example.com       2026-10-25 09:48:54
```

والسبب في سكربت البداية نفسه، فهو يبحث عن مستخدم بالبريد `admin@example.com`، فإذا لم يجده أنشأه بكلمة المرور الافتراضية. أي أن كل من يغير بريد المدير ثم يعيد التشغيل أو يحدث الإصدار، يترك باباً مفتوحاً بكلمة مرور منشورة في التوثيق. والحل الأنسب أن تترك المستخدم `admin@example.com` موجوداً وتغير كلمة مروره من سطر الأوامر، ثم تنشئ لنفسك مستخدماً آخر ببريدك:

```bash
docker compose exec mixpost php artisan mixpost-auth:password admin@example.com
```

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

```text
Password for admin@example.com updated successfully!
```

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

🛑

لا تقم بتشغيل Mixpost على عنوان عام قبل أن تغير كلمة مرور `admin@example.com` بالأمر أعلاه، والسبب أن هذا البريد وكلمة المرور منشوران في التوثيق، ومن يدخل بهما يرى مفاتيح كل الحسابات المربوطة وينشر باسمها.

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

من صفحة Settings اختر المنطقة الزمنية Timezone، وفيها `(GMT+03:00) Riyadh`، ونظام 24 ساعة، وأول يوم في الأسبوع الأحد، ثم بريداً يصله تنبيه عندما ينقطع ربط حساب. وبعد الحفظ أصبح التقويم يبدأ بالأحد، والأوقات تعرض بتوقيت الرياض وتخزن في قاعدة البيانات بتوقيت UTC، فالمنشور المجدول الساعة 09:00 في الرياض خزن بقيمة `06:00:00`. ولاحظ أن التنبيه بالبريد يحتاج إعداد SMTP في `.env` بالمتغيرات `MAIL_HOST` و`MAIL_USERNAME` وما بعدها، وإن لم يكن عندك خادم إرسال فقد شرحنا [الإرسال عبر Amazon SES](https://arabroot.io/articles/%D8%A7%D8%B1%D8%B3%D8%A7%D9%84-%D8%A8%D8%B1%D9%8A%D8%AF%D9%83-%D8%B9%D8%A8%D8%B1-amazon-ses/).

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

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

- **Facebook**: معرف التطبيق App ID والسر App secret من تطبيق تنشئه في حساب مطور Meta، وإصدار Graph API، والنسخة Lite تنشر في صفحات Facebook فقط.
- **X**: مفاتيح تطبيق من بوابة مطوري X. ولاحظ أن الـ API في X صارت بالدفع حسب الاستخدام، فبحسب [صفحة الأسعار](https://docs.x.com/x-api/getting-started/pricing?ref=arabroot.io) في 25 أكتوبر 2026 كل طلب لإنشاء منشور بسعر 0.015 دولار، والمنشور الذي فيه رابط بسعر 0.200 دولار، وهذه التكلفة تدفعها أنت لـ X مباشرة لأن التطبيق تطبيقك.
- **Mastodon**: لا يحتاج إعداداً مسبقاً، فعند الإضافة يسألك عن اسم الخادم، ثم يسجل Mixpost تطبيقاً على ذلك الخادم آلياً، ثم يحولك إلى صفحة الدخول في Mastodon لتوافق.
- **Unsplash وTenor**: مفاتيح اختيارية لمكتبة الصور والصور المتحركة داخل المحرر.

![نافذة Connect a new Mastodon profile في Mixpost تطلب اسم خادم Mastodon مع زر NEXT، وخلفها رسالة بأن خدمة Twitter غير معدة، وبطاقة حساب ArabRoot Lab](https://arabroot.io/content/images/2026/10/mixpost-lab-02-connect-mastodon.webp)

ربط Mastodon يبدأ باسم الخادم، ثم الدخول إلى الحساب في الخادم نفسه

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

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

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

![محرر المنشور في Mixpost وفيه نص عربي يبدأ بكيف تختار بين PostgreSQL وMySQL لمشروعك القادم، والنص محاذى إلى اليسار وعلامة الاستفهام في غير مكانها، والوسم الإنجليزي PostgreSQL ملون بالأزرق والوسم العربي قواعد_البيانات غير ملون، والعداد 373، وفي المعاينة نفس المشكلة، وفي الأسفل زر SCHEDULE وموعد Oct 27th 09:00](https://arabroot.io/content/images/2026/10/social-scheduling-tools-03-mixpost-arabic.webp)

النص العربي يحفظ وينشر صحيحاً، ولكن المحرر والمعاينة من اليسار إلى اليمين

وما وجدناه:

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

## التقويم

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

![التقويم الشهري لشهر أكتوبر 2026 في Mixpost يبدأ بيوم الأحد، وفيه ثلاثة منشورات عربية مجدولة في 27 و28 و29 أكتوبر في الساعات 09:00 و13:00 و19:30 مع شعار Mastodon، والنص العربي في البطاقات محاذى إلى اليسار، ويوم 31 فارغ](https://arabroot.io/content/images/2026/10/mixpost-lab-04-calendar.webp)

المنشورات المجدولة تظهر في التقويم، والمسودة المؤرخة في 31 أكتوبر لا تظهر

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

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

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

```bash
docker compose exec mixpost php artisan mixpost-auth:create
```

```text
User editor@example.com created successfully!
```

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

![صفحة Third Party Services في Mixpost عند المستخدم Editor، وفيها App ID بقيمة lab-fb-app-id وApp secret ظاهر بقيمة lab-fb-dummy-secret بعد الضغط على أيقونة العين](https://arabroot.io/content/images/2026/10/mixpost-lab-07-editor-sees-secret.webp)

المستخدم الثاني يرى سر تطبيق Facebook، ويستطيع تعديله وحذف الحسابات وقراءة السجلات

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

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

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

```text
[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 وبعلامة خضراء:

![قائمة Posts في Mixpost وأول منشور بعنوان تجربة النشر الفوري من Mixpost إلى حساب Mastodon غير موجود بحالة Published بنقطة خضراء بتاريخ Sun Oct 25 13:07، وتحته مسودة وثلاثة منشورات Scheduled](https://arabroot.io/content/images/2026/10/mixpost-lab-05-published-not-sent.webp)

المنشور لم يصل إلى أي منصة، والحالة Published

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

```text
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`:

![صفحة Failed Jobs في Laravel Horizon داخل Mixpost وفيها AccountPublishPostJob في الطابور publish-post مع وسم Post:7 وفشلت في 2026-10-25 13:07:05، وImportMastodonPostsJob في الطابور default، مع زر Retry لكل منهما](https://arabroot.io/content/images/2026/10/mixpost-lab-06-horizon-failed.webp)

الفشل الحقيقي موجود في Horizon وليس في قائمة المنشورات

ولم نختبر حالة رد المنصة بخطأ، لأن ذلك يحتاج حساباً حقيقياً، فما سبق يخص فشل الاتصال فقط. ولكنه كاف لقاعدة عملية: لا تعتمد على كلمة 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](https://arabroot.io/articles/nginx-proxy-manager-%D9%86%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-%D9%88%D8%B4%D9%87%D8%A7%D8%AF%D8%A7%D8%AA-tls/). ولم نختبر إصدار الشهادة في هذه التجربة لأنها تحتاج نطاقاً عاماً.

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

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

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

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

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

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

```bash
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 إضافية. وللاستعادة نوقف التطبيق ونعيد إنشاء القاعدة ونحملها ثم نشغله:

```bash
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. اقرأ [صفحة الإصدارات](https://github.com/inovector/mixpost/releases?ref=arabroot.io) لترى هل في الإصدار الجديد ترحيل Migration لقاعدة البيانات.
2. خذ نسخة احتياطية بالأوامر السابقة.
3. غير الوسم في `compose.yaml`، ثم `docker compose pull mixpost` و`docker compose up -d mixpost`. وسكربت البداية ينفذ `php artisan migrate --force` في كل تشغيل.
4. تذكر أن إنشاء Container جديد يعيد تنفيذ `chown` على كل الملفات، فخطط لتوقف بضع دقائق، وفي تجربتنا استغرق إنشاء Container جديد بعد تغيير `.env` سبع دقائق حتى عادت الواجهة.
5. بعد التحديث تحقق أن المستخدم `admin@example.com` ما زال بكلمة مرورك وليس `changeme`.

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

- **السجل فارغ والواجهة لا ترد بعد التشغيل الأول**: عملية `chown` ما زالت تعمل كما ذكرنا، انتظرها.
- **ظهر مستخدم Admin جديد**: غيرت بريد `admin@example.com` ثم أعدت التشغيل، فغير كلمة مرور المستخدم الجديد بالأمر `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 قاعدة البيانات القديمة في التوثيق.
- لا تغير بريد `admin@example.com`، وغير كلمة مروره من سطر الأوامر، وإلا عاد بكلمة `changeme` بعد إعادة التشغيل.
- النص العربي يحفظ ويعد صحيحاً، ولكن المحرر والمعاينة والتقويم من اليسار إلى اليمين، والوسم العربي لا يلون في المعاينة.
- لا أدوار في Lite، وكل مستخدم يرى أسرار التطبيقات ويستطيع حذف الحسابات.
- عند فشل الاتصال بالمنصة ظهر المنشور Published، فراقب Horizon ولا تعتمد على الحالة وحدها.
- انسخ `.env` مع قاعدة البيانات، فبدون `APP_KEY` لا تقرأ مفاتيح الحسابات.

[![](https://arabroot.io/content/images/2026/10/social-scheduling-tools-cover-cover.webp)دليلجدولة منشورات التواصل: Buffer وبدائله مفتوحة المصدرمقارنة Buffer وHootsuite وLater وSprout Social مع Postiz وMixpost بالتسعير والموافقة والاستضافة والعربية، وما تكلفه الاستضافة الذاتية فعلاً.](https://arabroot.io/articles/%D8%AC%D8%AF%D9%88%D9%84%D8%A9-%D9%85%D9%86%D8%B4%D9%88%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D9%88%D8%A7%D8%B5%D9%84-buffer-%D9%88%D8%A8%D8%AF%D8%A7%D8%A6%D9%84%D9%87-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1/)[![](https://arabroot.io/content/images/2026/10/social-media-marketing-cover-cover.webp)دليلالتسويق عبر وسائل التواصل Social Media: خطة وقياسكيف تختار المنصة التي فيها جمهورك بأرقام هيئة الاتصالات، وتضع تقويم نشر يتحمله فريق صغير، وتقيس ما يجلب الزيارات والعملاء فعلاً.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D9%82-%D8%B9%D8%A8%D8%B1-%D9%88%D8%B3%D8%A7%D8%A6%D9%84-%D8%A7%D9%84%D8%AA%D9%88%D8%A7%D8%B5%D9%84-social-media/)[![](https://arabroot.io/content/images/2026/10/social-media-tools-cover-cover.webp)دليلأدوات النشر المشترك لحسابات الجهة دون مشاركة كلمة المرورما الذي تقدمه أدوات النشر المشترك للجهة في الأدوار والموافقة وسجل من نشر، وما الذي اكتشفناه عند تشغيل Postiz على سيرفرنا.](https://arabroot.io/articles/%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%AD%D8%B3%D8%A7%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D9%88%D8%A7%D8%B5%D9%84-%D9%84%D9%84%D8%AC%D9%87%D8%A7%D8%AA/)

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

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