Обновление Joomla и возможные ошибки. Обновление 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.

При этом, происходит, примерно - следующее:

1. Предварительное обновление сайта, которое делается с одной-единственной целью -
   обновить базу данных (БД) сайта до уровня движка новой версии.
2. Обязательное создание резервной копии (backup) из обновлённой базы данных
3. Обязательное сохранение резервной копии (backup) из обновлённой базы данных
4. Полный снос системных файлов движка.
5. Заливка на хостинг новых файлов и установка новой управляющей системы.
6. Восстановление обновлённой базы данных из её резервной копии (backup).
7. Пользовательская настройка движка сайта «по-новой».

«Чистое обновление» - движка сайта CMS DLE

Алгоритм действий, примерно такой:

1. Совершаем обычное обновление CMS DLE, согласно инструкций разработчика.
2. Проверяем работоспособность своего сайта. Если всё «тип-топ», «YES» и «OK» - снова обязательно! делаем сайта и его базы данных. После чего, выкачиваем этот полный бекап к себе на локальную машину. После переустановки движка сайта база данных будет удалена и её придётся восстанавливать именно из этой, обновлённой и рабочей копии.
3. Удаляем на хостинге папки:
   Engine и language.
4. Не удаляем папки:
   backup - это копии базы данных (БД)
   templates - это шаблоны страниц сайта
   uploads - это самая ценная папка. В ней хранятся картинки и файло́ из новостей, публикаций и стат.страниц, а также личные файлы и аватары пользователей.
5. Выполняем новую установку движка, согласно инструкции разработчика. ВНИМАНИЕ! Во время новой установки движка CMS DLE, установщик сотрёт настоящую базу (БД) данных и создаст свою, другую. В этой БД будут только две-три новости-демки от DLE.
6. Восстанавливаем свою родную БД из обновлённой копии, сделанной накануне.
   Для этого, заходим в админпанель, в раздел «Список всех разделов» => «Управление базой данных» и жмём кнопочку «Восстановить базу данных». В списке копий выбираем именно ту самую копию, которая была сделана после её последнего обновления до новой версии управляющей системы.
7. Чистим кэш движка и браузера:
   - Кнопочка «Очистить кэш» находится в низу главной страницы панели управления
   - Очистить кэш браузера - Ctrl+Shift+Del

После таких издевательств над собой, наш сайт на DLE должен окончательно ожить в обновлённом виде. Теперь, уже обЕзательно - нужно зайти в админку сайта и выполнить по-новой все

К нам обращаются владельцы сайтов с разными целями (добавить на сайт новые функции/возможности, выполнить редизайн сайта, сделать адаптивную верстку и т.д.). И первое, на что мы обращаем внимание, - на большинстве сайтов CMS давно не обновлялась. Практически во всех таких случаях в ТЗ дописываем еще 1 пункт - обновление CMS. В этой статье расскажем, почему это важно.

Причины, по которым вам стоит обновлять CMS:

1. Вы подвергаете себя опасности быть взломанным.

Большинство CMS - лакомый кусок для хакеров. Поэтому разработчики выпускают новые версии, изменения в которых связаны именно с усилением безопасности. Об этом пишут кратко в описании обновления. Такие обновления рекомендуем устанавливать своевременно.

2. Вы используете сайт с багами, глюками, которые вас наверняка даже раздражают, но вы с ними миритесь.

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

3. Ваш сайт устаревает морально и технически.

Когда вы работаете со своим сайтом, то со временем замечаете, что некоторые моменты нужно изменить, чтобы вам и вашим пользователям стало удобнее пользоваться сайтом, или когда вы поняли, что пора делать редизайн сайта (подробнее в ). Например, улучшить поиск, добавить фильтры продукции, поменять принцип отображения фото и т. д. Вы спросите: при чем тут обновление CMS, если можно просто доработать существующие модули/плагины? Можно и доработать, а может, эти функции есть в коробке в новой версии вашей CMS. Тогда вы убьете сразу нескольких зайцев - и новые функции получите, и о безопасности позаботитесь, и используемые фреймворки обновите.

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

Как часто выполнять обновления?

Многие CMS о новых версиях уведомляют в админке с кратким описанием изменений: касаются они добавления новых функций и возможностей, устранения ошибок или проблем безопасности.

На скриншоте ниже пример такого уведомления в админке сайта на WordPress, с активной ссылкой на официальный сайт и описанием возможностей, которые вам будут доступны после обновления:

Админка WordPress с краткими новостями по последним обновлениям CMS и не только

Как вы понимаете, важно обновлять систему каждый раз при выпуске версий с устраненными ошибками и проблемами безопасности .
Новый функционал - это уже по желанию, может быть, он вам прямо сейчас и не нужен, и такое обновление может подождать.

Совет: перед обновлением и после добавления большого количества товаров, фото, статей обязательно делайте бэкап . В большинстве CMS есть встроенные модули создания/восстановления резервной копии либо плагины. Также создать/восстановить бэкап можно средствами админпанели хостинга. Обычно создать бэкап очень просто, и это может сделать владелец сайта без особых знаний принципа работы CMS. В хостинге можно разобраться самому либо написав в техподдержку.

Как обновлять?

Собираем все учетные записи (база данных, FTP, доступы в админку сайта).

Обновление может осуществляться автоматически, в несколько кликов в админке сайта (рис. 2-4), либо по FTP (для некоторых CMS это возможно только по FTP). Но принцип один и тот же - на сервере обновляются файлы, а в базе данных меняется структура таблиц либо самой базы данных. Обновление базы данных происходит практически незаметно для того, кто производит обновление, обычно от вас требуется только вводить данные для подключения к базе данных и нажимать кнопки «ОК» и «Далее», все остальное скрипт обновления сделает за вас.

Рисунок 2. Автоматическое обновление системы WordPress. Шаг первый — «волшебная кнопка»

Рисунок 3. Шаг второй — смотрим все, что система автоматического обновления нам предлагает «освежить». Тут и сам движок, и плагины (также могут быть темы)

Рисунок 4. Шаг третий, заключительный - отчет о внесенных изменениях и состоянии обновления (иногда могут быть ошибки, о которых мы на этом шаге и узнаем, в таком случае придется восстановить сайт из бэкапа)

Следует заметить, что иногда, особенно если сайт давно не обновлялся, могут меняться принципы подключения к базе данных в конфигурационных файлах, вызова функций, поддержка той или иной функции и т. д.

Обычно о том, какую примерно ручную работу по обновлению сайта с вашей версии CMS на последнюю необходимо будет выполнить, можно почитать на форуме разработчиков вашей системы управления сайтом и/или в документации. Часто для того, чтобы обновить старую версию до последней, нужно сделать обновление в несколько этапов. Например, обновление WordPress с очень старой версии, вроде 2.х до 4.х .

Также нужно быть готовым к тому, что большинство систем управления сайтом не поддерживают обновление шаблонов и существует большая вероятность, что ваш шаблон нужно будет переписывать для корректной работы (например, при обновлении с Opencart 1.5.x до 2.x, с Shop-Script (WebAssist) версии ниже 5 до 5.x/6.x).

Кому делать обновление?

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

В остальных случаях, особенно, если у вас интернет-магазин, рекомендуем делать обновление на тестовой версии, например, на поддомене на сервере, где расположен ваш сайт, и тщательно все протестировать, прежде чем перенести обновленную версию на работающий сайт.

Как проверить, все ли правильно настроено, и что именно проверять?

Обязательно нужно удостовериться, что после обновления весь функционал работает корректно.

Давайте рассмотрим минимальный набор тестов корректной работы CMS на примере магазина. Нам нужно сделать следующее:

• Чисто визуально оценить, нет ли проблем с версткой на главной и всех типах внутренних страниц.
• Зарегистрировать нового пользователя, сделать покупку, т. е. пройти все шаги заказа от непосредственного оформления заказа до уведомления о доставке пользователю. Все эти шаги выполните во всех доступных вам ролях: пользователя, менеджера, администратора и т.д.
• Проверить работу фильтров, поиска, постраничной разбивки и т. д.
• Проверить URL"ы, тайтлы, ключи и описания.

Если что-то работает некорректно, есть два варианта: восстановить сайт из бэкапа либо, если ошибка не критична, попытаться исправить ее на рабочем сайте.

Подведем итоги:

1. Следите за обновлениями своей CMS и обновляйтесь своевременно:
а) для безопасности;
б) чтобы от вашего сайта не веяло 90-ми.

2. Выделяйте время на тестирование обновленной системы (а также просите друзей и родственников о совете и помощи в тестировании).
3. Перед обновлением и, вообще, регулярно делайте бекапы.

В начале этого года был разработан ряд доработок для форума. Некоторые из них реализовывались путем обновления движка до последней версии. В связи с этим и был осуществлен переход. Как правило, обновление CMS обладает рядом преимуществ:

• В новых версиях устраняются недостатки, баги, ошибки и "дыры";
• Появляется дополнительный функционал;
• Поддерживается современность и актуальность движка.

Но в моем случае дополнительно к этим пунктам добавился 1 очень каверзный баг, который, на мой взгляд, и стал главной причиной резкого с поисковых систем. Графики посещений с Яндекса и Google (по неделям). Стрелочкой указана примерная дата обновления.

Поисковая посещаемость упала более чем на 1000 ежесуточных посетителей.

Замечу, что обновление не носило радикальный характер (обновлялась версия той же линейки). Появился вопрос "Что же повлияло на падение посетителей с поисковых систем". После обновления пользователи начали жаловаться на один баг, который время от времени стал появляться. При клике на одну страницу, форум перекидывал пользователя на другую. В основном, были затронуты URL"ы тем. Также браузер иногда отдавал ошибку о невозможности перехода по указанному урлу из-за циклической переадресации.

Я начал анализировать аккаунты для вебмастера в Яндексе и Google. В гугле после перехода на новую версию движка резко подскочили ошибки, относящиеся к URL - "Переход не выполнен".

Данные ошибки как раз начали появляться сразу после обновления (график начинается немного позднее - с начала марта). Почему баг каверзный? Все просто. Его до сих пор пока никто не смог обнаружить и исправить. Но я не теряю надежды и буду стараться как можно скорее избавиться от него .

Я задал вопрос службе поддержки Яндекса по этому поводу. Получил, на первый взгляд, обнадеживающий ответ.

Но, как видно из графиков посещаемости с Yandex, трафик продолжил свое падение. Получается, что иногда поисковый робот получает на свой запрос, либо циклическую переадресацию (не может выполнить переход), либо клоакинг (в выдаче одна страница, а осуществляется перенаправление на другую). Конечно, после таких ошибок не удивительно, что посещаемость резко пошла вниз.

Стал бы я обновляться, зная, какие последствия ждут меня впереди? Конечно, нет. Та пара пунктов из доработок, которые требовали новую версию, не покрывает некоторые неудобства для пользователей и поисковых роботов.

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

Кто-нибудь из вас сталкивался с проблемами после обновлений CMS? Поделитесь своим опытом и путями их решения. Желаю всем, чтобы баги и ошибки обходили ваши проекты стороной, а посещаемость с поисковых систем показывала только положительный рост !

Клиенты обращаются в наше агентство по разным вопросам: касательно создания и продвижения сайтов , редизайн а, чтобы заказать адаптивную верстку и так далее. В большинстве случаев наблюдаем, что cms сайта давно не обновлялась.

Тогда мы предлагаем клиенту обновить систему cms . Так ли это необходимо? Чем грозит владельцу сайта устаревающая система управления ? И какие преимущества от обновления cms можно ожидать? На эти и другие вопросы мы постараемся дать ответы в данной статье.

Что такое cms сайта и зачем она нужна

CMS или система управления контентом сайта - это программное обеспечение, с помощью которого, Вы легко можете управлять сайтом и наполнять его контентом, не владея, при этом особыми знаниями и навыками программирования. На сегодняшний день существует множество различных CMS , все они делятся на платные и бесплатные системы управления, а также на CMS с открытым и закрытым кодом.

Среди самых популярных движков 1С-Битрикс, UMI.CMS, WordPress, Joomla !

Узнать, какая система управления контентом установлена на Вашем сайте, можно воспользовавшись плагином для браузера Wappalyzer.

Обновлен - значит защищен

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

Ошибки в системе безопасности устаревшей CMS сайта - пригласительный билет для хакеров. Именно сайты на устаревшей CMS в первую очередь подвергаются атакам и взломам. Как правило, взломы совершаются с целью принудительно перенаправить посетителя Вашего сайта на абсолютно сторонний ресурс или с целью распространения вируса среди посетителей. Особое внимание владельцам сайтов здесь следует обратить

на то, что сайты, зараженные вирусом, блокируются поисковыми системами. По статистике около 70% взломов приходится именно на сайты с устаревшей CMS. И это вполне логично, ведь если есть открытое окно, зачем злоумышленнику ломиться в запертую дверь?

Итак, вместе с процессом совершенствования ПО свои навыки совершенствуют и взломщики, появляются новые вирусы и вредоносные программы. Поэтому, чтобы удержать баланс «добра и зла» и защитить своих пользователей разработчики систем CMS вынуждены выпускать обновленные более безопасные версии своего программного обеспечения.

Дабы избежать ненужных проблем, которые могут привести к лишним растратам, владельцам сайтов необходимо следить за выходом новых версий и своевременно производить обновление cms до актуальной версии .

Часто задаваемые вопросы

- Могут ли возникнуть проблемы, если не обновлять CMS?

Возможно, сразу Вы не заметите отличия в работе системы управления, сайт как работал, так и будет продолжать работать. Однако со временем (не забываем, что все связанное с информационными технологиями постоянно совершенствуется) могут возникать и накапливаться разного рода проблемы. Как мы уже говорили, могут возникнуть и проблемы с безопасностью сайта.

И если долго пренебрегать обновлением CMS, то может настать момент, когда простое обновление системы управления сайтом до новой версии уже не поможет. В таком случае придется производить перенос сайта на новую систему CMS, а это совсем другие трудозатраты и стоимость услуг здесь уже гораздо выше.

- Что делать, чтобы всегда иметь более совершенную и защищенную CMS?

Необходимо сразу производить обновление системы управления контентом, как только выходит новая актуальная версия. Вы можете заниматься мониторингом обновлений и их установкой как самостоятельно, так и, воспользовавшись нашими услугами по поддержке сайта, в которую включен пункт об обновлении CMS.

- Как часто выполнять обновления?

В интересах самих владельцев сайта обновлять систему CMS, сразу после выхода новых обновленных и усовершенствованных версий, с улучшенной системой безопасности и устраненными недочетами предыдущих версий. Узнать о выходе обновлений можно на

Обновлять CMS - или не обновлять - не вопрос!

Мы еще долго могли бы вести речь о том, стоит ли следить за обновлениями, обязательно ли обновлять систему CMS, но скажем так - обновлять или не обновлять - это не вопрос.

Для того, чтобы это подтвердить, приведем ниже несколько преимуществ, которые однозначно говорят в пользу обновления.

Преимущества своевременного обновления CMS

• Обновленная система безопасности сайта - лучшая профилактика от взломов и атак на сайт.
• Установка обновленных версий системы управления контентом положительно влияет на скорость работы сайта.
• Снижается возможность возникновения ошибок исполнения кода и работы с базами данных
• Обновления позволяют владельцам сайтов использовать новые приложения и расширения, благодаря которым сайт может стать более привлекательным для пользователя, более удобным

Все идет, все меняется, сегодня ваша система совершенна, а завтра кто-то придумал, как ее взломать. Наиболее эффективное решение вопроса - постоянно следить за обновлениями и своевременно производить их установку.

Обновление CMS MaxSite с предыдущей версии

Обычно уже через несколько месяцев владелец сайта задает себе вопрос - как обновить maxsite cms . Пока система молодая почти ежемесячно выходят новые версии с многими полезными улучшениями. В настоящее время самым распространенным является ручное обновление maxsite cms . Для обновления CMS MaxSite нам потребуется FTP -клиент.

Для статьи была использована инструкция обновления cms maxsite по адресу http://max-3000.com/page/maxsite-cms-070

Инструкция от Макса:

Обновляться, как я уже раньше писал, следует так:
Переименуйте текущие каталоги application в application-old и system в system-old .
Загрузите новые файлы MaxSite CMS на сервер.
Установите права на запись (777) на каталог кэша (application/cache/ ) и его подкаталоги.
Скопируйте старые файлы из application : config/database.php и maxsite/mso_config.php .
Скопируйте свой шаблон и сторонние плагины, если вы их устанавливали.
После тестрования каталоги application-old и system-old можно удалить.

Я думаю, для опытных пользователей этого достаточно, а новичкам можно почитать мою более подробную инструкцию. (Конечно, надо в первую очередь смотреть у автора, так как он мог и изменить процесс обновления в связи с добавлением каких-то функций).

Главное - перед каждым обновлением СКАЧИВАЙТЕ ПАПКУ своего САЙТА (из www) с СЕРВЕРА ! через FTP -клиент. Вообще-то надо сохранять сайт раз в месяц - скачать - пометить числом и удалить более ранний архив.

Пункты: Обновление сайта с шаблоном default и Бэкап сайта MaxSite вы найдете в конце статьи.

Ручное обновление maxsite cms

1.1. Во-первых, нам потребуется новая версия движка - latest.zip – которую надо скачать с официального сайта: http://max-3000.com/

1.2. После скачивания её следует разархивировать в папку latest .

Лучше сразу переименовать latest в MaxSite CMS x.xx , где x.xx - номер версии движка, потому что все последние версии на сайте http://max-3000.com имеют одинаковое наименование latest . Храните по крайне мере два мануала движка - раннее и новое, на которое обновляетесь.

Обновление напоминает первоначальную заливку движка на сервер, только поверх файлов существующего сайта.

1.3. Вначале откроем место, куда будем копировать. Запускаем программу FTP -клиента и в окне программы вставляем вверху в поля логин и пароль, которые вам прислал хостер в письме при покупке тарифа. Обычно используется порт 21 . Если нажать на "Быстрое соединение", то в правой части FTP -клиента вверху появятся папочки сервера, из которых для нас имеет интерес лишь самая нижняя - www .

Если кликнуть по папке www , то слева рядом появится квадратик (чекбокс) с плюсиком , клик по которому откроет эту папку. Внутри www будет папка вашего сайта (сайтов) (с именем сайта). Кликнем по оболочке папки сайта, чтобы внизу появилось её содержимое, но внутрь папки входить не требуется - то есть не надо кликать на плюсик рядом с папкой сайта.

1.4. Теперь в левой части FTP -клиента надо найти на вашем компьютере папку latest или MaxSite CMS x.xx , если вы ее переименовали. В верхней части слева по древу доходим до оболочки папки latest (MaxSite CMS x.xx ) и кликнем по ней так, чтобы внизу открылось всё её содержимое.

Собственно справа и слева будет почти одинаковый набор файлов.

Чтобы залить всё, что слева разом на сервер - надо выделить файлы, для чего можно кликнуть по первой строке или лучше прокрутить список файлов до самого низа, где кликнуть по пустому месту. Теперь, если нажать одновременно на клавиши Cntrl и латинская A , то все файлы выделятся.

1.5. Для закачки выделенных файлов на сервер достаточно кликнуть в них правой кнопкой мыши и выбрать в появившемся меню "Загрузить ", чтобы FTP -клиент начал загрузку мануала новой версии движка на сервер поверх файлов, существующих на сайте. Чтобы не мучиться с перезаписью каждого файла, надо FTP -клиенту указать "Перезаписать " и выбрать "для всех файлов ", выставив галочки - флаги.

2. Часто в процессе обновления затираются файлы: config/database.php и maxsite/mso_config.php . Мы их восстановим, следуя инструкции от Макса:

Скопируйте старые файлы из application : config/database.php и maxsite/mso_config.php .

2.1. Восстановим файл database.php по адресу: application/config/database.php .

Вначале в правой части FTP -клиента надо в верхней части нажать на крестик в чекбоксе рядом с папкой сайта, затем опуститься до папки application - кликнуть по ней и, чтобы открыть ее - в появившемся чекбоксе нажать на плюсик. Затем так же в верхней части клиента надо опуститься до папки config , но не открывать, а лишь кликнуть по ней. Сюда будем копировать файл, который у нас есть в сохраненном архиве сайта.

2.2. В левой части клиента вверху откроем папку сайта, сохраненного на ваш компьютер в самом начале, где постепенно открываем папки application , затем config . В последней кликаем правой по файлу database.php и в меню выбираем "Загрузить на сервер".

В результате файл database.php появится в папке application/config на сайте.

2.3. Аналогично поступаем для восстановления файла mso_config.php , для которого в правой части клиента вверху откроем папку application , затем его подпапку maxsite . Слева так же открываем попдпапку maxsite в папке application сохраненного сайта.

Среди файлов сохраненного сайта находим файл mso_config.php - кликаем правой - выбираем "Загрузить на сервер" - проверяем его появление среди файлов папки maxsite на стороне сервера.

3. Теперь на всякий случай – не закрываем FTP -клиент и выставляем заново права на запись (777 ) на каталог кэша – «cache » (путь application/cache/ ) и его подкаталоги «html », «rss » и «bd ».

Их надо просто найти на сайте и, кликнув правой клавишей мыши по их оболочке, выбрать в меню нижний пункт - выставить права - 777 .

4. Аналогично выставляются права на запись (обычно 777 ) на каталог /uploads/ и на вложенные каталоги «_mso_float », «_mso_i » и «mini ». Правда, обычно права на них не изменяются при обновлении.

5. Последними выставляются права на запись (обычно 666 ) на файл sitemap.xml

6. Если вы использовали свой ключ для шифрования cookes , то укажите его в файле «application/config/config.php »:

$config["encryption_key"] = "тут ваш ключ";

Автообновление MaxSite CMS

7. Ручное обновление cms maxsite не всегда удобно, если пользователь имеет большое количество сайтов, работающих на .

8.3. Использовать заготовку _create_a_new_template для создания шаблона (технология default ), даже если используется default логически правильно, так как при обновлении происходит копирование поверх всех файлов движка, включая . Я думаю, что все же лучше держать свои уникальные стили css в отдельной папке.

Бэкап сайта MaxSite

9. Если вы периодически делает сохранение (бэкап) файлов своего сайта на собственный компьютер, то у вас всегда есть возможность закачать на сервер сохраненные папки и файлы оформления вашего сайта. Не забывайте перед обновлением CMS MaxSite делать бэкап сайта MaxSite .

Лучше не перекладывать полностью на хостера вопрос сохранности файлов вашего сайта, ведь серверы у хостера то же могут поломаться. Когда же у вас имеется копия сайта, то нет проблем для восстановления сайта на другом сервере и у другого хостера.