Imaginemos una red de cursos de idiomas. El sitio lleva tiempo en Tilda y funciona tranquilo, pero en la siguiente reunión el informático de la empresa propone «exportarlo todo a nuestro servidor». Los argumentos suenan razonables: hosting propio, ninguna dependencia de la suscripción, control total. Un mes después resulta que los formularios de inscripción a la clase de prueba siguen funcionando solo con el plan pagado, el horario de los grupos en Flujos se edita en la cuenta antigua, y los enlaces directos a las noticias del boletín abren el vacío.
En esta historia la mudanza se parece a comprar una casa propia en la que los grifos del agua, por alguna razón, se cierran desde el piso anterior. Las paredes ya son suyas, pero vivir sin la dirección antigua todavía no se puede. La exportación de código existe en Tilda, y es útil en sus tareas. Solo que la independencia que se espera de ella suele ser mayor que la que da. Abajo voy a ver qué se muda con los archivos y qué se queda en la cuenta, con enlaces a la ayuda de Tilda.
Qué es la exportación de código y quién puede usarla
La exportación es la descarga del proyecto publicado en un archivo: páginas, estilos, scripts e imágenes que se pueden colocar en un servidor propio. Según la ayuda de Tilda sobre la exportación, la opción está disponible solo en la línea de planes Business, desde cinco sitios en adelante. En el plan para un solo sitio no está, así que la conversación sobre la exportación a menudo empieza por la pregunta de cambiar de plan.
El proceso en la ayuda se describe breve. En los ajustes del proyecto, en la pestaña «Exportación», se descarga un archivo zip, los archivos se copian al servidor y un archivo de servicio se renombra a .htaccess. Aquí hay un detalle técnico: ese archivo funciona solo con el servidor web Apache. Si en su servidor hay Nginx, las reglas habrá que escribirlas aparte.
La exportación descarga una instantánea de las páginas en el momento de la descarga. Para cambiar un texto o añadir una página nueva, usted sigue abriendo el editor de Tilda y vuelve a exportar el proyecto. Es más una forma de publicación que una mudanza a otra plataforma.
Qué se va con los archivos y qué se queda en la cuenta
La ayuda enumera lo que no se exporta. Tilda CRM y el Área personal están disponibles solo en la cuenta de Tilda. La contraseña que usted puso en una página o en el proyecto no se traslada, y en un servidor ajeno esas páginas se abrirán sin contraseña. Para los cursos con materiales cerrados esto es un riesgo aparte, en el que conviene pensar antes de la descarga.
Con Flujos y el Catálogo hay más límites. El panel de control no se exporta: crear y cambiar entradas y productos solo se puede dentro de la cuenta de Tilda. En su servidor las noticias y los productos se abrirán solo al hacer clic desde la lista general. Un enlace directo a una noticia o un producto concreto no funcionará, y la búsqueda de productos tampoco.
Para un sitio en el que las noticias, los artículos o los productos traen visitas desde la búsqueda y los boletines, esto importa. El enlace de un correo, «Abierta la inscripción al grupo nuevo», lleva a una entrada concreta, y es justo ese escenario el que se rompe después de la exportación. Yo comprobaría la lista de esas secciones antes de decidir la mudanza: suelen ser más de las que parece a primera vista.
Qué sigue dependiendo de la suscripción
Algunas funciones trabajan en un servidor ajeno, pero solo con una conexión viva con Tilda. El envío de formularios a través de los servicios de recepción de datos conectados exige una suscripción activa y el dominio indicado en los ajustes del sitio. Lo mismo con las fuentes de las bibliotecas ParaType y type.today: hace falta una suscripción activa y el dominio escrito. Si se apaga la suscripción, las solicitudes del sitio dejarán de llegar, y las fuentes pueden cambiar a las de reserva.
También hay el lado contrario. Un certificado para trabajar por HTTPS, añadido del lado de Tilda, no funcionará en su servidor. Habrá que conectarlo uno mismo, junto con las demás obligaciones del hosting: actualizaciones, copias de reserva, disponibilidad del servidor. Resulta que después de la exportación el sitio tiene dos puntos de dependencia en lugar de uno. La suscripción sigue haciendo falta para los formularios y las fuentes, y el servidor ahora es enteramente suyo.
Independencia que se puede comprobar
Si está pensando en mudar el sitio desde un constructor, yo empiezo por la lista de lo que el sitio hace: formularios, catálogo, noticias, secciones cerradas, pago. Después miramos qué de eso sobrevivirá a la exportación, qué pedirá un desarrollo y dónde es más honesto quedarse en la plataforma. La decisión la tomamos cuando esa lista está en la mano.
Reglas de uso del código exportado
La exportación tiene reglas, y la ayuda de Tilda las enumera directamente. El dominio en el que se va a colocar el código hay que indicarlo en los ajustes del sitio antes de exportar, y en otro dominio no se puede colocar el código. Está prohibido reproducirlo y distribuirlo. También está prohibido usarlo para crear páginas fuera de la plataforma y cambiar el código fuera de Tilda. Quitar el identificador del desarrollador con el enlace a Tilda está prohibido, salvo los casos previstos por los planes.
Ahí mismo hay un enlace al acuerdo de usuario. Los cambios no autorizados de los recursos del sitio, es decir de las páginas, los bloques y sus partes, Tilda los llama una violación de su derecho de autor, con independencia de dónde esté colocado el proyecto. Una valoración jurídica no la voy a dar. Para la práctica importa más la conclusión: el código exportado no se puede tomar por un código fuente que se pueda retocar con libertad en casa. Si el plan es reescribir las páginas a mano, eso ya es un proyecto aparte, y las reglas conviene comentarlas con un abogado de antemano.
Dependencia del sitio respecto del constructor: qué da de verdad la exportación
La exportación resuelve bien tareas estrechas. Por ejemplo, si por los requisitos de la empresa el sitio debe estar físicamente en su servidor, o si hay que gestionar las rutas de los archivos a través de una red propia de entrega de contenido. La ayuda menciona aparte la posibilidad de indicar rutas propias para las imágenes, los estilos y los scripts. Para un sitio de presentación estático que cambia poco, este formato también puede encajar.
De la dependencia de la plataforma la exportación no libera. El editor, el catálogo, Flujos, los formularios y las fuentes siguen ligados a la cuenta, y las reglas prohíben convertir el código en un proyecto independiente. Si el objetivo es la independencia, es más honesto hablar de un traslado a otra plataforma o de un desarrollo en el que los datos, la administración y el código le pertenecen. Es más caro y más largo, pero queda claro qué se obtiene.
Volvamos a los cursos de idiomas. A ellos, lo más probable, les habría convenido empezar por la pregunta de qué quieren ser independientes exactamente. Si del plan, la exportación conservará esa dependencia. Si de las reglas de la plataforma, hace falta otro camino. Si lo que de verdad preocupaba era la velocidad o la fiabilidad, la mudanza quizá no haga falta en absoluto. Basta con el orden en el sitio actual.