Як перенести сайт із Drupal на WordPress

Як перенести сайт із Drupal на WordPress за допомогою фрилансера: план перенесення контенту та функцій

Міграція з Drupal на WordPress — це не просто перенесення сторінок. Сайти на Drupal часто використовують типи матеріалів, таксономії, поля, права доступу й модулі, яким немає прямих аналогів у WordPress. Якщо проігнорувати ці особливості, новий сайт може здаватися готовим, хоча пошукові фільтри не працюватимуть, імена авторів зникнуть, а медіафайли втратять зв’язок із контентом.

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

1. Визначте відповідність між типами матеріалів Drupal і структурами WordPress

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

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

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

Додайте до таблиці відповідності й URL-адреси. Якщо стаття в Drupal зараз доступна за адресою /news/community-update, вирішіть, чи збереже WordPress цей шлях, чи перенаправлятиме на новий. У таблиці з типом вихідного матеріалу, цільовою структурою, полями, правилами для таксономій і налаштуваннями URL зручно звірятися під час тестування.

2. Визначте, що потрібно відтворити, замінити або залишити

Модулі Drupal часто підтримують конкретні робочі процеси. Тому недостатньо просто відтворити видиму функцію, якщо важливий і процес, що за нею стоїть. Складіть список модулів і власних функцій, які використовує сайт, і зазначте, хто від них залежить. Для входу учасників, черги редакційного погодження й фасетного пошуку можуть знадобитися три різні рішення для WordPress.

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

Попросіть фрилансера описати запропоноване рішення та його обмеження для кожної функції, яку планують зберегти. Якщо заміна змінить те, хто може редагувати контент або як відвідувач його знаходить, зафіксуйте це до початку розробки. Критерій «працює як Drupal» нічого конкретного не означає. Натомість «редактори можуть надіслати статтю на перевірку, не публікуючи її» — цілком зрозумілий критерій приймання.

Відокремте обов’язкові функції від побажань. Це допоможе контролювати обсяг робіт, якщо прямого аналога модуля Drupal немає, і дасть власнику змогу погодити простіший процес. Щоб дізнатися більше про вибір між окремим підрядником і командою, дивіться статтю чи варто наймати фрилансера.

3. Підготуйте репрезентативну вибірку для міграції

Перш ніж переносити всю базу даних, попросіть фрилансера мігрувати невелику вибірку з матеріалами різних типів. Таке перенесення контенту з Drupal у WordPress допоможе перевірити поля, таксономії, URL-адреси й медіафайли до обробки всього сайту. На простій сторінці можна перевірити базові поля та URL. Стаття з багатьма таксономіями допоможе перевірити прив’язки до термінів та ієрархію. Матеріал із великою кількістю медіа дасть змогу перевірити файли зображень, підписи й вбудований контент. Якщо на сайті є особливий тип матеріалу, додайте до вибірки хоча б один приклад.

Вибірка має бути достатньою, щоб охопити різні випадки, але не такою великою, щоб власник або редактор не міг перевірити кожен запис окремо. Домовтеся, які саме вихідні матеріали використати та що вважати правильним результатом для кожного з них. Наприклад, у статті зі зразка можуть бути потрібні початковий автор, два тематичні терміни, дата оновлення та файл для завантаження.

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

Попросіть фрилансера записати проблеми, знайдені під час тестової міграції, і відповідні зміни до таблиці. Цей документ стане першою версією нотаток про міграцію та допоможе уникнути ситуації, коли під час подальшого передавання справ усі покладаються лише на пам’ять.

4. Установіть правила очищення контенту та передавання роботи редакції

Міграція — не найкращий час для рішень щодо контенту, які ніде не зафіксовані. Заздалегідь домовтеся, що робити із застарілими чернетками, дубльованими сторінками, непідтримуваними значеннями полів і матеріалами, позначеними для перевірки. Один із практичних варіантів — переносити за замовчуванням опублікований контент, а чернетки залишити в окремому списку на перевірку. Конкретне рішення залежить від процесу публікації на сайті.

За рішення щодо дублікатів має відповідати конкретна людина. Фрилансер може позначити записи зі схожими заголовками чи URL, але об’єднати, видалити чи зберегти їх має вирішити редактор. Якщо дві сторінки Drupal із подібними заголовками містять різну інформацію, автоматичне очищення може призвести до втрати корисного контенту. Ведіть журнал рішень із вихідним URL, обраною дією та ім’ям відповідального редактора.

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

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

5. Перевірте перенесені дані, а не лише зовнішній вигляд

Візуальна перевірка виявить проблеми з версткою, але не підтвердить, що всі поля й зв’язки перенеслися правильно. Порівняйте записи Drupal і WordPress за заголовками, основним текстом, значеннями полів, прив’язками до таксономій, авторством, часовими мітками та зв’язками з медіафайлами. Вибирайте перевірки, що відповідають структурі контенту сайту, замість того щоб обмежуватися переглядом головної сторінки.

Якщо можливо, порівняйте кількість записів і вибрані поля за допомогою експорту або запитів до бази даних. Якщо потрібно перенести 240 записів про події з Drupal, у звіті про міграцію мають бути враховані цільові записи або наведений конкретний список винятків. Не припускайте, що кількість збігається, поки цього не перевірили. Якщо остаточне число ще невідоме, позначте його як таке, що потребує перевірки, а не вигадуйте цільове значення.

Перевірте зв’язки й у самому інтерфейсі WordPress. Відкрийте архів таксономії та переконайтеся, що там відображається стаття, прив’язана до потрібного терміна. Перевірте архів автора, якщо він використовується для навігації. Відкрийте кілька матеріалів із великою кількістю медіафайлів і переконайтеся, що зображення чи вкладення належать саме тим записам, а не просто десь є в медіатеці.

Описуйте винятки достатньо докладно, щоб їх можна було усунути: ідентифікатор вихідного запису, цільовий URL, проблема, відповідальна особа та статус. Нотатку «з деякими зображеннями щось не так» важко опрацювати. Якщо вказати статтю, якої бракує зображення, фрилансер і редактор отримають конкретне завдання.

6. Сплануйте перенесення з урахуванням змін контенту

Поки фрилансер налаштовує WordPress, контент на сайті може й далі змінюватися. Ще до початку міграції оберіть один із двох варіантів: тимчасово призупинити публікацію контенту або перенести всі зміни за останній період окремо. У першому випадку редактори на погоджений час припиняють публікувати матеріали в Drupal, поки відбувається фінальне перенесення та перевірки. У другому фрилансер спочатку імпортує основний контент, а потім переносить записи, створені чи змінені після цього.

Тимчасове призупинення простіше пояснити, але воно може завадити роботі активної редакції чи організації. Окреме перенесення останніх змін дає змогу продовжувати публікацію, однак для нього потрібен надійний спосіб визначати змінені записи й уникати дублікатів. З’ясуйте, хто відстежуватиме зміни, коли відбудеться останній імпорт і як перевірятимуть оновлення під час перенесення.

Складіть контрольний список запуску з конкретними етапами: завершено фінальний імпорт, перевірено пріоритетні сторінки, протестовано перенаправлення, успішно надіслано форми, повідомлено власників контенту. Якщо критично важливий етап не пройдено, заздалегідь вирішіть, чи потрібно відкласти запуск, чи проблему можна усунути за погодженим тимчасовим рішенням. Це рішення слід ухвалити до того, як настане напружений день запуску.

7. Завершіть передавання справ, документації та підготовку до відновлення

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

Перевірте й доступи до облікових записів. Видаліть тимчасові облікові записи або зменште рівень дозволів, які вже не потрібні. Якщо під час міграції доступами ділилися, змініть облікові дані. Призначте конкретну відповідальну особу адміністратором WordPress, щоб сайт не залежав від особистого облікового запису колишнього підрядника.

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