[Статья]

Короткая версия:
Закрыть форум, сделать бэкап, залить новые файлы с перезаписью, вызвать в браузере /install/upgrade.php, следовать инструкциям на экране

Но, увы, те, кому достаточно такой короткой версии, как правило и не спрашивают "как обновиться" - они просто обновляются

Всё чаще появляются вопросы относительно обновления от таких админов, которые зачастую даже не знают, где у них config.php
Дамы и господа, это никак не "наезд" - простая констатация. И ничего такого зазорного в этом нет. Форум мог "достаться по наследству", когда основной админ просто отошёл от дел. Форумы покупаются/продаются. Форум изначально мог быть установлен приглашённым специалистом. И то, что сейчас Вы хотите разобраться и вникнуть, чтобы всё делать самостоятельно - очень и очень похвально.

Так что давайте будем разбираться.

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

Оглавление:
Вместо вступления: Более развёрнутая версия, для тех, кто в первый раз
Основная часть: Полная подробная инструкция по обновлению форума
I. Глава первая. Предварительная диагностика.
II. Глава вторая: "Он сказал - Поехали!"
III. Глава третья: "А теперь - посмеёмся..."
Заключение: полезные ссылки.


Более развёрнутая версия, для тех, кто в первый раз в первый класс, но не совсем чайник:


1. Закрыть форум. Если обновление не на один пункт, а через несколько - выключить все хаки через систему модулей/продуктов
2. Сделать полный бэкап файловой системы + бэкап БД, убедиться, что бекапы - нормальные и их можно поднять
3. Отредактировать конфиг.пхп.нью - убрать .нью, внести все данные
// в принципе, этого можно и не делать, если обновление внутри линейки, там редко добавляется что-то новое, но тогда конфиг.пхп нЕ перезаливать
4. Залить файлы из дистрибутива в те же директории, с перезаписью.
5. Запустить в браузере домен/forum/install/upgrade.php
6. Профессионально тыкать кнопочку "дальше", пока все не закончится
7. По окончании процесса она (вобла) скажет, что надо удалить
8. Залить русик от этой же версии
9. Идти на форум, смотреть, что сломалось
посмотреть, не скосило ли стиль, если таки скосило - либо править, либо искать стиль для этой же линейки (актуально для всей 4ки)
включать хаки по одному, проверять работоспособность
периодически проверять лог ошибок - там много ценной информации

// если обновление не на один пункт, а через несколько - запустить в админке диагностику файлов, она расскажет, что осталось валяться лишнее (Файл не является частью форума) - если это точно файл не от хака, смело удаляем

10. Если всё благополучно - включаем форум, радуемся жизни)

При попутном ветре и шустром фтп процесс занимает минут 20

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

Глава первая. Предварительная диагностика.

Прежде всего необходимо прогуляться в ПМА (ПхпМайАдмин, phpmyadmin) и внимательно посмотреть на свою базу данных
Куда смотреть?
В самый низ, где под списком всех таблиц выводится информация о БД в целом

Скрин:

Все новые таблицы будут создаваться такими, какое указано дефолтное значение для базы
то есть, в примере со скрина это будет MyISAM и utf8_general_ci
Кстати, это касается не только обновления, но и установки хаков (если в коде установки не указано иное, но это уже совсем другая история)

Итак, на скрине мы видим:
вся БД - в utf8_general_ci
основные таблицы - тоже
И это абсолютно правильно!

Для собственного успокоения посмотрим на обожаемую кириллицу, лучше всего для диагностики заглянуть в таблицу post (пост) - обзор

Скрин:

Когда говорится, что

Originally Posted by Luvilla

Все таблицы базы должны быть в одной кодировке
Все строковые поля таблиц должны быть в кодировке таблиц

то речь вот об этом:

Скрин:

*пояснение: при дефолтной установке БД MyISAM и utf8_general_ci не все таблицы будут такие же, MyISAM, и не все поля - в utf8_general_ci
Вы можете увидеть ещё MEMORY - штатно только для таблиц сессий
Или поля в кодировке _bin - скажем, в таблице attachment (вложения)

Скрин:

Если всё так, как на скринах - смело можно двигаться дальше
Если все нЕ так... а что может быть НЕ так?

например, форум переезжал на другой хостинг (на другой сервак внутри хостинга, на свой сервер... не_важно)
при корректной правильной изначальной установке БД была создана правильно, с кодировкой проблем нет, все таблицы и поля в них - в корректной кодировке, утф или 1251
Но при переезде забыли проверить кодировку всей БД - а она по дефолту создаётся в латин1
И вот у нас прекрасно работающий форум, повторяю, без проблем с кодировками, но вся БД (первый скрин, помните, внизу?) - в latin1_swedish_ci

Что при таком раскладе будет происходить при обновлении?
да то же самое, что постоянно происходит при установке хаков: новые таблицы будут созданы в дефолтной кодировке БД, кириллица в них будет записываться в виде кракозябрицы, ну и дальше - понятно... куча проблем...
Кроме того, при обновлении не внутри линейки, где меняется только третья цифра версии, скажем, с 3.8.2 на 3.8.4, а при обновлении "between major versions of vBulletin"... как это по-русски... при смене линейки, когда происходит очень много обновлений в таблицах, то они создаются, то в них дописываются поля, то меняются значения полей... высока вероятность в процессе обновления получить ошибку

MySQL Error : Illegal mix of collations (cp1251_bin,IMPLICIT) and (latin1_bin,IMPLICIT) for operation '='
Error Number : 1267

Illegal mix of collations: Недопустимое сочетание сопоставлений, или, по-простому, винегрет из кодировок
Обновление при этом встанет колом, и Вам всё равно придётся отправляться в БД и пытаться вылечить её
Поэтому будем лечить сразу
Как?
В ПМА, находясь не в просмотре таблицы, а на главной БД (список всех таблиц), жмём кнопку "Операции"

Скрин:

Попадаем вот сюда:

Скрин:

Выбираем правильную кодировку, сохраняем
Эта операция не изменит состояния уже существующих таблиц, а только укажет скриптам обновления движка (и заодно - скриптам установки хаков), в какой кодировке создавать новые таблицы

ОК, с БД мы разобрались, что ещё?
Следующий пункт, который хорошо бы сделать перед обновлением - проверить установленные хаки (продукты/модули)
Сейчас речь пойдёт не только и не столько о работоспособности хака на той линейке, на которую Вы собираетесь обновляться
Есть более важный момент.
Дело в том, что продукты, грубо говоря, бывают трёх типов:
- просто продукт, импортируем через админку, он работает
- продукт + файлы, файлы заливаем по директориям, продукт импортируем, всё работает
// в обоих вышеперечисленных пунктах возможно требуется ещё ручная правка шаблонов, но это больше относится к установке новых стилей, чем к обновлению
- и третий вариант, важно именно при обновлении: продукту для корректной работы требуется правка исходных файлов движка

Поскольку при обновлении мы заливаем все файлы - новые, понятное дело, все правки в старых файлах уйдут в небытие... и Вы сломаете голову, выполняя пункт 9 из Развёрнутой версии "включать хаки по одному, проверять работоспособность" - почему хак не работает?

Если Вы сами устанавливали все продукты и точно знаете, есть/нет правленных файлов, смело пропустите этот пункт инструкции.

Как узнать, была ли правка исходных файлов?
Два способа.
1. Админка - Обслуживание - Диагностика - "Версии устаревших файлов" (может быть "Подозрительные версии файлов" или как-то так, зависит от версии перевода)
что полезного тут можно увидеть... это штатная диагностика, она проверяет соответствие файлов текущей версии и рассказывает, что ей не нравится
примеры:

Версия файла не совпадает: у вас 3.8.4 , а должна быть 3.8.4 Patch Level 2 - достаточно часто бывает при неправильно проведённом патче

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

Файл не содержит ожидаемого содержимого - наш случай. Это штатный файл движка, но внутренняя диагностика сравнила контрольную сумму и обнаружила различия.
Означает ли это, что файл был правлен для установки хака? - совсем не обязательно. Он мог быть перезалит, по какой-то причине, просто от другого нуля, где-то не совпадает один символ, диагностика это ловит.
Но если штатная диагностика не обнаружила таких файлов - это уже результат: правленных файлов нет, можно обновляться.

Что же делать, если "Файл не содержит ожидаемого содержимого" вывелось много раз?
не повезло...
2. Админка - продукты и модули - управление продуктами
Здесь мы видим список установленных продуктов
по крайней мере тех, которые импортировались как продукт
есть ещё отдельная категория хаков, где есть свои пхп-файлы и файлы битфилдов, но нет продукта - с позволения читателей я не буду забивать новичкам голову этой экзотикой
У большинства продуктов название - кликабельное, это ссылка на тему продукта.
Ахтунг! В большинстве случаев это ссылка на орг. Тыкайте в ссылку, только если у вас - лицензия. В ином случае (нЕ_лицензия) копируйте ссылку и открывайте отдельно, дабы реферрер не записался в лог, а то мало ли...
Идём по ссылке и читаем ридми. Если правки файлов нет - идём дальше, смотрим следующий продукт. Если в инструкции по установке расписано, какие штатные файлы надо править... в общем, я бы порекомендовала подумать, насколько необходим на форуме этот хак? может, поискать аналог без правки файлов?
Ну и, в общем, понятно: если хак жизненно необходим и аналогов нет - копировать себе ридми, чтобы после обновления выполнить всё по инструкции.

И отдельно - про файл includes/init.php
Если штатная диагностика не показала, что файл "не содержит ожидаемого содержимого" - пропустите этот пункт инструкции.
Если же файл правлен - скорее всего, вот по этой инструкции Кодировка vBulletin - хорошо бы разобраться, зачем он был правлен, и будет ли форум нормально работать с кодировками без этих костылей. В большинстве случаев на нормальных современных хостингах костыли нЕ требуются. Узнать, будет ли всё нормально, или нЕ будет, можно только экспериментальным путём. И лучше это сделать перед обновлением.
Как провести такой эксперимент? - элементарно: после того, как закроете форум и сделаете бэкап БД, просто залейте неправленный init.php и посмотрите на результат. Сделайте тестовый пост, посмотрите на кириллицу в посте и в БД - всё нормально? все буквы на месте? - ну и замечательно, в новом ините правки не требуются.
Всё сломалось? форум вдруг стал кракозябрами? - бывает... печально, но бывает. Значит, в новый инит тоже придётся пихать костыли.
Хотя есть ещё один вариант, мы рассмотрим его в следующей главе, когда будем изучать файл конфига.

// на этом сделаем небольшой перерыв, продолжение следует

Глава вторая: "Он сказал - Поехали!"

Подробно про config.php

В дистрибутиве нет файла config.php, есть config.php.new и лежит он в папке includes.
Если обновление внутри линейки, нет необходимости заполнять и перезаливать конфиг: там нет ничего нового
Если обновление на следующую линейку (через линейку...) - да, есть смысл залить новый конфиг. Как его заполнять, откуда брать данные?
всё просто: из старого конфига, того, что лежит у вас - /includes/config.php

Ахтунг!!! если используете переведённый файл конфига, будьте крайне внимательны, не сохраните файл с БОМ'ом (BOM - что это за зверь и как с ним бороться)
Проблема бом-бом достала уже даже разрабов воблы, в новом ридми по установке они указывают:

Note: We recommend using Wordpad on Windows and TextEdit on OS X.

раньше они писали просто - text editor

Нам нужны пункты (на примере конфига от 4.2):

$config['Database']['dbname'] = ''; - сюда копируем имя базы

$config['Database']['tableprefix'] = ''; - если в старом конфиге был префикс для таблиц, не забываем скопировать тот же префикс

$config['Database']['technicalemail'] = 'dbmaster@example.com'; - даже если в старом конфиге была заглушка, dbmaster@example.com, ставим сюда свой актуальный мыл. Если менялся хозяин форума - тоже проверяем актуальность е-мейла

$config['MasterServer']['username'] = 'root';
$config['MasterServer']['password'] = '';
имя юзера и пароль

$config['Misc']['admincpdir'] = 'admincp';
$config['Misc']['modcpdir'] = 'modcp';
если админка и модерка переименованы - вписываем (копируем из старого конфига) сюда имена директорий.
Обращаю ваше внимание на этот пункт.
Есть тенденция переименовывать админку с модеркой, но в конфиг эти изменения не вносить... как я уже говорила на одном форуме - поймать бы того спеца, который выдумал этот маразм по безопасности, и пригласить ко мне на процедуры...
Имена директорий админки и модерки по факту и прописанные в конфиге должны совпадать. Точка.
При обновлении переименованные админка с модеркой важны - нам нужно знать, куда заливать новые файлы админки/модерки. Если пнуть файлы заливаться "как есть", просто создадутся новые директории admincp и modcp, в переименованных останутся старые файлы.
Соответственно, либо переименовываем папки в дистрибутиве перед тем, как заливать; либо заливаем всё гамузом кроме этих двух папок, а их потом заливаем отдельно, файлы внутрь директории

Возвращаемся к заполнению конфига...

$config['Misc']['cookieprefix'] = 'bb'; - несущественно

При копировании информации из старого конфига в следующих пунктах обратите внимание, нет ли там посторонних ИДов

$config['SpecialUsers']['canviewadminlog'] = '1'; - ИД(ы) администраторов, кто может смотреть лог действий администраторов в админке

$config['SpecialUsers']['canpruneadminlog'] = '1'; - ИД(ы) администраторов, кто может удалять/очищать лог действий администраторов в админке

$config['SpecialUsers']['canrunqueries'] = ''; - ИД(ы) администраторов, кто может выполнять сиквел-запросы из админки

$config['SpecialUsers']['undeletableusers'] = ''; - "неудаляемые" пользователи - ИДы юзеров, чей профиль нельзя отредактировать через админку

$config['SpecialUsers']['superadministrators'] = '1'; - обожаю это слово, "суперадминистратор"... ИД(ы) админов, кто может выдавать/снимать админские права с других админов

И, наконец, мы дошли до пункта про кодировку
// $config['Mysqli']['charset'] = 'utf8'; - краеугольный камень проблем с кодировками, та самая "строка про утф", которую рекомендуется раскомментировать...
сто раз говорено было, но распишу ещё раз.
По дефолту строка закомментирована - то есть, в начале строки стоит два слеша // и пробел
"Раскомментировать" - означает убрать эти два слеша с пробелом.
Если кодировка форума - утф, то просто раскомментируем и всё
если кодировка форума 1251 - вот его сюда и вписываем вместо утф
Ахтунг! вписываем в пхп-формате, cp1251, а нЕ браузерном, windows-1251
cp1251 - латинскими буквами, це пе, а не русскими эс эр
нефик ржать, админы со стажем... своими глазами видела, и не раз, в конфиге и не только в конфиге, русские эс эр...

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

Итак, форум закрыт, бэкап сделан?
при обновлении внутри линейки делать бэкап файловой системы - не обязательно, хоть и не помешает
при обновлении, скажем, с тройки на 4ку, бэкап файлов - крайне желателен
При любом обновлении бэкап БД - обязателен.

Поехали!

Закрываем форум по .хтаксесс, денай фром олл, разрешаем только своему ИП
подробнее про .хтаксесс: [FAQ] .htaccess .htpasswd
если этого не сделать, есть вероятность взлома, именно в тот момент, пока доступен /инсталл/

Заливаем файлы с перезаписью
Вызываем в браузере /install/upgrade.php - процесс пошёл...

Кстати... в новых ридми (к 4ке) есть такой замечательный совет: перед тем, как заливать файлы для обновления, Delete install/install.php from your upload directory
Это чтобы случайно не получилось "не туда ткнул"...
причём "не туда" ткнуть надо несколько раз, чтобы снести существующую БД и всё поставить по новой
в любом случае - респект тому, кто писал это новое ридми

Возможные проблемы

их есть, и несколько...
у тройки, на каких-то шагах при обновлении с 3.6.х - ошибки удаления/создания таблиц
у 4ки, при обновлении с каких-то 4.0.х - периодически, не всегда, апгрейд становится колом на степ15 в обновлении до 408
отдельный разговор для 4ки, когда обновление с форума на сьют...
в большинстве случаев ошибки - индивидуальны, задавайте вопросы в этой теме

Но в целом, если все рекомендации по предварительной подготовке выполнены, обновление проходит гладко.

Глава третья: "А теперь - посмеёмся..."

Итак...
мы героически досмотрели на экране блокбастер vB_Upgrade
всё у нас получилось, воблочка всем довольна

Мы зашли на форум, вроде, всё живое...
Что дальше?
Открывать форум?
Ни в коем случае!
У нас, как минимум, версия перевода не совпадает с версией движка, да и хаки выключены...

Важно! Только для четвёрошников: Если после обновления Вы зашли в админку, и Ваша воблочка не потребовала удалить каких-то файлов или директорий, то это ещё не значит, что можно расслабиться! Сразу после обновления удаляйте папку /install/, пока Вас не взломали!

Важно! Для всех линеек! Если у вас установлен Debug Mode From AdminCP (и включен для вашего аккаунта) или прописан Debug Mode в конфиге, движок нЕ выведет сообщения о необходимости удалить /инсталл/ (про тулс.пхп, кстати, при включенном дебаге вобла тоже будет молчать, как рыба))
Не забудьте удалить /инсталл/
нЕ переименовать, а именно удалить, совсем

Первое, что делаем после обновления движка - обновляем перевод.
Всё про перевод и сам перевод - в этой теме, не забываем благодарить переводчика: Русификация vBulletin
Будьте внимательны, смотрите на кодировку

Да, кодировка...
если перед обновлением у нас нЕ был правлен инит.пхп - см. Предварительная диагностика и уже была раскомментирована "строка про утф" в конфиге, то как правило, никаких проблем и не будет.
Если же при подготовительных работах пришлось изымать костыли из инита, давайте перестрахуемся... тут всё просто: оставьте на форуме стандартный тестовый пост кириллицей, убедитесь, что после отправки и обновления страницы он и остался кириллицей, и посмотрите, как он записался в таблицу "пост".

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

Как правило, хаки для 3.6.х, 3.7.х и 3.8.х - "сквозные", и работают на всех трёх линейках
кое-где требуется лёгкий удар кувалдой, но обычно все инструкции, "куда бить", есть в темах с хаками, читайте
Не забываем, что хаки полезно обновлять, даже если они "вроде работают" - как минимум, из-за вопросов безопасности.

Некоторая часть хаков, разработанных для тройки, работает и на 4ке... правда, чем дальше развивается 4ка, тем меньше остаётся таких хаков...
однозначно нЕ работают на 4ке троечные хаки с врезкой в шаблоны: у 4ки совсем другая система шаблонов.
Поэтому рекомендуется обновить хаки на актуальные для своей версии.

Только для четвёрошников: Начиная с 4.2.0 в движок штатно добавлено довольно много функционала, того, который раньше добавлялся хаками.
Поэтому, если Вы обновились с древней 4ки на свеженькую, перед включением/обновлением хаков настоятельно рекомендуется изучить штатный функционал.

Важно:
- включил хаки - всё пропало! белая страница на форуме, в админку не зайти!!!
- спокойствие, только спокойствие... открываем includes/config.php и в любое место (только вне комментариев) дописываем строку
define('DISABLE_HOOKS', true);
сохраняем
эта нехитрая операция отключит все продукты глобально (включая ЦМС и блоги у 4ки-сьют), и даст Вам возможность зайти в админку. После отключения проблемного хака через управление продуктами не забудьте убрать строку из конфига.

И третье: стили.
В общем и целом, стили для 3.6.х, 3.7.х и 3.8.х - вполне компатибельны... ну, за исключением тех случаев, когда требуется лёгкий удар кувалдой по маркеру безопасности
Никакие стили от 3.х.х нЕ подходят к 4.х.х.
Внутри 4ки - тоже... со стилями всё непросто... если нет времени, желания или квалификации заниматься исправлением множества косяков со стилем, перед обновлением обязательно запаситесь стилем именно от той версии, на которую обновляетесь.

Считаю необходимым предупредить: уважаемые чертвёрошники! Если вы дочитали до этого места и у вас возникло желание поспорить с пунктом "множество косяков" - будьте столь любезны, откройте разделы с вопросами по 4ке и помогите новичкам. Потратьте время на позитив и устранение оных косяков, а не на споры со мной.

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

wow!

Luvilla, Я могу по твоем сценарию фильм снять, если ты не против..

Luvilla, ты же сказала что пришла с мероприятия. Это так мероприятия влияют?
Хорошо написано)

Originally Posted by Sven

Это так мероприятия влияют?
Хорошо написано)

То был трезвый корпоративчик

Originally Posted by StenLi

Я могу по твоем сценарию фильм снять, если ты не против..

не против... только чтобы там были эльфы, драконы и прынцессы...

Originally Posted by Sven

ты же сказала что пришла с мероприятия. Это так мероприятия влияют?

статья пишется третий день, я просто опубликовала первую часть, будет ещё несколько серий продолжения
кстати, в главе "А теперь - посмеёмся..." речь идёт о танцах с бубном после обновления
и так уж получается, что про 4ку я расписывать пока морально не готова
поэтому, господа четвёрошники, если есть желающие - будет очень и очень уместна подробная статья о работе со стилем после обновления, все эти четвёрошные заморочи "слияние шаблонов прошло неуспешно" или как-там-она-пишет
Есть добровольцы?

обсуждение статьи по даунгрейду перенесено в статью по даунгрейду