سجلت تطبيقين WordPress في Cloudways Site Manager علشان أراجعهم، واحد من شاشة الـ onboarding الموجودة جوه الشريط الجانبي الخاص بالتطبيق نفسه، وواحد من flow الـ bulk اللي موجود على مستوى الحساب.
ومن هناك، عملت Safe Update حقيقي على أربع plugins، وبنيت جدول auto-update مشترك يغطي الموقعين، وفعّلت activity logging، وقضيت وقت كفاية في الـ account-level dashboard عشان أفهم نفس المعلومة بتظهر فين أكتر من مكان، وليه ده مهم أكتر مما يبان.
Site Manager بدّل add-on أقدم من Cloudways اسمه SafeUpdates. فهم SafeUpdates كان مش قادر يعمل إيه بيفسر تقريبًا كل قرارات التصميم في المنتج الحالي.
SafeUpdates كان بيشغّل كل حاجة over SSH، وده كان بيعمل مجموعة مشاكل محددة لأي حد بيدير أكتر من كام موقع:
الوكالات اللي بيديروا عشرين أو أكتر من WordPress installs قالوا لـ Cloudways، بمعنى ما، إن الأداة كانت شغالة لحد ما بطلت تتوسع، والتوسع كان هو السبب كله في إنهم على Cloudways من الأساس.
Site Manager هو الرد المباشر على الفيدباك ده. والسياق ده مهم وأنت بتقرأ باقي المراجعة، لأنه بيوضح ليه أجزاء من المنتج باينة ناضجة بشكل غير معتاد بالنسبة لحاجة لسه في Public Preview، وليه أجزاء تانية، زي خطوة الـ onboarding اللي هتقابلها من أول يوم، لسه باين عليها الشقوق.
مع الخلفية دي، السؤال اللي بعده هو النطاق: الأداة دي بتوصل لإيه فعلًا. قبل ما ندخل في الـ onboarding، والتحديثات، والجدولة، مهم نكون دقيقين بخصوص Site Manager بيغطي إيه وما بيغطيش إيه، لأن الإجابة الصريحة أعقد بكتير من نعم أو لا بسيطة.
كل تطبيق كان متاح للتسجيل في Site Manager على مستوى الحساب، سواء من شاشة كل تطبيق لوحده أو من bulk wizard تحت Integrations، كان جاي من server موجود أصلًا داخل حساب Cloudways بتاعي.
ماكانش فيه field ألصق فيه credentials لموقع مستضاف خارجيًا، ولا connector لموقع شغال على host تاني بالكامل.
مجموعة الخصائص الكاملة اللي مغطاة في المراجعة دي، Safe Update اللي بيعمل staging clone، وvisual regression testing، وactivity logs، وbulk scheduling، كل ده عايش جوه الطبقة الأصلية دي المستضافة على Cloudways.
Cloudways كمان بتنشر WordPress plugin مجاني، كمان اسمه Cloudways Site Manager، متطور بالتعاون مع WP Remote.
بعكس الـ dashboard الأصلي، الـ plugin ده بيتثبت مباشرة على موقع WordPress بغض النظر هو مستضاف فين، وده معناه إنه يقدر يدخل موقع خارجي، non-Cloudways، في نسخة من نفس الـ centralized view.
لكن ده منتج مختلف فعلًا عن الـ dashboard الأصلي، والفجوة بين الاتنين مهمة:
| Capability | Native Site Manager (Cloudways-hosted apps) | Site Manager Plugin (any host) |
|---|---|---|
| Centralized dashboard | Yes | Yes |
| Core, plugin, theme updates | Yes | Yes |
| Safe Update (staging clone + visual regression) | Yes | No |
| Server-level caching (Varnish, Redis, Cloudflare) | Yes | No |
| Activity logs | Yes (Pro) | Not equivalent |
| Cost | Free (Basic) / paid (Pro) | Free |
الـ plugin كمان بيعطّل automatic updates بتاعة WordPress نفسها وهو شغال، وده اختيار مقصود من Cloudways علشان تتجنب التعارضات أثناء الإدارة عن بُعد.
Cloudways واضحة إن طريق الـ plugin هو خطوة وسيطة مش الوجهة النهائية: لو عايز الـ full stack، الـ automated backups، وone-click staging، وتكامل Cloudflare، وmanaged caching، فالممارسة الموصى بيها هي نقل الموقع الخارجي لـ Cloudways بدل إدارته عن بُعد على المدى الطويل.
بالنسبة لوكالة عندها portfolio كلها مستضافة على Cloudways، كل ده مش فارق. لكن لأي حد لسه شغال على كام موقع بره، ومعظم الوكالات اللي اتكلمت معاهم عبر السنين عندهم على الأقل كام واحد، فالـ plugin خيار حقيقي للمراقبة الأساسية والتحديثات، بس مش بديل عن اللي الـ native dashboard بيعمله.
مع حسم سؤال النطاق، الجزء العملي بيبدأ هنا: إزاي تسجل تطبيق WordPress فعلًا. Cloudways بتديك طريقتين للدخول إلى Site Manager الأصلي، ومش الاتنين مناسبين لنفس الشغل.
ودي كانت بالضبط الطريقة اللي دخلت بيها أول مرة. من Cloudways home dashboard، دخلت على server بتاعي، وبعدين على تطبيق WordPress اللي عليه، وده بيرميك على صفحة Access Details الخاصة بالتطبيق ده.
الـ sidebar الشمال هناك بيعرض Access Details، وStaging Management، وMonitoring، وApplication Security، وDomain Management، وبعدهم Site Manager، وعليه tag “New”. الضغط عليه نقلني مباشرة لشاشة بعنوان “Simplify App Management with Site Manager”، خاصة بالتطبيق ده لوحده، ومعاها plan cards اتنين جنب بعض، Basic وPro.
ضغطت Get Pro. وساعتها الأمور اتعكست.
الشاشة اتغيرت إلى “Subscribing to the Site Manager Plan…” مع رسالة بتوضح إن Cloudways بتثبت الـ plugin وبتزامن بيانات موقعي، وإن ده ممكن ياخد كام دقيقة حسب حجم التطبيق.
فضل شغال حوالي دقيقتين وبعدها فشل، وطلعلي إشعار خطأ أحمر: “Please delete existing plugin and install again.” ماكانش عندي أي تثبيت سابق أحذفه، فالمسج نفسها ماقالتش إيه اللي حصل غلط فعلًا.
ضغطت Get Pro مرة تانية، على نفس شاشة الخطة، من غير ما أغير أي حاجة. المحاولة دي نجحت. اشتغلت حوالي 3 دقائق وخلصت بإشعار نجاح أخضر بيأكد إني اشتركت في خطة Site Manager، وودتني على صفحة Site Manager Overview الخاصة بالتطبيق، مع plugin count، وtheme count، وperformance score، وManage Updates table كلها متعبية وجاهزة.
وده هو الطريق اللي يستحق تستخدمه أول ما يبقى عندك أكتر من موقع تديره، وده بالضبط اللي لقيته واستخدمته.
من Cloudways home dashboard، الـ navigation الشمال فيه صف أيقونات: Home، وFlexible، وAutonomous، وIntegrations، وAgency Partners. ضغطت على Integrations. ده فتح panel فيها cards، منها Site Manager (وعليه “New”)، وApplication Migration، وDNS Made Easy، وCookieYes، وEqualize Digital Accessibility Checker.
الضغط على بطاقة Site Manager وداني لشاشة مختلفة تمامًا عن Path 1، شاشة موجودة تحت breadcrumb Integrations → Add-Ons → Site Manager، وليها tabs خاصة بيها: Overview، وManage Updates، وAuto Updates، وHistory.
صفحة Overview دي هي مركز التحكم الحقيقي. بتعرض stats على مستوى الحساب، Total Apps on Site Manager، وApps on Free Plan، وApps on Pro Plan، وApps with Auto Updates، وتحتها جدول Manage Applications بيعرض كل تطبيق متسجل بالفعل.
علشان أضيف غيرهم، ضغطت Add Apps to Site Manager في أعلى يمين الجدول. ده فتح wizard من خطوتين:
ملاحظة فوق القائمة كانت بتوضح إنه بيستبعد apps الـ staging، والـ apps على servers متوقفة، وأي app شغال عليه أصلًا add-on SafeUpdates القديم. علّمت على التطبيق اللي عايزه وضغطت Select Plan.
الflow كله خد أقل من دقيقة بعد ما وصلت لشاشة الـ wizard، وطبق على كل app كنت علمت عليه في الخطوة الأولى مرة واحدة، من غير ما أكرر اختيار الخطة لكل موقع.
وبعد ما سجلت تطبيقات من الطريقتين، دي كانت الملاحظة اللي غيرت طريقة تفكيري في الصيانة اليومية للمنتج ده. ضفت تطبيق WordPress تاني على server كان عليه فعلًا Site Manager بيدير تطبيق تاني على نفس الـ server.
كنت متوقع إن التطبيق الجديد يظهر تلقائي، بما إنه موجود جنب تطبيق Site Manager كان عارفة أصلًا. ما حصلش. عداد الـ account-level dashboard لـ “Total Apps on Site Manager” فضِل ثابت في مكانه لحد ما مررت التطبيق الجديد يدويًا عبر الـ onboarding.
ده قرار تصميم، لكنه قرار ليه تكلفة تشغيلية:
Site Manager متقسم إلى free tier مفيد فعلًا وPro tier بيفتح الخصائص اللي الوكالة فعلًا هتبني عليها workflow.
| Feature | Basic (Free) | Pro |
|---|---|---|
| Site Overview | Yes | Yes |
| Manage Users, Themes, Plugins | Yes | Yes |
| Quick Updates | Yes | Yes |
| WordPress Single Sign-On | Yes | Yes |
| Centralized Dashboard | Yes | Yes |
| Safe Updates (staging clone + visual regression) | No | Yes |
| Scheduled Auto Updates | No | Yes |
| Site Performance Monitoring | No | Yes |
| Activity Logs | No | Yes |
| Update History | No | Yes |
Basic مش trial متقصّف. بيشمل site overview حقيقي، والقدرة على إدارة users، وthemes، وplugins من غير لمس wp-admin، وWordPress single sign-on بضغطة واحدة، وQuick Updates، والأهم، الـ centralized dashboard نفسه.
Cloudways ماقفلتش تجربة “تشوف كل مواقعك في مكان واحد” ورا paywall. اللي متقفل هو كل حاجة بتخلي الـ dashboard ده موثوق بما يكفي إنك تعتمد عليه من غير ما تراقبه طول الوقت.
Pro حاليًا مجاني للاستخدام خلال Public Preview بغض النظر عن سعره المذكور، واللي هو $3 لكل app في الشهر، وبينزل إلى $2 لكل app لما تعدي خمسة تطبيقات.
عتبة الخصم دي تستاهل تعمل عليها حساب قبل ما تفترض إن Pro رخيص مع التوسع:
| Sites managed | Pro cost (sticker price) |
|---|---|
| 3 sites | $9/month |
| 5 sites | $10/month ($2/app) |
| 10 sites | $20/month |
| 25 sites | $50/month |
| 50 sites | $100/month |
ولا واحد من الأرقام دي غير معقول مقارنة بالمشكلة اللي ممكن update واحد بايظ من غير backup يعملها في ثقة العميل، لكن التسعير per-app معناه إن الفاتورة بتزيد بخط مستقيم مع حجم البورتفوليو، مش بخصومات قفزية زي أدوات منافسة تانية عند المستويات الأعلى.
مع تسجيل المواقع والتسعير ورا ضهرنا، بقية المراجعة بتغطي شكل الاستخدام اليومي، وده يبدأ بجزء مهم تفهمه من المعمارية.
دي أكتر نقطة في تصميم Site Manager أخدت وقت لحد ما فهمتها فعلًا، ومش متشرحة في الواجهة نفسها.
دي تلات أبواب لنفس الأوضة. عرض كل تطبيق على حدة مخصص لحد شغال جوه الموقع ده فعلًا وناوي يلاحظ تحديث معلق بالصدفة. وrow action على مستوى الحساب مخصص لحد بيراجع البورتفوليو كله وبيقرر يتصرف على موقع واحد حالًا.
تبويب الجدولة معمول علشان يشيل العنصر البشري من المعادلة بالكامل.
من التلاتة أبواب اللي فاتوا، القسم ده بيغطي أول اتنين، عرض كل تطبيق على حدة وrow action على مستوى الحساب، لأن الاتنين بيفتحوا نفس آلية التحديث.
كل plan tier بيدي Quick Update. تطبيقه بياخد ثواني: التحديث بيتثبت مباشرة على production من غير compatibility check ومن غير backup يتاخد الأول.
واجهة Cloudways نفسها صريحة بخصوص المقايضة، وبتحذر إنّه “may carry risks if updates aren’t compatible.”
أنا ماعملتش Quick Update في الاختبار ده، فمش هقدر أوصف من تجربة شخصية الشكل اللي failure بتاعه بيظهر بيه على الشاشة. دي فجوة حقيقية في المراجعة، وكنت هتعامل مع أي ادعاء بخصوص سلوك الفشل في Quick Update، مني أو من أي حد ماجربهوش، بشوية شك مناسب.
Safe Update هو الجزء اللي Pro بيستاهل سعره من خلاله، ومن المهم نمشي فيه بالتفصيل لأنه أعقد من “backup، وبعدها update.”
ودي بالضبط الطريقة اللي شغّلته بيها. من account-level Overview table تحت Integrations → Site Manager، لقيت صف التطبيق اللي عليه updates معلقة وضغطت قائمة Actions ذات الثلاث نقط في نهاية الصف. فتحت أربع اختيارات: WP-Admin، وApp Overview، وManage Updates، وManage Plan. ضغطت Manage Updates.
ده فتح modal فيه كل plugin عليه update معلق، أربعة عندي، Breeze، وElementor، وObject Cache Pro، وWP ULike، كل واحد متعلم عليه علامة صح ومعاه الإصدار الحالي والإصدار اللي هيتحدث له.
تحت القائمة كان فيه اختيارين radio: Quick Update وSafe Update، وكل واحد معاه وصف سطر واحد للمقايضة. اخترت Safe Update وضغطت Proceed.
بدل spinner واحد، النافذة اللي بتفتح بعد كده بتعرض checklist مراحل بيتحدث في الوقت الحقيقي.
Staging environment:
Production:
بدأت التشغيل الساعة 6:21 pm وخلص الساعة 6:27 pm. ست دقايق، لأربع plugins، خلال دورة كاملة من staging ثم production. الـ modal نفسه بيقول إن ده “usually takes less than a minute,” لكن التشغيل بتاعي زاد عن التقدير ده بفارق كبير.
الفجوة بين الوقت المتوقع والوقت الفعلي دي تستحق إنك تخطط ليها بدل ما تتفاجئ بيها لو بتشغل Safe Update على batch من plugins أثناء maintenance window، احسبها بدقايق، مش ثواني، خصوصًا مع زيادة عدد plugins.
إشعار نجاح أكد النتيجة، وفي اللحظة اللي خلص فيها، تبويب History على مستوى الحساب سجلها كـ “On-Demand Successful: Plugins (4)” ومعاه link للتفاصيل الكاملة.
إغلاق الحلقة ده، إنك تشوف action بيحصل وبعدها مباشرة تقدر تشير إلى سجل دائم ليه، هو بالضبط نوع الإثبات اللي الوكالة محتاجاه قدام العملاء، وSafeUpdates عمره ما كان بيديه.
الاتنين دول موجودين جوه flow الجدولة مش شاشة التحديث عند الطلب، وده بيخليهم سهل يتفوتوا:
الاتنين defaults دول مع بعض بيحددوا إذا كان تشغيل تحديثات unattended بالليل هيصحّيك على plugin واحد متعلّم عليه في queue، ولا على موقع كامل عالق في نص التحديث لأن theme غير متوافق وقف العملية كلها. يستاهل تراجع الاتنين قبل ما تثق في أي schedule يشتغل من غير مراقبة.
ده كان بيغطي البابين الأول والثاني. القسم ده بيغطي الثالث: إنك تشيل العنصر البشري من المعادلة بالكامل. تبويب Auto Updates، اللي بتوصل له من نفس صفحة Site Manager على مستوى الحساب، هو المكان اللي فيه وعد “إدارة مواقع كتير كأنهم موقع واحد” يا إما بيشتغل أو بيفشل. في حالتي، اشتغل.
ودي بالضبط الطريقة اللي ظبطته بيها. من Integrations → Site Manager، ضغطت تبويب Auto Updates في الصف العلوي.
ومع عدم وجود أي schedule متضبط، الصفحة عرضت empty state، “No Auto Updates Schedule,” مع زر واحد: Set Auto Update Schedule.
الضغط عليه فتح wizard، “Set Auto Update Schedule,” اللي مشى في الآتي في مرة واحدة:
بعدها فتحت شاشة تانية، “Create Auto Update Schedule,” بتغطي:
الضغط على Set AutoUpdate Schedule في الأسفل حفظه، وطبق على كل app كنت مختاره في الخطوة التانية، من غير الحاجة تكرر الإعداد موقع بموقع.
الأبواب التلاتة وآلية التحديث نفسها بيغطوا الـ how. الميزة الأخيرة دي بتغطي الإثبات: سجل دائم بيحكي اللي حصل، منفصل عن عملية التحديث نفسها.
ودي بالضبط الطريقة اللي فعلتها بيها.
من صفحة Site Manager Overview الخاصة بالتطبيق ده، نفس الصفحة اللي بتوصلها بعد الاشتراك من Path 1، بطاقة بعنوان “Activity Logs are Disabled” بتكون جنب performance ring، ومعاها وصف قصير وزر واحد: Enable Activity Logs.
ضغطت عليه، والبطاقة اتحدثت فورًا، من غير confirmation modal، ومن غير خطوات إضافية. ولما بصيت على account-level Manage Applications table بعدها مباشرة، عمود Activity Logs لنفس التطبيق كان بالفعل اتبدّل من Disabled إلى Enabled، من غير ما أحتاج أعيد تحميل الصفحة.
الميزة دي موجودة وراء Pro، ومهمتها تجاوب على سؤال كل وكالة في النهاية بتتسألّه من العميل: مين غيّر إيه، وإمتى؟
من غيرها، الإجابة دي غالبًا بتعيش في WordPress logging plugin شغال جوه قاعدة بيانات الموقع نفسه، وده بيكبر مع الوقت ومبيوفرش حماية من العبث. إن السجل ده يبقى عايش خارج WordPress installation نفسها، داخل طبقة الاستضافة، دي درجة مختلفة فعلًا من الثقة لأي حاجة موجهة للعميل.
مع كل الخصائص، وتكلفتها، ونقاط الضعف، السؤال الأخير ببساطة هو هل بيناسب البورتفوليو بتاعك أنت.
أوضح fit هو وكالة أو مطور مستقل بيدير كام موقع WordPress، ويفضل عدد كبير وكلهم عايشين أصلًا داخل Cloudways، حيث update بايظ ليه تكلفة حقيقية في ثقة العميل مش مجرد إزعاج شخصي.
Safe Update وbulk scheduling موجودين تحديدًا علشان يحلوا المشكلة اللي بتظهر لما تعدي النقطة اللي بعديها مراجعة كل موقع لوحده تبقى لسه معقولة.
هو fit جزئي لأي حد عنده portfolio مختلط. الـ Site Manager plugin المجاني يقدر يدخل المواقع الخارجية للمراقبة الأساسية والتحديثات، لكن الخصائص اللي بتخلي الـ native dashboard يستاهل تدفع عليه، زي Safe Update المعتمد على staging، وvisual regression، وactivity logs، بتفضل خارج المتناول لحد ما المواقع دي تنتقل فعلًا إلى Cloudways.
وهو ببساطة غير ضروري لمالك موقع واحد. الطبقة المجانية كانت هتشتغل تقنيًا، لكن المنتج كله موجود علشان يحل مشكلة portfolio-scale ومفيش موقع واحد بيخلقها.
أيوه، site manager يستاهل إنك تعتمده، بشرط واحد: مواقعك تكون أصلًا عايشة على Cloudways. جوه الحدود دي، Site Manager بيقدم اللي وعد بيه، dashboard حقيقي عبر أكتر من تطبيق، ومسار Safe Update بيعمل backup قبل ما يلمس الإنتاج، وجدولة جماعية بتتعامل مع التحديثات كإجراء على أسطول كامل بدل ما تبقى شغلانة تسجيل دخول لكل موقع.
خارج الحدود دي، هو أداة أخف ومعاها دعوة واضحة للهجرة. أفضل fit هو وكالة بتوحّد مواقع العملاء على Cloudways وعايزة مكان واحد يثبت إيه اللي اتغيّر وإمتى.
| Description | Expert Review |
|---|---|
| استضافة WordPress مُدارة بسرعة وأمان وتحديثات خالي... | Read Wordpress Hosting Review |
| استضافة سحابية مرنة عالية الأداء مع موارد قابل... | Read Cloud Hosting Review |
| استضافة بريد إلكتروني آمنة وفعّالة مصممة خصيص�... | Read Email Hosting Review |
| استضافة Magento مُحسَّنة بسرعات عالية وأداء تجارة... | Read Magento Hosting Review |
| Read WooCommerce hosting Review | |
| Read VPS Hosting Review |
أيوه. Cloudways Site Manager هو إضافة أصلية بتجمع التحديثات، ومراقبة الأداء، وسجلات النشاط لتطبيقات WordPress الموجودة بالفعل داخل حساب Cloudways بتاعك. إضافة مجانية مرافقة منفصلة بتوسّع إمكانيات المراقبة الخفيفة والتحديث لمواقع WordPress المستضافة في أي مكان.
مش من خلال الداشبورد الأصلي اللي اتجرب في الريڤيو ده، لأنه محدود بالتطبيقات المستضافة بالفعل على Cloudways. إضافة مجانية، برضه اسمها Cloudways Site Manager ومتطورة بالتعاون مع WP Remote، ممكن تضيف مواقع خارجية علشان تراقب الكور والبلجنز والثيمات وتعمل لها تحديثات، لكن من غير staging clone بتاع Safe Update، ولا visual regression testing، ولا server-level caching.
الـ Basic tier مجاني وبيغطي نظرة عامة على الموقع، إدارة المستخدمين والإضافات، وQuick Updates. Pro بيضيف Safe Updates، الجدولة، مراقبة الأداء، وسجلات النشاط مقابل 3 دولارات لكل تطبيق شهريًا، وبتنزل لـ 2 دولار عند خمسة تطبيقات أو أكتر، وهو حاليًا مجاني للاستخدام خلال الـ Public Preview.
التحديث السريع بيطبق التغييرات مباشرة على الإنتاج في ثواني من غير أي نسخة احتياطية أو فحص للتوافق. التحديث الآمن بيعمل نسخة staging، وبيفحص التوافق، وبيحدث كل باكدج، وبيشغل اختبار visual regression، وبيوصل للإنتاج بس لو الاختبار ده نجح.
أيوه. التطبيقات الجديدة عمرها ما بتتسجل تلقائي، حتى لو اتضافت على سيرفر عليه بالفعل تطبيقات Site Manager تانية شغالة عليه. كل موقع لازم ليه خطوة onboarding خاصة بيه، يا إما بشكل فردي أو من خلال المعالج الجماعي تحت Integrations.
أجب على بعض الأسئلة البسيطة وابحث عن الحل المثالي لك!
بدء البحث في الاستضافة
يقدم HostAdvice.com مراجعات وتقييمات احترافية بخدمات استضافة مواقع الانترنت مستقلة تماما عن أي جهة أو كيان آخر. تقييماتنا عادلة وأمينة وتطبق نفس معايير التقييم على كل المراجعات التي تتم.
يتم استلام تعويض نقدي من الشركات التي نقوم بتقييمها. تعويض الخدمات والمنتجات ليس له تأثير على توجه أو استنتاجات تقييماتنا. ولا تؤثر هذه التعويضات على ترتيبنا لشركات استضافة المواقع المحددة.
تغطي هذه التعويضات تكاليف الإنفاق على المراجعين، شراء الحسابات، والاختبار.
