Подготовка к переезду

Сам по себе переезд не так уж сложен. Если, конечно, хорошо подготовиться.

Разумеется, надо как следует почистить каталоги сайта - зачем тащить ненужное барахло? Удаляем, например, заведомо ненужные языковые файлы (несколько сотен). Ищем файлы  Thumbs.db - для сервера это грязь. Нечего делать на сервере BMP-файлам и любым файлам с русскоязычными именами.

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

Обязательно надо удалить файлы, кэшируемые нашим любимим плагином DirectResize - они у нас живут в каталоге assets/cache/phpthumb.

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

Копирование сайта

Здесь нет ничего сложного. Главное - не промазать, ускопировать в правильный каталог. Копировать придется с помощью какого-то FTP-клиента.

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

manager/includes/config.inc.php

Это  параметры, задаваемые владельцем хостинга:

$database_server = "XXX";
$database_user = "YYYY";
$database_password = "ZZZZ";

Очень важным является установка прав доступа (атрибутов папок и файлов). На локальном сервере, работавшем под Windows, все папки были доступны. На настоящем сервере всё будет не так.

В документации указано, что права доступа 0777 должны иметь:

• /assets/cache (и все содержащиеся в ней файлы)
• /assets/export 
• /assets/images 
• /assets/modules (для установки модулей)
• /manager/includes/config.inc.php (позже должен иметь доступ "Только чтение") 

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

Вообще, откуда появилось требование в MODx на атрибут 777? Анализ кода показал, что он используется в браузере файлов MCPUK. Мы от него отказались (см. отдельную статью). Еще есть проверка такого атрибута в отдельных кривоватых плагинах. Атрибут 777 - это прямая дыра для взлома сайта. При работе через Менеджер MODx доступ к каталогам и файлам осуществляется от имени ВЕБ-сервера, а он относится к Членам группы. При загрузке файлов через FTP доступ осуществляется от имени Владельца. А вот всяким  Прочим совершенно незачем  записывать файлы.

Итак, мы скопировали сайт, но он пока не рабочий - у него нет базы данных.

Копирование базы данных

Вряд ли провайдер даст прямой доступ к серверу баз данных. Заполнять БД придется через SQL- запрос.  Вот для этого нам и нужен заготовленный SQL-файл. Получили мы его в результате экспорта локальной базы данных. В зависимости от использовавшегося инструмента SQL-файл может иметь немного отличающиеся комментарии.

SQL-файл надо просмотреть, и, как минимум, убедиться что он имеет правильную кодировку - UTF-8, причем без BOM.Кроме того, при экспорте БД надо было правильно указать кодировку, а это связано не только с кодировкой самого файла, но и с директивами SQL, которые включала программа-экспортер. Убеждаемся, что в SQL везде имеется директива

DEFAULT CHARSET=utf8  и нет DEFAULT CHARSET=cp1251

Не мешает поискать строчку вида http://site_name/ - где-то могут случайно оказаться абсолютные ссылки на старый, локальный сайт. Их необходимо исправить на относительные. У нас, кстати, нашлось несколько таких ссылок на картинки.

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

По идее всё просто - заходим в нашу пока пустую базу данных (или создаем её) и делаем импорт нашего SQL-файла. По идее должны создаться все требуемые таблицы и заполниться данными. По идее в БД должны оказаться данные в требуемой кодировке (в нашем случае - utf8).Такая кодировка должна быть указана для базы данных в момент создания, а кодировка таблиц задана в SQL.

Такую операцию мы проделывали десятки раз. Но вот с MODx "идея" не сработала! База данных на сервере оказалась в кодировке cp1251.  Про проблемы с кодировками мы уже писали в специальной заметке. На сервере имеется аналогичная ситуация. В MySQL крутятся несколько десятков баз данных и все они имеют кодировку cp1251. Она и задана в конфигурационном файле сервера. Там кодировку менять нельзя - перестанут отображаться другие сайты.

Во время импорта сервер сам перекодирует данныеиз utf8 в cp1251.

Для решения проблемы необходимо в начало SQL-файла вручную вписать директиву:

SET CHARACTER SET utf8; 

или

 SET NAMES utf8;

Вот теперь база данных попадет на сервер в нужной кодировке.

Для пробы загружаем сайт (он должен отобразиться нормально), заходим в менеджер - там также всё должно быть правильно отображаться - и дерево документов, и оформление самого менеджера.

Настройка менеджера

Сразу заходим в Инструменты-Конфигурация и настраиваем основные параметры.

1. На вкладке Интерфейс и представление заменяем строку Путь к файлам: на нечто наподобие

/usr/local/www/sites/site_name/www/assets/  - по указанию администратора хостинга.

2. Аналогичную замену делаем на вкладке Файл-менеджер в строке Путь для файлового менеджера.

Вот теперь, по идее, сайт должен работать. И на первый взгляд он работает.

Но приключения только начинаются....