Перенос сайта с Drupal на WordPress с фрилансером

Как перенести сайт с Drupal на WordPress с помощью фрилансера: план переноса контента и функций

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

Фрилансер может организовать работу, но владельцу сайта тоже предстоит принять ряд важных решений. Прежде чем выяснять, как перенести сайт с Drupal на WordPress с помощью фрилансера, составьте опись контента, определите, какими функциями действительно пользуются люди, и договоритесь, чем две системы должны отличаться после запуска. Если рассматриваете миграция Drupal на WordPress с фрилансером, заранее обсудите объём работ и критерии приёмки. Так у переноса будет план с проверяемыми критериями, а не расплывчатое указание «перенести всё».

1. Сопоставьте типы материалов Drupal со структурами WordPress

Для начала перечислите типы материалов Drupal и поля, связанные с каждым из них. Новостная статья может содержать заголовок, краткое описание, основной текст, автора, дату публикации, тему и главное изображение. У страницы товара может быть другой набор полей и связь с категорией или поставщиком. Прежде чем выбирать структуры WordPress, фрилансеру понадобится такая опись.

Материалы Drupal могут переноситься в стандартные записи или страницы WordPress, но для некоторых лучше создать отдельный тип записей. Например, каталог организаций с собственным архивом и полями профиля обычно удобнее оформить как тип записей «Организация», а не как набор обычных страниц. Таксономии могут стать рубриками WordPress или пользовательскими таксономиями — в зависимости от того, как они используются. Таблица сопоставления полей поможет наглядно зафиксировать эти решения.

Не думайте, что одинаковые названия полей означают одинаковое поведение. Для поля Drupal, допускающего несколько значений, может потребоваться иная настройка WordPress, чем для поля с одним значением. А для даты, сохранённой с часовым поясом, может понадобиться отдельное правило преобразования. Запишите примеры нестандартных значений, чтобы фрилансер мог проверить их, а не угадывать, как с ними поступить.

Включите в таблицу и URL. Если статья в Drupal находится по адресу /news/community-update, решите, сохранит ли WordPress этот путь или настроит перенаправление на новый. Таблица с типом исходного материала, целевой структурой, полями, правилами переноса таксономий и обработкой URL послужит общей опорой при тестировании.

2. Решите, что нужно перенести, заменить или оставить

Модули Drupal часто поддерживают определённые рабочие процессы. Недостаточно скопировать видимую функцию, если важен и процесс, который за ней стоит. Перечислите используемые на сайте модули и пользовательские функции, а затем укажите, кто от них зависит. Для входа пользователей, очереди редакционной проверки и фасетного поиска могут потребоваться три разных решения для WordPress.

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

Попросите фрилансера описать предлагаемое решение и его ограничения для каждой функции, которую вы собираетесь сохранить. Если замена меняет круг пользователей, которые могут редактировать контент, или способ, которым посетители его находят, зафиксируйте это до начала разработки. Формулировка «работает как Drupal» — плохой критерий приёмки. А вот «редакторы могут отправить статью на проверку, не публикуя её» — хороший.

Отделите обязательные функции от пожеланий. Так проще контролировать объём работ, если у модуля Drupal нет прямого аналога, и владелец сможет согласовать более простой процесс. При этом перенос контента и функций с Drupal на WordPress стоит планировать как единый процесс: сохранность данных и проверка рабочих сценариев одинаково важны. Подробнее о выборе между отдельным подрядчиком и командой читайте в статье нанять ли фрилансера.

3. Подготовьте репрезентативную выборку для переноса

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

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

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

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

4. Определите правила очистки контента и передачи редакторам

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

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

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

Договоритесь, кто будет проверять перенесённую копию и как передавать на обработку исключения. Например, фрилансер может подготовить таблицу материалов без изображений, а редактор — предоставить замены до запуска. Чёткий порядок передачи работ отделяет технический перенос от редакционной проверки.

5. Проверяйте перенесённые данные, а не только внешний вид

Визуальная проверка помогает выявить проблемы с вёрсткой, но не гарантирует, что все поля и связи перенесены правильно. Сравните записи в Drupal и WordPress по заголовкам, основному тексту, значениям полей, привязкам таксономий, авторам, временным меткам и связям с медиафайлами. Проверки должны учитывать структуру контента на сайте, а не ограничиваться просмотром главной страницы.

По возможности используйте выгрузки или запросы к базе данных, чтобы сравнить количество записей и выбранные поля. Если в план переноса входят 240 событий Drupal, в отчёте нужно учесть соответствующее число записей в WordPress или перечислить конкретные исключения. Не полагайтесь на совпадение чисел без проверки. Если итоговое количество пока неизвестно, отметьте это как пункт для проверки, а не придумывайте целевое значение.

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

Описывайте исключения так, чтобы по ним можно было действовать: укажите исходный идентификатор, URL в WordPress, проблему, ответственного и статус. Заметку «с некоторыми изображениями что-то не так» трудно обработать. Если указать конкретную статью и отсутствующее изображение, у фрилансера и редактора появится чёткая задача.

6. Спланируйте запуск с учётом изменений контента

Пока фрилансер занимается WordPress, контент на сайте может продолжать меняться. До начала переноса выберите один из двух вариантов: заморозить контент или перенести изменения отдельным этапом. В первом случае редакторы на согласованный период прекращают публикацию в Drupal, пока идёт финальный перенос и проверка. Во втором фрилансер сначала переносит основной контент, а затем — записи, созданные или изменённые после этого момента.

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

Составьте список условий для запуска с конкретными пунктами: финальный перенос завершён, важные страницы проверены, перенаправления протестированы, формы успешно отправляют данные, владельцы контента уведомлены. Заранее определите, будет ли запуск остановлен при сбое критически важного пункта или проблему можно будет решить согласованным обходным способом. Это решение нужно принять до того, как начнётся спешка в день запуска.

7. Завершите проект: доступы, документация и возможность отката

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

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

Готовность к откату означает, что у вас есть копия сайта на Drupal, которую можно восстановить, и понятно, кто займётся восстановлением, если после запуска нового сайта возникнет серьёзная проблема. Договоритесь, где хранится резервная копия, кто отвечает за восстановление и какие условия станут поводом для отката. Не удаляйте старый сайт сразу после запуска WordPress: сохраните его, пока не будут пройдены согласованные проверки и команда не подтвердит, что важный контент и рабочие процессы функционируют как нужно.