Quando a visibilidade de blocos pertence ao conteúdo, não à colocação

O core do Drupal liga a visibilidade ao sítio onde um bloco é colocado. Para um tipo de site cada vez mais comum, essa é a entidade errada, e quatro perguntas dizem-te em que caso estás.

Lançámos o Block Content Visibility, com a BloomIdea, a minha agência, como supporting organization do projeto. O argumento assenta no próprio modelo do core do Drupal e num issue público do core.

A afirmação é esta: o core do Drupal dá-te duas camadas de visibilidade de blocos e ambas estão presas à coisa errada para um tipo de site cada vez mais comum. Para blocos de conteúdo reutilizados em sites multilingues, com moderação, ou com separação de permissões, a visibilidade pertence à entidade block_content, não à colocação, e o core hoje não te dá onde a pôr aí. Isto é contestável, um site builder sénior vai contestá-lo, e dou a versão mais forte dele antes de responder.

As duas camadas que o core entrega, e onde ficam

A primeira camada é o sistema de condition plugins: User Role, Request Path, Language, e o resto que o core e o contrib expõem. A segunda camada é a colocação. Quando colocas um bloco em /admin/structure/block/add/<id>, o BlockForm renderiza esses condition plugins e guarda as tuas respostas na colocação, que é uma config entity block. Este é o modelo certo, e bom, quando um bloco é colocado uma vez numa região e a regra que decide se aparece é uma propriedade desse sítio na página.

Deixa de ser o modelo certo no momento em que a regra é uma propriedade do conteúdo e não do sítio.

Pega num único bloco reutilizável: uma promo de "portes grátis VIP". Colocá-lo em três regiões em dois temas. A regra "mostrar isto só ao segmento de audiência VIP" não é um facto sobre o cabeçalho, a barra lateral ou o rodapé. É um facto sobre a promo. O core obriga-te a reintroduzi-la nas três colocações e a mantê-las sincronizadas à mão para sempre. Muda o segmento e mudas em três sítios, ou falhas um e a regra dessincroniza em silêncio. Nada te diz que derivou.

Agora junta três coisas que são normais em Drupal de empresa e de setor público, não exóticas:

• O bloco é traduzido. A config da colocação e a tradução do conteúdo vivem em armazenamento diferente. A regra que devia viajar com o conteúdo traduzido não viaja.
• O bloco está sob Content Moderation. Queres a visibilidade versionada com o conteúdo, para que reverter uma revisão reverta também a sua visibilidade. A config da colocação não é revisionada com a entidade.
• As pessoas que gerem o block content não têm administer blocks. Esta é uma separação deliberada e comum: os editores são donos do conteúdo, os site builders são donos da estrutura. A única casa do core para a visibilidade é o lado da estrutura, por isso ou os editores não a conseguem definir ou sobre-concedes uma permissão estrutural a pessoas de conteúdo para contornar o modelo.

São o mesmo defeito visto de três ângulos. A regra é uma propriedade do conteúdo, e o único sítio onde o core te deixa guardá-la é a colocação.

O que o Block Content Visibility faz, em concreto

Acrescenta a terceira camada em falta: visibilidade ao nível do conteúdo. Anexa um único base field visibility_conditions ao block_content, um campo revisionável, de valor único, string_long, com um payload em JSON, e renderiza a UI de Condition Plugin do core diretamente no formulário padrão de adicionar e editar block content. A mesma UI aparece dentro do modal de inline block do Layout Builder, por isso um editor a compor uma página pode condicionar um bloco a uma condição de role ou cookie sem sair do Layout Builder. Há uma permissão dedicada administer block content visibility, por isso a capacidade segue a fronteira conteúdo versus estrutura em vez de a partir, e um formulário de definições em /admin/config/system/block-content-visibility para ativar bundles e esconder plugins ruidosos. Instala-se com composer require drupal/block_content_visibility.

Duas escolhas de design carregam o argumento todo, e são escolhas, não detalhes.

Não contribui nenhum condition plugin novo. É canalização. O seu valor são exatamente os plugins que já tens ativos, do core, do contrib ou teus, expostos na entidade em vez de só na colocação. Acrescenta um sítio onde pôr uma regra, não regras novas.

Faz AND com a visibilidade ao nível da colocação em vez de a substituir. No momento do render resolve a entidade subjacente, constrói uma ConditionPluginCollection, aplica os contextos de runtime por condição, e devolve um access result, espelhando como o próprio BlockAccessControlHandler do core já funciona, com bubbling completo da cache metadata. A visibilidade da colocação continua a funcionar e a significar o que significava. A visibilidade de conteúdo é uma porta adicional que viaja com o conteúdo. Um bloco aparece só se ambas as camadas permitirem. Essa coexistência é a resposta à objeção principal.

A objeção mais forte: o nível da colocação está certo by design

Um site builder sénior vai responder logo, e a forma forte tem razão nos seus próprios termos. Ligar a visibilidade à entidade está errado porque o mesmo bloco reutilizável legitimamente deve poder comportar-se de forma diferente em colocações diferentes. A instância no rodapé e a instância na barra lateral não são a mesma situação, e a colocação é exatamente onde essa diferença pertence.

Concordo com isso por inteiro, e é por isso que o módulo faz AND em vez de sobrepor. A diferença por colocação fica na colocação, corretamente modelada. A afirmação é mais estreita e mais difícil de refutar: existe uma classe de regra que é invariante em todas as colocações de um bloco porque é um facto sobre o conteúdo, e o core não te dá nenhum sítio ao nível da entidade para a exprimir, por isso és forçado a duplicá-la pelas colocações ou a empurrar a lógica do próprio conteúdo para config de estrutura. O módulo acrescenta a camada em falta para a regra invariante e deixa intacta a camada por colocação para a variante. As duas são precisas. O core só entrega uma.

A outra objeção: o issue #2916876 do core vai resolver isto

A resposta canónica a "preciso de visibilidade de blocos que o Layout Builder respeite" é o issue do core #2916876, "Add visibility control conditions to blocks within Layout Builder". Declaro o seu estado com a mesma precisão que exijo do meu lado. Foi aberto a 17 de outubro de 2017. É prioridade Major. Continua em "Needs work". Foi tocado pela última vez a 24 de janeiro de 2026, com um merge request ativo contra a 11.x, por isso está vivo, não abandonado. O seu próprio enunciado do problema é que o Layout Builder introduziu um novo paradigma de colocação sem mecanismo de visibilidade, o que é uma lacuna real e um esforço sério para a fechar.

Não é um substituto para esta camada, e a razão é arquitetural, não quem entrega primeiro. By design, o #2916876 guarda as condições na secção ou componente do Layout Builder. Cobre por isso só colocações de Layout Builder, e a regra vive no layout, não na entidade block_content. Não faz nada por colocações clássicas de blocos, e não faz a visibilidade viajar com o conteúdo através de tradução ou moderação, porque o layout não é o conteúdo. Se aterrar, será a correção certa para o caso variante, por componente, dentro do Layout Builder. Continuará a não ser um sítio onde pôr uma regra que é uma propriedade do conteúdo e tem de valer em todas as colocações, clássicas e de Layout Builder por igual. Camada diferente, âmbito diferente, e ao fim de oito anos, não é uma coisa contra a qual possas construir hoje.

O contrib adjacente tem a mesma forma de desencontro. O Block Visibility Groups agrupa blocos sob condições partilhadas de site-admin, uma ferramenta de administração de site com uma audiência de permissões diferente que não faz uma regra viajar com um único pedaço de conteúdo. O Block Visibility Conditions contribui condition plugins extra mas não muda onde as condições são guardadas. Nenhum deles põe a regra na entidade.

A regra de decisão

Esta é a parte útil, e podes aplicá-la sem instalar nada. Para qualquer regra de visibilidade de bloco que estejas prestes a configurar, pergunta:

• Esta regra é a mesma para todas as colocações deste bloco, ou difere conforme o sítio na página? A mesma em todo o lado aponta para conteúdo. Difere por sítio aponta para colocação.
• O bloco é traduzido, e a regra deve seguir a tradução? Sim aponta para conteúdo.
• O bloco está sob Content Moderation, e reverter uma revisão deve reverter a sua visibilidade? Sim aponta para conteúdo.
• As pessoas que definem esta regra têm administer blocks, ou só permissões de conteúdo? Só de conteúdo aponta para conteúdo.

Se respondeste "colocação" à primeira e o resto não se aplica, o core já te serve e não precisas deste módulo. Se respondeste "conteúdo" à primeira ou sim a qualquer das outras, o core não tem casa nativa para a regra e estás a escolher hoje entre duplicação manual, sobre-concessão de uma permissão estrutural, ou regras que dessincronizam. Essa lacuna é onde o Block Content Visibility pertence, especificamente em Drupal multilingue, com moderação, com governança pesada, que é também, em justiça, o tipo de site que a BloomIdea é paga para construir, e não como predefinição em todo o lado. É um release 1.0.0-beta1 com dependência dura do Block Form Alter e ainda não está coberto pela política de security advisory do Drupal, o que vale a pena saber antes de o pores em produção e não depois.

O modelo de colocação do core não está errado. Está incompleto numa direção que importa mais a cada ano, à medida que os sites Drupal ficam mais multilingues, mais moderados, e mais estritos quanto à fronteira editor versus site builder. A peça em falta é pequena, é a camada certa, e a camada é a entidade, porque a entidade é onde a reutilização, a tradução, a moderação e a propriedade editorial já vivem. Pôr a regra noutro sítio qualquer é pô-la ao lado dos dados em vez de neles.

José Fernandes é o fundador da BloomIdea, uma agência de Drupal e AI baseada em Braga, Portugal. É autor de Digital Marketing with Drupal (Packt, 2022), com prefácio de Dries Buytaert, criador do Drupal, e está a concluir um doutoramento sobre colaboração humano-AI em contextos organizacionais na Universidade do Minho.