Migrar un bloc des de Wix cap a un generador de llocs estàtics com Astro o Hugo promet senzillesa i control absolut sobre el contingut. No obstant, quan es tracta de portar tutorials tècnics —amb blocs de codi, imatges, vídeos incrustats i fragments de Gist— la realitat és molt diferent. L'HTML que serveix Wix no conté tot allò que l'usuari veu a la pantalla. Una part crítica del contingut s'hidrata mitjançant JavaScript al navegador, i qualsevol script que llegeixi únicament l'HTML del servidor falla en silenci. Aquest article desvetlla aquesta trampa, explica per què una expressió regular mal construïda pot saturar la CPU sense fi, i com una empresa com Q2BSTUDIO aplica metodologies robustes per a migracions sense pèrdua de dades.
Durant anys, molts desenvolupadors i equips de contingut han confiat en eines genèriques de conversió d'HTML a Markdown. Funcionen bé amb pàgines senzilles, però enfrontar-se a l'estructura específica de Wix —llistes imbricades, etiquetes d'èmfasi partides, imatges que en realitat són blocs de figura— el resultat és un Markdown incomplet o directament erroni. El veritable problema no és la conversió, sinó la recuperació del que no hi ha a l'HTML inicial. Wix lliura un esquelet i, mitjançant JavaScript, carrega la resta: reproductors de YouTube, galeries d'imatges, botons estilitzats, comentaris i, sobretot, els fragments de Gist per a codi. Cap eina que operi només sobre l'HTML del servidor pot recuperar-los. Enganyar-se pensant que sí és la forma més ràpida de publicar tutorials amb forats silenciosos.
La solució no passa per utilitzar intel·ligència artificial per 'endevinar' el contingut que falta. Un LLM pot parafrasejar la teva prosa i, pitjor encara, eliminar els blocs de codi sense previ avís, destruint el valor del tutorial. L'enfocament correcte és determinista: extreure l'HTML del servidor real, aïllar el cos de l'article entre els marcadors que Wix utilitza ( i ) i processar-lo amb un tokenitzador d'una sola passada. Això permet conservar l'ordre dels elements i convertir cada tipus d'etiqueta al seu equivalent en Markdown sense perdre informació. El secret està a capturar primer els blocs de codi i les llistes (que contenen caràcters arbitraris) mitjançant placeholders, i després aplicar una expressió regular combinada que recorre tot en ordre.
Però aquí apareix la segona trampa: una expressió regular mal dissenyada pot provocar un bucle infinit que satura la CPU. Si la regex inclou una alternativa buida (per exemple, un | seguit de res), aquesta alternativa coincideix amb la cadena buida a cada posició entre caràcters. Si a més s'utilitza un bucle manual que avança l'índex basant-se en la longitud del match, un match de longitud zero mai avança el punter, i el bucle es queda encallat a la mateixa posició, consumint el 100% d'un nucli de la CPU sense generar error. Aquest error és especialment perillós en articles amb moltes imatges, on hi ha molts forats entre etiquetes <figure> que l'alternativa buida pot aprofitar. A Q2BSTUDIO, quan desenvolupem eines de migració o automatització, sempre auditem les expressions regulars per detectar alternatives buides i fem servir matchAll en lloc de bucles manuals, perquè sabem que els detalls d'implementació marquen la diferència entre una migració exitosa i una pèrdua silenciosa de contingut.
Més enllà de l'enginyeria d'extracció, cal lidiar amb els 'paper cuts' específics de Wix: llistes imbricades que perden la indentació, negretes que envolten espais en blanc i produeixen marcadors buits, imatges redimensionades l'URL original de les quals es pot recuperar eliminant la part de transformació, i la duplicació de la imatge hero que apareix tant a la capçalera com al cos. Cadascun d'aquests detalls requereix un tractament específic. Per exemple, per a les negretes partides, cal mantenir els espais fora dels marcadors perquè no es generin **** intermedis. Per a les imatges d'alta resolució, n'hi ha prou amb extreure l'identificador de l'URL de transformació i sol·licitar la versió sense escalar des de static.wixstatic.com/media/<id>. Aquests ajustos no són complexos, però ignorar-los produeix un Markdown trencat.
Un cop obtingut el Markdown, el treball no s'acaba. Hi ha una part del contingut —la que Wix hidrata del costat del client— que és irrecuperable per mitjans automàtics. Per això és fonamental incloure un linter de control de qualitat que revisi el Markdown generat buscant indicis de contingut que falta: imatges amb alt buit, línies òrfenes que esmentin 'preferir vídeo' sense el vídeo incrustat, fragments de codi que semblen introduccions sense bloc posterior, o taules aplanades en paràgrafs curts. Aquest linter no omple els forats; només assenyala on ha d'intervenir un humà, verificant contra la pàgina original en viu. Al flux de treball de Q2BSTUDIO amb intel·ligència artificial, apliquem el mateix principi: la IA ajuda a detectar patrons, però mai fabrica contingut que no existeixi. La transparència és clau per mantenir la credibilitat tècnica.
Si el destí final és Astro amb MDX, apareixen dues trampes addicionals del compilador: un < sense escapar al text s'interpreta com l'inici d'una etiqueta JSX i trenca la compilació. Això és molt comú en escriptura tècnica (Array<String>, n <= 1). La solució és embolicar-lo en un span de codi o utilitzar l'entitat <. De la mateixa manera, les claus { i } al text alternatiu d'una imatge s'interpreten com a expressions JSX. Un linter amb la bandera --mdx pot detectar tots dos casos abans de llançar la construcció. A Q2BSTUDIO integrem aquestes comprovacions als nostres pipelines de CI/CD per garantir que cada migració passi sense errors de build.
La lliçó final és clara: una migració exitosa de Wix a Markdown no depèn d'una eina màgica, sinó d'un procés disciplinat que combini extracció determinista, maneig acurat d'expressions regulars, linter de qualitat i revisió humana. Ignorar el contingut hidratat o confiar que una IA el reconstruirà porta a publicar tutorials amb forats invisibles. Al món del desenvolupament de programari a mida, la precisió és un valor irrenunciable. Per això a Q2BSTUDIO desenvolupem aplicacions a mida amb estàndards de qualitat que eviten aquests problemes des del disseny. Ja sigui migrant contingut, desplegant infraestructura al núvol (AWS/Azure), implementant agents d'IA per a automatització, o enfortint la ciberseguretat de les dades, el principi és el mateix: mai inventar el que no existeix, només recuperar el que realment hi és.
