Основная проблема, которая существует в WordPress – отсутствие переносимости (portability).

Функция экспорта/импорта в WordPress

WordPress поставляется вместе с возможностью экспорта контента в XML-формате (используя специфичный для WordPress формат WXR). Эта возможность неплохо подходит для создания быстрого бэкапа, однако в конечном счете она убивает то, что многие издатели ждут от «переносимого» приложения.

Файл WXR содержит слишком мало информации для восстановления сайта с нуля. Среди пропавших элементов можно назвать:

• Пользовательская мета-информация (включая хэшированные пароли) – все пользователи должны быть заново созданы на целевом сайте.
• Прикрепления – медиа-файлы могут быть скачаны и импортированы на новый сайт только в том случае, если исходный сайт по-прежнему функционирует онлайн, и к медиа-файлам есть доступ.
• Параметры сайта – теглайн, настройки обратных ссылок и уведомлений, настройки временной зоны и т.д.

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

Разработчики даже создали разделители WXR-файлов, чтобы ускорить процесс импорта/экспорта. Все эти инструменты являются хорошими, однако они явно показывают, что у нас есть одна проблема.

Дампы базы данных

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

Я использую mysqldump для экспорта базы данных, копирую ее на целевой сервер, затем использую инструменты командной строки MySQL для повторного импорта той же самой базы данных. После этого с помощью WP-CLI я провожу замену всех поврежденных строк (т.е. измененные домены) в базе данных, что обычно выполняется вручную.

Данный процесс проходит гораздо быстрее, нежели разбиение файла WXR, поочередное импортирование его «кусков», а также ручное обновление параметров и других недостающих данных. Однако этот метод по-прежнему не является эффективным.

Некоторые сайты обладают относительно небольшими базами данных – дампы данных умещаются примерно в пару мегабайтов. На других сайтах стоят достаточно мощные системы – и дампы данных представляют собой файлы размерами по 1.5 Гб и выше. Одно дело – хранить такие объемы информации в базе данных; другое дело – переносить их.

Как это должно быть в идеале

Мне нравится, что MySQL заметно ускоряет поиск данных, помогая оптимизировать работу с отдельными объектами в базе данных. Мне не нравится то, что MySQL заметно усложняет перенос контента с одного сервера на другой.

В идеале WordPress должна быть отделенной от своего хранилища данных – позволяя, к примеру, заменить MySQL на YAML-документы для хранения данных. Возможность работы с различными системами передачи и обработки данных позволила бы администраторам сайта переводить свой контент из одного формата в другой и обратно без каких-либо потерь.

Формат WXR передает данные с потерями – он опускает некоторую важную информацию. Дампы MySQL идут без потерь, однако у них отсутствует гибкость – вы можете переносить MySQL только на MySQL, и только в том случае, если у вас есть прямой доступ к базе данных (если вы когда-либо пробовали вставить объемный дамп базы данных в phpMyAdmin, то вы понимаете, о чем я говорю).

Я хотел бы, чтобы у меня была возможность с помощью одного щелчка представить мой сайт в виде набора нескольких человеко-читаемых flat-файлов. Я хотел бы использовать те же самые flat-файлы для того, чтобы динамически воссоздавать весь сайт на другом сервере без потери данных.

Если когда-либо WordPress сможет достигнуть такого состояния, то продукт (а также контент, управляемый им) станет действительно переносимым.

Источник: eamann.com/tech