FFH para TYPO3

Extensões TYPO3 específicas de setor não falham na técnica, mas na manutenção

FFH é exemplar para uma categoria de extensões TYPO3 desenvolvidas para um cliente específico ou um setor específico: específicas do setor, funcionais, mas não mantidas de forma geral. No TER encontram-se centenas de extensões assim. Algumas têm 5 downloads por ano, nenhuma documentação e o último commit há 3 anos. Isso não significa que sejam ruins. Significa que precisam de manutenção que o desenvolvedor original não presta mais.

Para empresas que dependem de tais extensões, surge uma questão prática: continuar usando e manter por conta própria, migrar para uma alternativa ou desenvolver do zero. Todos os três caminhos são viáveis. A decisão depende da complexidade da extensão, da disponibilidade de alternativas e da pressão de versão do TYPO3.

Cenários típicos de uso

Associações setoriais com requisitos especiais. Câmaras de ofícios, associações esportivas e cooperativas profissionais operam sites TYPO3 com funcionalidades que nenhum plugin padrão cobre: diretórios de membros com raio de busca, gestão de eventos com pontos de qualificação, registros setoriais com status de certificação. Para isso existem extensões customizadas desenvolvidas 5 a 8 anos atrás e desde então minimamente atualizadas. A função roda, mas atualizações do TYPO3 se tornam um risco.

Empresas de mídia com workflows editoriais. Emissoras de rádio, editoras e empresas de mídia usam TYPO3 com extensões para playlists, programação, arquivos de mídia ou syndication de conteúdo. Essas extensões foram frequentemente desenvolvidas internamente ou construídas por uma agência que não mantém mais o projeto. O código funciona no TYPO3 v9, mas a migração para v12 falha por APIs desatualizadas.

Instituições públicas com requisitos legais. Escolas, museus e bibliotecas usam extensões para gestão de horários de funcionamento, busca em catálogos ou reservas de eventos. Os requisitos são específicos (p.ex. integração com software de biblioteca como Koha ou Alma), a extensão foi construída uma vez e desde então não atualizada.

Arquitetura técnica

Extensões TYPO3 específicas de setor seguem tipicamente o padrão Extbase/Fluid: modelo de domínio (classes PHP), Repository (acesso ao banco de dados), Controller (lógica de negócios) e templates Fluid (apresentação). Os dados ficam em tabelas de banco de dados próprias com prefixo tx_extensionname_.

Os padrões arquiteturais mais frequentes: extensões baseadas em plugin com saída frontend (listagem, visualização de detalhe, filtragem), módulos backend para manutenção de dados e tarefas Scheduler para importação/exportação. Muitas extensões específicas de setor integram sistemas externos via APIs REST ou importação CSV.

A qualidade do código varia consideravelmente. Extensões de agências profissionais seguem padrões de codificação TYPO3, usam Dependency Injection e têm testes unitários. Extensões desenvolvidas internamente ou trabalhos encomendados rapidamente frequentemente têm configurações hardcoded, tipagem ausente e nenhum teste. Ambas podem ser mantidas, mas o esforço difere por um fator de 3 a 5.

Um padrão típico de análise para extensões específicas de setor: medir escopo (linhas de código, número de classes, número de tabelas de banco de dados), verificar dependências (quais APIs TYPO3 são usadas, quais estão deprecated na v12/v13), avaliar testabilidade (existem testes unitários, o código é estruturado de forma testável) e estimar esforço de migração.

Problemas frequentes e soluções

APIs deprecated bloqueiam a atualização do TYPO3. A extensão usa $GLOBALS['TSFE'], GeneralUtility::_GP() ou ObjectManager::get(), todas APIs deprecated ou removidas no TYPO3 v12. Solução: refactoring sistemático. Cada API deprecated tem um substituto documentado no TYPO3 Changelog. Para uma extensão com 5.000 linhas de código, o esforço de refactoring é de 3 a 7 dias, dependendo do número de deprecations.

Nenhum mantenedor disponível. O desenvolvedor original deixou a empresa, a agência não existe mais, o pacote TER está abandonado. Solução: fazer fork do código no GitHub, incluir a extensão no repositório Composer próprio e manter por conta própria. Ou contratar um prestador de serviço externo. O fork é legalmente sem problema se a extensão está sob GPL (padrão para extensões TYPO3).

Nenhuma documentação. Nem comentários inline nem docs externos. Novos desenvolvedores precisam ler o código para entender a função. Solução: antes do refactoring, criar uma documentação técnica. 2 a 4 horas de análise são suficientes para uma extensão com 3.000 a 5.000 linhas de código para documentar arquitetura, modelo de dados e lógica de negócios.

Migração e compatibilidade de versões

Extensões específicas de setor naturalmente não têm suporte oficial para v12/v13. A migração deve ser feita individualmente. O esforço depende de três fatores:

Primeiro: qual versão TYPO3 é o ponto de partida? De v9 para v12 é significativamente mais trabalho que de v11 para v12, porque v10 introduziu o middleware stack e v11 mudou o registro de módulos backend.

Segundo: quantas APIs deprecated são usadas? O Extension Scanner do TYPO3 (no Install Tool) mostra isso automaticamente. Uma extensão com 5 deprecations precisa de um dia, uma com 50 precisa de uma semana.

Terceiro: quão bem estruturado é o código? Código Extbase limpo pode ser migrado mecanicamente. Código procedural com chamadas diretas ao banco de dados requer reescrita.

As três opções: portabilidade (adaptar extensão para nova versão TYPO3, 3 a 10 dias), redesenvolvimento (mesma função, arquitetura limpa, 2 a 4 semanas) ou encontrar alternativa (extensão padrão que cobre 80% da funcionalidade, mais adaptação customizada). A Gosign analisou, portou e redesenvolveu centenas de extensões TYPO3 específicas de setor e orienta sobre a opção mais econômica.