Перенос контента с CMS Joomla 3 на CMS WordPress 4

Выбор CMS для разработки сайта

Несколько лет назад при выборе CMS, на которой сделать сайт я пользовался довольной примитивной схемой. Не смотря на ее примитивность, на результате это не сказывалось. Делалось это так. Если будущий сайт должен был быть Интернет-магазином, то выбиралась Joomla. Если же предполагался любой другой сайт — выбирался WordPress. Он не подходил для магазина, потому что существовало всего 2-3 магазинных плагина, которые не имели интеграции с русскими платежными системами, службами доставки, да и для оптимизации под поисковые системы были не достаточно гибкими.

В настоящее время, Woocommerce для WordPress основательно расширил свой функционал и это позволяет делать Интернет-магазины на WP без каких-либо дополнительных сложностей. Однако, сейчас имеется несколько старых сайтов на Joomla и некоторые из них пришли к пределам возможностей этой CMS.

Нынешние проблемы с Joomla 3, из-за которых нужна миграция

Система ЧПУ

Joomla 3, как и более ранние версии имеет странную систему ЧПУ. Да, разработчики давно ушли от динамических урлов, но сделать качественные адреса страниц они не могут/не хотят/ленятся. В итоге для того, чтобы получить реально человеческое ЧПУ, приходится прибегать к сторонним компонентам.

Одним из самых популярных является sh404sef. Он поддерживает большое количество надстроек и для каждой из них делает урл вида: домен/категория/подкатегория/запись. Кроме того, что это удобно, это еще и дает более качественную индексацию и ранжирование в поиске. Под индексацией я имею ввиду не только попадание в индекс поисковиков, но систему быстрых ссылок и  отображение в сниппете хлебных крошек.

Однако, как выяснилось, у компонента есть существенный недостаток. Все далее описанное касается версии 4.7.3. После нее было принято решение об отказе в продлении лицензии. Поэтому, возможно, сейчас компонент и работает как-то иначе, но учитывая, что последняя версия 4.8.2 — вряд ли. А проблема заключается в следующем: компонент сканирует урлы внутри сайта. При переписке с разработчиком и указанием ему, что такой подход требует много ресурсов и часто выдает 404-ю ошибку, он заверил меня, что все работает не так, а компонент генерит урлы только при обращении к странице. Конечно, ему как разработчику виднее. Но я провел несколько экспериментов на новых локальных установках и на старых сайтах и итог один и тот же.

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

Пример 2. Старый сайт стал дико тормозить, в базе больше 800.000 записей урлов, созданных компонентом. При этом на сайте порядка 30.000 реальных страниц. Очищаю базу урлов, нажимаю «обновить». Урлы начинают прибавляться. То, что нужно, но не достаточно быстро. Перехожу сам по ссылкам и везде вижу 404 ошибку. То есть компонент не генерит ссылки при обращении. Спустя сутки некоторые из этих страниц стали доступны, когда количество урлов в базе выросло.

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

Каталоги

Так же, как и со многими другими решениями по расширению функционала, задачу каталогизации тоже выполняют разные компоненты. 2 самых популярных SOBI и Zoo. Оба платные. Zoo с учетом плагинов стоит несколько сотен долларов. Казалось бы, за эту цену компонент должен работать отлично, но нет. При создании базы на 130.000 записей, страница с категориями открывается по 30-40 секунд. При этом без записей, категории открываются быстро. Создается впечатление, что компонент сканирует все свои записи прежде, чем просто вывести список рубрик. Я не знаю, так ли это на самом деле, но по факту, чем больше записей в базе, тем дольше выводятся рубрики.

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

Выводы

1. Магазины с количеством товаров более 20.000 единиц со временем обречены на тормоза из-за расширений для ЧПУ.
2. Каталоги с количеством записей больше 25.000 обречены на тормоза сразу.

Варианты решения

1. Более мощный сервер. Проверено на VPS с 8 ядрами по 2.4 Мгц и 8 гигами оперативной памяти — нет прироста производительности.
2. Тонкая настройка сервера. 3 суток работы сисадмина с хорошей репутацией и отзывами — нет прироста производительности.
3. Сменить компонент ЧПУ. Возможно это решит проблему большого количества записей в базе, но учитывая, что есть проблема с каталогами, этот вариант не подходит. Кроме того, любые компоненты и плагины замедляют работу CMS и уход к CMS, которая из коробки делать качественные урлы, предпочтителен.
4. Сменить компонент каталога. То же, самое, что и п. 3.
5. Оптимизация кода CMS. Не очень нравится этот вариант, потому что при обновлении, старые правки могут быть затерты или будут конфликтовать. А отказываться от обновлений неразумно.
6. Перенос сайтов на другую CMS. Этим и займемся.

Старый опыт миграции с Joomla 1 на WordPress 3

Когда-то я уже переносил контент с Joomla 1 на WordPress 3. Путем перебора нескольких решений, удалось найти рабочий вариант. Собственно, если у Вас версии такие, то далее читайте тут. К сожалению, автор свою разработку забросил и за 5 лет обновлений не было. Поэтому в этот раз пришлось искать другие варианты.

Как перенести контент с Joomla 3 на WordPress 4

На удивление удалось найти всего 2 варианта.

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

Второй — платный плагин для WordPress. Есть и бесплатная версия, но она мало что может перенести, поэтому для полного переноса потребуется все-таки покупать. Стоит 40 евро сам плагин + к нему надо докупать расширения для переноса контента из разных компонентов Joomla. Например, комментарии из Jcomments — 15 евро, записи из К2 — 25 евро, товары из Virtuemart — 70 евро. Настроек не много, так что все просто: указали данные для подключения к базе Joomla, указали как размещать переносимый контент, запуск.

При обрыве, зависании и т.д., плагин умеет продолжать работу, без повторного переноса всего подряд.

Результат

WordPress с каталогом реализованным через pods и 50.000 записей открывается за 3 секунды с выключенным кешированием. После импорта остальных данных и включения кешей на сервере и на сайте, обновлю данные по скорости. Но уже очевидно, что WordPress обгоняет Joomla по производительности. Так что и остальные сайты будем переносить на WP.

На вопросы готов ответить в комментариях.

UPD. После увеличения количества записей WordPress до 90.000 штук, переноса на веб-сервер, подключения кеширования и CDN, скорость открытия страниц составила 1.7 секунды против 3.2 на Joomla. То есть ускорение статей, категорий и прочих записей почти в 2 раза. А каталог на Joomla открывался вообще по 30-32 секунды, так что тут ускорение почти в 20 раз.