Пользователь Strumjan поделился своим опытом по миграции большого (порядка 15 000 материалов) веб-сайта preminportal.com.mk с Joomla! 1.x до Joomla! 3.x. Ниже представлен перевод материала. Надеемся, что вы почерпнете для себя что-то полезное и вполне возможно примените это на практике.
Итак, задача была следующая: есть веб-сайт на Joomla 1.0.13, с базой данных размером 320 MB и корневой папкой размеров 3.5 GB. Все это необходимо было перевести на Joomla 3.x.
Если быть совсем точным, то содержимое базы данных на момент миграции было следующим:
jos_content = 15493 строки;
jos_menu = 131 строка;
jos_modules = 457 строк;
jos_sections = 23 строки;
jos_categories = 127 строк;
jos_users = 402 строки.
Чтобы избежать большой задержки на живом веб-сайте, моей идеей была полная миграция локально на компьютере и далее перенос на веб-хостинг. При этом я не переносил на локалку папки с изображениями, музыкой и другими документами, потому что решил не изменять их расположение (например, из images/stories в images) и избежать изменения путей во всех материалах.
Для локальной работы я использовал USBWebServer. Для того, чтобы импортировать базу данных, мне пришлось увеличить memory_limit, upload_max_filesize и post_max_size в php.ini и установить их значение в больше чем 400 MB.
В корневой папке USBWebServer я создал папку 'oldsite', и в неё я распаковал папки из старого веб-сайта preminportal.com.mk (только базовые папки Joomla 1.0.x). Далее я создал в USBWebServer базу данных с названием 'oldsite' и конечно же установил collation в utf8_general_ci, так как веб-сайт на кириллице.
В configuration.php я изменил следующие строки:
$mosConfig_db = 'oldsite';
$mosConfig_absolute_path = 'C:/USBWebserver-za-Premin\root' (путь должен быть реальным расположением вашего USBWebsrever);
$mosConfig_live_site = 'C:/USBWebserver-za-Premin\root' (путь должен быть реальным расположением вашего USBWebsrever);
$mosConfig_error_reporting = '0' (для выключения ошибок);
$mosConfig_password = 'usbw' (стандартный пароль для USBWebserver);
$mosConfig_user = 'root' (стандартное имя пользователя в USBWebserver);
$mosConfig_live_site = 'http://localhost:8080' (стандартный URL корневой папки в USBWebserver).
Для локальной работы с Joomla 1.0.x я использовал USBWebSerever версию 8, которая поставляется с PHP 5.3.2. Это более старая версия, но именно она и нужна, так как в ней есть magic_quotes_gpc (магические кавычки), которые должны быть включены для нормального отображения веб-сайта. В новых версиях PHP их нет.
Теперь веб-сайт полностью реплицирован локально (без изображений в материалах, но в конце, когда веб-сайт запустится на веб-сервере, они сами найдут пути) и можно начинать миграцию.
Я следовал инструкциям из https://docs.joomla.org/J1.5:Migrating_from_1.0.x_to_1.5_Stable (все верно, сначала веб-сайт должен быть смигрирован до Joomla 1.5.x, и только после этого на более новую версию). Так как сайт был на версии Joomla 1.0.13, я скачал рекомендованный патч из [ссылка битая].
После миграции я обнаружил, что база данных стала почти в два раза больше, поэтому пришлось делать миграцию еще раз. На форуме я нашел, что проблема может быть в материалах, которые находятся в Корзине. Я открыл панель управления Joomla 1.0 и нашел порядка 700 материалов и 20 пунктов меню в Корзине, и я их удалил. Также перед миграцией удалите все неопубликованные материалы, категории и разделы со старого веб-сайта.
Так как в Joomla 1.0 нельзя отсортировать материалы по состоянию (опубликованые/снятые с публикации), то в такой большой базе данных был сложно найти все снятые с публикации элементы. Поэтому я решил изменить код. В файле ./administrator/components/com_content/admin_content.php в строке 145 находится код, отвечающий за состояние материала ('display all equal or biger than zero'):
"c.state >= 0"
где 0 – это снятые с публикации, а 1 – опубликованные. Небольшое изменение кода:
"c.state = 0"
и теперь у меня в панели управления только снятые с публикации материалы, так что я смог их легко удалить. После чистки ненужных материалов я поменял код обратно. Теперь в менеджере материалов у меня было 11296 материалов, 3560 из них избранные и 2527 архивные.
Я также удалил все снятые с публикации категории и разделы, меню и суб-меню, модули. Все сторонние мамботы, модули и компоненты были удалены, а также удалены их таблицы в базе данных. Также были удалены все неактивные пользователи и все ненужные шаблоны. После всех этих операций я очистил кэш.
Далее в PHPMyAdmin я выбрал все таблицы базы данных, у которых был overhead и оптимизировал их. В итоге не осталось таблиц с overhead.
Следующий шаг – установка компонента Migrator, который мигрирует базу данных с Joomla 1.0 до 1.5. Он создает один sql-файл, и этот файл должен быть импортирован в чистую установку Joomla 1.5.
Теперь я перенес все установочные файлы Joomla 1.5.26 в папку 'oldsite15' и создал новую базу данных с названием 'oldsite15' и collation в utf8_general_ci.
Я попытался импортировать миграционный файл во время установки 1.5.26. По умолчанию предлагается кодировка ISO-8859-1, но она не подходит. Я попытался использовать кодировку utf-8, но все время получал следующую ошибку:
Notice: iconv() [function.iconv]: Detected an illegal character in input string in ...\installation\installer\helper.php on line 873
Строка 873 в этом helper.php:
$buffer = iconv( $srcEncoding, 'utf-8//TRANSLIT', $buffer );
После небольшого расследования в форумах о функции iconv, я решил попробовать следующий вариант:
$buffer = iconv( $srcEncoding, 'utf-8//IGNORE', $buffer );
Я сделал это, потому что самой первой ошибкой в уведомлениях была:
Error at the line 9: INSERT INTO jos_migration_backlinks
VALUES(1,"Дома","index.php?option=com_frontpage&Itemid=1","component/option,com_frontpage/Itemid,1/","");
Query:## Created using Migrator 1.3 for Joomla! 1.0
INSERT INTO jos_migration_backlinks VALUES(1,"�ома","index.php?option=com_frontpage&Itemid=1","component/option,com_frontpage/Itemid,1/","");
где в первой строке Joomla читает слово 'Дома' нормально, но после этого меняет на странные символы 'Ð�ома', поэтому я предположил, что проблемой является транслитерация.
Теперь миграция прошла только с двумя уведомлениями, но в конце показала сообщение об успешной миграции. Наконец-то я смог увидеть свой веб-сайт на Joomla 1.5 с нормальной кириллицей и читаемым текстом.
В версии 1.5 я установил Akeeba Backup 3.4.6 и сделал бэкап на этом шаге.
Теперь на новом USBWebServer 8.5 я должен был установить Joomla 3.3.6 (последняя версия на момент написания материала) и попытаться мигрировать веб-сайт с 1.5.26. Для этого необходимо, чтобы базы данных 1.5.26 и 3.3.6 были на одном и том же сервере, поэтому мне нужно установить 1.5.26 из бэкапа.
Я создал новую папку с названием 'newsite3', базу данных с названием 'newsite3' с collation в utf8_general_ci, а также базу данных 'oldsite15' с utf8_general_ci для Joomla 1.5.26.
На чистой установке Joomla 3.3.6 я запустил компонент redMigrator. В настройках я выбрал мигрировать только базу данных 'oldsite15'. После 23% redMigrator завис, поэтому я попробовал еще раз, при этом меняя настройки. Но все было по-прежнему. Я попытался увеличить memory_limit, после этого redMigrator сумел обработать около 3300 из 11296 материалов и снова застрял.
Далее я попробовал компонент MigrateMe, который импортирует базу данных 1.5 и конвертирует в версию 3. MigrateMe импортировал базу данных, начал её анализировать, но потом застрял.
Я слышал, что SPupgrade неплохо справляется с задачей, поэтому я решил попробовать. Я снова начал со свежей установки Joomla 3.
После установки SPUpgrade, я оставил все настройки по умолчанию. Я соединил её с базой данных 'oldsite15' и он работал более чем два часа. В это время в Firefox единственным признаком того, что оно работает, была крутящаяся иконка в панели. Время от времени я проверял в PHPMyAdmin состояние базы данных и видел, что количество строк изменяется, что было хорошим знаком. Через два часа веб-сайт вылогинил меня и представил страницу входа.
Я залогинился и увидел отчёт от SPUpgrade и внизу сообщение: 'Успешная миграция'. На месте были все меню, категории, модули и материалы. Обратите внимание, что в старых Joomla 1.0 и 1.5 были разделы и категории, а в Joomla 3 разделы = категории, а категории = субкатегории.
В базе данных таблица ucm_history, в которой хранятся версии материалов, была 316 MB. Я её очистил, так как материалы в Joomla 1.0 не имели версий, так как это было реализовано только в Joomla 3.
Материалы в Joomla 1.0 не имели дружественных URL, поэтому я решил это исправить. Только учтите, что старые ссылки с других веб-сайтов на ваш веб-сайт будут утеряны.
Так как все названия материалов были на Macedonian Cyrillic, я установил македонский язык и активизировал его в панели управления. Это дало Joomla возможность автоматически транслитирировать Macedonian Cyrillic в латинские символы. Но для этого нужно было открыть каждый материал и пересохранить его. Мне это не подходило, так как у меня было слишком много материалов, поэтому мне нужно было более быстрое решение.
В интернете я нашел вариант использования кнопки пакетной обработки. Сначала нужно установить в базе данных алиас в пустое значение, потом создать временную категорию и переместить туда выбранные материалы с помощью кнопки пакетной обработки. Когда Joomla перемещает материалы, она сохраняет каждые материал, что вызывает автоматическую генерацию алиса (так как они пустые). После этого просто перенесите материалы обратно с помощью той же кнопки пакетной обработки. Чтобы избежать каши в материалах, это нужно сделать категория за категорией. Обратите внимание, что этот процесс не работает для меню и категорий.
Итак, я сделал новые алиасы для меню и категорий и приступил к материалам. Сначла я обнулил алиас в базе данных через PHPMyAdmin:
UPDATE 'xyz_content' SET 'alias'=''
Далее я приступил к выше описанному способу. Это работало, но очень медленно. Я посчитал, что этой займет слишком много времени, поэтому решил найти решение для изменения напрямую в базе данных.
Я попросил помощи на форуме Joomla. Пользователь Manicakm посоветовал использовать такой вариант:
SELECT 'title',replace(replace(lower ('title'),' ','-'),"'",'') FROM 'xyz_content'
и проверить, подходит ли мне такой тип алиаса. Проверка показала, что все алиасы будут на кириллице.
После этого я выполнил следующий запрос:
UPDATE 'xyz_content'
SET alias=replace(replace(lower ('title'),' ','-'),"'",'')
Теперь все алиасы были почти такими, какими мне нужно было, но на кириллице. Это было неплохо, но можно ли сделать ещё лучше и перевести их в латиницу?
pe7er предложил такую проверку:
SELECT alias, COUNT(*) c FROM xyz_content GROUP BY alias HAVING c > 1
Этот запрос показал, что множество алиасов имели недружественные символы, типа
+,.„“()!?"’蔑ћђ✣✤ etc.
Теперь их необходимо заменить на '-' или на пустоту в зависимости от их позиции и использовании в названии материала.
Я сделал это следующим запросом:
UPDATE xyz_content
SET alias = REPLACE(alias,'+','')
или
UPDATE xyz_content
SET alias = REPLACE(alias,'✤','-')
После замены всех проблематичных символов я использовал такой же метод для замены всех кириллических символов в алиасах на их латинскую транслитерацию.
После этого я скопировал все изображения, музыку и документы со старого сайта, сохраняя пути. Установил новый шаблон и изменил его. Установил самую последнюю версию Akeeba Backup и восстановил веб-сайт на живом сервере. Миграция прошла успешно.
