К сожалению, многие владельцы интернет ресурсов не предполагают, что безопасность веб сайта может быть под угрозой. Но такая простая мера, как обновление CMS, может защитить от многих неприятностей, связанных с хакерскими атаками.
Любая CMS обладает большим набором различных модулей, по сути это сложный программный комплекс. И разработчики CMS, иногда допускают ошибки (уязвимости), которые позволяют хакерам осуществить взлом. И никто не может знать заранее, когда хакеры найдут такую уязвимость в программном коде, чтобы взломать сайт.
Обновление движка необходимо делать с периодичностью не реже 2 раз в год для оптимизации безопасности вашего ресурса и защите его от хакерских атак. Многие CMS уведомляют о выходе новых версий в админке, с кратким описанием сделанных изменений.
Если произошел факт взлома и нарушение безопасности сайта, это может иметь очень негативные и иногда трудно устранимые последствия:
Практически, любая CMS имеет уязвимости, однако это не фатально. Так как разработчики CMS их регулярно обнаруживают и устраняют. Обновление CMS – это обычная практика, которая защищает веб ресурс, так как при этом происходит устранение уязвимостей в программном коде CMS.
Обновление CMS желательно делать раз в полгода или не реже 1-го раза в год. Большинство CMS в админ панели сайта уведомляют о появлении новых версий. Часто добавляются краткие описания, которые поясняют, какие добавлены новые функции или возможности, какие устранены ошибки или проблемы безопасности.
Однако установив обновление на работающем сайте, может произойти сбой. Это происходит тогда, когда при разработке сайта устанавливались какие-то модули или плагины для выполнения сайтом определенных функций не из базового функционала. И это расширение не работает корректно с новой версией CMS. В этом случае необходимо искать аналогичный модуль под новую версию.
Периодическое обновление CMS до последнего актуального релиза – это необходимая мера, направленная на обеспечение безопасности сайта. Однако нужно понимать, что не всегда очередное обновление включает исправление всех уязвимостей. Особенно это касается бесплатных (open-source) движков.
Качество и частота появления новых обновлений – это, пожалуй, основной показатель надежности. Так как он говорит о том, что разработчики поддерживают CMS и устраняют ее уязвимости. Если движок не обновлялся полтора два года, то скорее всего разработчики перестали его поддерживать.
В случае применения коммерческих CMS, таких как Битрикс, ответственность за обновления несет компания-разработчик. Оплата лицензии включает в себя предоставление гарантированной технической поддержки.
В случае использования бесплатной (open-source) CMS, желательно чтобы компания-разработчик сайта осуществляла регулярные обновления. Для некоторых CMS выполнение обновлений является сложным процессом, который требует специалистов высокой квалификации. И в этом случае для проведения обновления необходимо временно закрыть сайт, на техническое обслуживание.
Регулярные обновления (не реже 1 раза в год) предотвращают не санкционированный доступ к программному коду. Так как команда разработчиков постоянно выявляет уязвимости и выпускает обновления для тех программных модулей, которые открывают злоумышленникам возможность удаленного исполнения кода.
Привет всем, простите за то что долго не писал. Сегодня хочу с вами поговорить на тему безопасного обновления WordPress. Что сподвигнуло меня на написании этого поста? При работе на одном из сайтов заказчика, я увидел сообщение о выходе нового релиза WordPress () и призыве обновится. Надеюсь вы тоже не раз встречали такое сообщение? 😉
И я конечно же решил обновится, почему я всем вам рекомендую это делать? Дело в том, что с каждым новым обновлением появляются новые функции, о которых вы можете узнать на странице после обновления WordPress. Например одна из новых фишек, которая появилась в движке — это растягиваю мышью. Раньше приходилось изменять размер вручную.
Полезно? По мимо этого, самым главным является исправления ошибок и «дыр», которые все же присутствуют в любом существующем движке, о том я писал раньше. Это самое главное, вот почему следует обновляться…
Так вот, после обновления я вижу сообщение о том, что произошла ошибка и следует обновится вручную. Обновляю я вручную и обнаруживаю, что половина написанных статей отсутствуют, или отображаются неправильно…
Это был шок, мне пришлось выкачивать базу данных, потом вручную добавлять все таблицы, корректируя их. Провозился я часов 5 не меньше, так что, что бы обезопасить свое творчество, время и силы, необходимо постоянно делать бэкап данных перед обновлением.
В этом деле вам поможет плагин, о котором я , создавайте резервную копию данных одной клавишей, сохраняйте ее на своем компьютере и будьте уверены, что все данные в любом случае будут при вас.
Для того, что бы обновить WordPress автоматически нам ничего не нужно, как только вы увидели сообщение о том, что доступна новая версия WordPress, тут же создаете резервную копию WordPress с помощью плагина который я описал чуть выше и обновляете.
Для этого, просто переходите в Консоль и нажимаете на кнопку Обновить. После этого вас перекидывает на страницу, где вы можете просмотреть результат обновления и ознакомится с новыми фишками, которые были внедрены разработчиками в новую версию.
Данный этап немного сложнее чем первый, для начала опять же создаем резервную копию сайта с помощью . И чистим КЭШ блога, что бы избежать возможных ошибок совместимости и так далее. Как это сделать я расскажу в следующей статье, что бы не пропустить.
Первое. После того, как правила безопасности соблюдены, необходимо . Желательно это делать с официального сайта, потому что различные доработанные версии могут быть чем-то и лучше, но так же с ними могут возникнуть и проблемы.
Второе. Распаковываем архив и удаляем папку wp-content. Для чего это нужно? В данной папке хранятся все ваши файлы: , изображения, которых набирается куча с первого дня ведения блога. новую папку нужно удалить, что бы она случайно не заменила папку с вашими файлами.
Третье. Подключаемся к вашему сайту через FTP, с помощью . Заходим в корневую папку вашего блога и делаем следующие действия:
Четвертое. Открываем в скачанный файл wp-config и файл в новом релизе WordPress wp-config-sample. И сравниваем их, также одновременно переносим из wp-config в wp-config-sample данные, такие как DB_Name, DB_User, DB_Host и т.д После чего сохраняем новый Wp-config-Sample файл, переименовывая его в Wp-Config.
Пятое.
Закачиваем все файлы нового скачанного движка в вашу корневую папку блога. Заметьте, что вам часто будет выдаваться сообщение о том, что такой файл уже существует, вы должны заменять старый файл и добавлять новый, для этого нажимаем «Перезаписать» и поставьте флажок над «Всегда использовать это действие», для того, что бы данные сообщение не выводилось +100500 раз.
Шестое. После того, как все данные обновились, заходим в Админку блога и вы увидите сообщение о том, что вам следует обновить Базу данных, обновляем и ВАУЛЯ! Теперь вы обладатель новой версии WordPress…
Напоследок хочу дать несколько советов по обновлению плагинов и тем. Перед тем как обновлять плагины и темы скачивайте их с сайта на компьютер. Бывает так, что новый плагин начинает конфликтовать с WordPress или другими плагинами, либо в него внедрили новые функции, которые вам вовсе не нужны. В этом случае у вас всегда будет возможность загрузить старую версию плагина, а обновление проигнорировать.
В случае с шаблонами или темами (Как вам угодно *pardon*), все изменения которые вы совершали в файлах темы автоматически обновляются на новые. То есть, после обновления тема — девственно чистая. Приходится вспоминать все изменения и добавлять их заново. Если вы сохраните тему заранее, то у вас будет возможность скопировать изменения из старой темы и сохранить уйму времени.
На этом все дорогие друзья, до скорых встреч, надеюсь мне удастся чаще радовать вас новыми статьями и , пока….
DataLife Engine (DLE) - популярная система управления материалами сайта, в народе - «движок». Перенос сайта на движке DLE осуществляется в виде простой переустановки дистрибутива. При этом, используется встроенная способность движка DLE самостоятельно и восстанавливать базу данных (БД). Эта же способность движка задействована и в CMS DLE - придумке от любителей всего новенького и чистенького. Лично мне, такие заморочки требуются исключительно при обновлении движка. После длительной файловой модификации и оптимизации - движок легче снести и переустановить по-новой. Отдельное спасибо Александру Алаеву за его уроки и наставления по оптимизации DLE.
Работа с файлами сайтовой операционной системы начинается с её бекапства (бекапинья). Backup - это спасательный круг. Создание резервной копии веб-ресурса позволит избежать многих проблем, связанных с неудачными файловыми операциями на сайте. Кроме этого, имея дистрибутив движка и резервную копию сайта, можно носить его, хоть по всей Сети.
В принципе, это не ахти какой новшество - использовать для переноса или переустановки движка CMS DLE его встроенную способность бекапить и восстанавливать свою базу данных (БД). Самое сложное и опасное в этом способе - не запутаться в её копиях. Потому что, версия БД должна в точности соответствовать версии самого движка.
База данных от старого движка никогда не встанет на новый, и наоборот
Если при переносе сайта на CMS DLE или переустановке движка не меняется его версия - можно забекапить старую базу данных и в последствии - её восстановить. Если-же версия движка возрастает, базу данных обязательно нужно будет сначала обновлять до актуальной версии, затем - бекапить, а в последствии - восстанавливать её, и только её. Использовать базу данных сайта и его движок разных версий не получится. Обновлять базу данных несложно. Она обновляется автоматически при обновлении самого движка. Причём, это не обязательно делать прямо на хостинге, можно и на локальной машине, используя пакет .
Первым делом - сотворяем бекап из своего любимого сайта (backup - резервная копия).
Сделать резервную копию (backup) в 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 и приступаем)
После создания и выкачивания из хостинга полной! резервной копии (backup) сайта,
приступаем к непосредственному обновлению его движка - CMS DLE.
При этом, происходит, примерно - следующее:
«Чистое обновление» - движка сайта CMS DLE
Алгоритм действий, примерно такой:
После таких издевательств над собой, наш сайт на DLE должен окончательно ожить в обновлённом виде. Теперь, уже обЕзательно - нужно зайти в админку сайта и выполнить по-новой все
Вопрос обновления CMS всегда остается актуальным, независимо от того, какая версия используется для работы сайта, рано или поздно все равно выйдет пакет с исправлениями, улучшениями или новым функционалом.
Глобальное обновление с переходом на более новую линейку имеет некоторые нюансы, поэтому полезно рассмотреть процесс более подробно.
Раньше обновлять версию Joomla приходилось вручную с помощью FTP . В этом случае старые файлы заменялись новыми, скачивать обновление надо было самостоятельно с официального сайта.
Такие пакеты, как правило, имели названия Joomla x.x Update Package . С выходом 2-ого поколения CMS, разработчики дополнили основной функционал встроенным механизмом обновления ядра.
Чтобы обезопасить себя и не потерять данные во время установки новой версии движка, рекомендуется перенести резервную копию сайта на локальный сервер. Выполнить это можно при помощи akeeba backup .
После этого нужно проверить наличие обновлений для текущей версии CMS и сторонних расширений, в случае их наличия установить все необходимое. Если используются расширения, которые не поддерживаются в Joomla 3.x , то их следует удалить заранее:
На следующем шаге нужно проверить совместимость хостинга с обновленной версией Joomla , для этого в меню «Сайт » выберите пункт «Информация о системе ».
Все настройки, которые отобразятся на открывшейся странице, должны отвечать минимальным системным требованиям разработчика. Эта информация доступна по адресу http://www.joomla.org/technical-requirements.html:
Проверьте базу данных на ошибки, для этого в «менеджере расширений » перейдите на вкладку «База данных ». Если все находится в норме, то система выдаст сообщение следующего характера: «Структура таблиц базы данных в актуальном состоянии ».
В том случае, если обнаружены ошибки, надо нажать кнопку «Исправить », которая находится в правой части страницы:
Теперь можно создать тестовый сайт, который должен находиться в поддомене на том же сервере, что и основной. Не забудьте сделать для него копию базы данных.
Сначала все операции выполняются на тестовом сайте. Чтобы начать переход к версии Joomla 3.x , нужно перейти в меню Компоненты и выбрать там пункт «Обновление Joomla! ».
В правой части страницы появится кнопка «Параметры », после нажатия которой, откроется окно с настройками:
Здесь следует изменить тип источника обновлений. По умолчанию выбраны «Дистрибутивы Joomla с длительным периодом поддержки ».
На данный момент в линейке 3.x выход такой версии только ожидается, поэтому нужно переключить сервер обновления на «Дистрибутивы Joomla с краткосрочной поддержкой ».
В некоторых случаях кнопка «Установить обновления » появляется не сразу, поэтому необходимо в меню «Расширения » выбрать подменю «Менеджер расширений », где на вкладке «Обновление » нажать кнопку «Очистить кэш »:
Теперь в разделе «Обновление Joomla! » появятся данные о самой последней доступной версии CMS. После установки проверьте базу данных на наличие ошибок.
В случае успешного завершения процесса, следуя инструкции о том, как обновить Joomla , повторите всю последовательность действий для основного сайта.
Удачи Вам!
Хорошо Плохо
Для создания сложных динамических сайтов веб-мастерами применяется такой метод, как установка joomla на денвер. После этого создаётся новый шаблон сайта, происходит…
