Как обновить WordPress вручную без потери данных
Если автоматическое обновление WordPress останавливается из-за ограничений хостинга, ошибки или отсутствия прав, ядро можно обновить вручную. Такой подход дает контроль над каждым заменяемым файлом и позволяет сохранить настройки, медиатеку, базу данных и установленные расширения. Важно понимать: ручная процедура безопасна только вместе с заранее проверенной резервной копией.
Вопрос о том, как обновить WordPress вручную без потери данных, возникает при неудачных автоматических обновлениях, сбоях на стороне хостинга и работе с нестандартными сборками. Правильный порядок выглядит просто: проверить совместимость, снять согласованную копию сайта и базы, заменить только системные файлы, выполнить миграцию схемы и осмотреть сайт. Любой шаг можно повторить или откатить по отдельности.
Подготовка перед заменой файлов
Сначала сделайте тестовую копию сайта, если хостинг поддерживает отдельные окружения. На ней обновите ядро и запустите основные сценарии: вход, публикацию страницы, отправку формы, загрузку изображения и работу с товарами. Это выявит конфликт плагина или темы до изменений рабочего сайта. Если тестовая среда недоступна, работы следует переносить на короткое время в режим обслуживания.
Проверьте требования новой версии WordPress к PHP и MySQL или MariaDB, свободное место на диске и права на каталоги. Сопоставьте их с параметрами сервера: хостинг может запускать старую версию PHP, из-за чего свежий код будет выдавать фатальные ошибки. Также убедитесь, что панель управления и FTP-клиент используют одну и ту же версию протокола, а учетная запись обладает достаточными правами.
До переноса файлов обновите плагины и темы, которые требуют более новой версии WordPress. Несовместимое расширение способно сломать админ-панель или заблокировать обновление базы. Плагины кэширования, оптимизации и обслуживания временно отключите, если инструкции разработчика это рекомендуют. Запишите список активных расширений и их версий, чтобы затем вернуть состояние сайта.
Резервная копия базы и файлов
Базу данных сохраняйте через phpMyAdmin, панель хостинга или командную строку. В phpMyAdmin выделите все таблицы префикса сайта, выберите экспорт, при необходимости включите сжатие и загрузите SQL-файл на компьютер. Проверьте, что файл не пуст, открывается без сообщения об ошибке и содержит таблицы с данными сайта. Снимок базы, сделанный хостингом, полезен как дополнительная страховка.
Для файлов используйте FTP, SFTP или файловый менеджер панели. Скачайте содержимое корня, включая скрытые файлы, каталоги wp-admin, wp-includes, wp-content, wp-config.php, .htaccess и robots.txt. Отдельно сохраните wp-content/uploads, если полная копия слишком велика. Конфигурацию базы и ключи безопасности из wp-config.php держите в закрытом месте и не публикуйте вместе с архивом.
Храните резервные копии как минимум в двух местах: на рабочем компьютере и на отдельном диске или в защищенном облачном хранилище. Согласуйте их по времени: копия файлов и выгрузка базы должны отражать одно состояние сайта. После скачивания откройте несколько архивов, проверьте размер и наличие ключевых файлов. Только после этой проверки можно удалять старые релизы с сервера.
Совместимость и выбор способа обновления
Перед обновлением проверьте журнал ошибок PHP, состояние базы и активность автоматических обновлений. В журнале не должно быть новых фатальных ошибок, которые скрывают реальную причину сбоя. Сбросьте кэш, если сайт использует оптимизацию, и убедитесь, что администратор может открыть страницу обновлений. Скрытые проблемы лучше исправить до замены ядра.
Отсутствие автоматического обновления само по себе не делает установку безопасной. Устаревшие плагины нередко содержат уязвимости, не связанные с ядром. Перед ручной заменой изучите заметку о уязвимости десериализации и проверьте версии установленных расширений по официальным источникам. Удаление неиспользуемых плагинов снижает поверхность атаки, но требует такого же внимательного резервного копирования.
Для регулярных небольших обновлений админ-панель удобнее, для контролируемой замены ядра — файловый доступ. WP-CLI подходит администраторам серверов, которым нужна автоматизация и единая команда для проверки версии. Сравнение помогает выбрать подход с учетом доступных прав и требований к откату.
| Способ | Что контролируется | Требования | Основной риск |
|---|---|---|---|
| Обновление из админ-панели | Ядро, плагины и темы средствами WordPress | Доступ администратора и стабильное соединение | Конфликт расширения или прерванная загрузка |
| Ручная замена через FTP или SFTP | Каждый системный файл и отдельное расширение | Доступ к серверу и архив нужной версии | Неполная замена или неверные права |
| WP-CLI | Ядро, плагины, темы и миграция базы | SSH и установленный WP-CLI | Ошибка команды или несовместимость окружения |
Замена ядра WordPress
Получите архив целевой версии только с официального сайта WordPress и распакуйте его на компьютере. Не берите сборки с неизвестных сайтов: в них могут быть измененные файлы. Сравните содержимое архива с сервером, зафиксировав версии через файл wp-includes/version.php. Сначала загрузите на сервер во временный каталог, чтобы файлы передавались целиком и не смешивались с текущей установкой.
Откройте временный каталог через FTP или SFTP. Удалите старые каталоги wp-admin и wp-includes, затем перенесите новые. В корне замените стандартные файлы WordPress, но сохраните wp-config.php, .htaccess и весь каталог wp-content. Именно там хранятся темы, плагины, языковые файлы и загруженные пользователями материалы. Не перезаписывайте wp-content содержимым стандартного архива. Сверьте перечень корневых файлов с официальным архивом и удалите старые элементы ядра, отсутствующие в новой версии, не затрагивая wp-config.php, .htaccess и пользовательские каталоги.
После замены выставьте владельца и права согласно настройкам хостинга: для PHP-файлов обычно используют 644, для каталогов — 755, если сервер не требует иных значений. Запустите wp-admin/upgrade.php, если WordPress не предложил обновление схемы автоматически. Не пропускайте этот этап: новое ядро может ожидать новые поля или таблицы. Завершив миграцию, включите сайт из режима обслуживания и сразу проверьте вход в админ-панель.
Обновление тем, плагинов и медиатеки
Плагины обновляйте по одному, начиная с критичных для функций сайта. Скачайте подходящий архив, сохраните старую версию и замените содержимое соответствующего каталога, не затрагивая его настройки и базу. Не смешивайте файлы разных выпусков. Если после установки появляется ошибка, верните прежнюю папку и проверьте совместимость на тестовой копии.
Тему также заменяйте целиком, сохраняя резервную копию и все дочерние темы. Пользовательские правки в style.css или functions.php могут быть перезаписаны, поэтому перед заменой перенесите их в дочернюю тему или сохраните отдельным патчем. Старую тему удаляйте только после проверки. Файлы переводов обновляются вместе с плагинами и темой, если они поставляются с соответствующим архивом.
Обновление не должно менять содержимое wp-content/uploads. Не запускайте массовую перекомпрессию изображений во время проверки: у отсканированных снимков бывают тонкие световые детали, а материал о механике появления ореолов помогает понять, почему такие эффекты нельзя исправлять без исходника. Оригиналы и файлы, созданные плагинами галерей, должны оставаться в резервной копии и проверяться по контрольной сумме.
Проверка сайта и готовность к откату
Проверьте главную страницу, запись, категорию, контактную форму, поиск, личный кабинет и корзину, если они есть. Убедитесь, что изображения загружаются, ссылки ведут на правильные адреса, а CSS и JavaScript не выдают ошибок в консоли браузера. Войдите и выйдите из панели, создайте черновик и отправьте тестовое письмо. Для интернет-магазина дополнительно проверьте оформление заказа без реальной оплаты.
Откройте журнал PHP и журнал сайта, затем обновите кэш и сбросьте постоянные ссылки, если структура адресов изменилась. Убедитесь, что задачи по расписанию выполняются, REST API отвечает, а модуль обновлений показывает актуальную версию. Временно включайте отладочный режим только на тестовой копии: на рабочем сайте он может раскрыть пути, секреты и персональные данные.
Откат предусматривайте по частям. Для возврата ядра замените системные файлы предыдущим архивом и запустите соответствующую миграцию базы. Если изменения затронули схему базы, восстановите согласованную SQL-выгрузку вместе с файлами. Не смешивайте старую базу с новым ядром без проверки. Зафиксируйте причину сбоя, верните сайт в рабочее состояние и повторите обновление на тестовой копии.
Регулярные обновления и безопасный результат
Сохраните себе короткую инструкцию: версии PHP и WordPress, путь к резервной копии, список плагинов, последовательность замены и результаты проверки. После каждого обновления удаляйте устаревшие архивы с сервера, но держите предыдущий рабочий выпус до завершения наблюдения. Такой журнал упрощает диагностику и позволяет быстро понять, что изменилось между двумя состояниями сайта.
Безопасный цикл сочетает регулярные обновления ядра и расширений с проверкой прав, резервным копированием и ограничением доступа. Случайные слабые пароли, старые учетные записи и ненужные плагины увеличивают риск независимо от способа установки новой версии. После обновления пересмотрите пользователей с правами администратора, включите двухфакторную аутентификацию и убедитесь, что сайт работает только по HTTPS.
Если во время ручного обновления встретилась нестандартная ошибка, опишите ее симптомы, версии и последовательность действий в странице обратной связи. Полезно приложить журнал PHP и сведения о том, на каком шаге появилась проблема. Завершите процедуру только после проверки основных сценариев и сохранения резервных копий в двух независимых местах.
