Я подключил два приложения WordPress к Cloudways Site Manager для этого обзора: одно — через экран onboarding, спрятанный в боковой панели самого приложения, другое — через массовый процесс, который находится на уровне аккаунта.

После этого я выполнил реальный Safe Update для четырёх плагинов, создал общий график автообновлений, охватывающий оба сайта, включил журналирование активности и провёл достаточно времени в панели на уровне аккаунта, чтобы понять, где одна и та же информация появляется в нескольких местах и почему это важнее, чем кажется.

Cloudways

Управляйте размещёнными на Cloudways WordPress-приложениями с централизованными обновлениями, Safe Updates, журналами активности и планированием для всего портфеля.

Cloudways

Что такое Cloudways Site Manager?

Site Manager заменил старый дополнительный сервис Cloudways под названием SafeUpdates. Понимание того, чего SafeUpdates не мог делать, объясняет почти каждое дизайнерское решение в текущем продукте.

SafeUpdates выполнял всё по SSH, что создавало вполне определённый набор проблем для любого, кто управлял более чем парой сайтов:

• Нет панели, а значит, нет способа увидеть, какие сайты требуют внимания, не проверяя каждый по отдельности
• Обновления жёстко привязаны к фиксированному недельному расписанию, независимо от того, нужен ли клиенту ежедневный патчинг или ежемесячное обслуживание
• Визуальное регрессионное тестирование ограничено тремя страницами на настольном компьютере на сайт — слишком слабое покрытие для чего угодно, кроме сайта-визитки
• Нет журнала аудита, показывающего, что изменилось, когда и кто внёс изменение

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

Site Manager — прямой ответ на эту обратную связь. Этот контекст важен для восприятия остального обзора, потому что он объясняет, почему некоторые части продукта кажутся необычно зрелыми для решения, которое всё ещё находится в Public Preview, и почему другие части, например шаг onboarding, с которым вы столкнётесь в первый день, всё ещё выглядят как неидеально скрытые швы.

Что умеет Cloudways Site Manager?

С учётом этого фона следующий вопрос — это охват: что именно этот инструмент может контролировать. Прежде чем переходить к onboarding, обновлениям и планированию, стоит точно определить, что Site Manager покрывает, а что нет, потому что честный ответ здесь сложнее простого «да» или «нет».

Нативная панель доступна только для Cloudways

Каждое приложение, доступное для подключения в Site Manager на уровне аккаунта, будь то через экран внутри приложения или через массовый мастер в разделе Integrations, находилось на сервере, уже размещённом в моём аккаунте Cloudways.

Там не было поля, куда можно вставить учётные данные для установки, размещённой на внешнем хостинге, и не было коннектора для сайта на совершенно другом провайдере.

Полный набор функций, рассмотренных в этом обзоре, Safe Update с клонированием staging, визуальное регрессионное тестирование, журналы активности, массовое планирование — всё это находится внутри этого нативного слоя, размещённого на Cloudways.

Отдельный плагин расширяет облегчённый мониторинг на любой сайт

Cloudways также выпускает бесплатный плагин WordPress, тоже под названием Cloudways Site Manager, созданный совместно с WP Remote.

В отличие от нативной панели, этот плагин устанавливается прямо на сайт WordPress независимо от того, где он размещён, а значит, может подключить внешний сайт, не размещённый на Cloudways, к версии того же централизованного просмотра.

Однако это действительно другой продукт, и разница между ними важна:

Плагин также отключает встроенные автоматические обновления WordPress, пока активен, — это сознательное решение Cloudways, чтобы избежать конфликтов при удалённом управлении.

Cloudways прямо говорит, что вариант с плагином — это ступенька, а не конечная точка: если вам нужен полный стек, автоматические резервные копии, staging в один клик, интеграция с Cloudflare, управляемый кэшинг, рекомендуемая лучшая практика — перенести внешний сайт на Cloudways, а не управлять им удалённо в долгосрочной перспективе.

Для агентства, у которого весь портфель уже размещён на Cloudways, всё это неважно. Для всех, кто всё ещё держит несколько сайтов где-то ещё, а за годы общения я встречал немало агентств, у которых как минимум несколько сайтов находятся на разных платформах, плагин — это реальный вариант для базового мониторинга и обновлений, но не замена тому, что делает нативная панель.

Cloudways

Управляйте размещёнными на Cloudways WordPress-приложениями с централизованными обновлениями, 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 — настоящий центр управления. Она показывает общие для аккаунта показатели: Total Apps on Site Manager, Apps on Free Plan, Apps on Pro Plan, Apps with 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” вообще не изменился, пока я вручную не провёл новое приложение через onboarding.

Это дизайн-решение, но такое решение имеет операционную цену:

• Для фрилансера с тремя или четырьмя сайтами помнить о подключении нового сайта — пустяк.
• Для агентства, которое каждую неделю или раз в две недели разворачивает новый сайт для клиента, это превращается в постоянный пункт чьего-то чек-листа.
• Пропустите один раз — и этот сайт окажется вне вашего мониторинга, вне массовых обновлений и вне журналов активности, невидимым для панели, которая должна быть вашим единым источником истины.

Cloudways

Управляйте размещёнными на Cloudways WordPress-приложениями с централизованными обновлениями, Safe Updates, журналами активности и планированием для всего портфеля.

Cloudways

За что вы на самом деле платите

Site Manager разделён на действительно полезный бесплатный тариф и Pro-тариф, который открывает функции, вокруг которых агентство и правда будет выстраивать рабочий процесс.

Basic против Pro, по функциям

Basic — это не урезанная пробная версия. В него входят полноценный обзор сайта, возможность управлять пользователями, темами и плагинами без захода в wp-admin, вход WordPress single sign-on в один клик, Quick Updates и, что особенно важно, сама централизованная панель.

Cloudways не спрятал базовый опыт «видеть все свои сайты в одном месте» за платным доступом. За платной стеной находятся все функции, которые делают эту панель достаточно надёжной, чтобы действовать через неё без постоянного контроля.

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

Сколько Pro реально стоит по мере роста портфеля

Эту скидку стоит просчитать заранее, прежде чем думать, что Pro дешево масштабируется:

Ни одна из этих цифр не выглядит чрезмерной по сравнению с тем, сколько может стоить один сломанный и незащищённый бэкапами update в доверии клиента, но почасовая модель тарификации означает, что счёт растёт линейно вместе с вашим портфелем, а не скачкообразно, как у некоторых конкурирующих инструментов на более высоких уровнях.

Три способа запустить одно и то же обновление

С вопросами подключения и цены разобрались, теперь остальная часть обзора посвящена тому, как это выглядит в повседневном использовании, начиная со схемы, которую важно понимать.

Эта часть дизайна Site Manager заняла у меня больше всего времени, чтобы действительно разобраться, и в самом интерфейсе это нигде не объясняется.

• Страница Overview самого приложения по-прежнему показывает собственную таблицу Manage Updates со всеми ожидающими обновлениями плагинов, которые вы увидели бы и в панели на уровне аккаунта.
• Меню Actions на уровне аккаунта в строке предлагает собственное действие Manage Updates, используя те же самые базовые данные.
• Вкладка Auto Updates позволяет запланировать такие же обновления для автоматического запуска для одного приложения или сразу для всех подключённых приложений.

Это три двери в одну и ту же комнату. Представление на уровне приложения предназначено для того, кто уже работает внутри конкретного сайта и вдруг замечает ожидающее обновление. Действие в строке на уровне аккаунта — для того, кто просматривает весь портфель и решает, что сейчас нужно обновить один сайт.

Вкладка планирования нужна для того, чтобы вообще убрать человека из цикла.

Quick Update против Safe Update

Из трёх описанных дверей этот раздел покрывает первые две — вид на уровне приложения и действие в строке на уровне аккаунта, поскольку оба открывают один и тот же механизм обновления.

Каждый тариф предлагает Quick Update. Его применение занимает секунды: обновление устанавливается прямо в production без проверки совместимости и без предварительного создания резервной копии.

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

Я не запускал Quick Update в этом тесте, поэтому не могу из личного опыта описать, как выглядит его сбой на экране. Это реальный пробел в этом обзоре, и любые утверждения о поведении Quick Update при ошибке, как от меня, так и от любого другого человека, который не вызывал такой сбой, я бы воспринимал с должной осторожностью.

Safe Update — это та функция, ради которой оправдан переход на Pro, и её стоит разобрать полностью, потому что процесс гораздо сложнее, чем просто «сделать бэкап, а потом обновить».

Как выглядит запуск 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 environment:

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

Production:

• Идентичная последовательность повторяется после успешного прохождения staging, завершаясь одной финальной очисткой кэша

Я запустил процесс в 6:21 pm, а завершился он в 6:27 pm. Шесть минут на четыре плагина, на полный цикл staging, а затем production. Само окно обещает, что это “usually takes less than a minute,” — мой запуск превысил эту оценку заметно.

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

Уведомление об успехе подтвердило результат, и в тот момент, когда всё завершилось, вкладка History на уровне аккаунта зафиксировала это как “On-Demand Successful: Plugins (4)” со ссылкой на полные детали.

Это завершение цикла — видеть, как действие происходит, и сразу же иметь возможность указать на постоянную запись о нём — именно тот уровень подтверждения, который нужен агентству для клиента, а SafeUpdates этого никогда не давал.

Две настройки, которые определяют, насколько снисходительными будут обновления

Обе они находятся внутри процесса планирования, а не на экране разового обновления, поэтому их легко пропустить:

• Visual Regression Sensitivity определяет, насколько большое визуальное различие между тестом на staging и production допускается, прежде чем обновление будет отменено для защиты макета. По умолчанию используется самый строгий доступный вариант — “Critical, 0% difference.”
• Smart Skip for Plugin/Theme Update Failures, включённый по умолчанию, означает, что сбой обновления одного плагина не останавливает весь пакет. Система откладывает только этот один элемент, обновляет всё остальное, выполняет проверку визуальной регрессии для того, что прошло успешно, и автоматически выводит эти изменения в production.

Вместе эти две настройки определяют, проснётесь ли вы после ночного безнадзорного запуска с одним помеченным плагином в очереди или с целым сайтом, застрявшим посреди обновления из-за одного несовместимого шаблона, который остановил весь процесс. Перед тем как доверять расписанию ночной запуск, стоит проверить обе настройки.

Cloudways

Управляйте размещёнными на Cloudways WordPress-приложениями с централизованными обновлениями, 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 and 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

Управляйте размещёнными на Cloudways WordPress-приложениями с централизованными обновлениями, Safe Updates, журналами активности и планированием для всего портфеля.

Cloudways

Плюсы и минусы

Для кого это на самом деле

Когда весь набор функций, его стоимость и слабые места уже на столе, остаётся только вопрос: подходит ли это именно вашему портфелю.

Самое очевидное соответствие — это агентство или независимый разработчик, управляющий несколькими, а в идеале многими сайтами WordPress, которые уже полностью живут внутри Cloudways, где сломанное обновление несёт реальную цену в виде доверия клиента, а не просто личного неудобства.

Safe Update и массовое планирование созданы именно для того, чтобы решать проблему, которая появляется, когда проверять каждый сайт по отдельности уже становится неразумно.

Это частичное решение для тех, у кого смешанный портфель. Бесплатный плагин Site Manager может подключать внешние сайты для базового мониторинга и обновлений, но функции, ради которых нативная панель вообще стоит оплаты — staging-ориентированный Safe Update, визуальная регрессия, журналы активности, — остаются недоступными, пока эти сайты не будут перенесены на Cloudways.

Для владельца одного сайта это просто не нужно. Бесплатный тариф технически подойдёт, но весь продукт существует для решения задачи на уровне портфеля, которую один сайт никогда не создаёт.

Итог: стоит того, но только внутри Cloudways

Да, Site Manager стоит использовать, но при одном условии: ваши сайты уже размещены на Cloudways. В этих рамках Site Manager выполняет то, что обещает: настоящую панель для всех приложений, путь Safe Update, который делает резервную копию до прикосновения к production, и массовое планирование, которое рассматривает обновления как действие для всего флота, а не как рутину по одному входу в систему.

За этими рамками это более лёгкий инструмент с явным намёком на миграцию. Лучше всего он подходит агентству, которое консолидирует клиентские сайты на Cloudways и которому нужно одно место, чтобы подтверждать, что и когда изменилось.

Cloudways

4.6

537 user reviews

950 руб. /mo

Цена от

Cloudways

Рейтинг на основе мнений экспертов

• Удобство
  4.5
• Техподдержка
  4.6
• Возможности
  4.8
• Надежность
  4.8
• Цены
  4.3