Кейс: миграция с K2 на ядро Joomla

Многие веб-сайты, созданные на Joomla 3, до сих пор используют популярный компонент K2 для управления контентом. Однако с выходом Joomla 4 и более новых версий K2 перестал быть совместимым, что создает серьезные проблемы для модернизации. Данное руководство подробно описывает процесс миграции данных из K2 в стандартную систему материалов Joomla, позволяя безопасно обновить сайт и использовать все преимущества современных версий CMS.

Предыстория

Компонент K2 был разработан как расширенная замена стандартной системы материалов Joomla. Начиная с версии Joomla 1.5, многие администраторы и разработчики устанавливали K2, чтобы получить доступ к его мощным функциям: дополнительные поля, вложения, теги, многоуровневые категории, автоматическое изменение размера загружаемых изображений, фотогалереи, видео и многое другое. K2 использовался для построения бесчисленного количества веб-сайтов, включая блоги, журналы, каталоги продукции и бизнес-справочники.

Ситуация оставалась стабильной до выхода Joomla 4, когда команда разработчиков K2 отказалась адаптировать компонент для работы с новыми версиями Joomla. В то же время хостинг-провайдеры начали переход на PHP 8+, а другие разработчики расширений для Joomla выпустили версии, совместимые с Joomla 4+, чтобы воспользоваться преимуществами улучшенной кодовой базы и более высокой производительностью PHP 8.x по сравнению с PHP 7.x. K2 стал серьезным препятствием для администраторов, желающих обновить Joomla. Между тем, в ядро Joomla были добавлены мощные пользовательские поля, теги и неограниченные уровни категорий, что сделало возможным миграцию обратно на стандартную систему контента Joomla в качестве замены K2.

В середине 2023 года клиент, управляющий новостным и медийным веб-сайтом, обратился с запросом на обновление его сайта с Joomla 3.x до Joomla 4. K2 был расширением, которое обеспечивало работу большей части контента веб-сайта, что делало проект чрезвычайно сложным с учетом следующих проблем и задач.

Проблемы и сложности

• Это был очень крупный веб-сайт с более чем 20 тысячами статей, тысячами тегов и десятками категорий. Это исключало возможность ручного переноса данных или даже использования простых SQL-запросов для миграции в систему материалов Joomla.
• Как новостной портал, для сайта было критически важно сохранить SEO-оптимизацию, включая ЧПУ-ссылки, мета-ключевые слова и описания, в которые клиент вложил значительные усилия.
• K2 использует собственный способ загрузки и хранения изображений статей, что требовало особого внимания для обеспечения корректного отображения изображений после миграции.
• На сайте использовался пользовательский плагин K2, который хранил дополнительную информацию для каждой статьи, и эти данные также необходимо было каким-то образом перенести вместе с остальной информацией.

Проектирование решения

Для продолжения работ по обновлению необходимо было найти способ миграции сущностей базы данных K2 в соответствующие им сущности системы материалов Joomla.

Первоначально были поиски готовых инструментов для выполнения этой задачи, но на момент начала проекта таковых не нашлось. Это означало, что необходимо было разработать собственное решение.

Разработка полноценного компонента Joomla показалась слишком трудоемкой (это было до бума AI, конечно же :)), поэтому оптимальным решением для этого случая, особенно учитывая размер веб-сайта, стало создание CLI-приложения (Command Line Interface) для Joomla.

Для тех, кто не знаком с концепцией CLI-приложений Joomla, это PHP-скрипты, предназначенные для запуска из командной строки. Опытный администратор Joomla может использовать их для выполнения задач администрирования и обслуживания в среде Joomla без использования веб-интерфейса.

Работа началась с подготовки таблицы для сопоставления сущностей K2 и Joomla. Получилась примерно такая таблица соответствий:

Была также подготовлена аналогичная таблица для сопоставления параметров элементов и категорий K2 с параметрами статей и категорий Joomla, чтобы минимизировать усилия по настройке макета после миграции. Более подробную информацию об этом можно найти в коде CLI-приложения.

Что касается изображений категорий и элементов, K2 хранит изображения в своей медиа-папке. Клиент хотел переместить их все в папку images. Однако скрипт можно модифицировать для создания отдельной папки для каждой категории и перемещения в нее изображений статей. Такой подход позволяет поддерживать папку с изображениями организованной и чистой.

Наконец, важно отметить, что миграция должна выполняться на сайте Joomla 3.x до начала процесса обновления. Очевидно, что такой подход безопаснее и контролируемее, поскольку позволяет убедиться в полном переносе всего контента перед обновлением.

Процесс миграции

ПРЕДУПРЕЖДЕНИЕ: Эта операция может быть прервана по любой причине. В таком случае необходимо восстановить базу данных из резервной копии и начать процесс заново.

В любом случае ОБЯЗАТЕЛЬНО создайте резервную копию вашего веб-сайта и протестируйте миграцию на копии, прежде чем применять ее на рабочем сайте. Используйте инструмент резервного копирования, такой как Akeeba Backup, или любой другой удобный инструмент для обеспечения безопасности контента вашего сайта.

Тщательно выполните следующие шаги для успешного завершения миграции:

1. Убедитесь, что в системе Joomla нет категорий или статей с таким же алиасом, что и у переносимых сущностей K2, так как это предотвратит миграцию соответствующих категорий и элементов K2.
2. Создайте необходимые пользовательские поля и группы, если в K2 использовались дополнительные поля.
3. Составьте таблицу соответствия ID дополнительных полей K2 и ID пользовательских полей статей Joomla. Эти данные понадобятся для заполнения массива $cfMapping в файле config.php (см. шаг 4 ниже).
4. Клонируйте или загрузите репозиторий MigrateK2 в папку cli в корневой директории вашего сайта Joomla.
5. Заполните необходимые значения конфигурации в файле migratek2/config.php. Более подробную информацию об этом файле конфигурации можно найти в файле README репозитория.
6. Откройте терминал на вашем сервере.
7. Перейдите в корневую директорию вашего веб-сайта Joomla.
8. Запустите скрипт с помощью команды:

   php cli/migratek2.php

9. Внимательно следите за сообщениями, выводящимися на экран. Вы увидите что-то подобное:
   
   

   

10. Если возникнет какая-либо проблема и миграция прервется, дополнительную полезную информацию можно найти в файле журнала: migrate_k2.log.php, который находится в папке logs вашего сайта.
11. После завершения процесса миграции вы увидите сообщение "Finished migrating K2 database."
12. Проведите аудит после миграции, чтобы подтвердить успешный перенос всех сущностей базы данных.
13. Если все прошло успешно, повторите миграцию на рабочем сайте и продолжите процесс обновления. В противном случае решите обнаруженные проблемы, восстановите базу данных (удалите частично перенесенные сущности) и перезапустите процесс миграции до его успешного завершения.
14. Наконец, можно безопасно удалить K2, удалить его зависимые расширения и завершить процесс обновления.

Действия после обновления

Чтобы сохранить те же ЧПУ-ссылки страниц категорий, элементов, тегов или авторов K2, необходимо воссоздать соответствующие пункты меню для статей или изменить пункты меню K2, установив для типа пункта меню соответствующий тип пункта меню статьи.

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

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

Желаем вам успешной и безопасной миграции :).