Как да мигрирате уебсайт от Drupal към WordPress: Пълно техническо ръководство

Мигрирането от Drupal към WordPress означава прехвърляне на съдържанието на вашата база данни, медийни файлове, URL структура и потребителски акаунти от архитектурата на CMS, базирана на обекти на Drupal, към модела на типове публикации на WordPress — без загуба на SEO стойност, прекъсване на вътрешни връзки или причиняване на престой. Процесът включва импортиране на съдържание на ниво база данни чрез плъгина FG Drupal to WordPress, последвано от съпоставяне на постоянни връзки, конфигуриране на 301 пренасочвания и реконструкция на темата.

Това ръководство обхваща всяка фаза на тази миграция с точни технически подробности: стратегия за архивиране преди миграция, настройка на средата, извличане на идентификационни данни за база данни, импортиране чрез плъгин, съгласуване на URL структурата и валидиране след стартиране. Независимо дали използвате Drupal 7, 9 или 10, описаният по-долу работен процес е приложим.

Защо да мигрирате от Drupal към WordPress

Drupal е мощна платформа, но сложността му носи реални оперативни разходи. Актуализациите на модулите често въвеждат критични промени, темите изискват познания за Twig шаблони, а рутинното редактиране на съдържание изисква участие на разработчик. WordPress, за разлика от него, предлага по-лесна крива на обучение, значително по-голяма екосистема от плъгини и по-ниска обща цена на притежание за сайтове с много съдържание, които не изискват детайлния контрол на достъпа или сложното моделиране на съдържание на Drupal.

Аргументът за производителност също е важен. Инсталация на WordPress на правилно конфигурирана среда за VPS Хостинг с LiteSpeed, обектно кеширане и NVMe съхранение ще превъзхожда постоянно раздута Drupal инфраструктура на споделена среда.

Основни мотиви за миграция по случай на употреба:

• Редакционни екипи, разочаровани от администраторския UX на Drupal и бавните работни процеси за публикуване
• Агенции, консолидиращи клиентски сайтове в единна управляема CMS
• Разработчици, намаляващи разходите за поддръжка от веригите на зависимости на модулите на Drupal
• SEO екипи, търсещи по-тясна интеграция с инструменти, родни за WordPress, като Yoast или Rank Math

Drupal срещу WordPress: Сравнение на архитектурата

Разбирането на структурните разлики между двете платформи е от съществено значение преди да започнете. Несъответстващите предположения за начина на съхранение на съдържанието са основната причина за неуспешни или непълни миграции.

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

Контролен списък преди миграция

Преди да докоснете която и да е среда, изпълнете всеки елемент от този списък. Пропускането на стъпки тук е водещата причина за загуба на данни и продължителен престой.

• Направете одит на инвентара на съдържанието на Drupal: типове възли, таксономични речници, брой потребители, брой файлове и общ размер на базата данни
• Идентифицирайте всички модули на Drupal без еквивалент в WordPress (напр. Rules, Webform сложна логика, Commerce)
• Потвърдете, че вашият WordPress сървър отговаря на минималните изисквания: PHP 8.1+, MySQL 8.0+ или MariaDB 10.6+, 256 MB PHP ограничение на паметта
• Определете прозорец за миграция — в идеалния случай период с ниско натоварване
• Активирайте режим на поддръжка в Drupal по време на финалното импортиране, за да предотвратите отклонение на съдържанието
• Проверете дали WordPress сървърът може да достигне хоста на базата данни на Drupal (същият сървър, отдалечен хост или SSH тунел)

Стъпка 1: Архивирайте вашия уебсайт на Drupal

Пълното, проверено архивиране е задължително. Нуждаете се от дъмп на базата данни и директорията с файлове.

Архивиране на база данни чрез Drush

Ако имате инсталиран Drush (стандартен за Drupal 9/10), това е най-бързият метод:

drush sql-dump --result-file=/var/backups/drupal_backup_$(date +%Y%m%d).sql --gzip

Архивиране на база данни чрез mysqldump

mysqldump -u drupal_user -p drupal_database_name | gzip > /var/backups/drupal_backup_$(date +%Y%m%d).sql.gz

Архивиране на директорията с файлове

tar -czf /var/backups/drupal_files_$(date +%Y%m%d).tar.gz /var/www/html/drupal/sites/default/files/

Архивиране чрез phpMyAdmin (GUI метод)

1. Влезте в phpMyAdmin чрез контролния панел на вашия хостинг
2. Изберете базата данни на Drupal от лявата странична лента
3. Кликнете Export, изберете метод за бърз експорт Quick, формат SQL
4. Кликнете Go, за да изтеглите файла .sql

Съхранявайте всички архивни файлове извън сървъра — качете ги в отдалечено хранилище или ги изтеглете локално чрез SFTP. Архив, който се съхранява само на същия сървър като мигрирания сайт, не е истински архив.

Стъпка 2: Настройте WordPress на целевия сървър

Инсталирайте чиста инстанция на WordPress на целевата среда. Не импортирайте съдържание от Drupal в съществуващ WordPress сайт, освен ако изрично не сте планирали обединяване на съдържание — инструментът за импортиране няма да премахва дублирани записи.

Изисквания към сървъра

За големи Drupal сайтове (10 000+ възли, медийни библиотеки с няколко GB), VPS с cPanel ви дава директен достъп до PHP конфигурация, параметри за настройка на MySQL и управление на cron задачи — всичко, от което ще се нуждаете по време на тежка миграция.

Инсталиране на WordPress чрез WP-CLI

cd /var/www/html/wordpress
wp core download
wp config create --dbname=wp_database --dbuser=wp_user --dbpass=secure_password --dbhost=localhost
wp core install --url="https://yourdomain.com" --title="Site Title" --admin_user=admin --admin_password=strongpassword --admin_email=admin@yourdomain.com

Инсталиране с едно кликване чрез cPanel

Ако вашият хост предоставя cPanel, отидете до Softaculous Apps Installer, изберете WordPress, попълнете идентификационните данни за базата данни и администратора и кликнете Install. Процесът отнема по-малко от две минути.

След инсталацията незабавно конфигурирайте тези PHP настройки в php.ini или чрез .htaccess:

php_value max_execution_time 300
php_value memory_limit 256M
php_value post_max_size 128M
php_value upload_max_filesize 128M

Стъпка 3: Инсталирайте и конфигурирайте плъгина FG Drupal to WordPress

Плъгинът FG Drupal to WordPress (безплатна версия налична; Premium се препоръчва за големи сайтове) обработва миграцията на ниво база данни на възли, таксономични термини, потребители и медийни файлове.

Инсталиране

1. В администраторския панел на WordPress отидете до Plugins > Add New
2. Потърсете FG Drupal to WordPress
3. Кликнете Install Now, след това Activate

Алтернативно, инсталирайте чрез WP-CLI:

wp plugin install fg-drupal-to-wp --activate

Сравнение на функциите на безплатната и Premium версия

За всеки производствен сайт, работещ на Drupal 8 или по-нова версия, Premium версията си заслужава разходите. Опитът за ръчно реконструиране на съдържание, базирано на параграфи, е значително по-скъп от гледна точка на времето на разработчика.

Стъпка 4: Съберете идентификационните данни за базата данни на Drupal

Плъгинът FG Drupal to WordPress се свързва директно с вашата база данни на Drupal. Нуждаете се от четири стойности: име на базата данни, потребителско име, парола и хост.

Намиране на идентификационни данни в settings.php на Drupal

grep -A 20 "'database'" /var/www/html/drupal/sites/default/settings.php

Изходът ще съдържа блок като този:

$databases['default']['default'] = [
  'database' => 'drupal_db_name',
  'username' => 'drupal_db_user',
  'password' => 'drupal_db_password',
  'host' => 'localhost',
  'port' => '3306',
  'driver' => 'mysql',
];

Съображения за отдалечен достъп до база данни

Ако WordPress и Drupal са на различни сървъри, базата данни на Drupal трябва да приема отдалечени връзки. На сървъра на базата данни на Drupal:

GRANT SELECT ON drupal_database.* TO 'drupal_user'@'wordpress_server_ip' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

Също така се уверете, че порт 3306 е отворен в защитната стена само за IP адреса на WordPress сървъра — никога не излагайте MySQL на 0.0.0.0.

Ако не можете да отворите директен MySQL порт, използвайте SSH тунел:

ssh -L 3307:localhost:3306 user@drupal_server_ip -N -f

След това задайте хоста на базата данни на плъгина на 127.0.0.1 и порта на 3307.

Стъпка 5: Стартирайте импортирането на съдържание

Отидете до Tools > Import в таблото на WordPress, превъртете до секцията Drupal и кликнете Run Importer.

Конфигуриране на настройките на инструмента за импортиране

Раздел за връзка с база данни:

• Database host: localhost (или отдалечен IP / адрес на SSH тунел)
• Port: 3306 (или вашият персонализиран порт)
• Database name: стойност от settings.php
• Username / Password: стойности от settings.php
• Drupal files URL: публичният URL на вашата директория sites/default/files/ на Drupal — необходим за изтегляне на медии

Кликнете Test the connection преди да продължите. Неуспешна връзка на този етап почти винаги се дължи на един от три проблема: неправилни идентификационни данни, защитна стена, блокираща MySQL порта, или потребителят на базата данни на Drupal, на когото липсват привилегии SELECT за целевата база данни.

Раздел за поведение — препоръчителни настройки за повечето миграции:

• Import posts: Да
• Import pages: Да
• Import categories and tags: Да
• Download images and attachments: Да (необходимо за копиране на медии в директорията за качване на WordPress)
• Remove WordPress data before import: Да (само при нова инсталация — това изтрива wp_posts и свързаните таблици)

Стартиране на импортирането

Кликнете Start / Resume the Importer. Плъгинът обработва съдържанието на партиди. За големи сайтове импортирането може да изтече и да изисква множество цикли на възобновяване — това е очаквано поведение, а не грешка. Просто кликнете Resume всеки път.

Наблюдавайте регистрационния журнал, показан на екрана. Следете за:

Error downloading file — показва, че URL адресът на файловете на Drupal е неправилен или директорията с файлове не е публично достъпна
Грешки Duplicate entry — обикновено безвредни, показващи, че плъгинът пропуска вече импортирани записи при възобновяване
MySQL server has gone away — показва, че wait_timeout е твърде ниска на MySQL сървъра; увеличете я до поне 600 секунди

SET GLOBAL wait_timeout = 600;
SET GLOBAL interactive_timeout = 600;
Стъпка 6: Съгласувайте URL структурата и конфигурирайте пренасочванията
Това е стъпката, която повечето ръководства подценяват. Несъответствията в URL структурата между Drupal и WordPress са основната причина за спадове в SEO класирането след миграция.
URL модели на Drupal (Общи)




URL модел на Drupal
Описание




/node/123
Път по подразбиране на възел (без псевдоним)


/about-us
Псевдоним на пътя (най-разпространен)


/taxonomy/term/5
Страница на таксономичен термин


/user/1
Потребителски профил


/content/article-title
Псевдоним с префикс на тип съдържание




Конфигуриране на постоянни връзки в WordPress
Отидете до Settings > Permalinks и изберете структура, която съответства възможно най-близо на псевдонимите на пътищата на Drupal. За повечето Drupal сайтове, използващи чисти псевдоними, /%postname%/ е правилният избор.
/%postname%/
Ако вашият Drupal сайт е използвал URL адреси с префикс на категория като /blog/article-title, използвайте:
/%category%/%postname%/
Прилагане на 301 пренасочвания
Инсталирайте плъгина Redirection (от John Godley) за управление на правила за пренасочване. За масови пренасочвания, експортирайте псевдонимите на пътищата на Drupal от базата данни:
SELECT source, alias FROM path_alias WHERE langcode = 'en';
След това импортирайте получения CSV файл в плъгина Redirection, съпоставяйки всеки псевдоним на Drupal с неговия еквивалент в WordPress. За URL адреси от стил /node/123, които никога не са имали псевдоним, създайте пренасочвания, базирани на регулярни изрази:
/node/([0-9]+)$ → /?p=$1
Това съпоставя ID на възли на Drupal с ID на публикации в WordPress — но работи само ако плъгинът FG е запазил оригиналните ID на възли като ID на публикации, което прави по подразбиране.
Критично: Тествайте всяко пренасочване с curl -I преди да стартирате:
curl -I https://yourdomain.com/old-drupal-path
Проверете дали отговорът е HTTP/2 301 с правилния заглавен ред Location, а не 302 или 200 с меко пренасочване.
Стъпка 7: Мигрирайте темите и реконструирайте дизайна
Темите на Drupal (базирани на Twig) нямат директен еквивалент в WordPress. Трябва да реконструирате визуалния дизайн, използвайки тема на WordPress като основа.
Стратегия за избор на тема

Теми, базирани на блокове (FSE): Използвайте WordPress Site Editor за пълен контрол върху оформлението без конструктори на страници. Най-подходящо за разработчици, запознати с блоков маркъп.
Класически теми с конструктор на страници: Теми като Astra или GeneratePress, съчетани с Elementor или Bricks Builder, предлагат най-близкия еквивалент на Layout Builder на Drupal.
Персонализирана дъщерна тема: Ако вашият Drupal сайт е имал силно персонализиран дизайн, изградете дъщерна тема, базирана на минимален родител (Underscores, Blocksy), и репликирайте CSS.

Реконструиране на навигационни менюта
Менютата на Drupal не се мигрират автоматично. Реконструирайте ги под Appearance > Menus (класически теми) или блока Navigation на Site Editor (FSE теми). Направете справка с вашата структура на менюто в Drupal:
drush eval "print_r(menu_tree_all_data('main', NULL));"
Или направете заявка директно към базата данни:
SELECT ml.link_path, ml.link_title, ml.weight, ml.depth
FROM menu_links ml
WHERE ml.menu_name = 'main-menu' AND ml.hidden = 0
ORDER BY ml.weight;
Уиджети и блокове
Блоковете на Drupal се съпоставят приблизително с уиджетите на WordPress и блоковете на Gutenberg. Реконструирайте страничните панели и регионите на долния колонтитул под Appearance > Widgets или директно в Site Editor. Персонализираните типове блокове на Drupal с PHP логика ще трябва да бъдат реконструирани като WordPress shortcodes или персонализирани блокове.
Стъпка 8: Одит на съдържанието след миграция
Не пропускайте тази фаза. Автоматизираните инструменти за миграция обработват добре структурираното съдържание, но се провалят безшумно при гранични случаи.
Проверки на целостта на съдържанието

Вградени медии: Вградените файлови препратки на Drupal използват персонализиран формат на токен ([file:123] или <drupal-media uuid="..."/>). Те няма да се визуализират в WordPress. Потърсете тези токени в базата данни:

SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%drupal-media%' OR post_content LIKE '%[file:%';

Shortcodes и Views: Drupal Views нямат еквивалент в WordPress. Всяка страница, която е визуализирала View (напр. филтриран списък на съдържание), ще бъде празна. Реконструирайте ги с WP_Query, архиви на персонализирани типове публикации или плъгин като Posts Table Pro.


Персонализирани полета: Данните от полетата на Drupal, мигрирани чрез Premium плъгина, се намират в wp_postmeta. Проверете дали стойностите на полетата са налични:

SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_key LIKE 'field_%' LIMIT 50;

Потребителски акаунти: Ако сте мигрирали потребители, проверете съпоставянето на роли. Ролята authenticated user на Drupal се съпоставя с Subscriber на WordPress. Drupal editor се съпоставя с Editor на WordPress. Drupal administrator се съпоставя с Administrator на WordPress. Направете одит на съпоставянето и коригирайте при необходимост.

Откриване на счупени връзки
Инсталирайте Broken Link Checker или стартирайте обхождане с Screaming Frog срещу вашата тестова среда преди смяната на DNS. Поправете всички вътрешни 404 грешки преди стартирането — не разчитайте на мониторинг след стартирането, за да ги открие.
Стъпка 9: Оптимизиране на производителността и сигурността
Прясно мигриран WordPress сайт се нуждае от укрепване преди да е готов за производство.
Конфигуриране на кеширане
Инсталирайте LiteSpeed Cache (ако сте на LiteSpeed сървър) или W3 Total Cache / WP Rocket за Apache/Nginx среди. Конфигурирайте:

Кеш на страниците с TTL от поне 3600 секунди за статични страници
Обектен кеш, поддържан от Redis или Memcached
Заглавни редове на кеша на браузъра чрез .htaccess или конфигурация на сървъра

SSL/HTTPS
Уверете се, че вашият WordPress сайт се обслужва изключително чрез HTTPS. Ако все още нямате сертификат, SSL сертификати могат да бъдат издадени бързо и конфигурирани за автоматично подновяване. Актуализирайте настройките за URL адреса на сайта в WordPress:
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'
Принудете HTTPS в .htaccess:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Контролен списък за укрепване на сигурността

Деактивирайте XML-RPC, ако не е необходим: добавете add_filter('xmlrpc_enabled', '__return_false'); към functions.php

find /var/www/html/wordpress -type d -exec chmod 755 {} ;
find /var/www/html/wordpress -type f -exec chmod 644 {} ;
chmod 600 /var/www/html/wordpress/wp-config.php

Стъпка 10: Смяна на DNS и стартиране

Извършете смяната на DNS по време на прозореца с най-ниско натоварване. Процесът трябва да отнеме под 15 минути реална работа, с прозорец за разпространение до 48 часа (обикновено 1–4 часа за повечето резолвери).

Финални проверки преди смяната

• Стартирайте пълно обхождане на URL адреса на тестовата среда и потвърдете нулеви 404 грешки
• Проверете дали всички 301 пренасочвания връщат правилни заглавни редове Location
• Тествайте форми за контакт, функционалност за търсене и всякакви потоци за електронна търговия
• Потвърдете, че Google Search Console е верифициран на новия сайт
• Генерирайте и изпратете нова XML карта на сайта чрез Yoast SEO или Rank Math

Процес на актуализиране на DNS

Ако сте регистрирали домейна си чрез Регистрация на домейни, актуализирайте A записа директно в панела за управление на DNS. Намалете TTL до 300 секунди поне 24 часа преди смяната, за да минимизирате забавянето на разпространението.

A record: yourdomain.com → [new WordPress server IP]
TTL: 300 (pre-cutover), restore to 3600 post-cutover

Мониторинг след стартиране

• Активирайте инструмента за смяна на адрес на Google Search Console, ако самият домейн се е променил
• Наблюдавайте Core Web Vitals в Search Console за първите 30 дни — очаквайте временно колебание в класирането, докато Google повторно обхожда и индексира
• Настройте UptimeRobot или еквивалент за мониторинг на наличността
• Проверявайте регистрационните журнали на сървъра ежедневно за първата седмица:

tail -f /var/log/apache2/error.log
# or for Nginx:
tail -f /var/log/nginx/error.log

Повторно подаване към търсачки

Изпратете актуализираната карта на сайта в Google Search Console:

1. Отидете до Search Console > Sitemaps
2. Въведете sitemap.xml (или sitemap_index.xml за големи сайтове)
3. Кликнете Submit

Изпратете също и до Bing Webmaster Tools и верифицирайте сайта там независимо — индексът на Bing се използва от няколко AI търсачки, включително Copilot.

Препоръки за хостинг инфраструктура

Производителността на мигрирания ви WordPress сайт зависи в голяма степен от основната инфраструктура. Миграцията от Drupal към WordPress е идеалният момент да модернизирате и вашия хостинг стек.

За сайтове с умерен трафик (10 000–100 000 месечни посещения), план за VPS Хостинг с поне 2 vCPU, 4 GB RAM и NVMe съхранение осигурява достатъчен резерв за WordPress с кеширане на пълни страници. За сайтове с висок трафик или интензивно използване на ресурси, Dedicated сървъри напълно елиминират проблема с шумните съседи и ви дават пълен контрол върху параметрите на ядрото, конфигурацията на MySQL и настройката на мрежовия стек.

Ако управлявате множество клиентски сайтове или предпочитате управление на сървъра чрез GUI, VPS контролни панели предлагат набор от опции, включително cPanel, Plesk и DirectAdmin — всеки поддържащ управление на множество WordPress сайтове, автоматизирани архиви и издаване на SSL сертификати от един интерфейс.

Матрица за технически решения: Кога да използвате всеки подход за миграция

Ключови технически изводи

• Архивирайте преди всичко останало. Компресиран SQL дъмп и tarball на sites/default/files/ са вашата предпазна мрежа. Проверете дали и двата са пълни и могат да бъдат възстановени преди да започнете.
• Тествайте свързаността с базата данни преди да стартирате инструмента за импортиране. Повечето неуспешни миграции спират при теста за връзка поради правила на защитната стена или липсващи SELECT привилегии.
• Съдържанието на Drupal, базирано на параграфи, изисква Premium плъгина. Безплатната версия ще пропуска безшумно полетата на параграфите, оставяйки съдържанието непълно без съобщение за грешка.
• 301 пренасочванията не са по избор. Всеки URL адрес на Drupal, който има външни обратни връзки или индексиране от търсачки, трябва да пренасочва към своя еквивалент в WordPress с постоянен 301. Липсващото пренасочване е изгубен сигнал за класиране.
• Намалете DNS TTL 24 часа преди смяната. Задайте го на 300 секунди, за да завърши разпространението за минути, а не часове, когато смените A записа.
• Направете одит на wp_postmeta за несъпоставени полета на Drupal. Данните от персонализираните полета се намират там след импортирането — проверете дали са налични и правилно ключувани преди да извадите от употреба инстанцията на Drupal.
• Не извеждайте Drupal от употреба незабавно. Поддържайте средата на Drupal работеща (в режим на поддръжка, не публично достъпна) поне 30 дни след стартирането като референция и опция за връщане назад.
• Изпратете повторно картата на сайта в същия ден, в който стартирате. Не чакайте Googlebot да открие новата структура органично — активното подаване ускорява повторното обхождане.

ЧЗВ

Мога ли да мигрирам инсталация на Drupal multisite към WordPress?

Да, но всеки подсайт на Drupal трябва да бъде мигриран поотделно. Плъгинът FG Drupal to WordPress не обработва нативно Drupal multisite в един проход. Стартирайте отделно импортиране за всеки подсайт, насочено към мрежа на WordPress Multisite или самостоятелни инсталации на WordPress в зависимост от вашата архитектура.

Ще се прехвърлят ли паролите на потребителите на Drupal към WordPress?

Не. Drupal използва хеширане с добавена сол SHA-512 (или bcrypt в по-новите версии), което е несъвместимо с хеширането, базирано на phpass, на WordPress. Плъгинът FG Premium мигрира потребителски акаунти, но нулира паролите, задействайки имейл за нулиране на парола до всеки потребител. Планирайте комуникацията с потребителите съответно.

Как да обработя типовете съдържание на Drupal без еквивалент в WordPress?

Регистрирайте еквивалентни Custom Post Types (CPTs) в WordPress преди да стартирате импортирането. Плъгинът FG Premium ви позволява да съпоставяте типове съдържание на Drupal с CPTs на WordPress. Без това съпоставяне всички възли по подразбиране ще бъдат от тип публикация post, сгъвайки вашата таксономия на съдържанието.

Какво се случва с таксономичните термини на Drupal по време на миграция?

Речниците на Drupal се съпоставят с таксономиите на WordPress. Съпоставянето по подразбиране преобразува tags на Drupal в тагове на WordPress и categories на Drupal в категории на WordPress. Персонализираните речници изискват ръчна регистрация на таксономия в WordPress преди импортирането, или ще бъдат изхвърлени.

Колко време отнема миграцията за голям Drupal сайт?

За сайт с 5 000 възли и 2 GB медии, очаквайте 2–4 часа за импортиране на добре оборудван сървър, плюс 4–8 часа за одит на съдържанието след миграция и конфигуриране на пренасочванията. Действителната смяна на DNS отнема под 15 минути. Общото изминало време от началото до стартирането обикновено е един до два работни дни за задълбочена, качествена миграция за производство.