Introdução
Num sistema Odoo, os modelos descrevem como os dados são organizados e guardados. Tudo o que manipula — páginas, contactos, encomendas — vive dentro de um modelo que dita campos, relações e regras.
Compreender os modelos do Odoo é obrigatório tanto para desenvolvedores como para consultores funcionais. É sobre eles que assentam as estruturas de dados: campos, ligações entre objetos e a lógica de negócio que governa o comportamento da aplicação.
Este texto concentra-se no website.page. É o modelo responsável pelas páginas estáticas do site construído com a app Website. Se cria landing pages, documentação institucional ou integra conteúdo externo, vai lidar com este modelo.
O que é o modelo website.page
O website.page corresponde às páginas estáticas do site no Odoo. Faz parte da aplicação Website e guarda as páginas criadas no construtor — por exemplo: Sobre Nós, Contactos, ou páginas promocionais pontuais.
Internamente, o website.page utiliza a herança de modelos do Odoo: cada registo está ligado a uma ir.ui.view através do mecanismo _inherits. A ir.ui.view contém o template QWeb (arch) e os metadados da vista.
Páginas geradas dinamicamente, como listagens de loja ou posts de blog, seguem outra lógica de produção e não são tratadas da mesma forma que páginas estáticas.
Essas páginas dinâmicas não ficam guardadas como website.page. O modelo destina-se especificamente a conteúdos estáticos que edita no construtor do website.
Campos-chave do modelo
A seguir estão os campos mais relevantes do website.page. Conhecê-los facilita gerir URLs, visibilidade e apresentação das páginas.
1. name
Tipo: Char. Título da página. Aparece na aba do browser, nos menus e nos resultados de pesquisa. Normalmente herdado da ir.ui.view associada.
2. url
Tipo: Char. Caminho da página no site — deve começar com uma barra. Exemplos: /contactos, /sobre-nos. É o endereço usado pelos visitantes para aceder à página.
3. view_id
Tipo: Many2one (ir.ui.view). Obrigatório. Liga a vista QWeb que contém o conteúdo. A view guarda o arch (XML) e o key. Apagar a view elimina a página associada.
4. website_id
Tipo: Many2one (website). Identifica o sítio ao qual a página pertence. Em configurações multi-site, pode ser específica ou partilhada quando vazia.
5. is_published
Tipo: Boolean. Determina se a página é visível ao público. Páginas não publicadas devolvem 404 ou redirecionamento; útil para ocultar sem apagar.
6. website_indexed
Tipo: Boolean. Controla se os motores de busca indexam a página. Deve ficar desligado em páginas de agradecimento ou internas que não pretende que apareçam nos resultados.
7. date_publish
Tipo: Datetime. Data de publicação. Serve para agendar a publicação e mostrar quando o conteúdo ficou disponível.
8. header_visible
Tipo: Boolean. Indica se o cabeçalho do site é exibido nesta página. Útil para landing pages com layout fullscreen onde não quer o cabeçalho padrão.
9. footer_visible
Tipo: Boolean. Controla a presença do rodapé. Tal como header_visible, permite criar páginas sem os componentes standard do site.
10. is_homepage
Tipo: Boolean (computado). Verdadeiro quando a página é a homepage do website. Só pode haver uma homepage por site.
11. is_visible
Tipo: Boolean (computado). Reflete se a página está visível com base no estado de publicação, data e regras de visibilidade.
12. menu_ids
Tipo: One2many (website.menu). Itens de menu que apontam para a página. Uma página pode aparecer em vários menus ou em nenhum.
13. create_date
Tipo: Datetime. Momento em que o registo foi criado. Gerido automaticamente; útil para auditoria e relatórios.
14. write_date
Tipo: Datetime. Última data de modificação do registo. Também gerido automaticamente para acompanhar alterações de conteúdo.
15. arch
Tipo: Text. Template QWeb em XML. Guarda a estrutura HTML e os snippets do Odoo; é editável através do construtor do website.
16. key
Tipo: Char. Identificador único da view. Usado em ficheiros XML de módulos e na herança de templates; costuma ter o formato module.view_name.
17. type
Tipo: Selection. Tipo de vista. Para páginas do website é sempre qweb; outros tipos incluem form, list e tree.
18. active
Tipo: Boolean. Flag de arquivo (soft delete). Quando falso, o registo fica arquivado e a página não é servida. Provém da ir.ui.view.
19. website_meta_title
Tipo: Char. Meta title para SEO. Substitui o título padrão nos resultados de pesquisa — crucial para visibilidade orgânica.
20. website_meta_description
Tipo: Text. Meta description para SEO. Texto exibido nos resultados; ideal entre 150–160 caracteres para melhor apresentação.
21. website_meta_keywords
Tipo: Char. Palavras-chave meta. Menos relevantes nas práticas SEO actuais, mas ainda usadas por alguns serviços; separadas por vírgulas.
22. header_overlay
Tipo: Boolean. Indica se o cabeçalho sobrepõe o conteúdo — comum em páginas com hero banner onde o cabeçalho fica por cima da imagem.
23. header_color
Tipo: Selection. Esquema de cor do cabeçalho (ex.: transparente, claro, escuro). Afeta contraste e legibilidade dos elementos.
24. visibility
Tipo: Selection. Controlo de acesso: Público, Utilizadores autenticados, Grupo restrito ou Protegido por palavra-passe. Define quem pode ver a página.
25. redirect_type
Tipo: Selection. Define o tipo de redirecionamento quando a URL muda: 301 (permanente), 302 (temporário) ou nenhum. Importante para preservar SEO ao mover conteúdos.
Como este modelo entra nos fluxos de trabalho empresariais
Casos de uso comuns: Landing pages e campanhas
As equipas de marketing criam landing pages para campanhas — cada uma como um registo website.page. Controlam a URL, o conteúdo e a data de publicação; o campo date_publish permite agendamentos automáticos.
Casos de uso comuns: Páginas institucionais
Páginas como Sobre Nós, Contactos, Termos e Política de Privacidade costumam ser website.page. São criadas e atualizadas ocasionalmente; a presença em menus é gerida através de menu_ids.
Casos de uso comuns: Páginas de agradecimento/confirmação
Mensagens tipo “Formulário enviado” ou “Pedido recebido” são geridas como website.page e devem ter website_indexed desligado para não aparecerem em motores de busca.
Casos de uso comuns: Multi-site e localização
Em setups com vários websites, o website_id determina onde a página aparece. Pode duplicar páginas por site para oferecer conteúdo localizado ou específico por marca.
Casos de uso comuns: Conteúdo protegido e acessos restritos
O campo visibility permite criar áreas apenas para utilizadores autenticados ou grupos específicos — útil para portais de membros ou documentação interna.
Como os desenvolvedores estendem este modelo
Os desenvolvedores podem estender website.page por vários padrões; a herança de modelos é o método padrão no Odoo.
Herança de modelo
Use _inherit = 'website.page' para estender o modelo. Pode adicionar campos, sobrepor métodos ou impor constraints. Trabalhar por herança mantém as alterações em modules separados e facilita upgrades.
Adicionar campos
Declare novos campos no modelo herdado usando o tipo correcto (Char, Many2one, Boolean, Integer, Text, Selection). Pense também em campos dependentes do website para ambientes multi-site.
Extensões em Python
Sobreponha create, write ou unlink para introduzir lógica personalizada — sempre chamando super() para preservar o comportamento original. Tenha atenção ao relacionamento view_id e ao efeito de cascade quando eliminar vistas.
Odoo Studio
O Odoo Studio permite personalizar páginas sem código, ideal para alterações rápidas ao layout. Para lógicas complexas ou conteúdo alimentado por API, os módulos customizados são mais sustentáveis.
Boas práticas
- Use slugs amigáveis nas URLs — evite espaços e caracteres especiais; prefira hífens para melhorar a legibilidade e o SEO.
- Desative website_indexed em páginas de agradecimento, confirmações e conteúdos internos para não apareçam nos motores de busca.
- Quando alterar URLs, configure redirecionamentos (301 preferencialmente) para manter o valor SEO e evitar links quebrados.
- Preencha sempre website_meta_title e website_meta_description nas páginas públicas — isso melhora a forma como as páginas aparecem em pesquisas orgânicas.
- Ao criar páginas via API ou XML-RPC, crie primeiro a ir.ui.view e depois o website.page apontando para view_id. Verifique que a view tem type = qweb e uma key única.
Erros comuns
- Evite criar uma website.page sem uma view_id válida: a vista QWeb tem de existir e ser do tipo qweb para a página funcionar corretamente.
- As URLs devem começar com uma barra. Odoo espera caminhos como /contactos em vez de contactos — caso contrário a rota não será reconhecida.
- Não esquecer de marcar website_indexed como False em páginas de agradecimento evita que estas entrem nos índices de busca e afetem os resultados.
- Alterar a URL de uma página sem configurar um redirect provoca links quebrados e faz com que motores de busca percam o histórico do conteúdo.
- Modificar o arch de uma vista que já foi editada no construtor pode ser complicado: o atributo noupdate em ir.model.data pode impedir que alterações via XML se apliquem; às vezes é necessário reajustar esse flag.
Conclusão
O website.page é o núcleo da gestão de páginas estáticas no Odoo: guarda metadados, URLs e definições de publicação, enquanto o conteúdo em si reside na ir.ui.view ligada.
Conhecer os campos principais e a herança com ir.ui.view ajuda a configurar, personalizar e integrar sites Odoo de forma eficiente. Para consultores e devs, dominar o website.page evita erros e acelera implementações.
Precisa de ajuda com a sua implementação Odoo?
A Dasolo acompanha empresas na implementação, personalização e optimização do Odoo. Temos experiência em integrações por API e no desenho da arquitectura de dados do Odoo, incluindo modelos como website.page.
Se precisa de apoio na sua implementação Odoo, criação de páginas web personalizadas ou integrações, podemos ajudar. Agende uma demonstração para falarmos sobre o seu projeto.