Тестовая копия сайта на WordPress (staging) — это закрытый от посетителей и поисковиков дубль рабочего сайта, на котором сначала ставят обновления плагинов, темы и ядра. Если после обновления копия работает, ту же операцию повторяют на рабочем сайте. Если что-то сломалось, страдает только копия, а клиенты и заявки не замечают проблемы.
Типичная картина у компаний, которые приходят к нам с сайтом на WordPress, такая: в панели висит 15-20 обновлений, их боятся нажимать, потому что прошлый раз после кнопки «Обновить все» пропала форма заявки или лег весь сайт. В итоге обновления копятся месяцами, а вместе с ними копятся закрытые разработчиками уязвимости. Тестовая копия решает обе проблемы: обновлять можно регулярно и без риска потерять день продаж.
Что такое staging WordPress и чем он отличается от резервной копии
Staging WordPress — это работающий сайт, а резервная копия — это архив, который нужно еще развернуть. Из бэкапа сайт возвращают после поломки, а на копии поломку ловят заранее. Нужно и то и другое: перед любым обновлением рабочего сайта сама документация WordPress советует сделать резервную копию, а подробно о том, как настроить копирование, мы писали в статье о резервном копировании WordPress.
У тестовой копии три обязательных свойства:
- она живет на отдельном адресе, например staging.example.kz или в подпапке, и не мешает рабочему домену;
- на ней те же версии PHP, темы и плагинов, что и на рабочем сайте, иначе проверка ничего не докажет;
- она закрыта паролем, чтобы ее не нашли поисковики и случайные посетители.
В самом WordPress с версии 5.5 есть понятие типа окружения. Это константа WP_ENVIRONMENT_TYPE в файле wp-config.php, и по описанию функции wp_get_environment_type в справочнике разработчика WordPress она принимает значения local, development, staging и production. Если константа не задана, сайт считается рабочим (production). На тестовой копии стоит прописать define( 'WP_ENVIRONMENT_TYPE', 'staging' );: часть плагинов кэширования, аналитики и рассылок читает это значение и отключает на копии то, что должно работать только на боевом сайте.
Какие обновления можно ставить сразу, а какие только через тестовую копию
Сразу можно ставить мелкие исправления безопасности ядра и обновления переводов, все остальное разумнее сначала прогнать на копии. По руководству WordPress по обновлению, у ядра бывают минорные обновления (обслуживание и безопасность) и крупные релизы, а фоновые обновления делятся на четыре вида: ядро, плагины, темы и файлы переводов. Риск у них разный.
| Что обновляется | Риск для сайта компании | Как обновлять |
|---|---|---|
| Переводы | Почти нулевой | Сразу на рабочем сайте |
| Минорная версия ядра (например, 7.1.3 → 7.1.4) | Низкий, это исправления ошибок и уязвимостей | Сразу, после свежего бэкапа |
| Крупная версия ядра | Средний: меняется редактор, функции, требования к PHP | Только через тестовую копию |
| Плагины форм, оплаты, магазина, конструкторы страниц | Высокий: от них зависят заявки и деньги | Только через тестовую копию |
| Тема и дочерняя тема | Высокий, если в теме есть доработки | Только через тестовую копию |
| Версия PHP на хостинге | Высокий для старых плагинов | Только через тестовую копию |
Отдельно про автообновления. Справка WordPress об автообновлениях плагинов и тем подтверждает, что с версии 5.5 их можно включать для каждого плагина и каждой темы отдельно, на экранах «Плагины» и «Внешний вид». Для сайта компании разумная схема такая: автообновление включено у простых служебных плагинов, а у всего, что связано с формами, оплатой, каталогом и версткой страниц, выключено. Эти плагины обновляют руками, после проверки на копии.
Если автообновления нужно выключить целиком, в wp-config.php для этого есть константа AUTOMATIC_UPDATER_DISABLED, а для ядра отдельно WP_AUTO_UPDATE_CORE. Документация прямо называет такой случай: отключить автообновления перед крупным релизом, чтобы успеть проверить его на development- или staging-окружении. Но выключать их и потом забывать обновлять опаснее, чем обновляться автоматически, поэтому вместе с отключением нужен регламент: кто и когда проверяет обновления.
Где сделать тестовую копию сайта WordPress: три варианта
Тестовую копию WordPress делают одним из трех способов: функцией хостинга, плагином клонирования или вручную. Выбор зависит от того, что умеет ваш хостинг и насколько сайт сложный.
| Способ | Когда подходит | На что обратить внимание |
|---|---|---|
| Кнопка staging в панели хостинга | Хостинг с поддержкой WordPress, в панели есть клонирование сайта | Проверьте, умеет ли панель переносить изменения обратно и что именно она переносит: файлы, базу или все сразу |
| Плагин клонирования или резервного копирования с функцией переноса | Обычный виртуальный хостинг, сайт до нескольких гигабайт | Плагин сам становится частью сайта и тоже требует обновлений, большие архивы могут упираться в лимиты хостинга по времени выполнения |
| Вручную: копия файлов и базы на поддомен | Сложные сайты, магазины, нестандартные доработки | Нужен доступ к FTP или SSH и к базе данных, плюс аккуратная замена адреса сайта в базе |
На проектах B2BPRO.KZ мы чаще всего видим второй и третий вариант: у казахстанских хостингов функция staging в панели встречается не везде, а там, где она есть, ей нередко не хватает переноса изменений в обратную сторону. Поэтому полезно один раз разобраться в ручном способе, даже если потом вы будете пользоваться кнопкой.
Как создать тестовую копию сайта WordPress вручную
Ручная копия делается за пять шагов: поддомен, файлы, база, замена адреса и закрытие доступа. На сайте среднего размера это занимает от получаса до пары часов, в основном на копировании файлов.
- Создайте поддомен и пустую базу данных. В панели хостинга заведите, например, staging.вашдомен.kz и отдельную базу MySQL с отдельным пользователем. Не используйте базу рабочего сайта даже с другим префиксом таблиц: одна ошибка в настройках, и копия начнет писать в боевые таблицы.
- Скопируйте файлы сайта. Нужна вся папка WordPress: ядро, wp-content с темами, плагинами и загрузками. Если папка uploads огромная, на копию можно перенести только свежие месяцы, а для старых картинок настроить подгрузку с рабочего сайта. Для проверки обновлений этого обычно хватает.
- Перенесите базу данных. Сделайте дамп рабочей базы и загрузите его в новую. В файле wp-config.php копии поменяйте имя базы, пользователя и пароль на новые.
- Замените адрес сайта в базе. WordPress хранит полный адрес в настройках, в ссылках внутри записей и в настройках плагинов. Часть этих данных сериализована, поэтому простая замена текста в SQL-файле ломает настройки виджетов и конструкторов. Используйте команду
wp search-replaceиз WP-CLI или плагин, который корректно работает с сериализованными данными. - Пропишите тип окружения и закройте доступ. Добавьте в wp-config.php
define( 'WP_ENVIRONMENT_TYPE', 'staging' );и поставьте пароль на поддомен средствами хостинга. О защите подробнее в следующем разделе.
Перед тем как пользоваться копией, зайдите на нее и пройдите главные страницы. Если копия с первой минуты выглядит иначе, чем рабочий сайт, ищите разницу сейчас: например, в версии PHP на поддомене или в кэше. Иначе потом вы не поймете, что сломало обновление, а что было сломано изначально.
Как закрыть тестовую копию от поисковиков и клиентов
Тестовую копию надежнее всего закрывать паролем на уровне сервера, а не только галочкой в настройках WordPress. В разделе «Настройки» → «Чтение» есть опция, которая просит поисковые системы не индексировать сайт, но это просьба, а не запрет. Google в справке о том, как ограничить показ контента в поиске пишет, что для закрытого контента нужна защита паролем: тогда страницы не попадут в выдачу, а уже попавшие со временем исчезнут из нее.
Копия, которая попала в индекс, становится полным дублем вашего сайта на другом адресе. Поисковик может начать показывать ее вместо основного домена, и клиенты будут оставлять заявки там, где формы никуда не отправляют письма или отправляют их не тому адресату, например на почту прежнего подрядчика.
Кроме пароля, на копии стоит отключить все, что связано с внешним миром:
- платежные модули переведите в тестовый режим или выключите;
- письма клиентам и интеграцию с CRM отключите, иначе тестовый заказ уйдет в Битрикс24 как настоящий лид;
- счетчики Яндекс Метрики и Google Analytics уберите, чтобы тестовые визиты не портили статистику;
- рассылки, отправку в мессенджеры и запланированные задачи, которые что-то отправляют наружу, остановите.
Как безопасно обновить плагины WordPress на тестовой копии
Чтобы безопасно обновить плагины WordPress, их обновляют по одному и проверяют сайт после каждого шага. Кнопка «Обновить все» удобна, но если после нее что-то сломалось, непонятно, какой из двадцати плагинов виноват. На сайтах клиентов мы действуем так:
- Синхронизируйте копию. Если копия создана месяц назад, сначала обновите ее с рабочего сайта. Проверка на устаревшей копии мало что гарантирует.
- Включите журнал ошибок. На копии можно включить
WP_DEBUGиWP_DEBUG_LOG, чтобы предупреждения PHP писались в файл. На рабочем сайте вывод ошибок на экран держите выключенным. - Прочитайте список изменений. У каждого плагина в каталоге wordpress.org есть журнал изменений. Если версия крупная, например с 3.x на 4.0, или в описании есть слова о смене требований к PHP, такой плагин обновляйте последним и проверяйте особенно внимательно.
- Обновите ядро отдельно от плагинов. Сначала ядро, проверка, затем плагины по одному или маленькими группами. Тему обновляйте отдельным шагом.
- После каждого шага пройдите чек-лист из следующего раздела. Сломалось — откатите один этот плагин и запишите, какая версия вызвала проблему.
- Запишите итоговый список. Какие плагины до какой версии обновлены, какие оставлены на старой версии и почему. Этот список и будет планом обновления рабочего сайта.
Есть страховка и на уровне самого WordPress. С версии 5.2 в нем работает режим восстановления: при фатальной ошибке в плагине или теме посетитель видит сообщение о технических трудностях вместо белого экрана, а на почту администратора приходит письмо со ссылкой для входа. Это описано в документации WordPress о настройках wp-config.php. Режим помогает быстро отключить сломанный плагин, но пока вы читаете письмо, сайт для клиентов уже не работает. Как действовать в такой ситуации, мы описали в статье про белый экран и ошибку 500 на WordPress.
Что проверить на сайте после обновления
После обновления проверяют прежде всего то, что приносит деньги: формы, корзину, оплату и отправку заявок. Внешний вид главной страницы важен, но сломанная форма обходится дороже, потому что ее замечают не сразу. Короткий чек-лист для сайта компании:
- главная, страница услуги, карточка товара и статья блога открываются без ошибок и «съехавшей» верстки, на компьютере и с телефона;
- форма заявки отправляется, письмо приходит, данные попадают туда, куда должны (на копии смотрите журнал отправки);
- корзина пересчитывает сумму, доставка и способы оплаты отображаются, тестовый заказ проходит до конца;
- поиск по сайту, фильтры каталога и пагинация работают;
- в админке открываются редактор записей и конструктор страниц, сохранение не выдает ошибок;
- в журнале ошибок PHP нет новых фатальных ошибок;
- раздел «Инструменты» → «Здоровье сайта» не показывает новых критических проблем.
Последний пункт часто пропускают, хотя он бесплатный. Экран «Здоровье сайта» показывает устаревшую версию PHP, неактивные плагины, проблемы с плановыми задачами и HTTPS. После обновления сравните его с тем, что было до.
Как перенести обновления с тестовой копии на рабочий сайт
Обновления переносят на рабочий сайт повторением, а не копированием базы с тестовой копии. Это главное правило staging для сайтов, где каждый день появляются заявки, заказы и комментарии. Пока вы проверяли обновления, на рабочем сайте прошли новые заказы. Если залить поверх базу копии, эти заказы исчезнут.
Правильный порядок выглядит так:
- Выберите время с минимальной нагрузкой: по счетчику посещаемости это обычно поздний вечер или раннее утро по Алматы.
- Сделайте свежую резервную копию рабочего сайта, файлов и базы, и убедитесь, что архив скачался и открывается.
- Повторите на рабочем сайте те же обновления в том же порядке и до тех же версий, что на копии.
- Если плагин после обновления просит обновить базу данных (так делают крупные плагины, например WooCommerce), выполните это сразу.
- Сбросьте кэш плагина кэширования и CDN, если он есть, и пройдите тот же чек-лист, что на копии.
- Отправьте с рабочего сайта одну настоящую тестовую заявку и убедитесь, что она дошла до CRM.
Перенос файлов с копии целиком оправдан в одном случае: когда на копии меняли код темы или делали доработки. Тогда переносят только измененные файлы темы, а базу рабочего сайта не трогают. Если правки затронули и настройки в базе, их переносят руками или скриптом миграции, но не заменой всей базы.
Пример: обновление интернет-магазина без простоя
Возьмем условный пример, похожий на типичные задачи наших клиентов. Интернет-магазин на WordPress с WooCommerce, около 2 000 товаров, оплата картой и выгрузка заказов в Битрикс24. В панели накопилось обновление ядра до новой крупной версии и 14 обновлений плагинов, включая сам магазин, конструктор страниц и модуль оплаты.
На тестовой копии обновление проходит по шагам. Ядро обновилось без проблем. Двенадцать плагинов тоже. После обновления конструктора страниц на карточке товара пропадает кнопка «Купить»: дочерняя тема использует старый шаблон, который в новой версии конструктора изменился. Модуль оплаты в новой версии требует более свежую версию PHP, чем стоит на хостинге.
Что делаем: конструктор оставляем на старой версии, разработчик правит шаблон дочерней темы на копии, проверяем. Версию PHP повышаем сначала на копии, проходим чек-лист, затем на рабочем сайте. Через два дня на рабочем сайте за 40 минут ночью повторяется уже проверенная последовательность, а исправленный шаблон переносится отдельным файлом. Магазин все это время работает. Без копии кнопка «Купить» исчезла бы прямо у покупателей, и заметили бы это, скорее всего, только по просевшим заказам.
Сколько времени это занимает и когда лучше отдать обновления подрядчику
Если копия уже настроена, плановое обновление сайта компании занимает от одного до трех часов в месяц: синхронизация, обновление по шагам, чек-лист и повторение на рабочем сайте. Первичная настройка копии, пароля, отключения писем и интеграций разовая и занимает больше времени, особенно на сложных сайтах.
Делать это своими силами разумно, если у сайта простой набор плагинов, нет магазина и интеграций, а в компании есть человек с доступом к хостингу, который понимает, что такое база данных. Отдавать подрядчику стоит, когда на сайте есть оплата, обмен с CRM или учетной системой, сильно доработанная тема или когда обновления уже месяцами стоят нетронутыми. В последнем случае обновление почти всегда превращается в небольшой проект: несколько крупных версий плагинов сразу, смена PHP, правка шаблонов.
Мы в B2BPRO.KZ берем такие задачи и в разовом формате, и как часть сопровождения. Если сайт устарел настолько, что обновления ломают его раз за разом, иногда дешевле пересобрать проблемные части, чем латать их, и тогда стоит посмотреть на разработку сайтов под ключ с правильной структурой плагинов. Что обычно входит в регулярное обслуживание, мы разбирали в материале о техподдержке сайта на WordPress.
Частые вопросы
Можно ли сделать тестовую копию WordPress на том же хостинге?
Да, тестовую копию обычно размещают на поддомене того же хостинга с отдельной базой данных. Это удобно и дешево, но проверьте, что на поддомене та же версия PHP, что и на основном сайте. Учтите, что копия занимает место на диске и в лимитах тарифа, поэтому папку загрузок иногда переносят не целиком.
Как часто нужно обновлять плагины на сайте компании?
Обновления безопасности ставят как можно быстрее, остальные удобно собирать в плановое обновление раз в две-четыре недели. Регулярный ритм безопаснее редких больших обновлений: когда за полгода копится двадцать версий, найти причину поломки намного труднее. Минорные обновления ядра WordPress на большинстве сайтов и так ставятся автоматически.
Попадет ли тестовая копия сайта в Google или Яндекс?
Может попасть, если она открыта без пароля, даже при включенной в WordPress опции «Попросить поисковые системы не индексировать сайт». Эта опция работает как просьба. Надежная защита — пароль на поддомен средствами хостинга: поисковый робот не увидит страницы, а случайный посетитель не оставит заявку на копии.
Можно ли после проверки просто скопировать тестовую копию поверх рабочего сайта?
Для сайта с заявками, заказами или комментариями так делать нельзя: база копии перезапишет все, что появилось на рабочем сайте за время проверки. Безопасный способ — повторить те же обновления на рабочем сайте после свежего бэкапа. Если на копии меняли код темы, переносят только измененные файлы, без базы.
Нужна ли тестовая копия для маленького сайта-визитки?
Для визитки из пяти страниц и пары простых плагинов достаточно свежей резервной копии перед обновлением и проверки сайта сразу после него. Тестовая копия окупается, когда у сайта есть формы с интеграцией в CRM, магазин, оплата или доработанная тема, то есть все, поломка чего стоит заявок и денег.