> ## 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. # تثبيت WordPress مع MariaDB وDocker Compose - URL: https://arabroot.io/articles/تثبيت-wordpress-مع-docker-compose/ - Published: 2026-09-26T19:30:00.000Z - Updated: 2026-10-04T20:05:55.000Z - Description: شغل موقع WordPress على خادمك بإعداد يصلح للاستخدام الفعلي، لا للتجربة فقط. نثبته مع MariaDB عبر Docker Compose، ونفعل HTTPS، ونجهز نسخاً احتياطياً يمكنك استعادته عند الحاجة. - Author: فريق عرب رووت - Tags: الأدلة التقنية, تطبيقات لفريقك, الاستضافة الذاتية, WordPress إذا أردت أن تطلق مدونة أو موقعاً لشركتك على [WordPress](https://wordpress.org/?ref=arabroot.io)، فالحل الأول الذي يخطر على البال هو أن تشترك في استضافة مشتركة Shared Hosting وتضغط زر التثبيت بنقرة واحدة One-Click Install من لوحة التحكم، وهذا الحل يعمل في اليوم الأول، ولكنك سوف تجد مع الوقت أنه يعيش على سيرفر Server يتقاسمه معك عشرات العملاء، فلا تختار فيه إصدار PHP ولا حدود الرفع ولا موعد التحديث، وإذا أبطأ موقع جارك أبطأ موقعك معه، والنسخ الاحتياطي Backup فيه عادة نسخة تحتفظ بها الشركة لأيام قليلة ولم تجرب أنت استعادتها في أي يوم. والحل الثاني هو الاستضافة المدارة Managed Hosting المخصصة لـ WordPress، وهي حل جيد ومريح، ولكنك تدفع فيها عن كل موقع، وتقيدك أحياناً في الإضافات Plugins التي تسمح بها، وتبقى بياناتك على سيرفرات شركة أخرى. لذلك فالحل الأنسب إذا كان عندك سيرفر تشغل عليه خدماتك الأخرى هو أن تستضيف WordPress بنفسك عبر Docker Compose، فتتحكم في الإضافات والبيانات والتكلفة، وتشغل الموقع بجانب بقية خدماتك على السيرفر نفسه، ولكن تذكر أن ثمن ذلك هو أن التحديثات Updates والأمان Security والنسخ الاحتياطي تصبح مسؤوليتك أنت، فإذا كان الموقع مصدر دخل أساسياً ولم يكن في فريقك من يتابعه، فقد تكون الاستضافة المدارة أجدى لك من الناحية الاقتصادية. والتثبيت بـ Docker نفسه يستغرق دقائق، ولكن كثيراً من الأمثلة المنشورة لا يصلح لبيئة الإنتاج Production، فسوف تجد فيها كلمة مرور Password مثل «TheDbPassword»، وImage بالوسم Tag `latest` يتغير محتواها دون علمك، وحد رفع Upload Limit لا يتجاوز 2 ميجابايت، ثم يدخل HTTPS خلف الـ Reverse Proxy في حلقة تحويل Redirect Loop لا تنتهي، والسبب أن هذه الأمثلة كتبت لتعمل على جهاز المطور وليس لتبقى سنوات على سيرفر حقيقي. وقد يتساءل البعض: لماذا لا أكتفي بالمثال المنشور في Docker Hub وأصلح ما يظهر لي من مشكلات لاحقاً؟ والإجابة أن أغلب هذه المشكلات لا تظهر في اليوم الأول، وإنما تظهر حين يرفع أحد المحررين أول فيديو، أو حين تحتاج إلى نسخة احتياطية فتكتشف أنك لم تأخذ إلا نصف الموقع، وإصلاحها بعد أن يمتلئ الموقع بالمحتوى أصعب بكثير من بنائها صحيحة من البداية. وسوف نناقش في هذا المقال ما يلي: - تثبيت WordPress مع MariaDB عبر Docker Compose بكلمات مرور مولدة وإصدارات محددة بأرقامها وفحوصات صحة Health Checks، وشرح كل سطر مهم في الملف. - رفع حدود الرفع في PHP، وتشغيل HTTPS خلف الـ Reverse Proxy دون حلقة تحويل. - معالج التثبيت والروابط الدائمة وصحة الموقع، ثم الإدارة من الطرفية بـ wp-cli. - النسخ الاحتياطي لقاعدة البيانات وwp-content والاستعادة على سيرفر جديد، ثم التحديث وأشهر المشكلات وحلولها. ## ما تحتاجه قبل أن تبدأ Requirements - سيرفر مثبت عليه Docker وCompose، وإذا لم تثبته بعد فابدأ بدليل [تثبيت Docker على Ubuntu](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-docker-%D8%B9%D9%84%D9%89-ubuntu/). - الموارد Resources: دون أي زيارات يستهلك الـ Container الخاص بـ WordPress قرابة 160 ميجابايت من الذاكرة RAM، وتستهلك MariaDB قرابة 145 ميجابايت، أما الموقع الفعلي فخطط له بذاكرة من 1 إلى 2 GB، وبمساحة تتسع للوسائط Media والنسخ الاحتياطية، والسبب أن الوسائط هي التي تكبر مع الوقت وليس قاعدة البيانات. - نطاق Domain مثل `blog.example.com`، وReverse Proxy يعمل بـ HTTPS مثل [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/) ومتصل بشبكة Docker باسم `proxy`. - لا تحتاج إلى فتح أي منفذ Port على السيرفر سوى 80 و443 للـ Reverse Proxy. ## تثبيت WordPress بـ Docker Compose ### مجلد التثبيت والأسرار Secrets نبدأ بإنشاء مجلد للخدمة يحفظ فيه ملف Compose وملف الأسرار وملف إعدادات PHP: ```bash sudo mkdir -p /opt/wordpress sudo chown $USER: /opt/wordpress cd /opt/wordpress ``` بعد ذلك نولد كلمتي مرور قاعدة البيانات Database عشوائياً في ملف `.env` لا يقرؤه أحد غيرك، والسبب أننا لا نريد أن نكتب كلمة المرور داخل ملف Compose نفسه فتظهر في كل نسخة منه: ```bash cat > .env < /var/www/html/wp-cli.yml && wp rewrite flush --hard' ``` وبعدها تفتح المقالات بالرمز `200` من جديد. ## كيف تتأكد أن كل شيء يعمل - الأمر `docker compose ps` يعرض كلا الـ Containers بحالة `healthy`. - الأمر `curl -sI https://blog.example.com` يعيد الرمز `200`، والأمر `curl -sI http://blog.example.com` يعيد الرمز `301` مع تحويل إلى `https://`. - مصدر الصفحة خال من روابط `http://blog.example.com`، أي لا يوجد محتوى مختلط Mixed Content يجعل المتصفح يحذر الزائر. - رابط مقالة بصيغة `/اسم-المقالة/` يفتح، وصفحة الرفع تعرض الحد الذي ضبطته. - الأمر `docker compose run --rm wpcli wp core check-update` يعيد الرسالة `Success: WordPress is at the latest version.` - تثبيت إضافة من لوحة التحكم يكتمل دون أن يطلب منك بيانات FTP. ## النسخ الاحتياطي Backup والاستعادة Restore موقع WordPress يتكون من جزأين: **قاعدة البيانات** وفيها المقالات والإعدادات والمستخدمون، و**wp-content** وفيه الوسائط والإضافات والقوالب. أما ملفات النواة Core فلا تحتاج إلى نسخها، والسبب أن الـ Image تعيدها وتولد الملف `wp-config.php` من متغيرات البيئة Environment Variables، ولكن لا تنس أن تنسخ أيضاً `compose.yaml` و`.env` و`uploads.ini`، فبدون `.env` لن تعرف كلمة مرور القاعدة التي استعدتها. ولتفريغ Dump القاعدة دون إيقاف الموقع نستخدم الأمر التالي، والخيار [\--single-transaction](https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump?ref=arabroot.io) يعطيك Snapshot متسقة لجداول InnoDB حتى لو كتب أحد المحررين مقالة أثناء التفريغ: ```bash cd /opt/wordpress mkdir -p backups docker compose exec -T db sh -c 'mariadb-dump --single-transaction -uwordpress -p"$MARIADB_PASSWORD" wordpress' | gzip > backups/db-$(date +%F).sql.gz ``` ولأرشفة `wp-content` نستخدم Container مؤقتاً يقرأ الـ Volume للقراءة فقط: ```bash docker run --rm -v wordpress_html:/data:ro -v "$PWD/backups":/backup alpine:3.24 tar czf /backup/wp-content-$(date +%F).tar.gz -C /data wp-content ``` جدول الأمرين ليعملا يومياً عبر cron، وانقل مجلد `backups` إلى خارج السيرفر، واحذف منه النسخ القديمة. وللاستعادة على سيرفر جديد انسخ ملفات الإعداد، وشغل `docker compose up -d` لتحصل على قاعدة فارغة، ثم نفذ الأوامر التالية: ```bash gunzip -c backups/db-2026-09-26.sql.gz | docker compose exec -T db sh -c 'mariadb -uwordpress -p"$MARIADB_PASSWORD" wordpress' docker run --rm -v wordpress_html:/data -v "$PWD/backups":/backup alpine:3.24 sh -c 'rm -rf /data/wp-content && tar xzf /backup/wp-content-2026-09-26.tar.gz -C /data && chown -R 33:33 /data/wp-content' docker compose restart wordpress ``` بعد الاستعادة تأكد أن عدد السجلات Rows في `wp_posts` يطابق عددها في القاعدة الأصلية، وأن صور المقالات تظهر، وجرب الاستعادة على سيرفر اختبار كل بضعة أشهر، والسبب أن النسخة الاحتياطية التي لم تجرب استعادتها لا يمكنك الاعتماد عليها يوم تحتاجها. وإذا تغير النطاق فاستبدله في القاعدة بالأمر [docker compose run --rm wpcli wp search-replace 'https://old.example.com' 'https://blog.example.com' --skip-columns=guid](https://developer.wordpress.org/cli/commands/search-replace/?ref=arabroot.io)، بعد أن تجربه مع `--dry-run`. ## تحديث WordPress إلى إصدار أحدث Upgrade هناك مشكلة رئيسية يقع فيها كثير ممن يشغلون WordPress في Docker، وهي أن نواة WordPress داخل Docker Image لا تتحدث بالطريقة التي يتوقعها، والسبب أن [الـ Image تنسخ ملفات النواة](https://github.com/docker-library/wordpress/blob/master/docker-entrypoint.sh?ref=arabroot.io) إلى الـ Volume `wordpress_html` **عند التشغيل الأول فقط** إذا لم تجدها فيه، وبعد ذلك فتغيير وسم الـ Image يحدث إصدار PHP وApache، ولكنه **لا يغير** ملفات WordPress الموجودة في الـ Volume. لذلك [تحدث النواة](https://developer.wordpress.org/advanced-administration/upgrade/upgrading/?ref=arabroot.io) من داخل WordPress نفسه، من لوحة التحكم أو بـ wp-cli أو بالتحديث التلقائي، ويجدر الانتباه هنا إلى أن [التحديث التلقائي للنواة](https://wordpress.org/documentation/article/configuring-automatic-background-updates/?ref=arabroot.io) يكون مفعلاً في التثبيت الجديد للإصدارات الأمنية والرئيسية معاً، وهو يعمل في إعدادنا لأن الملفات مملوكة للمستخدم `www-data` و`FS_METHOD` مضبوط على `direct`، فلا تعطله ظناً منك أن وسم الـ Image هو الذي يحدد الإصدار. 📌 في 20 يناير 2017 أبلغت شركة Sucuri فريق WordPress بثغرة في REST API في الإصدارين 4.7 و4.7.1 تسمح لأي زائر دون تسجيل دخول بتعديل محتوى المقالات، فأصدر الفريق الإصدار 4.7.2 في 26 يناير وأخر الإعلان عن الثغرة أسبوعاً كاملاً، وكما [شرح الفريق في إعلانه](https://make.wordpress.org/core/2017/02/01/disclosure-of-additional-security-fix-in-wordpress-4-7-2/?ref=arabroot.io) فقد وصل الإصلاح عبر نظام التحديث التلقائي إلى ملايين المواقع خلال ساعات دون أن يفعل أصحابها شيئاً. وبعد الإعلان بأيام رصدت Sucuri [أربع حملات تشويه Defacement](https://blog.sucuri.net/2017/02/wordpress-rest-api-vulnerability-abused-in-defacement-campaigns.html?ref=arabroot.io) تمسح الإنترنت بحثاً عن المواقع التي لم تتحدث، وكان في نتائج Google لحملة واحدة منها أكثر من 66 ألف صفحة مخترقة خلال 48 ساعة، والدرس أن المواقع التي وصلها التحديث التلقائي نجت، وأن الموقع الذي عطل صاحبه التحديث بقي مكشوفاً لهذه الحملات. وإذا أردت أن تحدث يدوياً فالخطوات كما يلي: 1. خذ نسخة احتياطية من القاعدة وwp-content كما في القسم السابق. 2. حدث النواة والإضافات والقوالب والترجمات بالأوامر التالية: ```bash docker compose run --rm wpcli wp core update docker compose run --rm wpcli wp core update-db docker compose run --rm wpcli wp plugin update --all docker compose run --rm wpcli wp theme update --all docker compose run --rm wpcli wp language core update ``` 1. ولتحديث PHP أو Apache أو MariaDB غير الوسوم في `compose.yaml`، مثل وسم WordPress الجديد بأرقامه الكاملة وإصدار MariaDB 11.8 التالي، ثم نفذ: ```bash docker compose pull docker compose up -d docker compose logs --tail 30 db ``` ابق على فرع MariaDB 11.8 LTS للتحديثات الإصلاحية Patch Releases، ولا تنتقل بين الإصدارات الرئيسية Major Versions، مثل الانتقال من 11.8 إلى 12.3، دون نسخة احتياطية وتجربة على سيرفر اختبار، وقبل أن ترفع إصدار PHP تأكد أن إضافاتك تدعمه، والسبب أن الإضافة القديمة التي لا تدعم الإصدار الجديد قد توقف الموقع كله بخطأ واحد. ## مشكلات شائعة وحلولها ### رسالة Error establishing a database connection السبب غالباً واحد من اثنين: الأول أن القاعدة لم تبدأ بعد، والثاني أن كلمة المرور في `.env` تغيرت بعد إنشاء القاعدة، والـ Image لا تقرأ متغيرات `MARIADB_*` إلا عند التهيئة الأولى Initialization، فتغييرها لاحقاً لا يغير كلمة المرور داخل القاعدة. راجع السجلات Logs بالأمر `docker compose logs db`، وإذا كنت غيرت كلمة المرور فأعدها إلى قيمتها السابقة، أو غيرها داخل القاعدة بالأمر `ALTER USER`. ### الملف تجاوز upload\_max\_filesize تأكد أولاً أن `uploads.ini` مركب داخل الـ Container بالأمر `docker compose exec wordpress php -i | grep upload_max_filesize`، فإذا كانت القيمة صحيحة وفشل الرفع بالرمز `413` فالحد مفروض في الـ Reverse Proxy أو في Cloudflare وليس في PHP. ### WordPress يطلب بيانات FTP عند التحديث السبب أن `FS_METHOD` غير مضبوط، أو أن الملفات ليست مملوكة للمستخدم `www-data`، وهذا يحدث عادة بعد نسخ الملفات بمستخدم آخر، ولإصلاح الملكية Ownership نفذ الأمر `docker compose exec wordpress chown -R www-data:www-data /var/www/html/wp-content`. ### ERR\_TOO\_MANY\_REDIRECTS بعد تفعيل HTTPS WordPress لا يعرف أن الطلب وصل عبر HTTPS فيحوله، ثم يعيده الـ Reverse Proxy إليه، وتتكرر الحلقة، لذلك تأكد أن الـ Reverse Proxy يرسل `X-Forwarded-Proto`، وNginx Proxy Manager يفعل ذلك افتراضياً. وإذا كان Cloudflare أمام الـ Reverse Proxy فاجعل وضع SSL فيه [Full (strict)](https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/?ref=arabroot.io)، وإذا تعذر عليك دخول لوحة التحكم تماماً فعدل `WP_HOME` و`WP_SITEURL` في `compose.yaml` ثم أعد إنشاء الـ Container. ### الروابط كلها تعيد 404 عدا الصفحة الرئيسية قواعد `.htaccess` محذوفة أو فارغة، وهذا يحدث إذا حذف الملف أو أفرغته إضافة أو تعديل يدوي، والحل أن تحفظ صفحة الروابط الدائمة من لوحة التحكم مرة واحدة، أو تستخدم الأمر [wp rewrite flush --hard](https://developer.wordpress.org/cli/commands/rewrite/flush/?ref=arabroot.io) مع `wp-cli.yml` كما في قسم wp-cli. ### صفحة صحة الموقع تعرض خطأ في loopback أو REST API الـ Container لا يصل إلى رابط الموقع العام من داخله، فتفشل المهام المجدولة Cron Jobs وبعض وظائف المحرر، وتتحقق من ذلك بالأمر `docker compose exec wordpress curl -sI https://blog.example.com`، فإذا فشل فالسبب غالباً DNS داخلي أو Router لا يدعم NAT loopback، والحل أن تضيف إلى خدمة `wordpress` السطر `extra_hosts: ["blog.example.com:host-gateway"]` حتى يصل الـ Container إلى الـ Reverse Proxy على السيرفر نفسه. ### المقالات المجدولة Scheduled Posts لا تنشر في موعدها WP-Cron لا يعمل إلا حين يزور أحد الموقع، لذلك في المواقع قليلة الزيارات أضف `define('DISABLE_WP_CRON', true);` إلى `WORDPRESS_CONFIG_EXTRA`، ثم [شغل المهام من cron السيرفر](https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler/?ref=arabroot.io) كل خمس دقائق بالأمر `cd /opt/wordpress && docker compose run --rm wpcli wp cron event run --due-now`. ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما فيه: - الاستضافة المشتركة والتثبيت بنقرة واحدة لا يعطيانك تحكماً في PHP والحدود والنسخ الاحتياطي، والاستضافة المدارة مريحة ولكنها مكلفة ومقيدة، وملف Compose خاص بك على سيرفرك يجمع التحكم الكامل مع إعداد تعرف كل سطر فيه. - ولد كلمات المرور في `.env`، وحدد وسوم الـ Images بأرقامها الكاملة، واجعل `post_max_size` أكبر قليلاً من `upload_max_filesize`. - لا تنشر منفذ WordPress، فالـ Image تصدق الترويسة `X-Forwarded-Proto`، وهذا آمن فقط حين يكون الـ Reverse Proxy هو الطريق الوحيد إلى الـ Container. - شغل wp-cli بالمستخدم 33 ومعه `HOME: /tmp`، وأخبره بوجود `mod_rewrite` في `wp-cli.yml` قبل أن تعيد توليد قواعد `.htaccess`. - انسخ القاعدة وwp-content ومعهما `.env`، وجرب الاستعادة على سيرفر اختبار، واترك التحديث التلقائي للنواة يعمل، لأن تغيير وسم الـ Image لا يحدث ملفات WordPress. ## سجل التحديثات Changelog - سبتمبر 2026: كتابة الدليل واختباره على [WordPress 7.1.2](https://wordpress.org/news/category/releases/?ref=arabroot.io) مع MariaDB 11.8.9. - أكتوبر 2026: مراجعة الدليل وإعادة اختباره، ورفع `post_max_size` فوق حد الملف، وإضافة `HOME: /tmp` إلى خدمة wp-cli، وتصحيح طريقة التحقق من HTTPS خلف الـ Reverse Proxy وشرح سلوك wp-cli مع `.htaccess`، وتوضيح موقع MariaDB 11.8 بعد صدور 12.3 LTS والتحديث التلقائي للنواة.