Перенос сайтов, созданных на разных CMS

За полгода работы на web-студию накопилось разного, полезного и не очень. Большим спецом в конкретной CMS я не стал, но видел многое. Работая с очередным сайтом, я разворачиваю его копию на локалке. Мне так удобно. В некоторых случаях все просто, достаточно переписать ключи доступа к БД, иногда заморочки затягиваются. В то время я работал еще на Windows, что добавляло ньюансов. Вообщем, статья является попыткой организовать мои заметки по вопросу переноса сайтов с CMS. Описываю все, от очевидного до сложного. Выгода этих записей в экономии времени при разворачивании очередного сайта на своей площадке.

Общие замечания

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

Локальная площадка имеет в наличии Apache, PHP, MySQL. Локальный домен рекомендую создавать двухуровневым, а не ограничиваться очевидным "localhost". Тому есть причины, описывать которые здесь не буду. Скажу коротко, могут быть неочевидные глюки с таким доменом. Поэтому мой локальный домен называется "site.loc".

Как я уже сказал, Винда добавляет проблем. Обычно кроссплатформа (*корректная работа CMS в окружении Windows) сводится к исправлениям кода после обращений к __FILE__ или __DIR__ на прямые слеши (/). Суть проблемы в том, что пути под Видной используются с обратными слешами, при инициализации скриптов сайта пишутся какие-то базовые константы с такими путями, а потом в коде приписываются пути аля-Linux и получается баг.

Другая проблема - отставание CMS от версии PHP. Однажды видел сайт, где еще поддерживались суперглобальные переменные! Чтобы предупреждения о deprecated не мешали, но остальные ошибки все равно выдавались, пиши в коде:

Или в .htaccess:

Выводить вообще все ошибки, предупреждения и т.п.

В некоторых движках (Kohana, Opencart) настройки .htaccess перекрываются в коде. Поэтому ищи в скриптах вызовы функции error_reporting().

Если на сайте используется Smarty, полезная команда (которую я почему-то забываю и долго роюсь потом в мануалах Smarty): PHP: var_dump($someVar);
Smarty: {$someVar|@var_dump}

Скачивание сайта в общем случае

Самая пичаль - пофайлово тянуть с FTP. В зависимости от степени бардака на сайте, время скачивания устремляется в бесконечность. Если повезет, на хост-панели будет файл-менеджер с возможностью упаковать каталог и скачать одним файлом. И совсем уже круто, когда есть ssh-доступ. Клиентом лучше пользоваться своим (puTTY, консоль). Все эмуляторы в браузере, что я видел, работали отвратительно. Допустим, доступ есть. Полезные команды:

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

На случай, когда совсем все хреново, есть такая идея (не проверенная). Через ftp создать php-скрипт в каталоге "www":

Потом вызвать его, обратившись по URLу. Теоретически может и получиться.

Joomla 3

1. Качаем сайт.
2. Делаем дамп БД, разворачиваем на локальном MySQL-сервере.

Идем в [/configuration.php], правим несколько мест: подключение к БД, каталоги tmp/ и logs/. Для Windows нужно провести замены в файлах:

Ошибка "Error displaying the error page: Application Instantiation Error" получается при любых косяках в Joomla %(( Проверь наличие и доступ к БД, файлы конфига.

Wordpress

Версия CMS - 4.7.5

Мануал по функциям: http://wp-kama.ru.

Качаем сайт, дамп БД. В корне wp-config.php. Меняем параметры подключения к БД. Для площадки на Windows меняем константу ABS_PATH

Включаем режим отладки

Если на русском сайт тупит безмерно, переключаемся на английский:

Настройки URLs в таблице `wp_options`. Меняй имя сайта на свой site.loc, иначе все запросы, включая css/js, уходят в инет. Пример запроса:

UPDATE wp_options 
SET option_value = REPLACE(option_value, 'https://www.server.com', 'http://site.loc') 
WHERE option_value LIKE '%https://www.server.com%';

Отключение SSL на локалке

Как видно из запроса выше, меняем протокол httpS на http. Но этого недостаточно. Нужно найти запись в `wp_options`, где `option_name`="httpsrdrctn_options" и вручную переписать ее значение. Это сериализованный массив, придется внимательно править. Запрос для поиска записи:

SELECT * FROM wp_options WHERE option_name="httpsrdrctn_options";

Заменил на 0 значения для "https", "https_domain" и "force_resources".

Yii v.1.x

Мануал, Class Reference

Настройки в каталоге [protected/config/]. Главный конфиг, как правило, main.php. Остальные подключаются к нему. Поищи в них подключение к БД.

Смена пароля юзера/админа для доступа в админку - UserModule.php [protected/modules/user/]. Функция encrypting() - собственно шифрование.

md5/sha1-хеш, зависит от настройки, см. в том же скрипте два свойства класса, $hash и $salt. Соль добавляется в конец пароля, потом строка хешируется. Конкатенация пароля и соли - в той же encrypting(). В базе смотри таблицу `users`.

CodeIgniter

Мануал на русском

config.php [application/config/]. Переписал $config['base_url'] = 'http://site.loc'.

Подключение к БД database.php [application/config/]

Kohana

Локальный доступ к БД database.php [application/config/].

Нужен доступ 0777 в каталоги [application/cache/] и [application/logs/]. Старые логи можно удалить.

Из-за отставания движка от версии PHP появились дополнительные проблемы. В главном index.php переписать уровень ошибок:

В связи с багом в новых версиях PHP (не понял, что написал %)) получается Notice в Writer.php::format_message() [system/classes/Kohana/Log/]. Точка вызова

И если в нормальной ситуации можно использовать подавление ошибки @strtr(), то в Kohana и оно не работает, потому что у нее свой error_handler. Короче получается, что с любой ошибкой в коде движок просто встает. Костылька: добавить перед указанной выше строкой это: echo '<pre>' . var_export($message, true) . '</pre>'; exit;//DBG

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

ModX Evo 1.0.12

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

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

Если не отключишь систему безопасности, можно получить постоянное http-соединение: браузер не догрузит страницу, будет висеть в режиме ожидания. Сбросить соединение получится только убив дочерний процесс httpd.exe.

Если будешь ковырять настройки, не забывай сбрасывать кеш [assets/cache/]. Сам каталог [cache/] должен существовать, движок не способен его создать. Полный доступ, как минимиум, на этот каталог.

В php.ini разрешить allow_url_fopen = on. Перезапустить Apache.

.htaccess в корне сайта

Настройки MODx, в частности логин/пароль и имя БД прописаны в config.inc.php [manager/includes/]

Контроль ошибок в 320 местах! Я фигею c этого движка.. :( Переписать контроль ошибок именно на такой:

Прописать это в

• главный index.php
• config.inc.php [manager/]
• config.inc.php [manager/includes/]

Чтобы ошибки видеть, в конце главного index.php закоментировать @ini_set("display_errors","0").

В БД изменить настройки в таблице `*_system_settings`

В той же таблице сбросить настройки безопасности (на локалке они мне не нужны):

На заметку:

• Расчет сумм выполняется в getSystemChecksum() [manager/includes/extenders/manager.api.class.inc.php]
• Проверка реферера в [/manager/index.php:234]

ModX Revo

В переносе сайта есть отличия от ModX Evo. Привожу все заметки, без выделения отличий.

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

Если будешь ковырять настройки, не забывай сбрасывать кеш [core/cache/].

ModX Revo вообще ни как не расчитан под кроссплатформу. Для Винды делаем замену в файлах через Notepad++

$modx->setDebug(true) не работает на локалке. Включаем опцию и получаем пустую страницу. Причину не выяснил.

В php.ini разрешить allow_url_fopen = on. Перезапустить Apache.

.htaccess в корне сайта

В config.core.php распаложенном в корне сайта, [manager/] и [connectors/] (одинаковый скрипт в трех местах!) пишем:

Настройки MODx, в частности логин/пароль и имя БД прописаны в config.inc.php [core/config/]

В БД изменить настройки в таблице `*_system_settings` поставить 0 для трех `key`="access_*" записей.

Переименовать или снести каталог [core/cache/]. А вот каталог [core/xpdo/cache/] как раз нельзя переименовывать или удалять. Это какой-то странный кеш, он не восстанавливается.

ocStore/Opencart

Документация

Качаем сайт, дамп БД. Ради Винды в корне файл config.php придется переписать практически весь. Добавить свою константу и заменить по аналогии ниже

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

Про настройки подключения к БД не забудь, они в конце конфигов.

В .htaccess никаких настроек сессии не пиши, движок по-своему рулит. Еще можно отключить (закомментировать)

чтоб он гарантировано не мешал дальнейшей настройке ошибок. Но при этом в самом начале главного индекса пропиши:

иначе ничего не увидишь. Пробовал тоже самое через .htaccess задавать - не работает.

C backtrace в Opencart вообще печаль. Движок его в логи не пишет. Можешь попробовать пробросить исключение, типа

получишь фатальную ошибку, т.к. его никто не поймает. В коде ошибки есть некий backtrace.

В [/system/startup.php]

В главном index.php пропиши в обработчике костыльку:

function error_handler($errno, $errstr, $errfile, $errline) {
    global $log, $config;
    if (empty($config)) return true; //Костыль
    ...
}

Это чтобы назначенный обработчик ошибок не приводил к багу в index.php:0.

Если включен vqmod, то изменения нужны еще и в его кеше. Удалить все из [vqmod/vqcache/] и файл mods.cache. Обновить страницу сайта. Изменения в системных файлах теперь перекешированы.

Ошибки могут писаться в лог и/или выводиться в браузер. Лог по умолчанию [/system/logs/error.txt]. Все настройки в таблице `setting`, ключи config_error_filename, config_error_log и config_error_display.

В админке большинство настроек сайта сразу и не найдешь :-/ Иди в Система > Настройки. Открой на изменение выбранный сайт и.. вот они все где! В тех настройках вкладка "Сервер", внизу можно настроить логирование ошибок.

SEO. ЧПУ могут быть прописаны в коде, их легко найти. Так же см. в таблице `url_alias`

Немного офтопика по OpenCart

Подгрузка скриптов возможна через вызовы типа:

$this->children = array(
    'common/column_left',
    'common/column_right',
);

//А так же более очевидное,

$this->language->load('product/category');
$this->load->model('catalog/category');

//Или еще круче:

$this->model_catalog_category->getCategory($path_id);

//И самая жесть:


nforeach ($module_data as $module) {
    $module = $this->getChild('module/' . $module['code'], $module['setting']);

Ни один из способов не резольвится автоматом в Eclipse. Оно и понятно.

Установка MCrypt

ocStore использует mcrypt. Не знаю, как с ним дела в PHP под Виндой, но на Ubuntu можно добавить в сборку так (источник): ставим пакеты php5-mcrypt, mcrypt. Должен появиться [/etc/php5/mods-available/mcrypt.ini]. В консоли запускаем:

Появится симлинк [/etc/php5/apache2/conf.d/mcrypt.ini]. Перезапускаем Apache и все должно работать:

vQmod

Это не CMS конечно, но в связи с OpenCart сюда же напишу заметки про vQmod.

Установка vQmod проста: распаковываем архив vqmod-x.x.x-opencart.zip в корень сайта. Запускаем по адресу типа: http://site.loc/vqmod/install/. Получим сообщение в браузер об успешной установке, все. Для себя под Windows правил файл [vqmod/vqmod.php], превращая его в кроссплатформу. Код не приведу, там много всего.

vQmod обрабатывает все файлы, подключаемые PHP при сборке ответа, но только их. А это значит, что можно внести изменения, например, в *.tpl, но нихрена не получится с css/js-файлами. Даже если написать свое дополнение системы по принудительной обработке таких файлов, все равно не получится их динамически подключать, потому что VQmod подключает измененные файлы из своего кеша, только когда к ним обращается сборщик ответа, PHP то бишь.

Чтобы поправить замененный vQmod-ом скрипт, нужно отключить правило (расширение поменяй) и скопировать файл из кеша в каталог с оригиналом. Переименовать оригинал и копию, теперь можно править.

Полное отключение vQmod может положить сайт! Рекомендую сделать копии с текущих индексных файлов перед отключением.

Я - Тундра!! Несколько часов копался в единственном работающем для vQmod скрипте и никак не мог найти свою ошибку %) САМОЕ ГЛАВНОЕ: НЕ СПЕШИ. Я же торопился по-быстрому оформить изменения в скриптах, и накосячил. Если не помнишь, как описывать правила, почитай мануал еще раз, там всего одна страница. Полчаса погоды не сделают.

Используй <operation error="log"> в правилах. В случае ошибок будет что посмотреть в логах.

Все описанное ниже относится к файлу [vqmod/vqmod.php]:

• этот файл в сочетании с правильным vqmod_opencart.xml из [vqmod/xml/] позволяет работать системе vQmod на OpenCart. Xml-файл идет в архиве с установкой, не надо его модифицировать, иначе потом вообще не разберешься, почему не работает. Xml-файл заточен под OpenCart.
• работающая лошадь системы - это функция VQMod::modCheck(). Все обрабатываемые модой файлы идут через нее. Функция вызывается только если требуется обновление кеша. Кеш в свою очередь складывается в каталог [vqmod/vqcache/] и пишется в файле [vqmod/mods.cache]. Чтобы при отладке постоянно не сносить кеши, можно закомментить return в VQMod::_getMods(). Он там один, ничего не возращает. Хотя не уверен в полезности этого шага.
• Дальше функции VQMod::modCheck() отлаживать не пришлось, т.к. я понял, что просто неправильно прописал путь к файлу! Поэтому ничего в нем не менялось.
• если файл описан в xml-правилах, но не попал в кеш, значит либо движок к нему не обращался (в modCheck() добавь в начале "echo $sourceFile;" обнови страницу и посмотри полученный список), либо правила описаны неверено. vQmod пишет логи, см. [vqmod/logs/], и я мог бы сэкономить время, если бы прописал "<operation error=log'>" в правилах, ибо об отсутствующем файле система пишет в лог :)
• xml парсится через DOMDocument (см. код в VQModObject::_parseMods()), а это - черный ящик для отладчика. Поэтому синтаксические ошибки xml-файла будет сложно определить. В лог пишется такое "DOM UNABLE TO LOAD: /xx/xx/file.xml"
• главный index.php OpenCart-а не проходит обработку, из него запускается сам VQMod. Он игнорирует этот скрипт почему-то. Или может я не так правила описывал.