O que é Plone: o CMS que nasceu para múltiplas áreas publicando

Plone em uma definição

Plone é um gerenciador de conteúdo (CMS) de código aberto, escrito em Python, com controle de permissão por seção e fluxo de revisão embutidos, sem precisar de nenhum plugin adicional. Essa combinação é o motivo de ele aparecer com frequência em portal de órgão público com muitas áreas publicando ao mesmo tempo.

Plone existe desde os anos 2000 e é mantido por uma comunidade internacional de desenvolvedores, não por uma empresa dona da plataforma. Não há licença para pagar nem fornecedor único de quem depender: o código é aberto, e qualquer equipe técnica com conhecimento em Python pode ler, ajustar e manter o que está publicado.

Isso o coloca numa categoria diferente de outros CMS populares. Um CMS como o WordPress, por exemplo, resolve muito bem blog e site institucional simples, com uma ou poucas pessoas publicando. O Plone nasceu para outro problema: organização com várias áreas, cada uma com sua própria hierarquia de aprovação, publicando no mesmo portal.

Não é o gerenciador certo para todo site, mas resolve bem um problema específico: o de várias equipes publicando no mesmo portal sem pisar no conteúdo umas das outras.

Permissões e fluxo de revisão embutidos

Em muitos outros CMS, controlar quem edita o quê exige um plugin de permissões, um pacote pago ou uma customização feita sob medida. No Plone, esse controle já vem de fábrica.

Isso importa porque um portal institucional raramente é escrito por uma pessoa só. Comunicação publica notícias. Recursos Humanos publica editais e concursos. Licitações publica atas e contratos. Cada área tem informação sensível, e nenhuma delas quer que a outra apague ou altere o que já publicou.

Quando essa separação não existe de fábrica, a solução costuma vir de fora da ferramenta: uma convenção informal ("essa pasta é só da Comunicação"), reforçada por um combinado entre pessoas, e não pelo sistema. Convenção informal funciona até a primeira pessoa nova na equipe que não conhece o combinado.

Quem pode publicar em cada seção do portal

No Plone, cada pasta do site pode ter suas próprias regras de quem lê, quem escreve, quem revisa e quem aprova. Uma pessoa da área de Licitações pode ter permissão total dentro da pasta de licitações e nenhuma permissão para editar a pasta de Recursos Humanos, mesmo estando logada no mesmo portal.

Esse desenho evita dois problemas comuns em portais que não nasceram para isso: a conta genérica que qualquer um usa para editar qualquer coisa, e a dependência de um único administrador para aprovar toda alteração, não importa a área.

O que acontece entre escrever e publicar (fluxo de revisão e histórico de versões)

Um conteúdo criado no Plone não vai direto ao ar. Ele passa por um fluxo de estados: rascunho, em revisão, publicado, e às vezes arquivado. Quem escreve não precisa ser quem publica, e o portal registra quem fez cada mudança e quando.

Esse fluxo pode ganhar mais etapas, conforme o processo de aprovação do órgão exigir: uma revisão jurídica antes da publicação, por exemplo, ou uma validação da assessoria de comunicação para conteúdo que vai para a página inicial. O fluxo padrão já atende um portal com várias áreas publicando, e pode ser ajustado quando o processo real do órgão pedir uma etapa a mais.

Isso também resolve um problema prático: se uma página precisa voltar para uma versão anterior, o histórico já existe. Ninguém precisa reconstruir de memória o que estava lá antes, nem torcer para que alguém tenha guardado uma cópia do texto anterior num arquivo à parte.

Essas duas características (permissão por seção e fluxo de revisão com histórico) são justamente o que estrutura o serviço de Plone para governo, da implantação de um portal novo à sustentação do que já está em produção.

Quando um gerenciador de conteúdo desse porte é excesso

Nem todo portal precisa de tudo isso. Se o site é institucional, com poucas páginas, atualizado por uma ou duas pessoas, e sem o cenário de várias áreas publicando ao mesmo tempo, o Plone tende a ser mais estrutura do que o projeto pede.

Um sinal prático: quanto menos gente edita o conteúdo, e quanto menos aprovação em cascata o processo exige, menos sentido faz carregar um CMS pensado para múltiplas áreas em conflito.

Há também um custo de manter essa estrutura no ar. Hospedar um portal em Plone exige uma infraestrutura própria para rodar Python, diferente da hospedagem simples que serve um site estático ou uma landing page. Para um portal pequeno, esse custo de infraestrutura pesa mais do que o benefício de um controle de permissões que ele nunca vai usar de verdade.

Nesses casos, uma criação de site institucional resolve com menos peso: página institucional, landing page ou portal simples, construído para o volume editorial que o órgão ou a empresa realmente tem, sem o aparato de permissões e revisão que ficaria ocioso.

A pergunta que separa os dois caminhos não é "qual ferramenta é melhor", e sim "quantas áreas diferentes vão publicar nesse portal, e o quanto elas precisam de controle umas sobre as outras". A resposta define o gerenciador de conteúdo certo, antes de qualquer decisão de tecnologia.

Se a sua área herdou um portal em Plone de uma gestão anterior e ninguém sabe ao certo o que está publicado, quem tem acesso a quê ou em qual estado técnico o site está, o primeiro passo é um diagnóstico do que já existe, não uma decisão apressada sobre trocar de plataforma. Nossos profissionais já atuaram em órgãos do setor público federal e em organismos internacionais. Se sua área precisa de reforço técnico, atendemos por adesão (carona) a ata de terceiros ou como parceiro técnico de uma integradora que já tem contrato com o órgão.