26 апреля 2017 года разработчики популярной CMS Joomla порадовали нас новой версией системы управления контентом 3.7. Многие, в том числе и я поспешили обновить движок Joomla, дабы проверить наличие долгожданных пользовательских полей. Именно процессу обновления и будет посвящен данный урок, а так же выявлению и устранению ошибок возникающих в процессе обновления.
Как обновить CMS Joomla
Обновить Joomla можно несколькими способами – обновиться через панель управления либо записать файлы новой версии напрямую на сервер. Рассмотрим все способы по порядку.
Автоматическое обновление Joomla через панель управления
Когда выходит новая версия Joomla в панели управления мы сразу же получаем об этом уведомление:
Нажимаем на кнопку «Обновить сейчас» и попадаем на страницу «Обновление Joomla!» с двумя вкладками «Автоматическое обновление» и Кроме того нас настоятельно рекомендуют проверить что установленные расширения совместимы с новой версией Joomla. А я в свою очередь хочу отметить, что если вы работаете со стандартным шаблоном Joomla и вносили в него изменения, то советую сохранить все изменения, иначе после обновления вы их потеряете.
Существуют и другие способы попасть на страницу «Обновление Joomla!»:
- Перейти в раздел «Система» -> «Панель управления» и в левой нижней части страницы найти надпись «Обслуживание», под которой будут ссылки на новые версии движка и расширений
- Перейти в раздел «Компоненты» -> «Обновление Joomla!»
Не важно, какой из способов вы выбрали, вы попадете на следующую страницу:
Для автоматического обновления Joomla остается только нажать на кнопку «Установить обновление» (смотрите скриншот выше) и если не возникнет никаких проблем, то движок Joomla будет обновлен.
Альтернативный способ обновления Joomla через панель управления
Если по каким либо причинам автоматическое обновление не доступно, в панели управления Joomla предусмотрен другой вариант, при помощи которого так же можно обновить CMS.
На той же странице «Обновление Joomla!» переходим во вторую вкладку «Загрузка и обновление» и наблюдаем примерно следующую картину:
Данный способ хорош в том случае, если по каким либо причинам не удается связаться с сервером обновлений Jommla, а причин этому может быть множество.
Все что нам потребуется это выбрать предварительно скаченный файл пакета со своего компьютера и нажать на кнопку «Загрузить и установить». После этого можно наслаждаться новой версией любимой CMS.
Обновление Joomla путем копирования новых файлов прямо на сервер
Последний способ, при помощи которого можно обносить Joomla, это записать файлы новой версии прямо на сервер. Не скажу что данный способ предпочтительный, но иногда бывают ситуации, когда обновить CMS можно только с помощью данного метода.
Для того чтобы обновить Joomla данным способом во избежание непредвиденных ситуаций стоит выполнить ряд действий:
Отключить кэширование (если включено)
Очистить и удалить устаревший кэш (если имеется)
Создать резервные копии файлов и базы данных
После этого скачиваем пакет обновлений (они обычно в формате ZIP) и распаковываем его в корневой каталог сайта.
Когда архив распакуется, заходим в панель управления и наблюдаем следующее - версия Joomla обновилась (о чем свидетельствует номер версии в правом нижнем углу), но система выдает нам неизвестную ошибку:
Что делать в данной ситуации? Главное не паниковать, все поправимо. Дело в том, что после записи новых файлов база данных осталась в устаревшем состоянии и это надо исправить.
Исправлять базу данных вручную не потребуется, в Joomla уже все предусмотрено. Переходим в раздел «Расширения» -> «Менеджер расширений» -> «Базы данных» и попадаем на страницу «Менеджер расширений: Проверка базы данных»:
Как и предполагалось, ошибки связаны с базой данных, после такой процедуры обновления она естественно не обновилась. Для того чтобы привести базу данных в актуальное состояние жмем на кнопку «Исправить».
После этого база данных скажет вам спасибо, а структура таблиц будет в актуальном состоянии. Но тут появляется очередная проблема – в панели управления не появляются такие новшества как дополнительные поля для материалов и пользователей (а если и появятся, то будут в отключенном состоянии).
В данной ситуации на помощь придет поиск загруженных, но не установленных расширений. Переходим в раздел «Расширения» -> «Менеджер расширений» -> «Найти» и попадаем на страницу «Менеджер расширений: Поиск» на которой представлен список не активных расширений:
Теперь если перейти на страницу обновлений, то можно заметить, что у нас установлена самая новая версия Joomla.
Но не всегда, я бы даже сказал очень часто, в процессе обновления Joomla возникают ошибки, основные из них мы сейчас и рассмотрим.
Ошибки при обновлении Joomla
Достаточно часто возникают ситуации, когда автоматическое обновление Joomla отказывается работать. Появляются различного рода ошибки, которые не всегда удается победить с первого раза. Конечно, всегда можно воспользоваться последним способом обновления – записать файлы напрямую на сервер, но данный процесс не всегда хорош.
Давайте посмотрим, какие ошибки могут возникнуть в процессе обновления и как от них избавиться.
Ошибка AJAX Loading Error: Not Found
Одна из коварных ошибок, которая возникает в процессе обновления, звучит так AJAX Loading Error: Not Found:
Не буду вдаваться в подробности, как я нашел причину возникновения данной ошибки, скажу прямо – все дело в конфигурации файла htaccess.
Если вы редактировали данный файл и настроили блокировку прямого доступа к ядру, то данная ошибка появится обязательно. Решений как всегда несколько:
- временно переименовать файл.htaccess
- Найти в нем строки кода блокирующие доступ к ядру и закомментировать их.
Первый способ самый простой – переименовываем файл «.htaccess» например, в файл «.htaccess_» и повторяем процесс обновления. Автоматическое обновление должно запуститься без проблем.
Во втором варианте открываем файл.htaccess для редактирования и ищем приблизительно следующие строки (в моем случае это строки с 86 по 98):
Модуль «Обновление CMS» обязателен для установки. Он относится к CMS «Управление» и является частью ядра DIAFAN.CMS. Имеет только административную часть.
Для корректной работы модуля необходимо PHP-расширение ZipArchive.
Автообновление
Модуль позволяет получать обновления для Вашей DIAFAN.CMS с нашего сервера.
При первой установке DIAFAN.CMS создается так называемая «точка возврата», которая содержит резервные копии всех установленных файлов «из коробки». В дальнейшем при получении обновлений, DIAFAN.CMS создает точки возврата и сохраняет отдельно обновленные версии файлов.
Обновления для DIAFAN.CMS проверяются только по Вашему запросу! Необходимо зайти в модуль «Обновление CMS» и нажа кнопку «Проверить обновление». Если для Вашей версии DIAFAN.CMS есть изменения, Вы увидите список обновлений, доступных для скачивания, и под списком будет кнопка «Скачать».
После клика по ней обновления начнут последовательно скачиваться. Если прервать закачку до завершения, при следующей проверке список обновлений будет скорректирован. Продолжить прерванное скачивание можно аналогичным способом – с помощью кнопки «Скачать» под списком. В обновлении могут участвовать все файлы DIAFAN.CMS, в том числе шаблоны, файлы стилей и изображения. При этом пропустить какой-либо из пакетов невозможно, система автоматически проверяет целостность каждого обновления.
При каждом скачивании обновлений точки возврата создаются автоматически. После скачивания обновления необходимо нажать кнопку «Применить» (она показывается на экране после последнего скачанного обновления). Применены будут все обновления от текущей точки возврата до последнего выполненного обновления.
Как работают обновления?
Сгенерируется тема . Что это значит? Все полученные обновленные файлы с нашего сервера сравниваются с текущими файлами всей системы в текущей точке возврата. Если DIAFAN.CMS находит, что какие-то текущие файлы системы не соответствуют полученным из обновления, они будут перемещены в папку custom в текущую тему. Если текущей темы нет, то будет создана новая.
На место перемещенных файлов будут записаны файлы, полученные из обновления. На сайте это никак не отобразится, потому что файлы из текущей темы обладают более высоким приоритетом.
Если в обновлении предусмотрено изменение структуры базы данных, то оно будет произведено.
Что делать, если функционал обновления не устраивает?
Можно вернуть всё обратно в один клик. Для этого достаточно зайти в модуль «Обновление CMS» и нажать «Применить» напротив любой предыдущей точки возврата. Откат к сохраненному состоянию касается также базы данных. Если с ней были произведены какие-то манипуляции, после применения точки возврата структура БД вернется к прежнему состоянию.
Можно ли удалять точки возврата?
Да, можно. При удалении точки возврата ее файлы присоединяются к следующей точке. Более того, удалять лишние точки возврата рекомендуется, потому что это ускорит генерирование темы. А также, не рекомендуется увлекаться слишком частым созданием точек возврата. Ведь система инспектирует все предыдущие точки, и чем их меньше, тем быстрее происходит генерирование.
Текущую точку удалить нельзя, также как и точки возврата скачанных, но еще не примененных обновлений.
Как посмотреть детализацию точек возврата?
Каждую точку возврата можно раскрыть, кликнув по ее названию. После этого будет показан полный список файлов, которые входят в точку возврата. Кроме того, будет показан список файлов, отличающихся от текущей версии сайта.
Обновления доступны только для сайтов с активированными лицензиями DIAFAN.CMS.
Подключение
Подключаемая часть – файл . В нем описан класс Update_inc . В модуле к объекту класса можно обратиться через переменную $this -> diafan -> _update . Экземпляр класса создается при первом вызове переменной.
Свойства
Var folders = array("adm", "css", "img", "themes", "modules", "includes", "plugins", "js") – папки и файлы, индексируеме для точек возврата.
Var exclude = array("adm/htmleditor", "includes/custom.php") – папки и файлы, не индексируемые для точек возврата.
Методы
Void first_return () – Добавляет первую точку возврата.
// при установки DIAFAN.CMS
$this
->
diafan
->
_update
->
first_return
();
Array get_files (integer $id) – Получает обновленные файлы точки с содержимым.
// получает файлы точки возврата ID=3
$rows
=
$this
->
diafan
->
_update
->
get_files
(3
);
print_r
($rows
);
/* выведит:
Array
[modules/news/news.model.php
] => ...
class News_model extends Model
{
...
[modules/news/news.php
] => ...
class News extends Controller
{
...
...
) */
Array get_all_files (integer $id) – Получает все файлы DIAFAN.CMS в точке с содержимым.
- integer $id: идентификатор точки
// получает все файлы DIAFAN.CMS, актуальные для точки возврата ID=3
$rows
=
$this
->
diafan
->
_update
->
get_all_files
(3
);
print_r
($rows
);
// выведет файлы в формате как функция get_files()
Файлы
modules/update/admin/js/update.admin.count.js – количество доступных обновлений, JS-сценарий;
modules/update/admin/js/update.admin.js – обновление, JS-сценарий;
modules/update/admin/update.admin.php – точки возврата;
modules/update/admin/update.admin.action.php – точки возврата;
modules/update/admin/update.admin.count.php – количество доступных обновлений для меню административной панели;
modules/update/update.inc.php – подключение модуля;
modules/update/update.install.php – установка модуля.
В начале этого года был разработан ряд доработок для форума. Некоторые из них реализовывались путем обновления движка до последней версии. В связи с этим и был осуществлен переход. Как правило, обновление CMS обладает рядом преимуществ:
- В новых версиях устраняются недостатки, баги, ошибки и "дыры";
- Появляется дополнительный функционал;
- Поддерживается современность и актуальность движка.
Но в моем случае дополнительно к этим пунктам добавился 1 очень каверзный баг, который, на мой взгляд, и стал главной причиной резкого с поисковых систем. Графики посещений с Яндекса и Google (по неделям). Стрелочкой указана примерная дата обновления.
Поисковая посещаемость упала более чем на 1000 ежесуточных посетителей.
Замечу, что обновление не носило радикальный характер (обновлялась версия той же линейки). Появился вопрос "Что же повлияло на падение посетителей с поисковых систем". После обновления пользователи начали жаловаться на один баг, который время от времени стал появляться. При клике на одну страницу, форум перекидывал пользователя на другую. В основном, были затронуты URL"ы тем. Также браузер иногда отдавал ошибку о невозможности перехода по указанному урлу из-за циклической переадресации.
Я начал анализировать аккаунты для вебмастера в Яндексе и Google. В гугле после перехода на новую версию движка резко подскочили ошибки, относящиеся к URL - "Переход не выполнен".
Данные ошибки как раз начали появляться сразу после обновления (график начинается немного позднее - с начала марта). Почему баг каверзный? Все просто. Его до сих пор пока никто не смог обнаружить и исправить. Но я не теряю надежды и буду стараться как можно скорее избавиться от него .
Я задал вопрос службе поддержки Яндекса по этому поводу. Получил, на первый взгляд, обнадеживающий ответ.
Но, как видно из графиков посещаемости с Yandex, трафик продолжил свое падение. Получается, что иногда поисковый робот получает на свой запрос, либо циклическую переадресацию (не может выполнить переход), либо клоакинг (в выдаче одна страница, а осуществляется перенаправление на другую). Конечно, после таких ошибок не удивительно, что посещаемость резко пошла вниз.
Стал бы я обновляться, зная, какие последствия ждут меня впереди? Конечно, нет. Та пара пунктов из доработок, которые требовали новую версию, не покрывает некоторые неудобства для пользователей и поисковых роботов.
В общем, что я хотел сообщить, публикуя этот пост? Во-первых, я не в коем случае, не отговариваю вас обновлять свои CMS. Во-вторых, обновление движка не всегда сопровождается позитивными изменениями (существуют и негативные, например, мой случай ). В-третьих, перед переходом на новую версию вашей системы управления контентом хорошо подумайте о важности и целесообразности таких изменений (возможно, они вам просто не нужны).
Кто-нибудь из вас сталкивался с проблемами после обновлений CMS? Поделитесь своим опытом и путями их решения. Желаю всем, чтобы баги и ошибки обходили ваши проекты стороной, а посещаемость с поисковых систем показывала только положительный рост !
DataLife Engine (DLE) - популярная система управления материалами сайта, в народе - «движок». Перенос сайта на движке DLE осуществляется в виде простой переустановки дистрибутива. При этом, используется встроенная способность движка DLE самостоятельно и восстанавливать базу данных (БД). Эта же способность движка задействована и в CMS DLE - придумке от любителей всего новенького и чистенького. Лично мне, такие заморочки требуются исключительно при обновлении движка. После длительной файловой модификации и оптимизации - движок легче снести и переустановить по-новой. Отдельное спасибо Александру Алаеву за его уроки и наставления по оптимизации DLE.
Сохраняем базу данных (БД)
Работа с файлами сайтовой операционной системы начинается с её бекапства (бекапинья). Backup - это спасательный круг. Создание резервной копии веб-ресурса позволит избежать многих проблем, связанных с неудачными файловыми операциями на сайте. Кроме этого, имея дистрибутив движка и резервную копию сайта, можно носить его, хоть по всей Сети.
В принципе, это не ахти какой новшество - использовать для переноса или переустановки движка CMS DLE его встроенную способность бекапить и восстанавливать свою базу данных (БД). Самое сложное и опасное в этом способе - не запутаться в её копиях. Потому что, версия БД должна в точности соответствовать версии самого движка.
База данных от старого движка никогда не встанет на новый, и наоборот
Если при переносе сайта на CMS DLE или переустановке движка не меняется его версия - можно забекапить старую базу данных и в последствии - её восстановить. Если-же версия движка возрастает, базу данных обязательно нужно будет сначала обновлять до актуальной версии, затем - бекапить, а в последствии - восстанавливать её, и только её. Использовать базу данных сайта и его движок разных версий не получится. Обновлять базу данных несложно. Она обновляется автоматически при обновлении самого движка. Причём, это не обязательно делать прямо на хостинге, можно и на локальной машине, используя пакет .
Делаем полный backup CMS DLE
Первым делом - сотворяем бекап из своего любимого сайта (backup - резервная копия).
Сделать резервную копию (backup) в CMS DLE достаточно легко. Посторонний софт для этого не понадобится, поскольку разработчик сайтодвижка предусмотрел подобную потребность. А, за сим - совершаем «невыносимый подвиг» - заходим в админку своего сайта, в раздел «Список всех разделов» => «Управление базой данных» и жмём кнопочку «Сохранить базу данных». После чего, «топаем» на свой и, выкачиваем на локальную машину всю корневую папочку сайта вместе с его новоиспечённой копией базы данных. Всё предельно просто, весело и даже немножко смешно.
Однако, господину и товарищу станет очень даже не весело и совсем даже не смешно, когда база данных его изумительного сайта слетит к едрён-батон и весь сайтец накроется медным тазом. При обновлении любимого движка CMS DLE такой риск есть и разработчик, так прямо и предупреждает - этот процесс не обратим. Так что, бекапимся, пока есть что бекапить. И не гоним зря на разработчика. Он тут не при чём. Такой облом может запросто получиться, например - в результате ошибки серверной операции.
Танцы с предварительным обновлением сайта как раз и связаны с необходимостью обновить базу данных до актуальной версии и её перед полным сносом файлов движка. Последующая установка нового движка и восстановление обновлённой БД из сохранённой копии как раз и создаёт эффект установки нового движка на старую базу данных. Вот только, чтобы на новом движке встала старая база данных - её нужно предварительно обновить и сохранить, чтобы затем - было что восстановить.
И ещё. Эта придумка может не проканать на больших сайтах, имеющих большие базы данных. Увы. Хочется отдельно напомнить, что ответственность за все деяния, сотворённые над своим сайтом, несёт только непосредственно проводящий работы (прораб). А статьи, подобные этой - публикуются исключительно в ознакомительных целях.
Зачем нужно «чистое» обновление (переустановка) CMS DLE
Скажу сразу, разработчик управляющей системы DataLife Engine (DLE) не одобряет подобных трюков и выходок. У разработчика есть своя подробная инструкция к обновлению движка, которая не меняется годами. Обновлять CMS DLE согласно инструкции разработчика гораздо проще и спокойнее - залил себе файлы на хостинг, вызвал установщик, быстренько пробежался по его кнопкам-рекомендациям, затем удалил из сервера папку upgrade и файл install.php , и - всех-то делов. За всё про всё, не более 10 минут. И, можно уже начинать пить пиво, или что там у кого есть...
Так для чего-же тогда нужно такое «чистое обновление»?
«Чистое обновление», это по сути своей - один из вариантов обычной переустановки . Такое обновление придумано любителями всего нового и чистенького. Иногда, переустановка движка выполняется для восстановления его файловой структуры или преследует цель избавиться от возможных подозрительных файлов. Лично я подобным методом переносил сайт из одного хостинга на другой.
«Чистое обновление» CMS DLE - это полная переустановка движка сайта, с полным сносом его системных файлов и обновлением базы данных (БД) до актуальной версии. «Чистым», называют обновление управляющей системы сайта, при котором удаляются все старые системные файлы, и взамен - устанавливается абсолютно новый дистрибутив. После такой переустановки движка производятся его новые пользовательские настройки.
Вот только, обновляясь обычным стандартным образом, я никогда не захожу в Админку движка. А это плохо. Потому что, каждое очередное обновление CMS DLE связано с добавлением ему новых функций, что в свою очередь вызывает добавление новых кнопок в его админпанели. Таким образом, заход в админпанель CMS DLE, для её изучения и настройки после обновления - процедура обязательная. Вот и получается, что «чистое» обновление - это как-бы пинок себе любимому, для стимуляции захода в админпанель движка, тщательного изучения и новой настройки.
Кроме этого, болтаясь по форуму DLE я обратил внимание, что у некоторых владельцев сайтов на CMS DLE начинаются проблемы после обновления управляющей системы до актуальной версии. Как правило, это связано с особенностями настройки хостинга, повреждением файловой структуры или работой посторонних модулей, которые не могут управиться с новыми изменениями. А, если модулей на сайте ещё и много - так иногда свихнуться можно, обновляя такой сайт. «Чистое» обновление CMS DLE даёт возможность сначала обновить и настроить работу самого движка сайта, и только потом - цеплять на него посторонние модули. Каждый по-отдельности, и каждый - по очереди. Кстати, это весьма неплохой повод задуматься о пользе и необходимости этих самых посторонних модулей на сайте. Практика показывает, что добрая половина таких разработок - это никчёмные игрушки, приколы, да и только.
Ну, и ещё есть одна дополнительная (а, часто и - основная) причина для переустановки («чистого» обновления) движка DLE. Это желание избавиться от паранойи и нервозности, связанных с появлением на сайте милых звИрушек от какого-нибудь хакерского сообщества… Конечно, - это тема философская. От сайто-поломки ещё никто и нигде не был застрахован. Вот только, после удаления всех старых файлов и распаковки на хостинге чистого дистрибутива - оно как-то поспокойнее будет...
Для «чистого» обновления CMS DLE потребуется
дистрибутив новой версии движка,
лицензия (код активации) и желание поработать
(Качаем дистрибутив с оф.сайта DLE и приступаем)
«Чистое» обновление (переустановка) CMS DLE
После создания и выкачивания из хостинга полной! резервной копии (backup) сайта,
приступаем к непосредственному обновлению его движка - CMS DLE.
При этом, происходит, примерно - следующее:
- Предварительное обновление сайта, которое делается с одной-единственной целью -
обновить базу данных (БД) сайта до уровня движка новой версии. - Обязательное создание резервной копии (backup) из обновлённой базы данных
- Обязательное сохранение резервной копии (backup) из обновлённой базы данных
- Полный снос системных файлов движка.
- Заливка на хостинг новых файлов и установка новой управляющей системы.
- Восстановление обновлённой базы данных из её резервной копии (backup).
- Пользовательская настройка движка сайта «по-новой».
«Чистое обновление» - движка сайта CMS DLE
Алгоритм действий, примерно такой:
- Совершаем обычное обновление CMS DLE, согласно инструкций разработчика.
- Проверяем работоспособность своего сайта. Если всё «тип-топ», «YES» и «OK» - снова обязательно! делаем сайта и его базы данных. После чего, выкачиваем этот полный бекап к себе на локальную машину. После переустановки движка сайта база данных будет удалена и её придётся восстанавливать именно из этой, обновлённой и рабочей копии.
- Удаляем на хостинге папки:
Engine и language. - Не удаляем папки:
backup - это копии базы данных (БД)
templates - это шаблоны страниц сайта
uploads - это самая ценная папка. В ней хранятся картинки и файло́ из новостей, публикаций и стат.страниц, а также личные файлы и аватары пользователей. - Выполняем новую установку движка, согласно инструкции разработчика. ВНИМАНИЕ! Во время новой установки движка CMS DLE, установщик сотрёт настоящую базу (БД) данных и создаст свою, другую. В этой БД будут только две-три новости-демки от DLE.
- Восстанавливаем свою родную БД из обновлённой копии, сделанной накануне.
Для этого, заходим в админпанель, в раздел «Список всех разделов» => «Управление базой данных» и жмём кнопочку «Восстановить базу данных». В списке копий выбираем именно ту самую копию, которая была сделана после её последнего обновления до новой версии управляющей системы. - Чистим кэш движка и браузера:
- Кнопочка «Очистить кэш» находится в низу главной страницы панели управления
- Очистить кэш браузера - Ctrl+Shift+Del
После таких издевательств над собой, наш сайт на DLE должен окончательно ожить в обновлённом виде. Теперь, уже обЕзательно - нужно зайти в админку сайта и выполнить по-новой все
