Acquia Site Studio · antigo Cohesion
Site Studio é governança de design system. Ou vira um depósito de componentes.
Os dois resultados vêm do mesmo produto. O que decide não é a ferramenta, é quem tem autoridade para criar componente e o que acontece quando alguém quer um novo.
A stack
Site Studio não roda sozinho.
Três peças, três responsabilidades distintas. Operamos as três.
CMS
A base. Conteúdo, permissões, workflow e a camada de cache.
Plataforma
Site Studio e a hospedagem gerenciada. Somos parceiros.
Busca
Solr gerenciado. A busca que o Site Studio não resolve.
O que é
Uma camada de construção visual em que o componente é configuração, não desenho.
Uma biblioteca de componentes definida pela engenharia, da qual o time de conteúdo monta as páginas. Cada componente é configuração versionada: vive no repositório, passa por revisão, viaja entre ambientes como código.
O que não está na biblioteca não pode ser usado. Essa restrição não é limitação do produto. É o produto.
01{% set f7f3c = 'Plano Controle' %}02{% set f2b19 = 11.94002.8922. %}03 04{% include 'component--card.html.twig' with {05 title: f7f3c,06 code: f2b19,07} %}Twig\Error\SyntaxError: Expected name or number, got value "" of type "end of statement block".
E não é um telefone com pontos: é um valor que TERMINA em ponto. O compilador lê esse ponto como começo de um acesso a propriedade e espera o nome que nunca veio. Com pontos no meio, compila e segue. É por isso que o defeito chega à produção.
01{% include '@ds/card.html.twig' with {02 title: card.title,03 code: card.code,04} %} compila com qualquer valor
O fonte carrega só estrutura. O valor do editor chega pelo contexto na renderização, e não há o que quebrar. É o que significa inerte por construção, em vez de inerte por escaping.
O erro que custa caro
Tratar Site Studio como page builder.
Começa parecendo agilidade, e o padrão é sempre o mesmo:
- 01Uma campanha precisa de um bloco diferente e ganha um componente novo
- 02O componente novo não é revisado, porque não é código aos olhos de ninguém
- 03Seis meses depois a biblioteca tem três versões do mesmo card
- 04O design system deixa de ser verificável: ninguém sabe qual versão é a certa
O sintoma é a biblioteca crescendo. A causa é não haver resposta para quem decide que um componente novo é necessário.
A camada de engenharia
O produto compila dado de editor dentro do código do template.
Esse único fato explica quase tudo o que dá errado em base grande. O template gerado não é um arquivo que lê dados: é um arquivo onde o valor digitado por quem edita vira parte do fonte compilado.
A consequência prática: um campo declarado como texto que apenas PARECE numérico é emitido sem aspas. Um telefone com um ponto sobrando no fim vira literal inválido, o Twig não compila, e o canvas passa a responder erro em toda renderização. Salvo com sucesso, quebrado para sempre.
As quatro respostas
Quatro defesas para o mesmo fato.
Não são quatro problemas. É um problema e uma progressão: conter, consertar, garantir no deploy e, se o custo continuar, assumir a geração.
- 01CONTER. No save, o Twig compilado é validado e o save é abortado se não compilar. Vale no presave da entidade, onde o template já chega compilado, e parseando do mesmo jeito que a renderização parsearia.
- 02CONSERTAR. Uma rotina confere o que já existe: se compila, não toca; se não compila, corrige e recompila para conferir; se continua quebrado, troca por um stub válido e registra. A página perde um bloco em vez de perder tudo.
- 03GARANTIR NO DEPLOY. Template compilado é artefato gerado, e qualquer regeneração o sobrescreve. A rotina roda dentro do deploy, no passo seguinte ao da regeneração. Conserto feito à mão some no próximo rebuild, em silêncio.
- 04ASSUMIR A GERAÇÃO. Gerar o template você mesmo, com o fonte carregando só estrutura e o valor viajando no contexto. Não é configuração: é decisão de arquitetura, e é o que torna o fonte inerte por construção.
Correção verificada, nunca presumida. Ao trocar o gerador do fornecedor por um próprio, a validação é comparar o HTML renderizado: ler o código gerado e achar que está igual não é prova.
O que o produto não faz
O que você vai escrever, queira ou não.
- Invalidação de componente compartilhado. Alterar um bloco reaproveitado não invalida as páginas que o renderizam, nem a borda. Exige descobrir quais páginas o usam, inclusive aninhado, e purgar cada uma fora do save, porque a busca é cara e faz o editor esperar.
- Preview do que ainda não foi salvo. O produto não mostra a página real com as alterações pendentes. Exige renderizar por subrequest, aplicando os valores não salvos, sem gravar em nó, layout ou revisão.
- Deploy de pacote de componente. Não anda no export e import de configuração padrão: exige rebuild no ambiente de destino. Errar essa etapa derruba o layout do site inteiro.
A solução
Tradução declarada.
O designer entrega uma tela e alguém recompõe aquela tela à mão dentro do CMS. É nesse trajeto que a biblioteca vira depósito: usa-se o componente parecido em vez do certo, e espaçamento e cor são digitados em vez de referenciados.
São duas camadas com donos diferentes: o Site Studio governa a composição, o design system governa a aparência e o comportamento. O ponto de contato é o componente do Site Studio emitir a tag do design system em vez de desenhar markup próprio.
Nada disso aparece em revisão, porque o resultado parece com o Figma. A recomposição manual é a causa. Uma tabela declara, por componente, o que ele emite no design system e o que ele vira no canvas, e a composição deixa de ser recomposta: passa a ser publicada.
O que ela ainda não garante
A arquitetura sustenta a garantia. A implementação ainda a entrega como preferência.
Quando um nó do Figma não casa com nenhuma entrada da tabela, o transformador não recusa: infere uma estrutura genérica a partir do tipo do nó, do nome, da direção do auto-layout e do preenchimento. O design perde o componente do design system e sobrevive como estrutura. E o casamento não é exato: o nome é normalizado e comparado por substring nos dois sentidos, então "Button Group" casa com a entrada "Button".
O desvio é contado quando o componente existe no Figma e não existe na tabela. Nos outros dois casos ele não aparece: um componente casado com a entrada errada é contado sob o nome errado, como se estivesse certo, e um sósia desenhado à mão nunca entra na contagem. O relatório mostra a ausência, não a divergência.
A tabela é o lugar do portão: recusar em vez de inferir, e casar exato em vez de por substring. São duas mudanças pequenas e conhecidas. Ainda não estão lá, e dizer o contrário seria o único trecho desta página que não se sustenta sob pergunta.
A decisão
Quando Site Studio vale, e quando não.
Vale quando
- Há muita gente publicando, com responsabilidades diferentes
- O design system existe e precisa sobreviver à pressa de quem publica
- A operação é multi-marca, multi-país ou multi-site
- Engenharia é gargalo para publicar, e isso está custando campanha
Não vale quando
- O site tem poucas páginas e um time pequeno publicando
- Não existe design system para proteger, e o Site Studio viraria o lugar onde ele deveria ter nascido
- A expectativa é de que a ferramenta substitua a decisão sobre governança
A pergunta útil não é se o Site Studio é bom. É se a sua operação tem o problema que ele resolve.
Perguntas de quem já opera
- Dá para migrar de Cohesion para Site Studio sem reconstruir o site?
- Na maioria dos casos, sim: é a mesma linhagem de produto e a migração é de versão, não de plataforma. O trabalho real raramente está na atualização em si, está em decidir o que fazer com os componentes que a base acumulou. Migrar carregando uma biblioteca inchada é pagar duas vezes pelo mesmo problema.
- Site Studio deixa o Drupal mais lento?
- Não por si. O que pesa é a quantidade de componentes distintos renderizando na mesma página e a granularidade das tags de cache que eles declaram. Biblioteca enxuta com cache bem declarado tem desempenho indistinguível de template escrito à mão; biblioteca inchada é lenta pelo mesmo motivo que qualquer página com componentes demais.
- Quem deve poder criar componente?
- Quem responde pela consistência do design system, e isso costuma ser engenharia junto de design, nunca quem está fechando uma campanha. Não é questão de confiança: quem está sob prazo escolhe sempre o caminho mais curto, e o caminho mais curto é criar um componente novo em vez de descobrir se já existe um parecido.
- Como saber se a nossa biblioteca já está grande demais?
- Um indicador prático: peça a duas pessoas do time de conteúdo que montem a mesma página, separadamente. Se escolherem componentes diferentes para o mesmo bloco, a biblioteca já tem duplicata e o design system já não está sendo imposto por ela.
- Site Studio substitui um design system?
- Não. Ele impõe um design system que já exista, e isso é diferente. Sem decisões de design tomadas antes, a biblioteca vira o lugar onde cada decisão é tomada de novo, uma campanha por vez, sem ninguém revisando o conjunto.
Conte o que a sua plataforma precisa aguentar.
Migração de versão, Site Studio, design system ou um Drupal que cresceu mais rápido que a arquitetura.
Engenharia não é decoração. É direção.