in2publish para TYPO3: Content Publishing entre Staging y Live

Por qué in2publish define el flujo de trabajo de contenido en proyectos TYPO3 enterprise

En instalaciones TYPO3 profesionales, los editores no trabajan directamente en el sistema en producción. Gestionan contenidos en un entorno de staging, coordinan cambios internamente y publican solo tras aprobación. Pero cómo llegan los datos de staging a producción. Sin in2publish eso significa: dump de base de datos en staging, restaurar en producción, sincronizar archivos por FTP. Un proceso propenso a errores que toma de 30 a 60 minutos y donde un clic equivocado puede sobrescribir toda la base de datos en producción.

in2publish de in2code elimina este proceso. Los editores pulsan “Publicar” en el backend TYPO3, y la extensión sincroniza exactamente los registros y archivos modificados al sistema en producción. Sin accesos FTP, sin dumps de base de datos, sin tiempo de inactividad.

Escenarios de uso habituales

Flujo de trabajo de aprobación editorial. Una corporación opera su web corporativa en TYPO3 con 12 editores en 3 departamentos. Cada departamento gestiona su área en staging. La jefatura de equipo revisa los cambios y los aprueba. El editor pulsa “Publicar” y solo sus páginas aprobadas pasan a producción. Otras áreas de la web quedan intactas. in2publish muestra una vista de diferencias: qué campos han cambiado, qué imágenes son nuevas, qué registros se sobrescribirán.

Publicación multi-idioma. Una empresa gestiona su web en 5 idiomas. La redacción española publica textos terminados mientras la traducción al inglés aún está en curso. in2publish permite publicación selectiva por idioma: el contenido en español pasa a producción, el inglés permanece en staging hasta completar la traducción.

Lanzamientos de campaña con fechas definidas. El equipo de marketing prepara una página de lanzamiento de producto que debe publicarse el 15 de octubre a las 8:00. Todos los contenidos - textos, imágenes, vídeos, landing pages - se preparan y prueban en staging. El día del lanzamiento, el editor responsable publica todo en un solo paso. En caso de problemas, in2publish puede revertir los cambios.

Arquitectura técnica

in2publish trabaja a nivel de base de datos y sistema de archivos. La extensión compara el estado de la base de datos de staging con la de producción y transfiere las diferencias. Los componentes principales son: Record Comparison (compara cada registro entre staging y producción, resolviendo relaciones para que al publicar una página se incluyan automáticamente todos los registros dependientes), FAL Synchronisation (imágenes y documentos se transfieren vía SSH/SFTP al sistema en producción, comparando tamaños y hashes), Transport Layer (comunicación vía SSH con autenticación por clave pública) y Configuration (YAML que define qué tablas se publican como whitelist y cuáles se excluyen).

Problemas frecuentes y soluciones

La publicación falla con “SSH Connection Failed”. La causa más frecuente: la clave SSH del servidor de staging no está registrada en el servidor de producción, o la configuración SSH en in2publish apunta al host/puerto incorrecto. Solución: probar la conexión SSH manualmente, luego verificar las credenciales en la configuración de in2publish.

Los registros no se actualizan en producción. La tabla no está en la whitelist de la configuración de in2publish. Ocurre frecuentemente con tablas personalizadas de extensiones propias. Solución: añadir la tabla en la configuración y definir las relaciones.

Faltan archivos FAL tras la publicación en producción. El FAL Storage en el sistema de producción tiene una ruta distinta a staging, o los permisos en el servidor de producción no permiten escritura en la carpeta de uploads. Solución: asegurar que la ruta base del FAL Storage sea idéntica en ambos sistemas.

Migración y compatibilidad de versiones

in2publish se mantiene activamente por in2code y está disponible para TYPO3 v11 y v12 LTS como paquete Composer. La versión Enterprise ofrece funcionalidades adicionales (transporte HTTP, logging ampliado, soporte multi-entorno) con licencia de pago.

Tras una actualización TYPO3 debe revisarse la configuración de in2publish: nuevas tablas del sistema, definiciones TCA modificadas y nuevos tipos de elementos de contenido requieren ajuste de la whitelist. Gosign recomienda tras cada actualización del core un test-publish con una sola página para validar la configuración antes de reanudar el flujo editorial completo. El test debe incluir una página con todos los tipos de contenido relevantes: elementos de texto, imágenes, descargas de archivos y al menos una relación.