Перенос сайтов, созданных на разных CMS
версия для печатиЗа полгода работы на web-студию накопилось разного, полезного и не очень. Большим спецом в конкретной CMS я не стал, но видел многое. Работая с очередным сайтом, я разворачиваю его копию на локалке. Мне так удобно. В некоторых случаях все просто, достаточно переписать ключи доступа к БД, иногда заморочки затягиваются. В то время я работал еще на Windows, что добавляло ньюансов. Вообщем, статья является попыткой организовать мои заметки по вопросу переноса сайтов с CMS. Описываю все, от очевидного до сложного. Выгода этих записей в экономии времени при разворачивании очередного сайта на своей площадке.
Общие замечания
Речь пойдет не об установке с нуля какой-то CMS, а именно запуске уже работающего сайта в новом окружении.
Локальная площадка имеет в наличии Apache, PHP, MySQL. Локальный домен рекомендую создавать двухуровневым, а не ограничиваться очевидным "localhost". Тому есть причины, описывать которые здесь не буду. Скажу коротко, могут быть неочевидные глюки с таким доменом. Поэтому мой локальный домен называется "site.loc".
Как я уже сказал, Винда добавляет проблем. Обычно кроссплатформа (*корректная работа CMS в окружении Windows) сводится к исправлениям кода после обращений к __FILE__ или __DIR__ на прямые слеши (/). Суть проблемы в том, что пути под Видной используются с обратными слешами, при инициализации скриптов сайта пишутся какие-то базовые константы с такими путями, а потом в коде приписываются пути аля-Linux и получается баг.
Другая проблема - отставание CMS от версии PHP. Однажды видел сайт, где еще поддерживались суперглобальные переменные! Чтобы предупреждения о deprecated не мешали, но остальные ошибки все равно выдавались, пиши в коде:
error_reporting(E_ALL & ~E_DEPRECATED | E_STRICT);Или в .htaccess:
php_flag display_errors onphp_value error_reporting "E_ALL & ~E_DEPRECATED | E_STRICT"
Выводить вообще все ошибки, предупреждения и т.п.
php_value error_reporting 2047234235В некоторых движках (Kohana, Opencart) настройки .htaccess перекрываются в коде. Поэтому ищи в скриптах вызовы функции error_reporting().
Если на сайте используется Smarty, полезная команда (которую я почему-то забываю и долго роюсь потом в мануалах Smarty):
PHP: var_dump($someVar);
Smarty: {$someVar|@var_dump}
Скачивание сайта в общем случае
Самая пичаль - пофайлово тянуть с FTP. В зависимости от степени бардака на сайте, время скачивания устремляется в бесконечность. Если повезет, на хост-панели будет файл-менеджер с возможностью упаковать каталог и скачать одним файлом. И совсем уже круто, когда есть ssh-доступ. Клиентом лучше пользоваться своим (puTTY, консоль). Все эмуляторы в браузере, что я видел, работали отвратительно. Допустим, доступ есть. Полезные команды:
ssh user@host //подключение через консоль (linux-вариант)tar -cf - ./www | gzip > site.tgz //упаковать и сжать подкаталог "www" в текущем каталоге
//или так
tar -cvzf site.tgz ./www //Список файлов побежит в консоли. Не очень удобно для больших проектов.
В качестве имени архива указал "-", тогда результат отправляется в стандартный вывод, где его подбирает gzip и пакует в указанный файл. После упаковки залазим по ftp и скачиваем весь сайт одним файлом. В разы быстрее :) Хостинги и окружение бывает разное, что-то может и не работать. Помню, где-то встречал отстуствие gzip в системе.. Пришлось только архивировать, без сжатия.
На случай, когда совсем все хреново, есть такая идея (не проверенная). Через ftp создать php-скрипт в каталоге "www":
<?php shell_exec(escapeshellcmd('tar -cf - ../www | gzip > site.tgz')); ?>Потом вызвать его, обратившись по URLу. Теоретически может и получиться.
Joomla 3
- Качаем сайт.
- Делаем дамп БД, разворачиваем на локальном MySQL-сервере.
Идем в [/configuration.php], правим несколько мест: подключение к БД, каталоги tmp/ и logs/. Для Windows нужно провести замены в файлах:
"__DIR__" на "str_replace('\\', '/', __DIR__)" 140 замен"DIRECTORY_SEPARATOR" на "'/'" (КАВЫЧКИ НЕ ЗАБУДЬ) 70(?) замен
Ошибка "Error displaying the error page: Application Instantiation Error" получается при любых косяках в Joomla %(( Проверь наличие и доступ к БД, файлы конфига.
Wordpress
Версия CMS - 4.7.5
Мануал по функциям: http://wp-kama.ru.
Качаем сайт, дамп БД. В корне wp-config.php. Меняем параметры подключения к БД. Для площадки на Windows меняем константу ABS_PATH
define('ABSPATH', str_replace('\\', '/', __DIR__ ) . '/');Включаем режим отладки
define('WP_DEBUG', true);Если на русском сайт тупит безмерно, переключаемся на английский:
define('WPLANG', 'en_US');Настройки 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";
В моем случае было такое содержимое в поле `option_value`:
a:5:{s:5:"https";s:1:"1";s:12:"https_domain";s:1:"1";s:17:"https_pages_array";a:0:{}s:15:"force_resources";s:1:"1";s:21:"plugin_option_version";s:3:"1.6";}
Заменил на 0 значения для "https", "https_domain" и "force_resources".
Yii v.1.x
Настройки в каталоге [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 переписать уровень ошибок:
error_reporting (E_ALL & ~E_DEPRECATED | E_STRICT)В связи с багом в новых версиях PHP (не понял, что написал %)) получается Notice в Writer.php::format_message() [system/classes/Kohana/Log/]. Точка вызова
$string = strtr($format, $message);И если в нормальной ситуации можно использовать подавление ошибки @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 в корне сайта
Options +SymLinksIfOwnerMatch -Indexesphp_value memory_limit 32M
Настройки MODx, в частности логин/пароль и имя БД прописаны в config.inc.php [manager/includes/]
$dbase //имя базы. Не забудь переписать!$database_server
$database_user
$database_password
Контроль ошибок в 320 местах! Я фигею c этого движка.. :( Переписать контроль ошибок именно на такой:
error_reporting(E_ALL & ~E_DEPRECATED & ~E_NOTICE);Прописать это в
- главный index.php
- config.inc.php [manager/]
- config.inc.php [manager/includes/]
Чтобы ошибки видеть, в конце главного index.php закоментировать @ini_set("display_errors","0").
В БД изменить настройки в таблице `*_system_settings`
'rb_base_dir' = '/home/user/www/site.loc/assets/''filemanager_path' = '/home/user/www/site.loc/'
В той же таблице сбросить настройки безопасности (на локалке они мне не нужны):
'validate_referer' = 0 - контроль по рефереру в админке.'check_files_onlogin' = '' - список файлов для проверки контрольной суммы.
'sys_files_checksum' = '' - сообственно контрольные суммы.
На заметку:
- Расчет сумм выполняется в getSystemChecksum() [manager/includes/extenders/manager.api.class.inc.php]
- Проверка реферера в [/manager/index.php:234]
ModX Revo
В переносе сайта есть отличия от ModX Evo. Привожу все заметки, без выделения отличий.
В админке есть свой инструмент для дампа базы.
Если будешь ковырять настройки, не забывай сбрасывать кеш [core/cache/].
ModX Revo вообще ни как не расчитан под кроссплатформу. Для Винды делаем замену в файлах через Notepad++
dirname(__FILE__) на str_replace('\\', '/', __DIR__)$modx->setDebug(true) не работает на локалке. Включаем опцию и получаем пустую страницу. Причину не выяснил.
В php.ini разрешить allow_url_fopen = on. Перезапустить Apache.
.htaccess в корне сайта
Options +SymLinksIfOwnerMatch -IndexesВ config.core.php распаложенном в корне сайта, [manager/] и [connectors/] (одинаковый скрипт в трех местах!) пишем:
define('MODX_CORE_PATH', '/home/user/www/site.loc/core/'); nНастройки MODx, в частности логин/пароль и имя БД прописаны в config.inc.php [core/config/]
$dbase //имя базы. Не забудь переписать!$database_server
$database_user
$database_password
$database_dsn
В БД изменить настройки в таблице `*_system_settings` поставить 0 для трех `key`="access_*" записей.
Переименовать или снести каталог [core/cache/]. А вот каталог [core/xpdo/cache/] как раз нельзя переименовывать или удалять. Это какой-то странный кеш, он не восстанавливается.
ocStore/Opencart
Качаем сайт, дамп БД. Ради Винды в корне файл config.php придется переписать практически весь. Добавить свою константу и заменить по аналогии ниже
define ('ROOT', __DIR__ . '/');define('DIR_APPLICATION', ROOT . 'catalog/');
В каталоге админки такая же фигня. Не понятно, зачем дублировать главный конфиг, но его тоже нужно весь переписать.
define ('ROOT', realpath( __DIR__ . '/../') . '/');define('DIR_APPLICATION', ROOT . 'admin/');
Про настройки подключения к БД не забудь, они в конце конфигов.
В .htaccess никаких настроек сессии не пиши, движок по-своему рулит. Еще можно отключить (закомментировать)
php_value error_reporting 1чтоб он гарантировано не мешал дальнейшей настройке ошибок. Но при этом в самом начале главного индекса пропиши:
error_reporting(E_ALL & ~E_DEPRECATED | E_STRICT);иначе ничего не увидишь. Пробовал тоже самое через .htaccess задавать - не работает.
C backtrace в Opencart вообще печаль. Движок его в логи не пишет. Можешь попробовать пробросить исключение, типа
throw new Exception('Че попало, лишь бы упало');exit;
получишь фатальную ошибку, т.к. его никто не поймает. В коде ошибки есть некий backtrace.
В [/system/startup.php]
error_reporting(E_ALL & ~E_DEPRECATED | E_STRICT);В главном 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]. В консоли запускаем:
php5enmod mcryptПоявится симлинк [/etc/php5/apache2/conf.d/mcrypt.ini]. Перезапускаем Apache и все должно работать:
service apache2 restartvQmod
Это не 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. Он игнорирует этот скрипт почему-то. Или может я не так правила описывал.
Похожие материалы:
Понравилась статья? Расскажите о ней друзьям: