أدرجتُ تطبيقين من WordPress في Cloudways Site Manager لهذه المراجعة، واحدًا عبر شاشة الإعداد الموجودة داخل الشريط الجانبي للتطبيق نفسه، وآخر عبر مسار الإضافة الجماعي الموجود على مستوى الحساب.

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

Cloudways

إدارة تطبيقات WordPress المستضافة على Cloudways مع تحديثات مركزية، وSafe Updates، وسجلات النشاط، وجدولة على مستوى المحفظة.

قم بزيارة Cloudways

ما هو Cloudways Site Manager؟

Site Manager حلّ محل إضافة Cloudways أقدم تُدعى SafeUpdates. إن فهم ما الذي لم يكن SafeUpdates قادرًا على فعله يفسر تقريبًا كل قرارات التصميم في المنتج الحالي.

كان SafeUpdates يشغّل كل شيء عبر SSH، ما خلق مجموعة محددة من المشكلات لأي شخص يدير أكثر من بضعة مواقع:

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

قالت الوكالات التي تدير عشرين عملية تثبيت WordPress أو أكثر لـ Cloudways، بمعنى ما، إن الأداة كانت تعمل إلى أن لم تعد كذلك قادرة على التوسع، وكان التوسع هو السبب الكامل لوجودهم على Cloudways من الأساس.

Site Manager هو الرد المباشر على تلك الملاحظات. وهذا السياق مهم لقراءة بقية هذه المراجعة، لأنه يفسر لماذا تبدو بعض أجزاء المنتج ناضجة بشكل غير معتاد بالنسبة لشيء لا يزال في المعاينة العامة Public Preview، ولماذا تُظهر أجزاء أخرى، مثل خطوة الإعداد التي ستصادفها في اليوم الأول، بعض آثار التدرزات.

ما الذي يمكن لـ Cloudways Site Manager فعله؟

مع هذا الخلفية، يصبح السؤال التالي هو النطاق: ما الذي يمكن لهذه الأداة الوصول إليه فعليًا. قبل الدخول في الإعداد، والتحديثات، والجدولة، من المهم أن نكون دقيقين بشأن ما يغطيه Site Manager وما لا يغطيه، لأن الإجابة الصادقة أكثر تعقيدًا من نعم أو لا بسيطة.

لوحة التحكم الأصلية مخصصة لـ Cloudways فقط

كل تطبيق كان متاحًا للتسجيل في Site Manager على مستوى الحساب، سواء عبر الشاشة الخاصة بالتطبيق أو عبر المعالج الجماعي تحت Integrations، جاء من خادم موجود بالفعل داخل حساب Cloudways الخاص بي.

لم يكن هناك حقل لإدخال بيانات اعتماد لتثبيت مستضاف خارجيًا، ولا موصل لموقع يعمل على استضافة مختلفة تمامًا.

مجموعة الميزات الكاملة التي يغطيها هذا الاستعراض، Safe Update ونسخة التدريج staging clone، واختبار الانحدار البصري، وسجلات النشاط، والجدولة الجماعية، كلها موجودة داخل هذه الطبقة الأصلية المستضافة على Cloudways.

إضافة منفصلة توسّع المراقبة الأخف لأي موقع

كما تنشر Cloudways إضافة WordPress مجانية، تحمل أيضًا اسم Cloudways Site Manager، طُوّرت بالتعاون مع WP Remote.

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

لكنها منتج مختلف حقًا عن لوحة التحكم الأصلية، والفجوة بين الاثنين مهمة:

كما أن الإضافة تعطل التحديثات التلقائية الخاصة بـ WordPress نفسها أثناء تفعيلها، وهو خيار مقصود من Cloudways لتجنب التعارضات أثناء الإدارة عن بُعد.

توضح Cloudways بصراحة أن مسار الإضافة هو خطوة انتقالية أكثر من كونه الوجهة النهائية: إذا كنت تريد الحزمة الكاملة، النسخ الاحتياطية التلقائية، والتدريج بنقرة واحدة، وتكامل Cloudflare، والتخزين المؤقت المُدار، فالممارسة الموصى بها هي نقل الموقع الخارجي إلى Cloudways بدلًا من إدارته عن بُعد على المدى الطويل.

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

Cloudways

إدارة تطبيقات WordPress المستضافة على Cloudways مع تحديثات مركزية، وSafe Updates، وسجلات النشاط، وجدولة على مستوى المحفظة.

قم بزيارة Cloudways

البدء: طريقتان لإلحاق المواقع

مع حسم سؤال النطاق، يبدأ الجزء العملي هنا: إلحاق تطبيق WordPress فعليًا. تمنحك Cloudways طريقتين للدخول إلى Site Manager الأصلي، وهما ليستا مناسبتين بنفس القدر للمهمة.

المسار 1: عبر الشريط الجانبي الخاص بالتطبيق نفسه

إليك بالضبط كيف وصلتُ إليه للمرة الأولى. من لوحة Cloudways الرئيسية، نقرتُ على الخادم، ثم على تطبيق WordPress الموجود عليه، وهو ما ينقلك إلى صفحة Access Details الخاصة بذلك التطبيق.

يسرد الشريط الجانبي الأيسر هناك Access Details، وStaging Management، وMonitoring، وApplication Security، وDomain Management، ثم Site Manager، مع وسم “New”. بالنقر عليه انتقلتُ مباشرةً إلى شاشة بعنوان “Simplify App Management with Site Manager”، مخصصة بالكامل لذلك التطبيق الواحد، مع بطاقتي خطتين جنبًا إلى جنب، Basic وPro.

نقرتُ Get Pro. وهنا سارت الأمور بشكل خاطئ.

تغيرت الشاشة إلى “Subscribing to the Site Manager Plan…” مع رسالة تشرح أن Cloudways كانت تثبّت الإضافة وتزامن بيانات موقعي، وأن ذلك قد يستغرق بضع دقائق حسب حجم التطبيق.

استغرق الأمر نحو دقيقتين ثم فشل، وعاد بإشعار خطأ أحمر: “Please delete existing plugin and install again.” لم يكن لدي أي تثبيت سابق لأحذفه، لذا فإن الرسالة نفسها لم تقل لي ما الذي حدث خطأً فعليًا.

نقرتُ Get Pro مرة ثانية، على شاشة الخطة نفسها، دون تغيير أي شيء. نجحت تلك المحاولة. استغرقت نحو ثلاث دقائق وانتهت بإشعار نجاح أخضر يؤكد أنني اشتركت في خطة Site Manager، ليصلني إلى صفحة Site Manager Overview الخاصة بالتطبيق، مع عدد الإضافات، وعدد القوالب، ودرجة الأداء، وجدول Manage Updates كلها مملوءة وجاهزة.

المسار 2: عبر لوحة مستوى الحساب

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

من لوحة Cloudways الرئيسية، يحتوي شريط التنقل الأيسر على صف من الأيقونات: Home، وFlexible، وAutonomous، وIntegrations، وAgency Partners. نقرتُ Integrations. ففتح لوحة من البطاقات، بينها Site Manager (مع وسم “New”)، وApplication Migration، وDNS Made Easy، وCookieYes، وEqualize Digital Accessibility Checker.

النقر على بطاقة Site Manager نقلني إلى شاشة مختلفة تمامًا عن المسار 1، شاشة تعيش تحت المسار Integrations → Add-Ons → Site Manager، مع صف تبويبات خاص بها: Overview، وManage Updates، وAuto Updates، وHistory.

تُعد صفحة Overview هذه مركز القيادة الحقيقي. فهي تعرض إحصاءات على مستوى الحساب، وإجمالي التطبيقات على Site Manager، والتطبيقات على الخطة المجانية، والتطبيقات على خطة Pro، والتطبيقات مع Auto Updates، وأسفل ذلك جدول Manage Applications يسرد كل تطبيق مسجل بالفعل.

ولإضافة المزيد، نقرتُ Add Apps to Site Manager في أعلى يمين ذلك الجدول. ففتح ذلك معالجًا من خطوتين:

1. Select Application(s): قائمة تحقق بكل تطبيق WordPress في حسابي غير مسجل بعد، مع خيار Select All وحقل بحث.

أوضح تنبيه أعلى القائمة أنه يستبعد تطبيقات staging، والتطبيقات على الخوادم المتوقفة، وأي تطبيق يعمل بالفعل على الإضافة القديمة SafeUpdates. وضعتُ علامة على التطبيق الذي أردته ونقرتُ Select Plan.

2. Select your Plan: بطاقتا Basic وPro جنبًا إلى جنب مرة أخرى، مع تأكيد عدد التطبيقات التي حددتها والتكلفة الشهرية الإجمالية لهذه الدفعة. اخترتُ Pro ونقرتُ Enable Site Manager.

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

الفجوة التي لا يحذرك منها أحد

بعد أن ألحقتُ التطبيقات عبر كلا المسارين، إليك الملاحظة التي غيّرت طريقة تفكيري في صيانة هذا المنتج يوميًا. أضفتُ تطبيق WordPress ثانيًا إلى خادم كان عليه بالفعل Site Manager يدير تطبيقًا آخر على الخادم نفسه.

توقعتُ أن يظهر التطبيق الجديد تلقائيًا، لأنه كان موجودًا بجوار تطبيق يعرفه Site Manager بالفعل. لكنه لم يظهر. بقي عداد لوحة مستوى الحساب “Total Apps on Site Manager” على حاله تمامًا إلى أن مررتُ التطبيق الجديد يدويًا عبر الإعداد.

هذا خيار تصميمي، لكنه خيار له كلفة تشغيلية:

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

Cloudways

إدارة تطبيقات WordPress المستضافة على Cloudways مع تحديثات مركزية، وSafe Updates، وسجلات النشاط، وجدولة على مستوى المحفظة.

قم بزيارة Cloudways

ما الذي تدفع مقابله فعليًا

يقسم Site Manager إلى طبقة مجانية مفيدة بالفعل، وطبقة Pro تفتح الميزات التي ستبني الوكالة حولها سير عمل حقيقيًا.

Basic مقابل Pro، ميزة بميزة

Basic ليس نسخة تجريبية مقصوصة. فهو يتضمن نظرة عامة حقيقية على الموقع، والقدرة على إدارة المستخدمين والقوالب والإضافات دون لمس wp-admin، وتسجيل دخول موحد بنقرة واحدة إلى WordPress، وQuick Updates، والأهم من ذلك، لوحة التحكم المركزية نفسها.

لم تُقفل Cloudways تجربة “رؤية كل مواقعك في مكان واحد” الأساسية خلف جدار مدفوع. ما هو مقفل هو كل ما يجعل تلك اللوحة جديرة بالثقة بما يكفي للتصرف بناءً عليها دون مراقبة مستمرة.

Pro مجاني الاستخدام حاليًا أثناء Public Preview بغض النظر عن سعره المدرج، وهو $3 لكل تطبيق شهريًا، وينخفض إلى $2 لكل تطبيق بمجرد تجاوز خمسة تطبيقات.

ما تكلفة Pro فعليًا مع نمو محفظتك

تستحق عتبة الخصم هذه إجراء الحسابات قبل افتراض أن Pro يتوسع بثمن زهيد:

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

ثلاثة أماكن لتشغيل التحديث نفسه

مع الانتهاء من الإلحاق والتسعير، تغطي بقية هذه المراجعة شكل الاستخدام اليومي فعليًا، بدءًا من جزء من البنية يستحق الفهم.

هذا هو الجزء من تصميم Site Manager الذي استغرق أطول وقت لأفهمه فعليًا، وهو غير مشروح في الواجهة نفسها.

• صفحة Overview الخاصة بالتطبيق نفسه لا تزال تعرض جدول Manage Updates الخاص بها، والذي يسرد نفس تحديثات الإضافات المعلقة التي ستراها في لوحة مستوى الحساب.
• قائمة Actions على مستوى الصف في لوحة الحساب تقدم إجراء Manage Updates خاصًا بها، مستندًا إلى نفس البيانات الأساسية.
• تبويب Auto Updates يتيح لك جدولة ذلك النوع نفسه من التحديثات ليعمل تلقائيًا، على تطبيق واحد أو على كل التطبيقات المسجلة دفعة واحدة.

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

أما تبويب الجدولة فمخصص لإخراج الإنسان من الحلقة تمامًا.

Quick Update مقابل Safe Update

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

كل مستوى خطة يقدم Quick Update. يستغرق تطبيقه ثوانٍ: يتم تثبيت التحديث مباشرة على الإنتاج دون أي فحص توافق ودون أخذ نسخة احتياطية أولًا.

تكون نسخة Cloudways نفسها صريحة بشأن المقايضة، محذرةً من أنه “may carry risks if updates aren’t compatible.”

لم أشغّل Quick Update في هذا الاختبار، لذا لا أستطيع أن أصف من التجربة كيف يبدو الفشل فيه على الشاشة. وهذه فجوة حقيقية في هذه المراجعة، وأتعامل مع أي ادعاء حول سلوك فشل Quick Update، مني أو من أي شخص آخر لم يختبره، بحذر مناسب.

Safe Update هو المكان الذي تبرر فيه Pro سعرها، ويستحق أن نمر عليه بالكامل لأن العملية أعقد من مجرد “backup, then update.”

كيف يبدو تشغيل Safe Update فعليًا

إليك بالضبط كيف شغّلته. من جدول Overview على مستوى الحساب تحت Integrations → Site Manager، وجدتُ صف التطبيق الذي لديه تحديثات معلقة ونقرتُ قائمة Actions ذات النقاط الثلاث في نهاية ذلك الصف. ففتحت أربعة خيارات: WP-Admin، وApp Overview، وManage Updates، وManage Plan. نقرتُ Manage Updates.

فتح ذلك نافذة منبثقة تسرد كل إضافة لديها تحديث معلق، أربع إضافات في حالتي، Breeze وElementor وObject Cache Pro وWP Ulike، وكل منها معروض كعنصر محدد بعلامة صح مع نسخته الحالية والنسخة التي سيُحدَّث إليها.

أسفل القائمة ظهرت خياران على شكل أزرار اختيار: Quick Update وSafe Update، مع وصف قصير للمقايضة لكل منهما. اخترتُ Safe Update ونقرتُ Proceed.

بدلًا من مؤشر تقدم واحد، تعرض النافذة المنبثقة التي فتحت بعد ذلك قائمة تحقق مرحلية تتحدث في الوقت الحقيقي.

بيئة staging:

• Pre Snapshot
• Fetch Update Packages
• Update each plugin individually
• Post Snapshot
• Purge Cache
• Visual Regression

الإنتاج:

• تتكرر التسلسلات نفسها مرة أخرى بعد نجاح staging، وتنتهي بتنظيف نهائي واحد لذاكرة التخزين المؤقت

بدأتُ التشغيل عند 6:21 pm وانتهى عند 6:27 pm. ست دقائق لأربع إضافات، عبر دورة كاملة من staging ثم الإنتاج. النافذة المنبثقة نفسها تضع التوقع بأن ذلك “usually takes less than a minute,” لكن عملي تجاوز التقدير بفارق كبير.

تلك الفجوة بين التقدير المعلن والزمن الفعلي تستحق أن تُؤخذ في الحسبان بدلًا من أن تفاجئك إذا كنت تشغّل Safe Update على دفعة إضافات خلال نافذة صيانة، فخصص دقائق، لا ثوانٍ، خاصة مع ازدياد عدد الإضافات.

أكد إشعار نجاح النتيجة، وبمجرد انتهائه، سجّلته علامة التبويب History على مستوى الحساب على أنه “On-Demand Successful: Plugins (4)” مع رابط إلى التفاصيل الكاملة.

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

الإعدادان اللذان يحددان مدى تسامح التحديثات

يقع كلاهما داخل مسار الجدولة بدلًا من شاشة التحديث عند الطلب، ما يجعلهما سهلَي التجاوز:

• Visual Regression Sensitivity يتحكم في مقدار الاختلاف البصري بين اختبار staging والإنتاج الذي يُسمح به قبل أن يُلغى التحديث لحماية التخطيط. ويبدأ افتراضيًا بأشد إعداد متاح، “Critical, 0% difference.”
• Smart Skip for Plugin/Theme Update Failures، وهو مفعّل افتراضيًا، يعني أن فشل إضافة واحدة في التحديث لا يوقف الدفعة بأكملها. يضع النظام هذا العنصر جانبًا، ويحدّث كل ما نجح، ويجري فحص الانحدار البصري على ما نجح، ويدفع تلك التغييرات إلى الإنتاج تلقائيًا.

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

Cloudways

إدارة تطبيقات WordPress المستضافة على Cloudways مع تحديثات مركزية، وSafe Updates، وسجلات النشاط، وجدولة على مستوى المحفظة.

قم بزيارة Cloudways

جدولة التحديثات عبر محفظة كاملة دفعة واحدة

ذلك يغطي البابين الأولين. يغطي هذا القسم الباب الثالث: إخراج الإنسان من الحلقة تمامًا. تبويب Auto Updates، الذي يتم الوصول إليه من نفس صفحة Site Manager على مستوى الحساب، هو المكان الذي إما ينجح فيه وعد “إدارة مواقع كثيرة كما لو كانت موقعًا واحدًا” أو يفشل. وفي حالتي، نجح.

إليك بالضبط كيف أعددته. من Integrations → Site Manager، نقرتُ تبويب Auto Updates في الصف العلوي.

ومع عدم وجود أي جدول مجدول بعد، عرضت الصفحة حالة فارغة، “No Auto Updates Schedule”، مع زر واحد: Set Auto Update Schedule.

أدى النقر عليه إلى فتح معالج، “Set Auto Update Schedule”، الذي مرّ عبر ما يلي في تمريرة واحدة:

1. Day of Week and Schedule Time: قائمتان منسدلتان، بالإضافة إلى محدد منطقة زمنية بجانب حقل الوقت. ضبطتُه على Friday، بين midnight و5:59am UTC.
2. Select Application: قائمة تحقق بكل تطبيق مسجل بالفعل في Site Manager، مع خيار Select All، وملاحظة أن أي جدول زمني قائم مُعيّن مسبقًا على تطبيق محدد سيتم استبداله بهذا الجدول الجديد. اخترتُ كلا التطبيقين ونقرتُ Choose Preferences.

فتحت شاشة ثانية بعد ذلك، “Create Auto Update Schedule”، وتغطي:

3. Configure Update List: ثلاثة أقسام قابلة للتوسيع، WordPress Core، وPlugins، وThemes، وكل منها مع قائمة تحقق خاصة به وعدّادًا حيًا لعدد العناصر المختارة. عبر تطبيقَيّ الاثنين، كانت هناك عشر إضافات وأربعة قوالب متاحة للإدراج، وكل إضافة وقالب مدرج يبيّن بالضبط كم عدد تطبيقاتي التي تستخدمه فعليًا، وهي تفصيلة صغيرة لكنها مهمة جدًا عندما تدير عشرات المواقع وتحاول معرفة أي التحديثات تستحق الاختبار على نطاق واسع وأيها يطال موقعًا واحدًا فقط.

4. Update Type: قائمة منسدلة تقدم Quick Update أو Safe Update، مع نفس الوصف المعروض في النافذة المنبثقة عند الطلب. أدى اختيار Safe Update إلى إظهار عنصرين إضافيين لا يظهران إلا لهذا الوضع، هما Visual Regression Sensitivity وSmart Skip for Plugin/Theme Update Failures.

5. Critical Updates: مفتاح تشغيل/إيقاف، مُعطّل افتراضيًا، مخصص لدفع تصحيح أمني خارج الجدول المعتاد فور الإبلاغ عن ثغرة.

حفظ النقر على Set AutoUpdate Schedule الجدول، وطبّقه على كل تطبيق اخترته في الخطوة الثانية، دون الحاجة إلى تكرار الإعداد لكل موقع على حدة.

سجلات النشاط: الجزء الذي يتعلق فعليًا بثقة العميل

الأبواب الثلاثة وآليات التحديث وراءها تغطي الكيفية. تغطي هذه الميزة الأخيرة الإثبات: سجل دائم لما حدث، منفصل عن عملية التحديث نفسها.

إليك بالضبط كيف شغّلتُه.

من صفحة Site Manager Overview الخاصة بذلك التطبيق، وهي نفسها التي تصل إليها بعد الاشتراك عبر المسار 1، توجد بطاقة بعنوان “Activity Logs are Disabled” بجوار حلقة الأداء، مع وصف قصير وزر واحد: Enable Activity Logs.

نقرتُ عليه، وتحديثت البطاقة فورًا، دون نافذة تأكيد منبثقة، ودون خطوات إضافية. وعند التحقق من جدول Manage Applications على مستوى الحساب مباشرة بعد ذلك، تحت Integrations → Site Manager، كانت قيمة عمود Activity Logs لذلك التطبيق قد تحولت بالفعل من Disabled إلى Enabled، دون الحاجة إلى تحديث الصفحة.

تقع هذه الميزة خلف Pro، وهي موجودة للإجابة عن سؤال تطرحه كل وكالة في النهاية من عميل: من الذي غيّر ماذا، ومتى؟

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

Cloudways

إدارة تطبيقات WordPress المستضافة على Cloudways مع تحديثات مركزية، وSafe Updates، وسجلات النشاط، وجدولة على مستوى المحفظة.

قم بزيارة Cloudways

الإيجابيات والسلبيات

لمن هذا المنتج فعلًا؟

بعد عرض المجموعة الكاملة من الميزات، وتكاليفها، وعيوبها، يبقى السؤال الأخير ببساطة: هل يناسب محفظتك المحددة؟

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

إنه توافق جزئي لمن لديه محفظة مختلطة. يمكن لإضافة Site Manager المجانية أن تُدخل مواقع خارجية للمراقبة والتحديث الأساسيين، لكن الميزات التي تجعل اللوحة الأصلية تستحق الدفع، Safe Update القائم على staging، والانحدار البصري، وسجلات النشاط، تبقى بعيدة حتى تنتقل تلك المواقع فعليًا إلى Cloudways.

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

الخلاصة: يستحق ذلك، لكن فقط داخل Cloudways

نعم، يستحق Site Manager الاعتماد عليه، بشرط واحد: أن تكون مواقعك موجودة بالفعل على Cloudways. داخل هذا الحد، يفي Site Manager بما يعد به، لوحة حقيقية عبر التطبيقات، ومسار Safe Update ينسخ احتياطيًا قبل لمس الإنتاج، وجدولة جماعية تعامل التحديثات كإجراء على مستوى الأسطول بدلًا من مهمة مرتبطة بتسجيل دخول لكل موقع.

خارج هذا الحد، فهو أداة أخف مع دفع واضح نحو الانتقال مُرفق بها. أفضل توافق له هو وكالة توحّد مواقع العملاء على Cloudways وتحتاج إلى مكان واحد تثبت فيه ما الذي تغيّر ومتى.

Cloudways

4.6

537 user reviews

US$ 11,00 /mo

السعر المبدأي

قم بزيارة Cloudways

Rating based on expert review

• سهولة الاستخدام
  4.5
• الدعم الفني
  4.6
• المميزات
  4.8
• الموثوقية
  4.8
• الأسعار
  4.3