Știința din spatele unei migrații de succes Drupal 7 la 9 (și de ce unii dintre ei eșuează)

Îți amintești acel site minunat pe care toți cei din compania ta l-au iubit (sau cel puțin l-au tolerat) că ai fost forțat să migrezi la un sistem mai nou? Și echipa în care ai avut încredere să o facă, poate că a rupt mai mult decât poate mesteca? Ceea ce poate fi fost cândva un site web perfect frumos și funcțional, acum devine o mizerie de probleme bizare, performanță slabă sau, uneori, un site aproape inutilizabil.

Dacă vă sună familiar și vă confruntați cu probleme ciudate după ce v-ați actualizat site-ul Drupal 7 (sau 6) la Drupal 9 (sau 8), vă rugăm să citiți acest articol până la sfârșit . Vom aborda problemele comune cu care se confruntă proprietarii de site-uri după ce fac upgrade la Drupal 7 (sau 6) la Drupal 9 (sau 8) și cum pot fi rezolvate. Acest lucru nu va acoperi toate problemele pe care le vedem atunci când venim pentru o salvare a migrației, dar ar trebui cel puțin să vă aducă într-un punct în care să puteți dormi noaptea.

Upgrade Drupal 7 la 9 - Provocarea fundamentală

Prima întrebare pe care probabil ți-o pui este: „De ce?” Actualizarea de la Drupal 7 la Drupal 9 (Drupal 8 a fost acum apus) pare că nu ar trebui să fie atât de dificilă din perspectiva platformei.

Ei bine, Drupal 8 a schimbat totul. A avut o revizuire arhitecturală completă, astfel încât CMS să poată fi mai durabil, mai relevant și mai ușor de înțeles pe termen lung. Adoptarea tehnologiilor și cadrelor moderne, cum ar fi programarea orientată pe obiecte, Symfony, Twig, cele mai recente versiuni PHP și (atât de multe) altele, au permis, de asemenea, comunității Drupal să crească exponențial, găzduind o gamă mai largă de abilități pentru a ajuta la construirea Drupal. Ceea ce înseamnă că acum este mai ușor să găsești un expert care să creeze și să întrețină site-ul tău web Drupal. Vestea grozavă este că actualizarea la orice versiuni viitoare de Drupal (cum ar fi Drupal 8 la Drupal 9) după acea migrare inițială este extrem de ușoară și nu va necesita o reconstrucție.

Dar, revenind la problema de față, multe organizații migrează încă de la Drupal 7 la 9 , ceea ce implică o reconstrucție completă a site-ului web. Reconstrucția în sine este suficient de complexă, fără a menține structura actuală a conținutului, încât să le poată oferi celor mai experimentați dezvoltatori. Și, în majoritatea cazurilor, site-urile web mai mari necesită și mai multă atenție, deoarece tind să aibă mai multe module personalizate și contribuite, care nu au o cale directă de actualizare. Toate acestea împreună deschid oportunități infinite pentru erori.

Pentru echipele care nu au încercat acest tip de migrare, de cele mai multe ori, prima greșeală de migrare Drupal 7 la 9 este lipsa de pregătire. Primul și cel mai important pas pentru o migrare de succes a Drupal este efectuarea unui audit amănunțit de migrare pentru a analiza fiecare mic detaliu al structurii actuale a site - ului . Acest raport nu numai că vă ajută să evaluați implicațiile migrației, dar vă va oferi și perspective asupra domeniilor de îmbunătățire. Următorul pas cel mai important este să decideți dacă permiteți unui partener de dezvoltare Drupal specializat (cineva care respiră Drupal zi de zi) să efectueze migrarea. Așa cum ați prefera ca un chirurg cardiac să efectueze o operație de bypass față de un chirurg ortoped; a avea o companie specializată axată pe Drupal pentru a-ți construi site-ul web Drupal va duce la o migrare de succes.

Drupal obișnuite 7 până la 9 provocări de migrare

Una dintre cele mai frecvente surse de frustrare după o migrare Drupal 6/7 la 8/9 este să nu știi de unde să începi atunci când te confrunți cu probleme. Cum afli, cu sau fără abilități de codare, unde se află adevăratele probleme? Ușor - verificați jurnalele de erori. Știu, se pare că ai deschide o altă cutie de viermi încercând să înțelegi ce spun jurnalele, dar te vom prezenta mai jos prin cele obișnuite.

Să ne aruncăm direct în unele dintre cele mai frecvente probleme cu care se confruntă proprietarii de site-uri Drupal după o migrare de la Drupal 7 la Drupal 9.

Site-ul abia este deschis / stricat

1. Probleme cu serverul: serverul dvs. poate fi compromis dacă nu aveți suficiente permisiuni pentru a vă accesa serverul. O privire mai aprofundată a jurnalelor de erori vă va ajuta să înțelegeți de unde provine problema. Dacă este o problemă cu serverul, asigurați-vă că aveți suficiente drepturi pentru a vă accesa serverul. Contactați furnizorul dvs. de găzduire pentru a vă mări limita de memorie dacă vă confruntați cu o problemă de lipsă de spațiu. Dacă acest lucru nu ajută, ridicați un bilet cu ei menționând problema dvs. de server.
2. Cod personalizat: dacă site-ul dvs. web Drupal 6/7 a fost mai complex decât era de așteptat, sunt șanse ca în loc să evaluați codul personalizat și să le mapați corect înainte de migrare, să se efectueze o schimbare simplă și o schimbare. Dacă aveți condiții personalizate care se declanșează atunci când pagina dvs. se încarcă și nu găsește codul personalizat asociat cu aceasta, veți ajunge cu o pagină ruptă. Primul lucru de făcut este să verificați dacă ați evaluat corect site-ul web în auditul de migrare (dacă ați făcut unul) pentru a verifica dacă există module și coduri personalizate. Dacă problema se datorează unei condiții personalizate și codul lipsește, veți avea nevoie de dezvoltatorul Drupal pentru a crea implementarea codului personalizat. În mod ideal, codul personalizat ar fi trebuit creat înainte ca orice conținut să fie migrat.
3. Modulul Core/Contrib: Uneori puteți întâlni o problemă cunoscută la modulul de bază sau contribuit care are deja o soluție/patch. O mică cercetare poate ajuta la identificarea acestui lucru. Găsiți și aplicați plasturele și ar trebui să fiți gata.
4. Versiune/biblioteci PHP depășite: noul dvs. site Drupal ar putea încă rula o versiune mai veche de PHP sau biblioteci de care depinde codul dvs. Asigurați-vă că site-ul dvs. implementează cea mai recentă versiune de PHP și alte biblioteci. De asemenea, verificați dacă toate cerințele și configurațiile de sistem sunt îndeplinite.

Nu se pot edita paginile (probleme de permisiuni)

1. Eroare 500: Dacă nu reușiți să editați pagini deoarece vă confruntați cu o eroare 500 Internal Server, aceasta poate fi din diverse motive (configurare greșită, cod greșit, indexare greșită, agregare etc.). Cu toate acestea, unul dintre cele mai frecvente motive este că s-ar putea datora unei nepotriviri între formatele câmpurilor sau a câmpurilor lipsă. De exemplu, dacă câmpul dvs. de dată de pe site-ul dvs. Drupal 7 nu este migrat în formatul corect sau valoarea nu a fost transformată în formatul Drupal 9, va genera o eroare. Un alt exemplu este dacă în Drupal 7 ați folosit câmpul Imagini, dar, în Drupal 9, utilizați un câmp media. Cel mai bun mod de a remedia acest lucru este de a rectifica scriptul de migrare pentru a stoca corect datele. Dacă există doar câteva câmpuri de editat, puteți crea și o actualizare a cârligului.
2. Eroare 403: De multe ori, eroarea 403 se datorează transferului incorect al permisiunilor. Verificați dacă permisiunile sunt configurate corect. Dacă utilizați un modul pentru a vă gestiona utilizatorii, verificați dacă acesta este disponibil în Drupal 9. Uneori, este posibil să aveți cârlige sau abonați la evenimente care restricționează accesul unor utilizatori. Verificați aceste condiții și asigurați-vă că sunt implementate și în noua instalație.
3. Pagina de permisiuni nu răspunde: site-ul dvs. Drupal ar putea implementa un cod personalizat pentru a gestiona permisiunile. Dacă acest cod nu este implementat în noul site Drupal 9, este posibil să nu puteți vedea sau edita (sau ambele) pagina de permisiuni. Ocazional, vedem situații în care utilizatorii au fost migrați în bloc fără a migra în mod corespunzător rolurile și profilurile de utilizator. Ca practică standard, înainte de a migra permisiunile, dezvoltatorul ar trebui să creeze permisiuni personalizate și să le atribuie unor roluri de la persoane/permisiuni.

Performanță mizerabilă a site-ului

1. Module inutile: modulele sunt elementele de bază ale site-ului dvs. Drupal, așa că veți dori să le migrați și pe acestea. Dar uneori vedem module Drupal 7 învechite și inutile mutate în Drupal 9, ceea ce poate cauza tot felul de probleme. Mai ales că îți pot greși site-ul. Iată câteva motive pentru care unele dintre modulele dvs. nu trebuie să fie migrate:
   • Modulul (sau funcționalitatea acestuia) s-a mutat deja în Drupal Core. De exemplu, modulul media contribuit a fost mutat în core în Drupal 8.5, ceea ce elimină necesitatea de a utiliza modulul contribuit.
   • Funcționalitatea sa este simplă și poate fi introdusă într-un alt modul personalizat. De exemplu, dacă un modul node::postSave este folosit doar pentru unul sau două tipuri de conținut pentru a alege unde ar trebui să meargă utilizatorul odată ce nodul este creat, ar putea fi posibil să mutați codul într-un modul personalizat.
   • Cerințele pentru modul trebuie reevaluate. Uneori, o mică modificare a gradului de utilizare poate îmbunătăți considerabil performanța site-ului. De exemplu, toate site-urile web nu au nevoie cu adevărat de un modul de moderare a conținutului decât dacă echipa de marketing de conținut este mare și distribuită. Caracteristicile de bază ale fluxului de lucru editorial ale Drupal (Ciornă, Publicare) sunt suficient de bune pentru majoritatea cerințelor de afaceri care nu necesită un flux de lucru complex/detaliat.
   • Uneori, submodulele sunt instalate împreună cu modulele, dar sunt rare/niciodată folosite. Astfel de submodule ar trebui îndepărtate.
2. Replicarea aceleiași arhitecturi: deși este mai ușor să ridicați și să mutați și să vă ștergeți mâinile de pe o migrare, aproape niciodată nu este o abordare bună. Mai ales dacă arhitectura mai veche (Drupal 6/7) era dezordonată și mai puțin robustă. O schimbare a logicii/cerințelor de afaceri ar putea necesita, de asemenea, o re-arhitectură completă. Un audit amănunțit al site-ului vă va spune exact ce module trebuie păstrate și ce pot fi eliminate în siguranță.

Integrarea terților nu mai funcționează

1. Versiune API învechită: dacă site-ul dvs. este conectat la diferite instrumente terțe, cum ar fi Salesforce, Marketo, Mailchimp etc., o migrare executată incorect poate afecta modul în care funcționează aceste integrări. Adesea, API-ul pe care îl solicitați în modulul de integrare Drupal este o versiune mai veche. Singura soluție este că integrarea ar trebui să fie scrisă în cea mai recentă versiune a API-ului terță parte.
2. Probleme cu modulul de integrare: va trebui să verificați dacă API-urile terță parte sunt apelate corect în modulul de integrare. Parametrii sunt trecuți corespunzător? Verificați cum sunt setate și preluate. Verificați coada de probleme pentru modulul de integrare respectiv. Ar putea exista un patch disponibil care trebuie aplicat. Trebuie efectuate testarea adecvată pentru a se asigura că API-ul a fost portat corect pe Drupal 9.

Alte probleme comune și remedieri

1. Instalarea modulelor: utilizați întotdeauna compozitorul pentru a instala module. Acest lucru va evita erorile din cauza dependențelor invalide/indisponibile.
2. Nepotrivirea sursei de migrare: indiferent care este sursa dvs. de migrare (CSV, Bază de date, JSON, XML), asigurați-vă că câmpurile sursă se potrivesc cu câmpurile destinație. Dacă utilizați CSV ca sursă, țineți cont de ordinea de import - prioritatea contează pentru maparea tipurilor de conținut.
3. Căile imaginilor: de multe ori, utilizatorii adaugă imagini direct în conținutul CKEditor. Aceste imagini nu merg întotdeauna la calea desemnată atunci când sunt migrate, deoarece locația lor este de obicei diferită de locul în care se află celelalte fișiere media. O migrare planificată meticulos ar trebui să se ocupe de această problemă.
4. SEO: O migrare neglijentă Drupal 7 la 9 poate afecta SEO site-ului dvs. în multe feluri. Una dintre cele mai importante probleme este legaturile rupte. Asigurați-vă că structura URL existentă și navigarea sunt păstrate, deoarece orice modificare poate duce la o mulțime de link-uri întrerupte. Trebuie efectuat un audit SEO complet pentru a vă asigura că nu există denivelări pe drum.
5. Stilul Drupal 7: Adesea, problemele de migrare de la Drupal 7 la Drupal 9 (în special probleme de performanță) apar deoarece dezvoltatorii folosesc același stil de codare ca Drupal 7 în loc să se adapteze la schimbările aduse de Drupal 8. Exemple, (a) modul în care ucideți memoria cache a paginii este foarte diferită în Drupal 8. (b) Drupal 8 are un management al configurației încorporat, dar adesea nu este implementat corect sau întreținut bine în fiecare mediu. (c) Am întâlnit, de asemenea, cazuri în care proiectul Drupal 8 încă implementează stilul de cod procedural.