De la reparație Elementor la Astro: reconstrucția NovaPera pe un stack modern

Despre proiect
Proiect în două etape: salvarea unui build Elementor spart, apoi migrarea NovaPera pe Astro și EmDash CMS — design system și flux de conținut pregătit pentru AI.
Tehnologii
Client: NovaPera
Industrie: Sănătate mintală, educație și personal branding
Servicii: Migrare de platformă, arhitectură frontend, design system, UI/UX design, flux de conținut asistat de AI, SEO
Proiectul s-a desfășurat în două etape distincte. A început ca o operațiune de salvare: un site WordPress construit în Elementor, cu layout-uri care se rupeau la schimbarea rezoluției și un styling fără reguli comune. Am făcut audit de interfață, am reconstruit containerele stricate și am standardizat layout-ul până când s-a afișat corect pe orice dispozitiv.
Acea intervenție a adus stabilitate — dar a scos la iveală și problema reală: platforma în sine era plafonul. Așa că etapa a doua a fost o migrare completă. NovaPera a fost reconstruit de la zero pe Astro cu EmDash CMS, pe infrastructura serverless Cloudflare, împreună cu un design system nou, care transformă consistența dintr-o disciplină manuală într-o proprietate a codului.
Clientul și contextul
NovaPera reprezintă brandul profesional al unui psihoterapeut, autor și formator recunoscut la nivel național. În sănătate mintală și educație, încrederea și autoritatea sunt totul — prezența digitală trebuie să susțină același standard ca munca din spatele ei.
Obiectivul nu a fost niciodată „un site care funcționează", ci o platformă credibilă, care se încarcă instant pentru un public numeros și care poate fi actualizată fără teamă.
Etapa întâi: salvarea build-ului Elementor
Am preluat un site WordPress construit în Elementor care ceda în moduri vizibile pentru vizitatori:
- Layout-uri rupte: Structura paginilor își pierdea alinierea și se prăbușea complet la anumite rezoluții.
- Probleme de responsivitate: Pe tabletă și mobil conținutul se suprapunea, textul devenea ilizibil, iar navigarea frustrantă.
- Styling inconsistent: Fără reguli globale de design, spațierea și tipografia variau de la pagină la pagină, iar ierarhia vizuală se destrăma.
Intervenția a fost una chirurgicală:
- Restructurarea Elementor: Am refăcut containerele și secțiunile problematice care generau punctele de rupere, curățând în paralel structura DOM.
- Spațiere și tipografie de precizie: Spațierea globală și locală corectată manual, tipografia standardizată după ghidul de brand.
- CSS custom: Acolo unde controalele native Elementor nu ajungeau la acuratețe pixel-perfect, am scris CSS care forța comportamentul corect.
- Creație vizuală: Am proiectat și integrat imagini custom, adaptate contextului specific al conținutului clientului.
- Recuperarea responsivității: Breakpoint-uri și logică de scalare redefinite, fără suprapuneri, cu elemente care se adaptează fluid oricărui viewport.
Rezultatul: un site care se afișa corect peste tot și care arăta ca brandul pe care îl reprezenta. Funcționa. Doar că nu putea deveni mai bun de atât.
De ce reparația nu era finalul
O reparație rezolvă simptome. Nu schimbă ce le produce.
Limitarea nu a fost niciodată PHP ca limbaj — PHP-ul modern e rapid și perfect capabil. Limitarea era modelul: un page builder care stochează prezentarea sub formă de markup adânc imbricat, o stivă de temă și pluginuri în care fiecare cerere a unui vizitator declanșează interogări în baza de date și randare pe server, și un strat de styling în care „consistent" depinde de cineva care își amintește să seteze din nou aceeași valoare.
Modelul acesta are trei consecințe practice:
- Greutate care se acumulează: Fiecare widget de builder adaugă markup, CSS și JavaScript trimise vizitatorului indiferent dacă pagina le folosește sau nu.
- Consistență fragilă: Deciziile de design trăiesc în setările fiecărui widget, nu într-o sursă unică de adevăr. Nimic nu împiedică următoarea editare să strice sistemul.
- Suprafață de mentenanță: Pluginuri, teme și update-uri de core aduc fiecare risc de compatibilitate și de securitate — și fiecare update e o ocazie ca un layout să se rupă din nou.
Pentru un brand a cărui credibilitate este produsul, „stabil deocamdată" nu era o poziție suficient de bună.
Etapa a doua: migrarea pe Astro și EmDash CMS
Reconstrucția a țintit un stack în care performanța și consistența sunt structurale, nu întreținute manual.
- Astro: Randează paginile ca HTML static în mod implicit și nu trimite JavaScript decât acolo unde o componentă are nevoie. Interactivitatea se activează pe insule, nu se plătește global. Pentru un site centrat pe conținut — articole, cursuri, pagini de prezentare — potrivirea e aproape ideală: vizitatorul descarcă un document, nu o aplicație.
- EmDash CMS: Un CMS open-source full-stack construit pe Astro și Cloudflare, cu panou de administrare familiar, bibliotecă media, autentificare și un model de conținut definit din interfață. Îi oferă clientului experiența de editare cu care era deja obișnuit, fără a moșteni runtime-ul WordPress.
- Cloudflare: Asigură runtime-ul — Workers pentru execuție la edge, D1 pentru baza de date de conținut, R2 pentru media. Paginile sunt servite din locații apropiate de vizitator, nu de pe un singur server de origine.
Migrarea, în practică
- Întâi modelul de conținut: Înainte să mut o singură pagină, am mapat conținutul existent în colecții tipate — pagini, articole și tipurile de conținut asociate — astfel încât structura să vină dintr-o schemă, nu din ce a produs întâmplător un builder.
- Reconstrucție, nu export: Markup-ul Elementor nu a fost convertit, ci înlocuit. Fiecare template a fost rescris ca și componente Astro curate și semantice.
- Migrarea media: Fișierele au fost mutate în R2, re-encodate în formate moderne și servite prin imagini responsive.
- Păstrarea URL-urilor: Adresele existente au fost păstrate, cu redirect 301 acolo unde o cale trebuia schimbată, ca să nu se piardă valoarea SEO acumulată.
- Integrări reconectate: Formularele, tracking-ul și integrările terțe au fost reconectate la noul stack și verificate cap-coadă înainte de cutover.
- Cutover controlat: Reconstrucția a fost validată pe un domeniu de staging, apoi comutată prin DNS, cu vechiul install păstrat ca plan de rollback.
Design system-ul
Migrarea a fost și momentul potrivit să tratăm consistența nu ca pe un obicei, ci ca pe infrastructură.
- Design tokens: Culorile, tipografia, spațierea, colțurile rotunjite, umbrele și breakpoint-urile sunt definite o singură dată ca tokens și consumate peste tot. Schimbarea unei valori de brand înseamnă acum o editare, nu o căutare prin toate paginile.
- O scară tipografică reală: Titlurile, textul de conținut și textul secundar respectă o ierarhie definită, cu line-height și lungime de rând calibrate pentru citit lung — esențial pe un site construit în jurul articolelor și al conținutului educațional.
- Un sistem de spațiere: Ritmul vertical urmează o scară fixă, deci secțiunile se raportează previzibil una la alta, în loc să fie ajustate din ochi pe fiecare pagină.
- Bibliotecă de componente: Hero, carduri, layout de articol, CTA-uri și navigație sunt componente reutilizabile, cu variante definite. O pagină nouă se asamblează din piese existente și moștenește automat sistemul.
- Accesibilitate din construcție: Markup semantic, contrast verificat pentru lizibilitate, focus vizibil, navigare de la tastatură și text alternativ relevant pentru imagini.
- Responsiv prin construcție: Layout-urile sunt fluide din start, nu un set de design-uri de desktop peticite la trei breakpoint-uri — exact modul de eșec pe care etapa întâi a trebuit să îl repare.
Odată cu asta a venit și partea de UI/UX: arhitectură de informație mai clară, navigație simplificată, flux de citire mai bine gândit pe paginile de articol și ierarhie vizuală mai puternică în jurul acțiunilor care contează.
Operațiuni de conținut: un stack care lucrează cu AI
Unul dintre cele mai clare câștiguri ale migrării nu se vede într-un screenshot: conținutul este acum mult mai ușor de creat și de modificat cu ajutorul LLM-urilor.
Motivul e structural. În build-ul Elementor, o pagină era, de fapt, date serializate de builder — obiecte de layout adânc imbricate, cu conținutul îngropat în ele. Formatul e practic opac: un model AI nu îl poate citi fiabil și cu siguranță nu îl poate scrie în siguranță. Orice modificare trebuia făcută manual, prin interfața builder-ului.
După migrare, situația s-a schimbat pe trei niveluri:
- Conținutul este date structurate: Intrările stau în colecții tipate, cu câmpuri reale — titlu, corp, metadate — separate de prezentare. Un model poate citi o colecție, poate scrie o intrare nouă sau o poate rescrie pe una existentă, iar rezultatul intră direct în site fără să atingă layout-ul.
- Template-urile sunt cod lizibil: Paginile sunt componente Astro semantice, într-un repository Git. O secțiune nouă sau o pagină întreagă poate fi generată dintr-un prompt cu un agent de cod, revizuită ca diff și anulată dintr-o comandă dacă nu e bună. Nimic din acest flux nu era posibil pe stack-ul vechi.
- Design system-ul e plasa de siguranță: Pentru că spațierea, tipografia și culorile vin din tokens și din componente existente, rezultatul generat de AI moștenește brandul în loc să inventeze unul propriu. Sistemul constrânge modelul — exact lucrul care face viteza sigură.
În practică, asta a redus dramatic costul publicării. Redactarea unui articol, generarea metadatelor și a textelor alternative, construirea unei variante noi de pagină sau restructurarea uneia existente au trecut de la asamblare manuală în builder la o buclă scurtă de revizuire. Clientul obține mai mult conținut, publicat mai repede, fără derapajul vizual care de obicei însoțește viteza.
Rezultate și impact
- Performanța ca proprietate a arhitecturii: Paginile sunt pre-randate ca HTML static, nu trimit JavaScript decât acolo unde o componentă are nevoie și sunt servite de la edge. Viteza nu mai e ceva de recuperat ulterior — nu există stivă de pluginuri, payload de builder sau randare la fiecare cerere din care să te recuperezi.
- Consistență implicită: Deciziile de design stau în tokens și componente, deci paginile noi moștenesc sistemul în loc să îl reimplementeze. Derapajul vizual a încetat să mai fie o sarcină de mentenanță.
- Suprafață de atac și de mentenanță redusă: Fără stivă de pluginuri de actualizat, fără conflicte temă–plugin, fără update de builder care rearanjează pe tăcute un layout.
- Costuri previzibile: Servirea paginilor pre-randate de la edge elimină complet ecuația clasică de hosting și încărcare a serverului.
- Editare fără frică: Clientul editează conținut printr-un panou care se comportă ca cel cu care era obișnuit — dar o editare greșită nu mai poate rupe un layout, pentru că layout-ul nu mai e stocat în conținut.
- Conținut care scalează cu AI: Crearea și actualizarea conținutului sunt acum o buclă scurtă de revizuire asistată, în loc de asamblare manuală, iar design system-ul menține fiecare rezultat în identitatea de brand.
- SEO păstrat și îmbunătățit: URL-urile au fost transferate intact, peste care s-au adăugat încărcare mai rapidă și markup semantic mai curat — iar metadatele sunt acum generate din modelul de conținut, nu întreținute manual, pagină cu pagină.
Concluzie
Cele două etape merită citite împreună. Prima a demonstrat că un build stricat poate fi reparat la un standard cu adevărat înalt. A doua a demonstrat că reparația are un plafon — și că, la un moment dat, recomandarea onestă către client nu mai e „lasă-mă să repar din nou", ci „hai să mutăm proiectul pe ceva ce nu va mai trebui reparat în același fel".