Una dintre bucuriile reale ale lucrului cu Drupal e ecosistemul de module contrib. Zeci de mii de module, construite și puse la dispoziție de o comunitate globală, care acoperă aproape orice funcționalitate de care ar putea avea nevoie un site. Orice ai încerca să faci, sunt șanse mari ca cineva să o fi făcut deja, să o fi împachetat și să o fi publicat pentru toată lumea. E unul dintre cele mai puternice argumente pentru platformă.
Dar abundența vine la pachet cu o altă treabă: trebuie să alegi. Pentru multe nevoi obișnuite există mai multe module candidate, plus varianta de a scrie mai degrabă puțin cod propriu. Iar alegerea contează mai mult decât pare pe moment, pentru că un modul adăugat pe un site nu e o comoditate pe care o folosești o dată și gata. E o dependență pe care site-ul o va purta ani de zile, prin fiecare ciclu de actualizare, fiecare actualizare de securitate și fiecare migrare de versiune majoră care urmează.
Așa că orice modul, înainte să ajungă pe site-ul unui client, trece prin aceeași evaluare. Niciunul dintre pași nu e secret sau complicat. Publicăm lista pentru că e utilă oricui construiește cu Drupal, și pentru că clienții merită să știe că între ecosistem și site-ul lor există filtrul ăsta.
Începe cu angajamentul, nu cu funcționalitatea
Schimbarea de perspectivă de care depinde tot restul: când evaluăm un modul, funcționalitatea e jumătatea mai mică a întrebării. Demo-ul poate fi perfect și modulul poate fi totuși alegerea greșită. Ceea ce evaluăm de fapt e o relație pe termen lung. Va fi întreținut codul ăsta în toți anii cât va trăi site-ul? Va trece curat la următoarea versiune majoră de Drupal când îi vine vremea? Problemele lui de securitate vor fi găsite și reparate? Un modul e ușor de adăugat și mult mai greu de scos odată ce conținutul, configurația și fluxurile de lucru cresc în jurul lui, așa că momentul în care îl adaugi e momentul în care ai cea mai mare putere de decizie. Acolo trebuie să fii atent.
E acoperit de echipa de securitate?
Prima verificare concretă e dacă modulul intră în programul de avertizări al echipei de securitate Drupal. Drupal are aici ceva cu adevărat valoros: un program coordonat în care vulnerabilitățile din proiectele acoperite sunt raportate privat, reparate și anunțate printr-o avertizare, astfel încât site-urile să se poată actualiza înainte ca detaliile să circule. Versiunile stabile ale modulelor acoperite beneficiază de această protecție; modulele din afara programului, sau versiunile marcate ca fiind de dezvoltare, nu.
Pentru un site pe care îl avem în grijă, acoperirea asta aproape că nu se negociază. Întreaga noastră rutină de actualizări de securitate e construită pe ritmul acestor avertizări, iar un modul din afara lui e un punct orb în ea. Când un modul care altfel ne place nu e acoperit, e un semn clar să ne uităm la alternative, să așteptăm o versiune stabilă acoperită sau să rezolvăm nevoia altfel.
Activitatea de întreținere și ritmul lansărilor
Apoi ne uităm la proiect ca la un organism viu. Când a fost ultima lansare, și cea de dinaintea ei? Primesc problemele raportate vreun răspuns de la cineva care întreține modulul, fie el și scurt? După lansările recente de Drupal core, au venit actualizări de compatibilitate într-un timp rezonabil? Nu căutăm activitate constantă; un modul mic și stabil poate, pe bună dreptate, să aibă nevoie doar de atenție din când în când. Ce vrem să aflăm, de fapt, e dacă e cineva acasă.
Coada de probleme e adesea mai grăitoare decât istoricul lansărilor. O coadă în care raportările sunt triate și primesc răspuns îți spune că cineva se ocupă de proiect, chiar dacă lansările sunt rare. O coadă în care bug-uri simple stau mult timp fără niciun răspuns de la un om îți spune că, atunci când site-ul tău dă de o problemă, cel mai probabil vei fi pe cont propriu. Niciuna dintre situații nu e o judecată morală la adresa voluntarilor care întrețin modulele și care nu datorează nimănui nimic. E pur și simplu o informație despre ce poate aștepta site-ul de la dependența asta în anii care urmează.
Drumul către următoarea versiune majoră
Drupal trece prin versiuni majore după un calendar public, iar fiecare site pe care îl construim azi va trece prin cel puțin un astfel de prag de-a lungul vieții lui. Așa că pentru fiecare modul candidat întrebăm: e pregătit pentru următoarea versiune majoră sau măcar se vede că e pe drum? Există o ramură publicată sau un plan declarat? Dacă modulul rămâne în urmă, cât de adânc e înfipt în arhitectura site-ului?
Ultima întrebare merită subliniată. Un modul rămas în urmă la marginea unui site, care ține un singur element pe o singură pagină, e un risc izolat: îl înlocuiești sau renunți la el când vine momentul. Un modul rămas în urmă care definește modelul de conținut sau stă sub zeci de pagini e cu totul altceva, pentru că viitorul upgrade de versiune majoră îl moștenește ca dependență blocantă. Punem în balanță pregătirea și adâncimea: cu cât rolul e mai central, cu atât planul de upgrade trebuie să fie mai solid înainte să construim pe el.
Câte site-uri stau în spatele lui
Drupal publică statistici de utilizare pentru proiectele contrib, iar noi ne uităm întotdeauna la ele. Adopția largă nu e o dovadă de calitate, dar schimbă profilul de risc, iar efectele se adună. Unui modul care rulează pe mii de site-uri i-a descoperit deja altcineva cazurile-limită. Problemele lui sunt raportate repede, reparațiile primesc atenție, iar dacă cel care îl întreținea inițial se retrage, șansele ca proiectul să fie preluat de comunitate sunt mult mai bune, pentru că foarte multe site-uri au interesul ca el să supraviețuiască.
Un modul de nișă poate fi totuși alegerea potrivită când răspunde exact nevoii și codul e solid. Doar că punem cinstit diferența în calcul: dacă îl alegi, îți asumi o parte mai mare din responsabilitatea pentru viitorul lui, iar asumarea asta ar trebui să fie o decizie, nu un accident.
Întrebarea cu drept de veto: chiar avem nevoie de el?
Ultima verificare merge în direcția opusă. După ce am stabilit că un modul e bine întreținut, acoperit, pregătit de upgrade și folosit pe scară largă, ne întrebăm dacă site-ul chiar are nevoie de tot ce aduce modulul cu el. Modulele contrib sunt construite ca să servească mii de site-uri diferite, ceea ce înseamnă că vin cu ecrane de configurare, opțiuni și căi de cod pentru situații pe care site-ul tău nu le va întâlni niciodată. Toate se actualizează, toate cer atenție și toate vin după tine la fiecare upgrade viitor.
Uneori răspunsul sincer e că ai nevoie de un comportament mic și bine înțeles, iar o implementare proprie, concentrată, care urmează propriile API-uri Drupal, e angajamentul mai ușor: mai puțină suprafață de întreținut, nimic nefolosit și cod scris după aceleași standarde ca restul proiectului. Alteori e exact invers: ce pare o nevoie simplă ascunde subtilități pe care un modul matur le-a învățat în ani de zile și pe care nicio implementare nouă n-ar trebui să le reînvețe pe banii unui client. Nu există o regulă universală. Există doar disciplina de a pune întrebarea de fiecare dată, gândindu-ne la anii de întreținere, nu la săptămâna de dezvoltare.
Ce câștigi cu lista de verificări
Treci fiecare candidat prin aceste verificări și efectul se adună: întreaga listă de dependențe a site-ului rămâne sănătoasă, nu prin campanii de curățenie, ci prin filtrul de la ușă. Actualizările rămân o rutină pentru că tot ce e pe site participă la același ritm de securitate și de lansări. Upgrade-urile de versiune majoră vin ca muncă planificată, nu ca săpături arheologice. Iar editorii simt rezultatul fără să știe de ce: mai puține ciudățenii, mai puține regresii, un site care se comportă anul acesta la fel ca anul trecut.
Verificările durează o oră sau două per modul. Dependența pe care o evaluează va trăi cu site-ul ani de zile. Credem că e unul dintre cele mai bune raporturi efort-rezultat din meseria asta, și nu costă nimic în afară de obiceiul de a întreba înainte să instalezi.