Откат Word Press на более старую (предыдущую) версию мне пришлось делать уже несколько раз, и каждый раз — после криво вставшего обновления. Думаю, что случается такое часто и не у меня одного: после обновления Word Press сайт иногда начинает тормозить, перестает грузиться графика в посты, перестают работать некоторые плагины, — может быть не самые ключевые, но привычные и так сказать «милые сердцу»… Короче нередко после обновления Word Press возникает множество проблем, решать которые самостоятельно (то есть влезать в коды, или курить форумы программистов-фанатов WordPress) совершенно не хочется.
Ну и так как это происходит со мной уже не первый раз, то я решил записать небольшую «памятку», которая может пригодиться как мне самому (ибо держать все в голове глупо), так и кому-то другому, ибо подозреваю, что я далеко не единственный пользователь Word Press, столкнувшийся с подобной проблемой и желающий по какой-то причине вернуться к предыдущей версии движка после неудачно прошедшего обновления…
Конечно, если делать обновление грамотно, — то есть в соответствии с инструкцией, сохранив предварительно базы данных и все файлы и папки из директории блога, то при откате вообще никаких проблем возникнуть не должно: нужно просто, что называется, «тупо вернуть все на место». Но чаще всего свежий бэкап перед очередным обновлением нам делать лениво В последнее время появилось множество специализированных плагинов для создания резервной копии или переноса сайта на другой хостинг, с возможностью восстановения, что называется, "одним кликом". Это существенно упрощает ситуацию, поскольку создание бэкапа производиится реально просто и единственное, что может этому помешать - это спешка, то есть нежелание (или невозможность) потратить 10-15 минут на ожидание. Аргумент, согласитесь, уже совсем какой-то несерьезный. Лично я использую коммерческую версию плагина BackupGuard, которым очень доволен, и который могу смело рекомендовать. Кстати, бесплатная версия плагина BackupGuard работает также очень неплохо, и без всяких подвохов, характерных для многих других плагинов-аналогов, бесплатность которых заканчивается ровно в тот момент, когда требуется восстановить блог. («русское авось» рулит) и свежих резервных копий просто нет. Что тогда?
А ничего страшного! Для начала нужно где-то взять дистрибутив старой версии (то есть той версии, которая стопроцентно работала). Если этой версии не сохранилось в архивах компьютера, то без особого труда это можно найти и в Интернете. Например — здесь, или на любом другом аналогичном ресурсе, найти который с помощью любого поисковика не составит оособого труда.
После распаковки архива на локальный компьютер, нужно перезалить на хостинге папки wp-admin и wp-includes, а также файл из коренной директории блога wp-settings.php.
После этого для корректного отображения админки (если у вас русская версия админки блога) можно еще заменить на сервере файлы ru_RU.mo и ru_RU.php из папки wp-content/languages
Замену файлов, разумеется, лучше производить по FTP. Я не исключаю, что можно ограничиться и более «избирательной» перезаливкой, то есть закачивать не все папки из старого архива, но лишь часть файлов из этих папок. Очень даже может быть, что так лучше. Но сам я предпочитаю этим не «заморачиваться», поскольку замена папок с перезаписью обычно производится достаточно быстро и дает нужный результат, без «побочных эффектов», а ковыряться в отдельных файлах, сортировать их, путаться в их названиях и т.д. — просто не хочется.
После процедуры замены файлов при заходе в админку обычно появляется предупреждение о том, что требуется обновление базы данных, которое может выглядеть примерно так (ну или как-то аналогично):
Нажатие на кнопку «Обновить базу данных» по прошествию некоторого времени обычно приводит к нужному результату и, как говорится, вуаля… Получите старую админку и живите как раньше, то есть без проблем 🙂
А вообще вычитал недавно в каком-то блоге один очень дельный совет, которым собираюсь руководствоваться в дальнейшем:
например, при переходе с 3.4.2 на 3.5 (ну или что там сейчас разрабатывается) — резоннее подождать, пока будет выпущена пара-тройка патчей в рамках новой версии (3.5.1 а лучше 3.5.2) и тогда уже пробовать, потому что в свежей «глобально новой» версии почти неизбежно будет огромная куча всяких проблем, и если Вы не программист, а обычный блогер, не фанатеющий по решению «программерских головоломок», то не торопитесь — пусть более нетерпеливые «кидаются на амбразуры»… а вы успеете еще обновиться.
Еще один вывод, который я сделал для себя:
Если вы не можете позволить себе иметь отдельный постоянный тренировочный блог-полигон для обкатки всяких нововведений, — у меня таким является демо-сайт для клиентов; там можно попутно обкатывать плагины, темы и всякие модные «примочки». Но если у вас такого нет, то можно воспользоваться таким простым трюком: устанавливать в отдельную папку (или даже в отдельный поддомен) своего сайта временный блог, и на нем проводить все эксперименты по обновлению. Ну а затем уже и решать — обновлять свой основной сайт, или лучше подождать еще. Тренировочный полигон наверное лучше регулярно «сносить», чтобы не смущать поисковые машины подозрительными «говностраницами» в своей доменной зоне и не портить репутацию сайта. Но лучше всего, конечно, просто развернуть тренировочный полигон в какой-то отдельной доменной зоне, чтобы не рисковать «пузомерками» своего основного ресурса. Впрочем, этот совет уже наверное все же для «гурманов и фанатов»…
