Записах две WordPress приложения в Cloudways Site Manager за този преглед, едното чрез onboarding екрана, скрит в страничната лента на самото приложение, другото чрез груповия поток, който се намира на ниво акаунт.

Оттам нататък проведох реален Safe Update на четири плъгина, изградих общ график за автоматични обновявания, обхващащ и двата сайта, включих activity logging и прекарах достатъчно време в dashboard-а на ниво акаунт, за да разбера къде една и съща информация се появява на повече от едно място и защо това е по-важно, отколкото изглежда.

Cloudways

Управлявайте WordPress приложения, хоствани в Cloudways, с централизирани обновявания, Safe Updates, activity logs и планиране за цялото портфолио.

Посетете Cloudways

Какво е Cloudways Site Manager?

Site Manager замени по-стар add-on на Cloudways, наречен SafeUpdates. Разбирането какво SafeUpdates не можеше да прави обяснява почти всяко дизайнерско решение в текущия продукт.

SafeUpdates изпълняваше всичко през SSH, което създаваше специфичен набор от проблеми за всеки, който управлява повече от няколко сайта:

• Няма dashboard, така че няма начин да видите кои сайтове се нуждаят от внимание, без да проверявате всеки поотделно
• Обновяванията са заключени към фиксиран седмичен график, независимо дали клиентът се нуждае от ежедневно пачване или месечна поддръжка
• Визуалното regression testing е ограничено до три desktop страници на сайт, твърде слабо покритие за всичко извън brochure сайт
• Няма audit trail, който да показва какво се е променило, кога или кой е направил промяната

Агенции, управляващи двадесет или повече WordPress инсталации, казаха на Cloudways, по същество, че инструментът работи, докато не работи, а мащабирането беше самата причина те да са на Cloudways.

Site Manager е пряк отговор на този feedback. Този контекст е важен за четенето на останалата част от този преглед, защото обяснява защо някои части на продукта изглеждат необичайно зрели за нещо, което все още е в Public Preview, и защо други части, като onboarding стъпката, с която ще се сблъскате в първия ден, все още показват шевовете.

Какво може да прави Cloudways Site Manager?

С този фон на място следващият въпрос е обхватът: до какво всъщност достига този инструмент. Преди да преминем към onboarding, обновяванията и планирането, си струва да бъдем точни за това какво покрива Site Manager и какво не, защото честният отговор е по-нюансиран от плоско да или не.

Нативният dashboard е само за Cloudways

Всяко приложение, достъпно за записване в account-level Site Manager, независимо дали чрез екрана за отделното приложение или чрез bulk wizard-а под Integrations, идваше от сървър, който вече се намираше в моя Cloudways акаунт.

Нямаше поле, в което да поставите credentials за външно хоствана инсталация, нито connector за сайт, работещ изцяло на друг хост.

Пълният набор от функции, покрити в този преглед, Safe Update staging clone, visual regression testing, activity logs, bulk scheduling, всичко това живее в този нативен, хостван от Cloudways слой.

Отделен плъгин разширява по-лекото наблюдение към всеки сайт

Cloudways също публикува безплатен WordPress плъгин, също наречен Cloudways Site Manager, разработен съвместно с WP Remote.

За разлика от нативния dashboard, този плъгин се инсталира директно на WordPress сайт, независимо къде е хостван, което означава, че може да включи външен, нехостван в Cloudways сайт в версия на същия централен изглед.

Това е наистина различен продукт от нативния dashboard, обаче, и разликата между двата има значение:

Плъгинът също така деактивира автоматичните обновявания на WordPress, докато е активен, умишлен избор от страна на Cloudways, за да се избегнат конфликти при remote управление.

Cloudways е откровен, че пътят през плъгина е междинна стъпка, а не крайната цел: ако искате пълния stack, автоматизирани backups, staging с едно кликване, Cloudflare интеграция, управлявано caching, заявената добра практика е да мигрирате външния сайт към Cloudways, вместо да го управлявате дистанционно дългосрочно.

За агенция с изцяло Cloudways-хоствано портфолио нищо от това няма значение. За всеки, който все още управлява шепа сайтове другаде, а и повечето агенции, с които съм разговарял през годините, имат поне няколко, плъгинът е реална опция за базово наблюдение и обновявания, просто не е заместител на това, което прави нативният dashboard.

Cloudways

Управлявайте WordPress приложения, хоствани в Cloudways, с централизирани обновявания, Safe Updates, activity logs и планиране за цялото портфолио.

Посетете Cloudways

Начало: Два начина за onboarding на сайтове

С въпроса за обхвата изяснен, практическата част започва тук: действително записване на WordPress приложение. Cloudways дава два начина за влизане в нативния Site Manager, и те не са еднакво подходящи за задачата.

Път 1: през страничната лента на самото приложение

Ето точно как стигнах дотам първия път. От Cloudways home dashboard-а кликнах в сървъра си, след това в WordPress приложението, което се намира върху него, което ви отвежда на страницата Access Details на това приложение.

Лявата странична лента там изброява Access Details, Staging Management, Monitoring, Application Security, Domain Management и след това Site Manager, отбелязан с етикет “New”. Кликването върху него ме отведе директно до екран, озаглавен “Simplify App Management with Site Manager,” изцяло обхващащ само това едно приложение, с две plan карти една до друга, Basic и Pro.

Кликнах Get Pro. Тогава нещата се объркаха.

Екранът се промени на “Subscribing to the Site Manager Plan…” с съобщение, обясняващо, че Cloudways инсталира плъгина и синхронизира данните на сайта ми, и че това може да отнеме няколко минути в зависимост от размера на приложението.

Това работи около две минути и след това се провали, връщайки червено error известие: “Please delete existing plugin and install again.” Нямах предишна инсталация, която да изтрия, така че самото съобщение не ми каза какво всъщност е станало погрешно.

Кликнах Get Pro за втори път, на същия screen за plan, без да променям нищо. Този опит проработи. Работи около три минути и завърши със зелено success известие, потвърждаващо, че съм се абонирал за Site Manager plan-а, и ме отведе до Site Manager Overview page на приложението, plugin count, theme count, performance score и Manage Updates table, всичко попълнено и готово.

Път 2: през dashboard-а на ниво акаунт

Това е пътят, който си струва да използвате в момента, в който имате повече от един сайт за управление, и ето точно как го открих и използвах.

От Cloudways home dashboard-а лявата навигация има ред икони: Home, Flexible, Autonomous, Integrations и Agency Partners. Кликнах Integrations. Това отвори панел с карти, Site Manager (отбелязан с “New”), Application Migration, DNS Made Easy, CookieYes и Equalize Digital Accessibility Checker сред тях.

Кликването върху картата Site Manager ме отведе до съвсем различен екран от Path 1, такъв, който живее под breadcrumb-а Integrations → Add-Ons → Site Manager, със собствен ред от табове: Overview, Manage Updates, Auto Updates, History.

Тази Overview страница е истинският command center. Тя показва account-wide 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 с две стъпки:

1. Select Application(s): checklist на всяко WordPress приложение в моя акаунт, което още не е включено, със Select All опция и поле за търсене.

Бележка над списъка обясняваше, че изключва staging приложения, приложения на спрени сървъри и всяко приложение, което вече работи със стария SafeUpdates add-on. Маркирах приложението, което исках, и кликнах Select Plan.

2. Select your Plan: Basic и Pro, показани един до друг отново, този път потвърждавайки колко приложения бях избрал и общата месечна цена за този batch. Избрах Pro и кликнах Enable Site Manager.

Целият поток отне под минута, след като бях на екрана на wizard-а, и се приложи към всички приложения, които бях избрал в стъпка едно, наведнъж, без да повтарям избора на plan за всеки сайт.

Пропастта, за която никой не ви предупреждава

След като вече записах приложения чрез двата пътя, ето находката, която промени начина, по който мисля за ежедневната поддръжка на този продукт. Добавих второ WordPress приложение към сървър, който вече имаше Site Manager, управляващ активно друго приложение на същия сървър.

Очаквах новото приложение да се появи автоматично, тъй като стоеше точно до приложение, което Site Manager вече познаваше. Не се появи. Броячът “Total Apps on Site Manager” на dashboard-а на ниво акаунт остана точно там, където беше, докато не преминах ръчно новото приложение през onboarding-а.

Това е дизайнерско решение, но е дизайнерско решение с оперативна цена:

• За freelancer с три или четири сайта е тривиално да запомни да onboard-не нов такъв.
• За агенция, която пуска нов клиентски сайт всяка седмица или две, това се превръща в постоянна линия в нечий checklist, завинаги.
• Пропуснете ли го веднъж, този сайт остава извън вашето наблюдение, вашите bulk updates и вашите activity logs, невидим за dashboard-а, който трябва да бъде единственият източник на истина.

Cloudways

Управлявайте WordPress приложения, хоствани в Cloudways, с централизирани обновявания, Safe Updates, activity logs и планиране за цялото портфолио.

Посетете Cloudways

За какво всъщност плащате

Site Manager се разделя на наистина използваем безплатен tier и Pro tier, който отключва функциите, върху които една агенция наистина би изградила workflow.

Basic срещу Pro, функция по функция

Basic не е орязан trial. Той включва реален site overview, възможност да управлявате users, themes и plugins без да отваряте wp-admin, one-click WordPress single sign-on, Quick Updates и, забележително, самия централен dashboard.

Cloudways не заключи основното преживяване “виж всички сайтове на едно място” зад paywall. Зад paywall са заключени всичко, което прави този dashboard достатъчно надежден, за да действате без да го наблюдавате постоянно.

Pro в момента е безплатен за използване по време на Public Preview, независимо от обявената му цена, която е $3 на приложение на месец, падаща до $2 на приложение, след като преминете пет приложения.

Какво всъщност струва Pro с растежа на портфолиото

Този праг на отстъпката си струва да се пресметне, преди да приемете, че Pro мащабира евтино:

Нито една от тези суми не е неразумна на фона на това колко може да струва едно счупено, непокрито обновяване по отношение на доверието на клиента, но per-app ценообразуването означава, че сметката расте по права линия с портфолиото ви, а не по стъпковия модел на отстъпки, който някои конкуренти предлагат при по-високи tier-ове.

Три места, от които да задействате едно и също обновяване

С onboarding-а и ценообразуването зад гърба ни, останалата част от този преглед обхваща как всъщност изглежда ежедневната работа, започвайки с една архитектурна подробност, която си струва да се разбере.

Това е частта от дизайна на Site Manager, която ми отне най-много време, за да работи наистина, и тя не е обяснена никъде в самия интерфейс.

• Собствената Overview страница на приложението все още показва своя собствен Manage Updates table, изброявайки същите чакащи plugin обновявания, които бихте видели от dashboard-а на ниво акаунт.
• Row-level Actions менюто на account-level dashboard-а предлага собствено действие Manage Updates, като черпи от същите основни данни.
• Tab-ът Auto Updates позволява да насрочите същия тип обновяване да се изпълнява автоматично, за едно приложение или за всяко включено приложение наведнъж.

Това са три врати към една и съща стая. Изгледът на отделното приложение е за някой, който вече работи в конкретния сайт и случайно забелязва чакащо обновяване. Row-level action-ът на account-level е за някой, който преглежда целия портфолио и решава да действа веднага върху един сайт.

Scheduling tab-ът е за премахване на човека от цикъла изцяло.

Quick Update срещу Safe Update

От трите врати, описани току-що, този раздел обхваща първите две, изгледа на отделното приложение и row-level action-а на ниво акаунт, тъй като и двата отварят един и същ update механизъм.

Всеки plan tier предлага Quick Update. Прилагането му отнема секунди: update-ът се инсталира директно в production без проверка за съвместимост и без да се прави backup предварително.

Собственият интерфейс на Cloudways е честен за компромиса, предупреждавайки, че той “may carry risks if updates aren’t compatible.”

Не тествах Quick Update в това проучване, така че не мога от първа ръка да опиша как изглежда едно неуспешно изпълнение на екрана. Това е реална празнина в този преглед и бих третирал всяко твърдение за поведението при failure на Quick Update, от мен или от който и да е друг, който не го е задействал, с подходящ скептицизъм.

Safe Update е мястото, където Pro оправдава цената си, и си струва да го разгледаме в пълни подробности, защото процесът е по-сложен от “backup, then update.”

Как всъщност изглежда един Safe Update run

Ето точно как го задействах. От table-а Overview на ниво акаунт под Integrations → Site Manager открих реда за приложението с чакащи обновявания и кликнах триточковото меню Actions в края на този ред. То отвори четири опции: WP-Admin, App Overview, Manage Updates и Manage Plan. Кликнах Manage Updates.

Това отвори modal, изброяващ всеки plugin с чакащо обновяване, четири в моя случай, Breeze, Elementor, Object Cache Pro и WP ULike, всеки показан като маркиран елемент с текущата му версия и версията, до която ще бъде обновен.

Под списъка имаше две radio опции: Quick Update и Safe Update, всяка с едноредово описание на компромиса. Избрах Safe Update и кликнах Proceed.

Вместо един единствен progress spinner, следващият modal показва staged checklist, който се обновява в реално време.

Staging environment:

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

Production:

• Идентичната последователност се повтаря, след като staging мине успешно, завършвайки с едно последно purge на cache

Започнах run-а в 6:21 pm и той завърши в 6:27 pm. Шест минути, за четири плъгина, през пълен staging-then-production цикъл. Самият modal задава очакването, че това “usually takes less than a minute,” а моят run надхвърли това с голяма разлика.

Тази разлика между посочената оценка и реалното време си струва да се планира, вместо да ви изненадва, ако пускате Safe Update върху batch от плъгини по време на maintenance прозорец, планирайте минути, не секунди, особено когато броят на плъгините расте.

Съобщение за success потвърди резултата и в момента, в който приключи, History tab-ът на ниво акаунт го записа като “On-Demand Successful: Plugins (4)” с връзка към пълните детайли.

Това затваряне на цикъла, да видите как едно действие се случва и веднага след това да можете да посочите постоянен запис за него, е точно от този вид доказателство, от което една агенция се нуждае пред клиента, а SafeUpdates никога не им го даде.

Двете настройки, които решават колко forgiving са обновяванията

И двете живеят в потока за планиране, а не в екрана за on-demand обновяване, което ги прави лесни за пропускане:

• Visual Regression Sensitivity контролира колко голяма визуална разлика между staging теста и production се допуска, преди обновяването да бъде прекратено, за да защити оформлението ви. По подразбиране е зададена най-строгата налична настройка, “Critical, 0% difference.”
• Smart Skip for Plugin/Theme Update Failures, включена по подразбиране, означава, че един плъгин, който не успее да се обнови, не спира целия batch. Системата оставя този един елемент настрана, обновява всичко останало, изпълнява visual regression check върху това, което е успяло, и автоматично пуска тези промени в production.

Заедно тези две настройки решават дали един unattended overnight update run ще ви събуди с един маркиран плъгин, останал на опашка, или с целия сайт, заседнал по средата на обновяването, защото една несъвместима тема е спряла целия процес. Струва си да ги проверите и двете, преди да се доверите на график да работи без надзор.

Cloudways

Управлявайте WordPress приложения, хоствани в Cloudways, с централизирани обновявания, Safe Updates, activity logs и планиране за цялото портфолио.

Посетете Cloudways

Планиране на обновяванията през цялото портфолио наведнъж

Това покрива първите две врати. Този раздел покрива третата: премахване на човека от цикъла изцяло. Auto Updates tab-ът, достъпен от същата account-level Site Manager страница, е мястото, където pitch-ът “manage many sites like they’re one” или работи, или се разпада. В моя случай работи.

Ето точно как го настроих. От Integrations → Site Manager кликнах tab-а Auto Updates в горния ред.

При липса на насрочено нещо, страницата показваше празно състояние, “No Auto Updates Schedule,” с един единствен бутон: Set Auto Update Schedule.

Кликването върху него отвори wizard, “Set Auto Update Schedule,” който преминаваше през следното на един ход:

1. Day of Week and Schedule Time: два dropdown-а, плюс timezone selector до полето за време. Зададох Friday, между midnight и 5:59am UTC.

2. Select Application: checklist на всяко приложение, вече включено в Site Manager, със Select All опция и бележка, че всяка съществуваща schedule, вече зададена за избрано приложение, ще бъде заменена от тази нова. Избрах и двете си приложения и кликнах Choose Preferences.

Друг screen след това се отвори, “Create Auto Update Schedule,” обхващащ:

3. Configure Update List: три разгъваеми секции, WordPress Core, Plugins и Themes, всяка със собствен checklist и брояч в реално време колко са избрани. Между двете ми приложения имаше на разположение десет плъгина и четири теми за включване, и всеки отделен plugin и theme показваше точно в колко от приложенията ми се използва, малка подробност, която има огромно значение, щом управлявате десетки сайтове и се опитвате да разберете кои обновявания си струва да се тестват широко и кои засягат само един сайт.

4. Update Type: dropdown, предлагащ Quick Update или Safe Update, всеки със същото описание, показано в on-demand modal-а. Изборът на Safe Update разкриваше два допълнителни control-а, които се появяват само за този mode, Visual Regression Sensitivity и Smart Skip for Plugin/Theme Update Failures.

5. Critical Updates: toggle, изключен по подразбиране, запазен специално за изпращане на security-driven patch извън нормалния график в момента, в който бъде отбелязана уязвимост.

Кликването на Set AutoUpdate Schedule в долната част запази настройката, приложена към всяко приложение, което бях избрал в стъпка две, без нужда да повтарям конфигурацията поотделно за всеки сайт.

Activity Logs: Частта, която всъщност е за доверието на клиента

Трите врати и механизмите за обновяване зад тях обясняват как. Тази последна функция обяснява доказателството: постоянен запис за това какво се е случило, отделно от самия процес на обновяване.

Ето точно как я включих.

От собствената Site Manager Overview page на това приложение, същата, на която попадате след абонамент през Path 1, до performance ring-а има карта, озаглавена “Activity Logs are Disabled”, с кратко описание и един-единствен бутон: Enable Activity Logs.

Кликнах върху него и картата се обнови веднага, без потвърждаващ modal, без допълнителни стъпки. Проверявайки immediately account-level Manage Applications table-а след това, под Integrations → Site Manager, колоната Activity Logs за това приложение вече беше сменена от Disabled на Enabled, без да е нужно да презареждам страницата.

Тази функция е зад Pro и съществува, за да отговори на въпрос, който всяка агенция в крайна сметка получава от клиент: кой какво промени и кога?

Без нея този отговор обикновено живее в WordPress logging плъгин, записващ в собствената база данни на сайта, което с времето я натоварва и не предлага защита срещу манипулация. Да имате този запис извън WordPress инсталацията, в самия hosting слой, е значимо различно ниво на trust за всичко, ориентирано към клиенти.

Cloudways

Управлявайте WordPress приложения, хоствани в Cloudways, с централизирани обновявания, Safe Updates, activity logs и планиране за цялото портфолио.

Посетете Cloudways

Плюсове и минуси

За кого всъщност е това

След като всички функции, разходи и груби ръбове са на масата, последният въпрос е просто дали това пасва на вашето конкретно портфолио.

Най-ясното приложение е за агенция или freelance developer, който управлява няколко, идеално много, WordPress сайта и които вече живеят изцяло в Cloudways, където счупено обновяване носи реална цена по отношение на доверието на клиента, а не просто лично неудобство.

Safe Update workflow-ът и bulk планирането съществуват именно, за да решат проблема, който се появява, когато вече не е разумно да проверявате всеки сайт поотделно.

Това е частично подходящо за всеки с mixed portfolio. Безплатният Site Manager плъгин може да включи външни сайтове за базово наблюдение и обновявания, но функциите, които правят нативния dashboard достатъчно ценен, staging-базиран Safe Update, visual regression, activity logs, остават недостъпни, докато тези сайтове не се преместят действително в Cloudways.

Това просто е ненужно за собственик на един сайт. Безплатният tier технически би работил, но целият продукт съществува, за да реши проблем на ниво портфолио, който един сайт никога не създава.

Заключение: Струва си, но само в Cloudways

Да, site manager-ът си струва да бъде възприет, при едно условие: сайтовете ви вече да живеят в Cloudways. В рамките на тази граница Site Manager доставя това, което обещава, реален cross-app dashboard, Safe Update път, който прави backup преди да докосне production, и bulk планиране, което третира обновяванията като fleet-wide действие, а не като задача поотделно за всяко влизане.

Извън тази граница това е по-лек инструмент с ясно прикрепен подтик към миграция. Най-доброто приложение е агенция, която консолидира клиентски сайтове в Cloudways и има нужда от едно място, където да докаже какво се е променило и кога.

Cloudways

4.6

537 user reviews

9,46 € /mo

Начална цена

Посетете Cloudways

Rating based on expert review

• Удобен за потребителя
  4.5
• Поддръжка
  4.6
• Опции
  4.8
• Надеждност
  4.8
• Цени
  4.3