Vor supraviețui extensiile tale Magento mutării la Hyvä?

Întreabă orice comerciant ce îl îngrijorează la mutarea spre Hyvä și rareori e tema. Sunt cele douăzeci, patruzeci, uneori optzeci de extensii pe care rulează magazinul. Vestea bună: cele mai multe sunt în regulă. Munca stă în a ști care nu sunt, înainte să începi, nu după.

Hyvä publică un tracker public exact pentru această întrebare și are acum puțin sub o mie de intrări. Cifra e liniștitoare și înșelătoare în același timp. Iată cum se citește corect și cum îți faci auditul propriu înainte să îți dea cineva un preț.

Ce se schimbă de fapt și ce nu

Hyvä înlocuiește stratul de afișare și nimic altceva. Knockout.js dispare, înlocuit de Alpine.js. RequireJS dispare, deci nu mai există niciun încărcător de module la care să înregistrezi ceva. jQuery și biblioteca lui de widget-uri dispar. LESS e înlocuit de Tailwind. Tot ce e sub linia asta rămâne neatins.

Așadar injecția de dependențe a unei extensii, plugin-urile și observerii ei, modelele de resurse, job-urile cron, comenzile de consolă, ecranele de admin și endpoint-urile REST sau GraphQL funcționează exact ca înainte. Conectorul tău de ERP nu se sinchisește cum arată tema. Nici motorul de taxe, nici instrumentul de import, nici tracking-ul server-side.

Se strică ce afișează ceva în magazin. Documentația Hyvä o spune direct: modulele construite pe temele Luma sau Blank au nevoie de un modul de compatibilitate ca să meargă pe Hyvä. În practică, aceste module se trădează prin patru semne:

• șabloane sub view/frontend care poartă atribute Knockout data-bind sau blocuri x-magento-init,
• un fișier requirejs-config.js,
• JavaScript de frontend scris ca modul RequireJS sau widget jQuery,
• fișiere LESS sub view/frontend/web/css/source.

Consecința utilă e că un modul de compatibilitate rescrie doar stratul de afișare. Codul PHP al extensiei originale e refolosit ca atare. De aceea munca e delimitată și se poate estima, în loc să fie deschisă la nesfârșit, iar furnizorii care au făcut-o descriu majoritatea codului ca fiind copiat, nu rescris.

Cinci variante, nu trei

Fiecare extensie din magazinul tău ajunge într-unul din cinci locuri.

• Are deja suport nativ pentru Hyvä. Furnizorul livrează suportul chiar în extensie, deci actualizezi și mergi mai departe. Amasty lucrează așa pe tot catalogul. La fel Smile Elasticsuite, modulele Dotdigital și Snowdog Menu.
• Există un modul de compatibilitate Hyvä gratuit. Aproximativ trei sute treizeci de intrări din tracker sunt aici. Algolia e cea mai cerută de pe tot trackerul. Magefan Blog, Yotpo, Nosto, Klaviyo, Ebizmarts MailChimp și majoritatea cataloagelor Aheadworks și MageWorx sunt tot în grupul ăsta.
• Furnizorul distribuie propriul adaptor. Uneori din propriul repository Composer, nu din al Hyvä. Mirasvit a mutat mai multe în pachete proprii. Aheadworks livrează acum unele module de compatibilitate doar prin repository-ul lor, ceea ce înseamnă abonament activ. Mollie, Tweakwise și SeQura publică pe cont propriu.
• Nu există nimic și trebuie reconstruită sau înlocuită. Aici ajung mereu modulele făcute la comandă pe care o agenție anterioară le-a pus în app/code, pentru că ele nu vor apărea niciodată pe niciun tracker.
• O lași pe Luma. Hyvä livrează un modul de fallback care păstrează rutele nominalizate pe tema veche. Revenim mai jos, pentru că e și portiță de scăpare, și capcană.

Auditul înseamnă pur și simplu să numeri câte dintre ale tale sunt în ultimele două categorii. Numărul acela e adevăratul scop al proiectului. Oricine îți dă un preț pentru Hyvä fără să facă asta ghicește.

Ce nu îți spune trackerul

Trackerul e public, rulează din 2021 și e punctul de plecare corect. Caută după numele furnizorului și citește conținutul tichetului, nu doar eticheta. Trei lucruri pe care nu ți le spune contează mai mult decât statusul:

Publicat nu înseamnă complet. Fiecare tichet are o listă de funcții care arată ce părți din extensie au fost efectiv portate. Intrarea pentru Klaviyo bifează două lucruri: layout-ul nu se strică și informațiile despre client ajung în Klaviyo. Restul e nebifat. O portare completă și una parțială arată identic din exterior dacă te uiți doar la etichetă.

Un modul de compatibilitate poate exista și totuși să fie răspunsul greșit. Exact o intrare din tracker poartă o etichetă de avertizare pentru performanță, și e un page builder folosit pe scară largă. Cineva a făcut munca, rezultatul e lent, iar trackerul o spune dacă citești dincolo de status.

Suportul furnizorului e legat de versiune. Intrările Amasty poartă un avertisment propriu care îți spune că informația poate fi valabilă doar pentru anumite versiuni de modul și să verifici direct cu ei. Dacă magazinul tău e fixat pe versiuni din 2023, o intrare verde nu e undă verde pentru tine. Aproximativ o sută de intrări nu au nicio etichetă. Acelea sunt cereri pe care nu le-a preluat nimeni.

Pornește de aici: trackerul de module de compatibilitate Hyvä. Mai există unul separat pentru checkout, și acolo se greșește cel mai des la estimare.

Checkout-ul e un proiect separat

Cea mai frecventă greșeală e să tratezi checkout-ul ca parte din migrarea temei. Nu este.

Extensiile terțe de one-page checkout nu se portează. Sunt rescrieri în Knockout ale checkout-ului Magento, iar Hyvä Checkout e un checkout complet diferit, vândut cu licență comercială proprie, la o mie de euro per instalare Magento. Variantele realiste sunt să ții checkout-ul Luma sub fallback de temă, să treci la Hyvä Checkout, sau să folosești checkout-ul React gratuit și open source de la proiectul Friends of Hyvä.

Metodele de plată sunt cea mai clară formă a separării dintre frontend și backend. Integrarea cu procesatorul e server-side și trece migrarea neatinsă. Formularul de plată, iframe-ul găzduit, gestionarea redirectului: acelea sunt frontend și trebuie reintegrate pentru checkout-ul pe care îl alegi. Hyvä ține un al doilea tracker numai pentru asta, cu peste patru sute de intrări, și acoperă și livrarea și completarea automată a adresei. Selectoarele de puncte de ridicare ale curierilor și validarea adresei sunt cod de frontend din checkout și au nevoie exact de același tratament.

FAQ-ul Hyvä listează checkout-urile Luma confirmate că merg sub fallback, printre care OneStepCheckout, Amasty Checkout, Clean Checkout și Mageplaza One Step Checkout. Ei spun explicit că e o soluție de tranziție și că un checkout Luma într-un magazin Hyvä are nevoie de muncă suplimentară de stilizare ca să nu arate ca un alt site.

Portița de scăpare despre care nu vorbește nimeni

Hyvä publică un modul de fallback de temă și e răspunsul onest pentru coada lungă. Îl instalezi, îl activezi și nominalizezi rutele care rămân pe Luma. Un configurator vechi și greu. O pagină de cont vizitată rar. Un checkout pe care nu ești gata să îl reconstruiești.

Compromisul e documentat chiar de Hyvä. Pe o rută de fallback, tema Hyvä nu e activă deloc. Nu se încarcă nici Tailwind, nici Alpine. Se încarcă RequireJS și tot lanțul de dependențe Luma, iar stilizarea acelor pagini trebuie făcută în modul vechi, Magento. Deci pagina funcționează, pierzi câștigul de viteză pe ruta aceea și acum întreții două frontend-uri.

Folosit deliberat pe trei rute, e inginerie bună. Folosit ca să eviți auditul, așa ajungi cu un magazin Hyvä care nu e rapid.

Cum îți faci auditul într-o după-amiază

E muncă mecanică și poți face cea mai mare parte singur, înainte să vorbești cu cineva.

1. Ia lista reală de module

Rulează bin/magento module:status. Folosește asta, nu composer show, pentru că include modulele puse direct în app/code, despre care Composer nu știe nimic, și exact acelea nu au intrare în tracker și nici furnizor pe care să îl întrebi.

2. Vezi care dintre ele ating magazinul

Trei căutări rezolvă aproape tot. Caută directoare care se potrivesc cu view/frontend. Caută orice requirejs-config.js pe o cale de frontend. Numără fișierele .phtml din view/frontend/templates pentru fiecare modul. Un modul cu director de frontend, fără șabloane, fără JavaScript și doar cu fișiere de email tranzacțional e aproape sigur în regulă. Un modul cu requirejs-config.js și patruzeci de șabloane e un proiect.

3. Caută API-urile care nu mai există

Caută în fișierele .phtml după data-bind, x-magento-init și data-mage-init. Caută în JavaScript după ko.observable, uiComponent și înregistrări de widget-uri jQuery. Fiecare rezultat e cod din stratul de afișare care trebuie rescris în Alpine.

4. Verifică ce ai deja

Rulează composer show și filtrează după hyva. Citește app/etc/hyva-themes.json, care listează modulele de compatibilitate înregistrate în build-ul Tailwind. Pe un magazin unde s-a mai încercat o migrare parțială la Hyvä, aici e deseori mai mult decât se așteaptă lumea.

5. Compară, apoi pune preț

Verifică tot ce a rămas în ambele trackere și pe site-ul furnizorului, pentru că datele din tracker sunt legate de versiune. Există și un instrument de comunitate, hyva-compatibility-checker, care parcurge un root de Magento și scrie rapoarte JSON și CSV cu fiecare modul și numărul de fișiere și linii de JavaScript, șabloane și layout XML. Nu e un produs Hyvä, deci tratează rezultatul ca pe o estimare. Dar numărul de linii per modul e o măsură directă a efortului, și exact asta transformă anxietatea migrării într-un tabel căruia cineva chiar îi poate pune preț.

Mai puține extensii e deseori chiar scopul

O migrare e cel mai bun moment să nu mai plătești pentru balast. La Vitacom am eliminat în jur de 180 de module care sufocau backend-ul, iar magazinul a devenit mai rapid și mai ieftin de întreținut, nu mai sărac în funcții. PageSpeed a urcat de la 12 la 100, răspunsul serverului a coborât de la 15.814ms la 12ms, iar hardware-ul de la 64 de nuclee și 256GB RAM la 8 nuclee și 32GB. De opt ori mai puțină infrastructură. Citește studiul de caz Vitacom.

Deci înainte să reconstruiești o extensie de frontend pentru Hyvä, prima întrebare onestă e dacă magazinul chiar are nevoie de ea. Încă două merită puse în aceeași trecere. Face extensia asta ceva ce Magento face acum nativ? Și e instalată, dar oprită, lucru frecvent pe magazinele care au schimbat agenția de câteva ori?

Fiecare extensie la care renunți e una pe care nu o portezi, nu o testezi, nu o licențiezi și nu o actualizezi. Economia asta se adună an de an și e partea din migrare pe care nu o trece nimeni în ofertă.

Dacă vrei întâi imaginea de ansamblu, am scris separat despre ce implică de fapt o migrare la Hyvä, inclusiv termene și ce tinde să se strice.

Programează un apel gratuit de strategie

Trimite-ne lista de extensii și îți spunem care supraviețuiesc mutării, care au nevoie de un modul de compatibilitate, care merită scoase și care vor trebui reconstruite. Programează un apel gratuit de strategie și o transformăm într-un scop clar înainte să te angajezi la ceva.