Magento · 14 august 2026 · 10 min citire
Fiecare modul instalat în Magento e o datorie pe care o plătești la upgrade
Un modul costă o sută de euro azi și te ține în loc peste doi ani. Cum alegi, ce întrebi înainte de cumpărare și ce faci cu cele pe care le ai deja.
Ecosistemul de module e principalul motiv pentru care Magento e ales în locul unei platforme închise. E și principalul motiv pentru care magazinele Magento rămân blocate pe versiuni vechi.
Amândouă sunt adevărate în același timp, iar diferența dintre ele o face felul în care alegi.
De ce un modul e o datorie, nu o achiziție
Când cumperi un modul, plătești o dată. Dar te angajezi la ceva pe termen lung: la fiecare actualizare de Magento, cineva trebuie să verifice că încă funcționează. Dacă furnizorul nu a scos versiune compatibilă, ai trei variante, toate cu cost.
- Aștepți — și amâni upgrade-ul, deci și patch-urile de securitate.
- Plătești pe cineva să îl porteze — de obicei mai mult decât a costat modulul.
- Renunți la funcționalitate — și explici echipei de ce nu mai merge ceva cu care se obișnuise.
Într-un upgrade, blocajul nu e aproape niciodată Magento. Sunt cele trei module fără versiune nouă.
Șapte întrebări înainte să cumperi
| Întrebare | Semnal bun |
|---|---|
| Când a fost ultima actualizare? | În ultimele șase luni. Peste un an, tratează-l ca abandonat. |
| A scos versiune pentru ultimul Magento? | Da, în câteva săptămâni de la lansare. |
| Are variantă compatibilă cu Hyvä? | Da, sau cel puțin e anunțată. Altfel te blochează la migrare. |
| Câte alte module cere ca dependență? | Cât mai puține. Fiecare aduce propria datorie. |
| Modifică tabele din baza de date? | Dacă da, dezinstalarea devine dificilă. Întreabă cum se face. |
| Ce se întâmplă dacă îl dezactivez? | Magazinul funcționează, doar fără acea funcție. |
| Există cod public de citit? | Da. Codul obfuscat sau criptat e motiv suficient de refuz. |
Regula pe care o aplicăm noi
Înainte de a instala orice, o singură întrebare: ce se întâmplă dacă nu îl punem? Dacă răspunsul e „ar fi frumos”, nu se pune. Un modul se justifică doar când rezolvă o problemă care costă bani măsurabili.
A doua regulă: preferăm o funcție construită simplu, în cod propriu, unui modul care aduce cincizeci de funcții din care folosim una. Codul propriu îl întreținem noi și se rupe previzibil. Modulul se rupe când decide altcineva.
Ce faci cu ce ai deja
Aproape orice magazin cu câțiva ani vechime are module pe care nu le mai folosește nimeni. Sunt cost pur: încetinesc, măresc suprafața de atac și blochează upgrade-uri.
- Fă inventarul. Lista completă, cu versiunea și data ultimei actualizări a furnizorului.
- Marchează ce nu se mai folosește. Întreabă echipa, nu presupune. Vei fi surprins câte sunt.
- Dezactivează pe un mediu de test, nu în producție. Vezi ce se rupe.
- Elimină definitiv ce a trecut testul, inclusiv tabelele rămase.
- Pentru ce rămâne, notează starea: întreținut, abandonat, de înlocuit. Lista asta e planul tău de upgrade.
Pașii ăștia sunt exact ce facem în analiza de cod, și e de obicei prima dată când proprietarul vede ce are, de fapt, în magazin.
Legătura cu viteza
Fiecare modul care atinge frontend-ul își adaugă propriul JavaScript și CSS. Zece module înseamnă zece bagaje, încărcate pe fiecare pagină, indiferent dacă sunt folosite acolo.
De asta magazinele cu multe extensii câștigă cel mai mult la trecerea pe Hyvä: nu doar că se elimină stiva veche, dar migrarea forțează inventarul de module — și de obicei jumătate nu supraviețuiesc, pentru că nimeni nu găsește un motiv să le păstreze.