in2publish para TYPO3: Publicação de conteúdo entre staging e live

Por que in2publish define o workflow de conteúdo em projetos TYPO3 enterprise

Em instalações TYPO3 profissionais, editores não trabalham diretamente no sistema live. Eles mantêm conteúdos em um ambiente de staging, alinham alterações internamente e publicam apenas após aprovação. Mas como os dados chegam do staging ao live? Sem in2publish, isso significa: criar dump de banco de dados no staging, importar no live, sincronizar arquivos via FTP. Um processo suscetível a erros, que leva 30 a 60 minutos e onde um clique errado pode sobrescrever todo o banco de dados live.

in2publish da in2code elimina esse processo. Editores clicam em “Publish” no backend TYPO3, e a extensão sincroniza exatamente os registros e arquivos alterados para o sistema live. Sem acessos FTP, sem dumps de banco de dados, sem downtime. O padrão da indústria para staging de conteúdo no TYPO3.

Cenários típicos de uso

Workflow de aprovação editorial. Uma corporação opera seu site corporativo em TYPO3 com 12 editores em 3 departamentos. Cada departamento mantém sua área no staging. A liderança revisa as alterações e as aprova. O editor clica em “Publish” e apenas suas páginas aprovadas vão para o live. Outras áreas do site permanecem inalteradas. in2publish exibe uma visualização de diferenças: quais campos mudaram, quais imagens são novas, quais registros serão sobrescritos.

Publicação multi-idioma. Uma empresa mantém seu site em 5 idiomas. A redação alemã publica textos finalizados, enquanto a tradução para inglês ainda está em andamento. in2publish permite publicação seletiva por idioma: o conteúdo alemão vai ao ar, o inglês permanece no staging até a tradução ser concluída.

Lançamentos de campanha com datas definidas. A equipe de marketing prepara uma página de lançamento de produto que deve ir ao ar em 15 de outubro às 8h. Todo o conteúdo é preparado e testado no staging. No dia do lançamento, o editor responsável publica tudo em uma única etapa. Em caso de problemas, in2publish pode reverter as alterações.

Arquitetura técnica

in2publish trabalha nos níveis de banco de dados e sistema de arquivos. A extensão compara o estado do banco de dados de staging com o de live e transfere diferenças.

A arquitetura consiste em quatro componentes centrais: Record Comparison (compara cada registro entre staging e live, resolve relações e apresenta em estrutura de árvore), sincronização FAL (transfere imagens e documentos via SSH/SFTP, comparando tamanhos e hashes), camada de transporte (comunicação via SSH com autenticação por chave pública, com a versão Enterprise suportando também comunicação baseada em HTTP) e configuração (via YAML define quais tabelas são publicadas e quais são excluídas).

Dependências: TYPO3 Core, acesso SSH entre servidor staging e live, extensão PHP-SSH2 ou binários ssh2 no servidor.

Problemas frequentes e soluções

Publicação aborta com “SSH Connection Failed”. Causa mais frequente: a chave SSH do servidor staging não está depositada no servidor live, ou a configuração SSH no in2publish aponta para host/porta errados. Solução: testar conexão SSH manualmente, depois verificar credenciais na configuração in2publish.

Registros no live não são atualizados. A tabela não está na whitelist da configuração in2publish. Isso acontece frequentemente com tabelas personalizadas de extensões próprias. Solução: adicionar a tabela na configuração e definir as relações.

Arquivos FAL faltam após publicação no live. O storage FAL no sistema live tem caminho diferente do staging, ou as permissões no servidor live não permitem escrita na pasta de upload. Solução: garantir que o caminho base do FAL Storage seja idêntico em ambos os sistemas.

Migração e compatibilidade de versões

in2publish é mantido ativamente pela in2code e está disponível para TYPO3 v11 e v12 LTS como pacote Composer. A versão Enterprise oferece recursos adicionais (transporte HTTP, logging estendido, suporte multi-ambiente) e é licenciada com custo.

Em um upgrade TYPO3, a configuração in2publish deve ser verificada: novas tabelas de sistema, definições TCA alteradas e novos tipos de elementos de conteúdo requerem ajustes na whitelist. A Gosign recomenda após cada upgrade de Core um publish de teste com uma única página para validar a configuração, antes de retomar a operação editorial completa. O teste deve incluir uma página com todos os tipos de conteúdo relevantes: elementos de texto, imagens, downloads de arquivo e pelo menos uma relação. Só assim todos os caminhos de sincronização são cobertos.