Как обновить WordPress — просто и «без воды»

WordPress используют на своих сайтах очень многие, неудивительно, что интернет пестрит статьями об этой CMS и, естественно, о том, как «правильно и безопасно» обновиться при появлении новой версии.

Пришло время обновляться и нам, с версии 6.1.1 до недавно вышедшей 6.2. Чтобы не наступить на какие-нибудь давно известные «грабли» решили сначала почитать, что же пишут об обновлениях опытные IT-специалисты 🤓. И очень скоро поняли, что эта идея была «так себе» — сложилось впечатление, множество статей об обновлениях Вордпресс’а, ссылками на которые забиты первые страницы поисковиков, написаны отнюдь не гуру по этой теме, а… видимо, блогерами-SEOшниками, которым, извините за выражение, «по барабану» о чем писать, лишь бы шел пользовательский трафик.

Что навело на эту мысль? Первое: популярные статьи о замене версий Вордпресс на более новые имеют почти одинаковую и жутко раздутую структуру. Примерно так:

  • Что  такое WordPress?
  • Как здорово и круто, что вы решили сделать сайт на WordPress — Вы такой молодец!
  • Почему появляются новые версии WordPress?
  • Зачем обновляться до новой версии?
  • Что будет, если вовремя не обновиться — ах, ах, какой кошмар!!!…
  • и т.д. … … вобщем, вы поняли, источник «воды» не иссякает… … … … … …
  • в самом конце, ВОЗМОЖНО, будет немного полезной информации о самом процессе обновления. А может быть, автор отделается несколькими общими фразами, которые только собьют с толку неопытного пользователя.

Второе: часть материалов, которые попались на глаза — это переводы статей англоязычных авторов, сделанные АВТОМАТИЧЕСКИМ ПЕРЕВОДЧИКОМ (Google, Яндекс или др.) и опубликованные «как есть», даже без попытки корректуры для русскоязычной аудитории. А зачем? ))) Трафик-то и так идет, что и требуется владельцу ресурса с подобными публикациями. Риторический вопрос: стоит ли доверять автору, который настолько не уважает своих читателей?

Теперь о том, как обновляли WordPress мы, с помощью автоматического обновления.

Никаких специальных плагинов для этого использовать не стали, а включили элементарную логику, которая говорит о том, что система «Вордпресс», условно говоря, состоит из двух частей.

Первая часть — это составляющие данную CMS  файлы. Если Ваш сайт полностью построен на движке «Вордпресс», они находятся в корневой папке сайта, если же Вы решили сделать на «Вордпресс» отдельный раздел сайта, то, соответственно, в той папке, которую Вы указали при установке WordPress на хостинг (она находится уровнем ниже «корня»).

У нас второй случай — файлы блога на WordPress лежат в отдельной папке — о нем дальше и будем говорить.

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

Не нужно быть продвинутым программистом, чтобы догадаться, что в процессе обновления версии какие-то файлы WordPress будут заменены на новые, вероятно, будут внесены изменения и в базу данных. Следовательно — что? ))) Правильно, нужно сделать резервные копии того, что имеем на данный момент, чтобы было возможно «откатиться» назад, если в процессе или после обновления что-то пойдет не так.

На самом деле можно было бы обойтись и без этих рассуждений — ровно то, что сказано выше, написано в админской консоли, а разделе «Обновления WordPress»:

Обновление версии WordPress через консоль

Как сделать резервные копии?

Сохранить файловую часть Вордпресс очень просто:

  • либо с помощью любого FTP-клиента скачайте с сервера на хостинге ВСЮ папку, в которую установлен WordPress, на локальный компьютер (на свой домашний или офисный ПК ));
  • либо воспользуйтесь непосредственно на хостинге файл-менеджером — скопируйте полностью папку с WordPress’ом в любую другую, под любым именем.

Мы  сделали это в менеджере файлов, так быстрее и проще (но это дело вкуса).

Вы можете спросить, что делать, если Вородпресс не в отдельной папке, а в корне (т.е. весь Ваш сайт — это и есть Вородпресс)? Да то же самое. Либо делаете копию всей корневой папки на хостинге, либо скачиваете по FTP все, что лежит в корне, со всеми подпапками, на свой ПК. В любом случае, копия сайта на локальной машине никогда не повредит (даже если Вы вообще не используете WordPress) — мало ли какая авария может случиться у хостера…

Резервную копию (дамп) базы данных мы также создали в админ-панели своего аккаунта на хостинге. У нас это делается «в 2 клика», но у разных хостинг-провайдеров эта процедура может различаться. Если не знаете , как это делать, лучше обратиться в техническую поддержку — там подскажут.

У нас дамп базы сохранился в корневой каталог сайта, в файл xxx_mysql_2023-04-10_12-34.sql.gz. Через FTP скачали его на персональный компьютер, но можно было бы этого не делать — из корня сайта на сервере он бы никуда не исчез (если не брать в расчет форс-мажор — например, что в дата-центр теоретически может ударить молния, и т.п. ))

С резервированием на этом всё!

Теперь возвращаемся в консоль WordPress и нажимаем кнопку «Обновить до версии 6.2_ru_RU». Честно говоря, приготовились ждать, но процесс обновления завершился очень быстро — буквально через несколько уже читали появившийся на мониторе «рекламный проспект» о преимуществах новой версии 6.2.

Конечно, начали проверять, не сломало-ли что-то это обновление. Зашли в консоли в раздел «Здоровье сайта» — всё хорошо. Посмотрели, как работают основные функции в админке — в частности, редактор, администрирование учетных записей пользователей, не «ругаются» ли плагины, не слетели ли настройки нашей темы, в которые были добавлены собственные стили css… Затем сделали «ревизию» с точки зрения рядового, незарегистрированного пользователя, только что зашедшего в блог. Страницы, записи, иллюстрации, другие элементы — всё на своих местах. Стили не сбились.

Таким образом, убедились, что обновление действительно завершилось успешно.

А если бы это оказалось не так?

Тогда 2 варианта:

  • разбираться и исправлять появившиеся ошибки (для администратора блога, не являющегося web-разработчиком — довольно трудная задача, может понадобиться привлечение стороннего специалиста);
  • вернуться к старой версии Вордпресс (для этого ведь и делали резервирование), а потом уже думать, как перейти на новую.

Начали бы мы с восстановления базы данных. Для этого сначала убедились бы, что у нас сохранены ее параметры: имя базы, логин, пароль, имя хоста (если эти данные у Вас утрачены — обращайтесь в техподдержку за помощью). Затем удалили бы с хостинга имеющуюся базу WordPress, как говорится, «с концами». После этого создали бы новую базу — с теми же параметрами, которые были у удаленной (с тем же именем, логином, паролем и именем хоста).

Далее, нужно наполнить прежним контентом вновь созданную базу — его восстанавливаем из резервной копии. На нашем хостинге в панели администратора для этого есть опция «Импортировать базу из файла» — для импорта использовали бы ранее сохраненный файл *.sql.gz. Также это можно сделать через интерфейс «phpMyAdmin». По этому вопросу посоветуйтесь с техподдержкой своего хостинг-провайдера.

С файлами Вордпресс еще проще — как Вы помните, на хостинге была сделана копия папки с этими файлами. Для возврата к предыдущей версии:
а) удаляем основную папку, с которой ранее делали копию, и в которой обновились файлы при установке новой версии;
б) переименовываем копию папки — даем ей то же имя, которое было у только что удаленной.

«Откат» на этом завершен, и, если Вы ничего не меняли в копиях файлов и не проводили никаких манипуляций по изменению дампа базы данных, все должно вернуться на круги своя. В консоли Вы увидите надпись, что у Вас версия WordPress с таким-то номером, что уже вышла новая, и неплохо бы до нее обновиться…

P.S. В некоторых статьях можно прочитать, что перед обновлением Вордпресс желательно отключить все плагины. Мы этого не делали. Для перестраховки, если предположить, что во время обновления какие-то из них могут вдруг начать что-то делать по установленному в них расписанию, наверное, можно и отключить — хуже от этого точно не будет.

P.P.S. Буду рад, если эта статья кому-то поможет. Но она — не руководство к немедленному и неукоснительному действию. )) У Вашего сайта может быть своя специфика, о которой автору ничего не известно. Использовать эти рекомендации или поступить как-то иначе — решать исключительно Вам.

Поделиться:

Добавить комментарий