Перехід з Drupal на 1С-Бітрікс — завдання, яке ми вирішуємо регулярно. Клієнти приходять зі скаргами на складнощі інтеграції з 1С, відсутність корпоративних інструментів (Бітрікс24) або необхідність імпортозаміщення. Міграція з Drupal технічно складніша, ніж з більшості інших CMS, через гнучку, але нестандартну модель зберігання даних. Одна з типових ситуацій — інтернет-магазин на Drupal Commerce, який перестав справлятися з навантаженням і потребує інтеграції з 1С. Перенесення на Бітрікс не тільки вирішує ці проблеми, але й скорочує час на обмін даними з обліковою системою в 2-3 рази завдяки готовим модулям обміну. Наші клієнти економлять до 40% бюджету на розробку інтеграцій у порівнянні з доопрацюваннями Drupal. Зв'яжіться з нами для аудиту вашого проекту. Отримайте консультацію — обговоримо деталі вашого переїзду.
Чому міграція з Drupal технічно складніша, ніж з інших CMS?
У Drupal 7 контент зберігається через систему Field API. Кожне поле вузла (node) зберігається в окремій таблиці з ім'ям виду field_data_{field_name} та field_revision_{field_name}. Основні таблиці:
-
node— базовий запис:nid,type,title,uid,status,created,changed. -
node_revision— історія ревізій. -
field_data_body— тіло матеріалу:body_value,body_summary,body_format. -
field_data_{custom_field}— довільні поля, одна таблиця на кожне. -
taxonomy_term_data,taxonomy_vocabulary— таксономія (категорії, теги). -
file_managed— медіафайли. -
users,users_roles,role— користувачі.
У Drupal 8/9 архітектура схожа, але зберігання через Doctrine DBAL і конфіги в YAML. Таблиці: node__body, node__field_{name} (одна таблиця на поле, всі ревізії в node_revision__*). Згідно з офіційною документацією, така структура забезпечує гнучкість, але ускладнює пряму міграцію.
Проектування структури в Бітрікс
Кожен тип контенту (content type) Drupal стає інфоблоком у Бітрікс. Таксономія — розділи інфоблоку або властивості типу «Список». Поля node мапимо на властивості інфоблоку.
Перед написанням скрипту складаємо таблицю мапінгу:
| Drupal | Тип | Бітрікс | Тип властивості |
|---|---|---|---|
field_data_body.body_value |
text_long | DETAIL_TEXT |
— |
field_data_image.field_image_fid |
image | PREVIEW_PICTURE |
— |
field_data_field_tags |
term_reference | PROPERTY_TAGS |
Список |
field_data_field_price |
decimal | PROPERTY_PRICE |
Число |
Скрипт міграції
Drupal 7: скрипт читає дані через PDO з MySQL-бази Drupal. Для кожного node:
SELECT n.nid, n.title, n.created, b.body_value, b.body_summary FROM node n LEFT JOIN field_data_body b ON b.entity_id = n.nid AND b.bundle = 'article' WHERE n.type = 'article' AND n.status = 1 Потім для кожного поля — окремий JOIN або підзапит. Результат — масив даних для CIBlockElement::Add().
Медіафайли. У Drupal файли реєструються в file_managed з полем uri формату public://photos/image.jpg. Фізично файл лежить у sites/default/files/photos/image.jpg. Копіюємо файли, реєструємо через CFile::SaveFile(), прив'язуємо до елемента.
Таксономія. Терміни таксономії (taxonomy_term_data) переносимо як розділи інфоблоку або як значення властивостей типу «Список». Якщо в Drupal в одного матеріалу кілька термінів з одного словника — створюємо властивість «Множинне» в Бітрікс.
Як перенести багатомовний сайт?
Drupal має вбудовану багатомовність через модулі i18n (Drupal 7) або вбудований Content Translation (Drupal 8+). Переклади зберігаються в field_data_* з різними language-значеннями. Бітрікс підтримує багатомовність через інфоблоки з LANGUAGE_ID або через різні сайти в одній установці. Якщо сайт багатомовний — цей етап потребує окремого проектування.
Views та блоки
Drupal Views — динамічні списки матеріалів з фільтрацією та сортуванням. У Бітрікс їх аналог — компонент bitrix:news.list з параметрами фільтрації. Прямого перенесення Views не існує: кожен View аналізується вручну та реалізується як компонент або кастомний код.
Блоки Drupal (region/block) — у Бітрікс це області ($APPLICATION->ShowPanel()) та компоненти в шаблоні. Структура сторінок переноситься при розробці дизайну, не при міграції даних.
Модулі Drupal без аналогів
Webform → форми через bitrix:form. Commerce (Drupal Commerce) → модулі catalog + sale. Rules → бізнес-процеси Бітрікс або обробники подій. Feeds (імпорт) → агент або cron-задача Бітрікс.
Як зберегти SEO-позиції при переїзді?
Ключовий елемент — 301 редиректи. Ми створюємо карту відповідності старих URL Drupal новим адресам у Бітрікс. Додатково налаштовуємо sitemap, robots.txt, передаємо мета-теги з полів Drupal. Для зображень зберігаємо alt-тексти та імена файлів.
Як виконати міграцію: покроковий план
- Аудит бази даних Drupal: аналіз структури, типів контенту, обсягів.
- Проектування інфоблоків та мапінг полів: повна схема відповідності.
- Розробка скрипту міграції: PHP-скрипт на PDO, обробка всіх сутностей.
- Перенесення медіафайлів: копіювання файлів зі збереженням шляхів та атрибутів.
- Налаштування SEO-редиректів: генерація .htaccess з 301 редиректами.
- Тестування та верифікація даних: звірка кількості елементів, перевірка посилань.
- Документація та навчання адміністраторів: передача знань.
- Підтримка після міграції: технічний супровід на 2 тижні.
Строки
| Етап | Типові строки |
|---|---|
| Аудит типів контенту та полів | 1–2 дні |
| Проектування інфоблоків та мапінг полів | 1–2 дні |
| Розробка скрипту міграції | 3–6 днів |
| Перенесення медіафайлів | 1–2 дні |
| Багатомовність (за наявності) | 2–3 дні |
| SEO-редиректи | 1 день |
| Тестування та правки | 1–2 дні |
| Разом | 10–18 робочих днів |
Drupal — одна з найскладніших для міграції CMS саме через нестандартну структуру зберігання та велику кількість можливих модулів. Реальний строк завжди уточнюється після аудиту вихідної бази даних. Щоб оцінити обсяг роботи для вашого проекту, отримайте консультацію — ми проведемо аудит і запропонуємо план міграції під ключ. Гарантуємо якість та збереження позицій.