15%

Economisește 15% la toate serviciile de găzduire

Testează-ți abilitățile și obține Reducere la orice plan de găzduire

Utilizați codul:

Skills
Începeți
23.10.2024

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.

DimensiuneDrupalWordPress
Model de conținutEntități (noduri, termeni de taxonomie, câmpuri)Tipuri de postări (posts, pages, CPTs)
Schema bazei de dateFoarte normalizată, mai multe tabele per tip de conținutModel plat wp_posts + wp_postmeta
Rutare URLAliasuri de cale stocate în tabelul path_aliasReguli de rescriere permalink prin .htaccess
Motor de tematizareȘabloane Twig + hook-uri de preprocesareIerarhie de șabloane PHP + hook-uri
Roluri de utilizatorPermisiuni granulare per rolIerarhie fixă de roluri (Subscriber → Admin)
Gestionarea mediaEntitate de fișiere gestionate cu atașamente de câmpBibliotecă media cu tip de postare atașament
MultilingvModulul de bază LanguageNecesită pluginul WPML sau Polylang
REST APIModule de bază JSON:API + RESTWP REST API integrat
Complexitate hostingRidicată (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 --gzip

Backup bază de date prin mysqldump

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

Backup 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)

  1. Conectați-vă la phpMyAdmin prin panoul de control al găzduirii
  2. Selectați baza de date Drupal din bara laterală stângă
  3. Faceți clic pe Export, alegeți metoda de export Quick, formatul SQL
  4. 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țăMinimRecomandat
Versiune PHP7.48.2
MySQL/MariaDBMySQL 5.7 / MariaDB 10.3MySQL 8.0 / MariaDB 10.11
Limită memorie PHP64 MB256 MB
max_execution_time30s300s
upload_max_filesize8 MB128 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.com

Instalare 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 128M

Pasul 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

  1. În administrarea WordPress, mergeți la Plugins > Add New
  2. Căutați FG Drupal to WordPress
  3. Faceți clic pe Install Now, apoi pe Activate

Alternativ, instalați prin WP-CLI:

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

Comparație funcționalități gratuit vs. Premium

FuncționalitateGratuitPremium
Suport Drupal 6/7DaDa
Suport Drupal 8/9/10ParțialComplet
Migrare paragrafeNuDa
Migrare utilizatoriNuDa
Migrare WebformNuDa
E-commerce (Drupal Commerce)NuDa
Conținut multilingvNuDa
Suport prioritarNuDa

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.php

Rezultatul 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 -f

Apoi 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.php
  • Schimbați prefixul implicit al tabelului wp_ (necesită redenumirea bazei de date — faceți acest lucru înainte de import dacă este posibil)
  • Instalați Wordfence sau Solid Security pentru firewall și protecție la autentificare
  • Setați permisiunile fișierelor: directoare 755, fișiere 644, wp-config.php 600
  • 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

    Pasul 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 Location corecte
    • 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-cutover

    Monitorizare 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.log

    Retrimiterea la motoarele de căutare

    Trimiteți sitemap-ul actualizat în Google Search Console:

    1. Mergeți la Search Console > Sitemaps
    2. Introduceți sitemap.xml (sau sitemap_index.xml pentru site-uri mari)
    3. 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

    ScenariuAbordare recomandatăInstrument cheie
    Drupal 7, site mic (<500 noduri)Nivel gratuit plugin FG, același serverFG Drupal to WordPress (gratuit)
    Drupal 9/10, conținut bazat pe paragrafePlugin FG Premium, server de stagingFG Drupal to WordPress Premium
    Drupal Commerce → WooCommerceFG Premium + add-on WooCommerceFG + modul de migrare WooCommerce
    Site Drupal multilingvFG Premium + WPMLFG + plugin WPML
    Drupal cu Views complexeReconstrucție manuală necesarăWP_Query + CPT UI
    Migrare pe server diferitTunel SSH pentru acces la baza de dateRedirecționare port SSH
    Cerință de zero timp de nefuncționareImplementare blue-greenReducere 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 SELECT lipsă.
    • 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_postmeta pentru 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.

    15%

    Economisește 15% la toate serviciile de găzduire

    Testează-ți abilitățile și obține Reducere la orice plan de găzduire

    Utilizați codul:

    Skills
    Începeți