استخدام Storage Server مع WordPress: ما ينجح وما لا ينجح

المجلد wp-content/uploads هو الجزء من WordPress الذي ينمو بلا كابح. صور وملفات PDF ومقاطع فيديو، يضاف إليها عدة أحجام لكل صورة يُنشئها WordPress تلقائياً. وبعد سنوات قليلة تقبع هناك عشرات الجيجابايتات، والمساحة على خادم الويب هي أغلى مساحة يمكن شراؤها.

يكلّف Storage Server جزءاً صغيراً من ذلك. والسؤال هو فقط ما الذي يمكن نقله فعلاً. فعلى الشبكة يُكتب في ذلك كثير لا يعمل في الواقع العملي. يفصل هذا المقال الحالات الثلاث بوضوح.

الحالات الثلاث في نظرة عامة

والنقطة الأخيرة هي التي يتعثر بها الأكثرون. ولهذا نبدأ بالحقيقة غير المريحة.

لماذا لا توجد إضافة لمكتبة الوسائط

إضافات النقل المعروفة في WordPress تتكلم كلها اللغة نفسها: S3. فهي تتصل بـ Amazon S3 أو بخدمة متوافقة معه، وترفع الملف إلى هناك، وتحذف النسخة المحلية، وتستبدل العنوان في المقال بعنوان عام من عناوين الخدمة.

وهذا بالضبط لا يمكن نقله إلى Storage Server، ولسببين:

• خادم التخزين يتكلم SMB وSFTP وWebDAV، لكنه لا يتكلم S3.
• لا يوجد عنوان عام لكل ملف. فكل وصول يتطلب تسجيل الدخول، أي لا يمكن أن يوجد رابط يستدعيه متصفح الزائر مباشرةً.

توجد إضافات مفردة تعمل بـ FTP، لكن لا توجد إضافة ذات انتشار يُعتدّ به وصيانة حديثة تنقل مكتبة الوسائط بالكامل عبر SFTP أو WebDAV. ومن يجد واحدة، فعليه أن ينظر قبل استخدامها إلى تاريخ آخر تحديث وإلى عدد التثبيتات النشطة.

الطريق الذي ينجح: التركيب بدلاً من النقل

على خادم خاص بكم مع صلاحيات root تُقلب المسألة. فبدلاً من تعليم WordPress أن يتكلم مع تخزين غريب، يُجلب التخزين إلى الموضع الذي يكتب فيه WordPress أصلاً:

apt install -y cifs-utils
mkdir -p /mnt/storage
printf 'username=u123456-sub1\npassword=كلمة_مروركم\n' > /etc/samba/storage.cred
chmod 600 /etc/samba/storage.cred

المدخل في /etc/fstab:

//u123456.storage.kernelhost.net/backup /mnt/storage cifs credentials=/etc/samba/storage.cred,uid=www-data,gid=www-data,file_mode=0660,dir_mode=0770,seal,_netdev,nofail 0 0

بعد ذلك انقلوا الملفات الموجودة واستبدلوا المجلد:

mount -a
mkdir -p /mnt/storage/uploads
rsync -a /var/www/example.com/wp-content/uploads/ /mnt/storage/uploads/
mv /var/www/example.com/wp-content/uploads /var/www/example.com/wp-content/uploads.alt
ln -s /mnt/storage/uploads /var/www/example.com/wp-content/uploads

لا يلاحظ WordPress شيئاً من ذلك، فهو للتطبيق مسار عادي تماماً. ويبقى المجلد القديم موجوداً باسم uploads.alt حتى تتحقّقوا من أن كل شيء يعمل. وعندها فقط احذفوه، لا قبل ذلك.

الفخ هنا: الصور المصغّرة

يُنشئ WordPress من كل صورة عدة أحجام ويحمّلها عند كل استدعاء للصفحة. وإذا كانت هذه الملفات الصغيرة على التخزين الشبكي، أُضيف زمن المرور في الشبكة لكل ملف، ومعرض فيه أربعون صورة ينتظر أربعين مرة.

حلّان، وكلاهما جيد:

• ضعوا ذاكرة مؤقتة أمامه، مثلاً ذاكرة مؤقتة في خادم الويب تحتفظ بالملفات المسلَّمة محلياً.
• ضعوا الأصول وحدها على خادم التخزين واتركوا الأحجام المُنشأة محلياً. وهذا عمل أكثر قليلاً، لكنه أنقى طريق للمواقع كثيرة الصور.

النسخ الاحتياطية: أسرع فائدة

إن فعلتم شيئاً واحداً فقط، فليكن هذا. فالنسخة الاحتياطية على الخادم نفسه ليست نسخة احتياطية: إذا مُحي القرص أو شُفِّر الموقع، ذهبت معه. أما على تخزين منفصل فتبقى.

تستطيع الإضافة المجانية WPvivid في نسختها الأساسية أن تنسخ احتياطياً إلى خادم التخزين عبر SFTP، مع جدول زمني وقاعدة للاحتفاظ. والدليل الكامل لذلك في مقال نسخ WordPress الاحتياطية على Storage Server.

وعلى خادم خاص بكم يمكن الأمر بشكل أفضل، أي بـ rsync أو BorgBackup من داخل جدول زمني مباشرةً. فعندها لا تنقلون غير التغييرات، ويزيل BorgBackup التكرار فوق ذلك.

تسليم التنزيلات الكبيرة

خادم التخزين مثالي للملفات التي يُراد أن ينزّلها الزوّار: فهي تُقرأ قليلاً، وحجمها كبير، ولا يلزم أن تكون سريعة، بل أن تصل فقط. ويمر الوصول عبر سكربت صغير يتحقّق من الصلاحية أولاً:

<?php
// في functions.php أو كإضافة خاصة
add_action('template_redirect', function () {
    if (!isset($_GET['kh_download'])) {
        return;
    }
    if (!is_user_logged_in()) {
        wp_die('يرجى تسجيل الدخول', '', ['response' => 403]);
    }

    $pfad = '/mnt/storage/downloads/' . basename($_GET['kh_download']);
    if (!is_readable($pfad)) {
        wp_die('لم يُعثر على الملف', '', ['response' => 404]);
    }

    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename="' . basename($pfad) . '"');
    header('Content-Length: ' . filesize($pfad));
    readfile($pfad);
    exit;
});

ينطلق المثال من تخزين مركّب. ومن دون تركيب تستبدلون readfile() باستدعاء SFTP أو WebDAV، كما هو موضح في مقال استخدام Storage Server لموقعكم الخاص.

والأثر الجانبي لطيف: لأن الملف لا يحمل عنواناً عاماً أبداً، لا يستطيع أحد تمرير الرابط. ولا يمكن تجاوز التحقّق من الصلاحية.

ما يبقى على الاستضافة المشتركة

على الاستضافة المشتركة يكون WebDAV عبر HTTPS أوثق طريق، لأن المنفذ 443 لا يكاد يكون محظوراً أبداً. ويعمل SFTP كذلك، لكنه يجري عندنا على المنفذ 23، وليس كل مزوّد يسمح باتصالات صادرة على منافذ كهذه. والأفضل التحقّق من ذلك سريعاً قبل الطلب.

حساب فرعي لكل غرض

يسمح كل Storage Server بـ 100 حساب فرعي كحد أقصى، لكل منها مجلد بداية خاص وكلمة مرور خاصة وتصاريح بروتوكولات خاصة. وبالنسبة لـ WordPress يعني ذلك حسابين على الأقل:

• حساب للموقع لا يرى غير /uploads.
• حساب للنسخ الاحتياطية لا يرى غير /backup.

فإذا اختُرق الموقع يوماً، وجد المهاجم في wp-config.php بيانات دخول الحساب الأول. وتبقى النسخ الاحتياطية سليمة، لأن هذا الحساب لا يعرفها أصلاً. أما بحساب رئيسي واحد وحده، فكان كل شيء سيذهب في هذا الموضع.

عندما يحتاج عدة مستخدمين مساحة خاصة

لا يعرف Storage Server أي حصة لكل حساب فرعي. فالحساب يبقى في مجلده، لكنه يستطيع أن يملأ هناك التعرفة كلها. ومن يريد أن يمنح عملاء أو مصوّرين أو محرّرين حصة محدودة لكل واحد، فهو يضع أمامه تطبيقاً يتولى ذلك. وNextcloud هو الأقرب لهذا الغرض، فهو يأتي بالمستخدمين والحصص وروابط المشاركة: ربط Nextcloud بـ Storage Server.

أي تعرفة تناسبكم

لموقع WordPress واحد مع نسخه الاحتياطية تكفي Storage-1 في العادة مدة طويلة. ومن ينقل مكتبات وسائط لعدة مواقع أو يعمل بالفيديو، يصل سريعاً إلى Storage-2 أو Storage-3. وتقف جميع التعرفات في ألمانيا، وتأتي دون رسوم إعداد، وتُحاسب على أساس الدفع المسبق، وليس لها مدة التزام دنيا. والانتقال إلى التعرفة الأكبر التالية ممكن في أي وقت، دون لمس البيانات.