Cum să Migrezi un Site Drupal pe WordPress: Un Ghid Tehnic Complet
Migrarea de la Drupal la WordPress înseamnă transferul conținutului bazei de date, al fișierelor media, al structurii URL și al conturilor de utilizator din arhitectura CMS bazată pe entități a Drupal la modelul de tip post al WordPress — fără a pierde capitalul SEO, a întrerupe linkurile interne sau a provoca timp de nefuncționare. Procesul implică un import de conținut la nivel de bază de date prin intermediul pluginului FG Drupal to WordPress, urmat de maparea permalink-urilor, configurarea redirecționărilor 301 și reconstrucția temei.
Acest ghid acoperă fiecare fază a migrării în detaliu tehnic precis: strategia de backup pre-migrare, configurarea mediului, extragerea credențialelor bazei de date, importul bazat pe plugin, reconcilierea structurii URL și validarea post-lansare. Indiferent dacă rulați Drupal 7, 9 sau 10, fluxul de lucru de mai jos se aplică.
De ce să migrați de la Drupal la WordPress
Drupal este un framework puternic, dar complexitatea sa implică un cost operațional real. Actualizările modulelor introduc frecvent modificări incompatibile, tematizarea necesită expertiză în șabloane Twig, iar editările de conținut de rutină necesită implicarea unui dezvoltator. WordPress, prin contrast, oferă o curbă de învățare mai ușoară, un ecosistem de pluginuri mult mai vast și un cost total de proprietate mai scăzut pentru site-urile cu conținut bogat care nu necesită controlul granular al accesului sau modelarea complexă a conținutului din Drupal.
Argumentul performanței contează de asemenea. O instalare WordPress pe un mediu VPS Hosting configurat corespunzător cu LiteSpeed, cache de obiecte și stocare NVMe va depăși în mod constant un stack Drupal supraîncărcat pe infrastructură partajată.
Principalele motivații de migrare pe cazuri de utilizare:
- Echipele editoriale frustrate de UX-ul de administrare al Drupal și de fluxurile de publicare lente
- Agențiile care consolidează site-urile clienților pe un singur CMS gestionabil
- Dezvoltatorii care reduc costurile de întreținere din lanțurile de dependențe ale modulelor Drupal
- Echipele SEO care caută o integrare mai strânsă cu instrumentele native WordPress precum Yoast sau Rank Math
Drupal vs. WordPress: Comparație arhitecturală
Înțelegerea diferențelor structurale dintre cele două platforme este esențială înainte de a începe. Presupunerile nepotrivite despre modul în care este stocat conținutul reprezintă cauza principală a migrărilor eșuate sau incomplete.
| Dimensiune | Drupal | WordPress |
|---|---|---|
| Model de conținut | Entități (noduri, termeni de taxonomie, câmpuri) | Tipuri de postări (posts, pages, CPTs) |
| Schema bazei de date | Foarte normalizată, mai multe tabele per tip de conținut | Model plat wp_posts + wp_postmeta |
| Rutare URL | Aliasuri de cale stocate în tabelul path_alias | Reguli de rescriere permalink prin .htaccess |
| Motor de tematizare | Șabloane Twig + hook-uri de preprocesare | Ierarhie de șabloane PHP + hook-uri |
| Roluri de utilizator | Permisiuni granulare per rol | Ierarhie fixă de roluri (Subscriber → Admin) |
| Gestionarea media | Entitate de fișiere gestionate cu atașamente de câmp | Bibliotecă media cu tip de postare atașament |
| Multilingv | Modulul de bază Language | Necesită pluginul WPML sau Polylang |
| REST API | Module de bază JSON:API + REST | WP REST API integrat |
| Complexitate hosting | Ridicată (necesită Composer, Drush) | Scăzută (stack standard LAMP/LEMP) |
| Ecosistem plugin/modul | ~50.000 de module | ~60.000+ pluginuri |
Cel mai critic decalaj arhitectural este modelul de entitate de conținut. Drupal stochează paragrafe, câmpuri personalizate și referințe de taxonomie în mai multe tabele unite. Pluginul FG Drupal to WordPress mapează acestea la meta-datele postărilor WordPress și la termenii de taxonomie, dar aspectele complexe bazate pe paragrafe vor necesita reconstrucție manuală.
Listă de verificare pre-migrare
Înainte de a atinge oricare dintre medii, completați fiecare element de pe această listă. Omiterea pașilor este principala cauză a pierderii de date și a timpului de nefuncționare prelungit.
- Auditați inventarul de conținut Drupal: tipuri de noduri, vocabulare de taxonomie, număr de utilizatori, număr de fișiere și dimensiunea totală a bazei de date
- Identificați orice module Drupal fără echivalent WordPress (de ex., Rules, logică complexă Webform, Commerce)
- Confirmați că serverul WordPress îndeplinește cerințele minime: PHP 8.1+, MySQL 8.0+ sau MariaDB 10.6+, limită de memorie PHP de 256 MB
- Decideți o fereastră de migrare — ideal o perioadă cu trafic redus
- Activați modul de întreținere pe Drupal în timpul pasului final de import pentru a preveni deriva conținutului
- Verificați că serverul WordPress poate accesa gazda bazei de date Drupal (același server, gazdă la distanță sau tunel SSH)
Pasul 1: Faceți backup la site-ul dvs. Drupal
Un backup complet și verificat este obligatoriu. Aveți nevoie atât de dump-ul bazei de date, cât și de directorul de fișiere.
Backup bază de date prin Drush
Dacă aveți Drush instalat (standard pentru Drupal 9/10), aceasta este cea mai rapidă metodă:
drush sql-dump --result-file=/var/backups/drupal_backup_$(date +%Y%m%d).sql --gzipBackup bază de date prin mysqldump
mysqldump -u drupal_user -p drupal_database_name | gzip > /var/backups/drupal_backup_$(date +%Y%m%d).sql.gzBackup director de fișiere
tar -czf /var/backups/drupal_files_$(date +%Y%m%d).tar.gz /var/www/html/drupal/sites/default/files/Backup phpMyAdmin (metodă GUI)
- Conectați-vă la phpMyAdmin prin panoul de control al găzduirii
- Selectați baza de date Drupal din bara laterală stângă
- Faceți clic pe Export, alegeți metoda de export Quick, formatul SQL
- Faceți clic pe Go pentru a descărca fișierul
.sql
Stocați toate arhivele de backup în afara serverului — încărcați-le în stocare la distanță sau descărcați-le local prin SFTP. Un backup care există doar pe același server cu site-ul care este migrat nu este un backup real.
Pasul 2: Configurați WordPress pe serverul țintă
Instalați o instanță WordPress curată pe mediul dvs. țintă. Nu importați conținut Drupal într-un site WordPress existent dacă nu ați planificat explicit fuzionarea conținutului — importatorul nu va deduplica.
Cerințe de server
| Cerință | Minim | Recomandat |
|---|---|---|
| Versiune PHP | 7.4 | 8.2 |
| MySQL/MariaDB | MySQL 5.7 / MariaDB 10.3 | MySQL 8.0 / MariaDB 10.11 |
| Limită memorie PHP | 64 MB | 256 MB |
max_execution_time | 30s | 300s |
upload_max_filesize | 8 MB | 128 MB |
Pentru site-urile Drupal mari (10.000+ noduri, biblioteci media de mai mulți GB), un VPS cu cPanel vă oferă acces direct la configurarea PHP, parametrii de reglare MySQL și gestionarea job-urilor cron — toate acestea de care veți avea nevoie în timpul unei migrări intensive.
Instalare WordPress prin 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.comInstalare cu un singur clic prin cPanel
Dacă gazda dvs. oferă cPanel, navigați la Softaculous Apps Installer, selectați WordPress, completați credențialele bazei de date și ale administratorului și faceți clic pe Install. Procesul durează mai puțin de două minute.
După instalare, configurați imediat aceste setări PHP în php.ini sau prin .htaccess:
php_value max_execution_time 300
php_value memory_limit 256M
php_value post_max_size 128M
php_value upload_max_filesize 128MPasul 3: Instalați și configurați pluginul FG Drupal to WordPress
Pluginul FG Drupal to WordPress (nivel gratuit disponibil; Premium recomandat pentru site-uri mari) gestionează migrarea la nivel de bază de date a nodurilor, termenilor de taxonomie, utilizatorilor și fișierelor media.
Instalare
- În administrarea WordPress, mergeți la Plugins > Add New
- Căutați
FG Drupal to WordPress - Faceți clic pe Install Now, apoi pe Activate
Alternativ, instalați prin WP-CLI:
wp plugin install fg-drupal-to-wp --activateComparație funcționalități gratuit vs. Premium
| Funcționalitate | Gratuit | Premium |
|---|---|---|
| Suport Drupal 6/7 | Da | Da |
| Suport Drupal 8/9/10 | Parțial | Complet |
| Migrare paragrafe | Nu | Da |
| Migrare utilizatori | Nu | Da |
| Migrare Webform | Nu | Da |
| E-commerce (Drupal Commerce) | Nu | Da |
| Conținut multilingv | Nu | Da |
| Suport prioritar | Nu | Da |
Pentru orice site de producție care rulează Drupal 8 sau o versiune ulterioară, versiunea Premium merită costul. Încercarea de a reconstrui manual conținutul bazat pe paragrafe este mult mai costisitoare în timp de dezvoltator.
Pasul 4: Colectați credențialele bazei de date Drupal
Pluginul FG Drupal to WordPress se conectează direct la baza de date Drupal. Aveți nevoie de patru valori: numele bazei de date, numele de utilizator, parola și gazda.
Găsirea credențialelor în settings.php al Drupal
grep -A 20 "'database'" /var/www/html/drupal/sites/default/settings.phpRezultatul va conține un bloc ca acesta:
$databases['default']['default'] = [
'database' => 'drupal_db_name',
'username' => 'drupal_db_user',
'password' => 'drupal_db_password',
'host' => 'localhost',
'port' => '3306',
'driver' => 'mysql',
];Considerații privind accesul la baza de date la distanță
Dacă WordPress și Drupal se află pe servere diferite, baza de date Drupal trebuie să accepte conexiuni la distanță. Pe serverul bazei de date Drupal:
GRANT SELECT ON drupal_database.* TO 'drupal_user'@'wordpress_server_ip' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;De asemenea, asigurați-vă că portul 3306 este deschis în firewall doar pentru IP-ul serverului WordPress — nu expuneți niciodată MySQL la 0.0.0.0.
Dacă nu puteți deschide un port MySQL direct, utilizați un tunel SSH:
ssh -L 3307:localhost:3306 user@drupal_server_ip -N -fApoi setați gazda bazei de date a pluginului la 127.0.0.1 și portul la 3307.
Pasul 5: Rulați importul de conținut
Navigați la Tools > Import în tabloul de bord WordPress, derulați până la secțiunea Drupal și faceți clic pe Run Importer.
Configurarea setărilor importatorului
Fila conexiune bază de date:
- Gazdă bază de date:
localhost(sau IP la distanță / adresă tunel SSH) - Port:
3306(sau portul dvs. personalizat) - Nume bază de date: valoarea din
settings.php - Nume utilizator / Parolă: valorile din
settings.php - URL fișiere Drupal: URL-ul public al directorului
sites/default/files/al Drupal — necesar pentru descărcarea media
Faceți clic pe Test the connection înainte de a continua. O conexiune eșuată în această etapă este aproape întotdeauna cauzată de una dintre trei probleme: credențiale incorecte, un firewall care blochează portul MySQL sau utilizatorul bazei de date Drupal care nu are privilegii SELECT pe baza de date țintă.
Fila comportament — setări recomandate pentru majoritatea migrărilor:
- Import postări: Da
- Import pagini: Da
- Import categorii și etichete: Da
- Descărcare imagini și atașamente: Da (necesar pentru a copia media în directorul de încărcare al WordPress)
- Eliminare date WordPress înainte de import: Da (doar pe o instalare nouă — aceasta trunchiază
wp_postsși tabelele aferente)
Pornirea importului
Faceți clic pe Start / Resume the Importer. Pluginul procesează conținutul în loturi. Pentru site-urile mari, importul poate expira și poate necesita mai multe cicluri de reluare — acesta este comportamentul așteptat, nu o eroare. Pur și simplu faceți clic pe Resume de fiecare dată.
Monitorizați jurnalul de import afișat pe ecran. Urmăriți:
Error downloading file — indică faptul că URL-ul fișierelor Drupal este incorect sau că directorul de fișiere nu este accesibil public
Erori Duplicate entry — de obicei inofensive, indicând că pluginul sare peste înregistrările deja importate la o reluare
MySQL server has gone away — indică faptul că wait_timeout este prea scăzut pe serverul MySQL; măriți-l la cel puțin 600 secunde
SET GLOBAL wait_timeout = 600;
SET GLOBAL interactive_timeout = 600;
Pasul 6: Reconciliați structura URL și configurați redirecționările
Acesta este pasul pe care majoritatea ghidurilor îl subestimează. Nepotrivirile structurii URL între Drupal și WordPress sunt principala cauză a scăderilor de clasament SEO post-migrare.
Tipare URL Drupal (comune)
Tipar URL Drupal
Descriere
/node/123
Cale implicită a nodului (fără alias)
/about-us
Alias de cale (cel mai frecvent)
/taxonomy/term/5
Pagina termenului de taxonomie
/user/1
Profil de utilizator
/content/article-title
Alias prefixat cu tipul de conținut
Configurarea permalink-urilor WordPress
Mergeți la Settings > Permalinks și selectați o structură care se potrivește cât mai bine cu aliasurile de cale Drupal. Pentru majoritatea site-urilor Drupal care folosesc aliasuri curate, /%postname%/ este alegerea corectă.
/%postname%/
Dacă site-ul dvs. Drupal a folosit URL-uri prefixate cu categorie precum /blog/article-title, utilizați:
/%category%/%postname%/
Implementarea redirecționărilor 301
Instalați pluginul Redirection (de John Godley) pentru gestionarea regulilor de redirecționare. Pentru redirecționări în masă, exportați aliasurile de cale Drupal din baza de date:
SELECT source, alias FROM path_alias WHERE langcode = 'en';
Apoi importați CSV-ul rezultat în pluginul Redirection, mapând fiecare alias Drupal la echivalentul său WordPress. Pentru URL-urile de tip /node/123 care nu au fost niciodată aliasate, creați redirecționări bazate pe regex:
/node/([0-9]+)$ → /?p=$1
Aceasta mapează ID-urile nodurilor Drupal la ID-urile postărilor WordPress — dar funcționează doar dacă pluginul FG a păstrat ID-urile originale ale nodurilor ca ID-uri de postări, ceea ce face implicit.
Critic: Testați fiecare redirecționare cu curl -I înainte de lansare:
curl -I https://yourdomain.com/old-drupal-path
Verificați că răspunsul este HTTP/2 301 cu antetul Location corect, nu un 302 sau un 200 cu o redirecționare soft.
Pasul 7: Migrați temele și reconstruiți designul
Temele Drupal (bazate pe Twig) nu au un echivalent direct în WordPress. Trebuie să reconstruiți designul vizual folosind o temă WordPress ca fundație.
Strategia de selecție a temei
Teme bazate pe blocuri (FSE): Utilizați WordPress Site Editor pentru control complet al aspectului fără constructori de pagini. Cel mai bun pentru dezvoltatorii familiarizați cu marcajul de blocuri.
Teme clasice cu constructor de pagini: Teme precum Astra sau GeneratePress asociate cu Elementor sau Bricks Builder oferă cel mai apropiat echivalent al Layout Builder din Drupal.
Temă copil personalizată: Dacă site-ul dvs. Drupal a avut un design puternic personalizat, construiți o temă copil bazată pe un părinte minimal (Underscores, Blocksy) și replicați CSS-ul.
Reconstruirea meniurilor de navigare
Meniurile Drupal nu migrează automat. Reconstruiți-le în Appearance > Menus (teme clasice) sau în blocul Navigation al Site Editor (teme FSE). Consultați structura meniului Drupal:
drush eval "print_r(menu_tree_all_data('main', NULL));"
Sau interogați direct baza de date:
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;
Widget-uri și blocuri
Blocurile Drupal se mapează aproximativ la widget-urile WordPress și la blocurile Gutenberg. Reconstruiți regiunile din bara laterală și subsol în Appearance > Widgets sau direct în Site Editor. Tipurile de blocuri Drupal personalizate cu logică PHP vor trebui reconstruite ca shortcode-uri WordPress sau blocuri personalizate.
Pasul 8: Auditul conținutului post-migrare
Nu omiteți această fază. Instrumentele de migrare automată gestionează bine conținutul structurat, dar eșuează silențios în cazuri limită.
Verificări ale integrității conținutului
Media încorporată: Referințele inline la fișiere ale Drupal folosesc un format de token personalizat ([file:123] sau <drupal-media uuid="..."/>). Acestea nu se vor reda în WordPress. Căutați aceste token-uri în baza de date:
SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%drupal-media%' OR post_content LIKE '%[file:%';
Shortcode-uri și Views: Drupal Views nu au echivalent în WordPress. Orice pagină care reda un View (de ex., o listă de conținut filtrată) va fi goală. Reconstruiți-le folosind WP_Query, arhive de tipuri de postări personalizate sau un plugin precum Posts Table Pro.
Câmpuri personalizate: Datele câmpurilor Drupal migrate prin pluginul Premium ajung în wp_postmeta. Verificați că valorile câmpurilor sunt prezente:
SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_key LIKE 'field_%' LIMIT 50;
Conturi de utilizator: Dacă ați migrat utilizatori, verificați maparea rolurilor. Rolul authenticated user din Drupal se mapează la Subscriber în WordPress. editor din Drupal se mapează la Editor în WordPress. administrator din Drupal se mapează la Administrator în WordPress. Auditați maparea și ajustați după necesitate.
Detectarea linkurilor întrerupte
Instalați Broken Link Checker sau rulați o crawlare cu Screaming Frog pe mediul de staging înainte de schimbarea DNS. Remediați toate erorile 404 interne înainte de lansare — nu vă bazați pe monitorizarea post-lansare pentru a le detecta.
Pasul 9: Optimizarea performanței și securizarea
Un site WordPress proaspăt migrat necesită securizare înainte de a fi pregătit pentru producție.
Configurarea cache-ului
Instalați LiteSpeed Cache (dacă pe un server LiteSpeed) sau W3 Total Cache / WP Rocket pentru medii Apache/Nginx. Configurați:
Cache de pagini cu un TTL de cel puțin 3600 de secunde pentru paginile statice
Cache de obiecte susținut de Redis sau Memcached
Anteturi de cache pentru browser prin .htaccess sau configurarea serverului
SSL/HTTPS
Asigurați-vă că site-ul dvs. WordPress este servit exclusiv prin HTTPS. Dacă nu aveți deja un certificat, Certificatele SSL pot fi emise rapid și configurate pentru reînnoire automată. Actualizați setările URL ale site-ului WordPress:
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'
Forțați HTTPS în .htaccess:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Listă de verificare pentru securizare
Dezactivați XML-RPC dacă nu este necesar: adăugați add_filter('xmlrpc_enabled', '__return_false'); în functions.phpwp_ (necesită redenumirea bazei de date — faceți acest lucru înainte de import dacă este posibil)755, fișiere 644, wp-config.php 600find /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.phpPasul 10: Schimbarea DNS și lansarea
Efectuați schimbarea DNS în fereastra cu cel mai scăzut trafic. Procesul ar trebui să dureze mai puțin de 15 minute de lucru efectiv, cu o fereastră de propagare de până la 48 de ore (de obicei 1–4 ore pentru majoritatea resolverelor).
Verificări finale înainte de schimbarea DNS
- Rulați o crawlare completă a URL-ului de staging și confirmați zero erori 404
- Verificați că toate redirecționările 301 returnează antetele
Locationcorecte - Testați formularele de contact, funcționalitatea de căutare și orice fluxuri de e-commerce
- Confirmați că Google Search Console este verificat pe noul site
- Generați și trimiteți un sitemap XML proaspăt prin Yoast SEO sau Rank Math
Procesul de actualizare DNS
Dacă v-ați înregistrat domeniul prin Înregistrare domenii, actualizați înregistrarea A direct în panoul de gestionare DNS. Reduceți TTL-ul la 300 de secunde cu cel puțin 24 de ore înainte de schimbare pentru a minimiza întârzierea de propagare.
A record: yourdomain.com → [new WordPress server IP]
TTL: 300 (pre-cutover), restore to 3600 post-cutoverMonitorizare post-lansare
- Activați instrumentul de schimbare a adresei din Google Search Console dacă domeniul însuși s-a schimbat
- Monitorizați Core Web Vitals în Search Console pentru primele 30 de zile — așteptați-vă la o fluctuație temporară a clasamentului pe măsură ce Google recrawlează și reindexează
- Configurați UptimeRobot sau echivalent pentru monitorizarea disponibilității
- Verificați zilnic jurnalele de erori ale serverului în prima săptămână:
tail -f /var/log/apache2/error.log
# or for Nginx:
tail -f /var/log/nginx/error.logRetrimiterea la motoarele de căutare
Trimiteți sitemap-ul actualizat în Google Search Console:
- Mergeți la Search Console > Sitemaps
- Introduceți
sitemap.xml(sausitemap_index.xmlpentru site-uri mari) - Faceți clic pe Submit
Trimiteți de asemenea la Bing Webmaster Tools și verificați site-ul independent acolo — indexul Bing este utilizat de mai multe motoare de căutare AI, inclusiv Copilot.
Recomandări privind infrastructura de hosting
Performanța site-ului dvs. WordPress migrat depinde în mare măsură de infrastructura de bază. O migrare de la Drupal la WordPress este momentul ideal pentru a moderniza și stiva de hosting.
Pentru site-urile cu trafic moderat (10.000–100.000 de vizite lunare), un plan VPS Hosting cu cel puțin 2 vCPU, 4 GB RAM și stocare NVMe oferă suficient spațiu de manevră pentru WordPress cu cache de pagini complete. Pentru site-urile cu trafic ridicat sau intensive în resurse, Serverele dedicate elimină complet problema vecinului zgomotos și vă oferă control deplin asupra parametrilor kernel, configurației MySQL și reglajului stivei de rețea.
Dacă gestionați mai multe site-uri de clienți sau preferați o experiență de gestionare a serverului bazată pe GUI, Panourile de control VPS oferă o gamă de opțiuni incluzând cPanel, Plesk și DirectAdmin — fiecare suportând gestionarea WordPress multi-site, backup-uri automate și emiterea SSL dintr-o singură interfață.
Matricea de decizie tehnică: când să utilizați fiecare abordare de migrare
| Scenariu | Abordare recomandată | Instrument cheie |
|---|---|---|
| Drupal 7, site mic (<500 noduri) | Nivel gratuit plugin FG, același server | FG Drupal to WordPress (gratuit) |
| Drupal 9/10, conținut bazat pe paragrafe | Plugin FG Premium, server de staging | FG Drupal to WordPress Premium |
| Drupal Commerce → WooCommerce | FG Premium + add-on WooCommerce | FG + modul de migrare WooCommerce |
| Site Drupal multilingv | FG Premium + WPML | FG + plugin WPML |
| Drupal cu Views complexe | Reconstrucție manuală necesară | WP_Query + CPT UI |
| Migrare pe server diferit | Tunel SSH pentru acces la baza de date | Redirecționare port SSH |
| Cerință de zero timp de nefuncționare | Implementare blue-green | Reducere TTL DNS + staging |
Concluzii tehnice cheie
- Faceți backup înainte de orice altceva. Un dump SQL comprimat și un tarball al
sites/default/files/sunt plasa dvs. de siguranță. Verificați că ambele sunt complete și restaurabile înainte de a începe. - Testați conectivitatea bazei de date înainte de a rula importatorul. Majoritatea migrărilor eșuate se blochează la testul de conexiune din cauza regulilor de firewall sau a granturilor
SELECTlipsă. - Conținutul Drupal bazat pe paragrafe necesită pluginul Premium. Nivelul gratuit va sări silențios câmpurile de paragrafe, lăsând conținutul incomplet fără niciun mesaj de eroare.
- Redirecționările 301 nu sunt opționale. Fiecare URL Drupal care are backlink-uri externe sau indexare în motoarele de căutare trebuie să redirecționeze către echivalentul său WordPress cu un 301 permanent. O redirecționare lipsă înseamnă un semnal de clasament pierdut.
- Reduceți TTL-ul DNS cu 24 de ore înainte de schimbare. Setați-l la 300 de secunde astfel încât propagarea să se finalizeze în minute, nu în ore, când schimbați înregistrarea A.
- Auditați
wp_postmetapentru câmpurile Drupal nemapate. Datele câmpurilor personalizate ajung acolo după import — verificați că sunt prezente și cu cheia corectă înainte de a dezafecta instanța Drupal. - Nu dezafectați Drupal imediat. Păstrați mediul Drupal funcțional (în modul de întreținere, nu accesibil public) timp de cel puțin 30 de zile după lansare ca referință și opțiune de rollback.
- Retrimiteți sitemap-ul în aceeași zi în care lansați. Nu așteptați ca Googlebot să descopere organic noua structură — trimiterea activă accelerează recrawlarea.
Întrebări frecvente
Pot migra o instalare Drupal multisite la WordPress?
Da, dar fiecare subsite Drupal trebuie migrat individual. Pluginul FG Drupal to WordPress nu gestionează nativ Drupal multisite într-o singură trecere. Rulați un import separat pentru fiecare subsite, țintind fie o rețea WordPress Multisite, fie instalări WordPress independente în funcție de arhitectura dvs.
Vor fi transferate parolele utilizatorilor Drupal la WordPress?
Nu. Drupal folosește un hash SHA-512 cu salt (sau bcrypt în versiunile mai noi) care este incompatibil cu hash-ul bazat pe phpass al WordPress. Pluginul FG Premium migrează conturile de utilizator, dar resetează parolele, declanșând un email de resetare a parolei pentru fiecare utilizator. Planificați comunicarea cu utilizatorii în consecință.
Cum gestionez tipurile de conținut Drupal fără echivalent WordPress?
Înregistrați tipuri de postări personalizate (CPT) echivalente în WordPress înainte de a rula importul. Pluginul FG Premium vă permite să mapați tipurile de conținut Drupal la CPT-urile WordPress. Fără această mapare, toate nodurile vor fi implicite la tipul de postare post, colapsând taxonomia conținutului dvs.
Ce se întâmplă cu termenii de taxonomie Drupal în timpul migrării?
Vocabularele Drupal se mapează la taxonomiile WordPress. Maparea implicită convertește tags din Drupal la etichete WordPress și categories din Drupal la categorii WordPress. Vocabularele personalizate necesită înregistrarea manuală a taxonomiei în WordPress înainte de import, altfel vor fi eliminate.
Cât durează migrarea pentru un site Drupal mare?
Pentru un site cu 5.000 de noduri și 2 GB de media, așteptați-vă la 2–4 ore de timp de import pe un server bine dotat, plus 4–8 ore de auditare a conținutului post-migrare și configurare a redirecționărilor. Schimbarea efectivă a DNS durează mai puțin de 15 minute. Timpul total scurs de la început până la lansare este de obicei una până la două zile lucrătoare pentru o migrare temeinică, de calitate pentru producție.
