Перенос сайтов, созданных на разных 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 on
php_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

  1. Качаем сайт.
  2. Делаем дамп БД, разворачиваем на локальном 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

Мануал, 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 переписать уровень ошибок:

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 -Indexes
php_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 restart
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. Он игнорирует этот скрипт почему-то. Или может я не так правила описывал.

[1oo%, EoF]
Похожие материалы:
Понравилась статья? Расскажите о ней друзьям:


Комментарии

Показать/скрыть правила
Имя
[i] [b] [u] [s] [url]
:-) ;-) :D *lol* 8-) :-* :-| :-( *cry* :o :-? *unsure* *oops* :-x *shocked* *zzz* :P *evil*

Осталось 1000 символов.
Код защиты от спама Обновить код
Каждый комментарий проходит ручную модерацию. 100% фильтрация спама.
Для работы модуля комментариев включите javaScript

Продвижение
Время
Метки