Nesse artigo vamos aprofundar na parte de backend do Drupal. Como foi dito na Parte 1, o backend do Drupal é versátil e intuitivo de usar devido a dois conceitos fundamentais: Entidades (Entities) e Campos (Fields). Aqui segue uma definição informal porém exata do que são Entities e Fields:

Entities são coisas que usam Fields para guardar informações.

Acredito que alguns exemplos de como Entities e Fields podem ser utilizados irá clarificar esse conceito:

• Uma página pode ser uma Entity com Fields para armazenar o conteúdo de uma página.
• Um usuário pode ser uma Entity com Fields para nome, email e senha.
• Um produto pode ser uma Entity com Fields para cor, tamanho, preço e quantidade.
• Uma sala de aula pode ser uma Entity com Fields para horário de início, professor, duração e alunos.

Fields

Você percebeu que Fields são bem flexíveis? Eles são flexíveis porque podem armazenar qualquer tipo de informação. O Drupal já vem com vários tipos de Fields que podem armazenar dados como texto, número, data, email, senha, link, imagem, arquivo, referência a outras entities, etc. Adicionalmente, é possível instalar outros tipos de fields gratuitamente para armazenar dados como endereço, post de redes sociais, vídeo, latitude e longitude, telefone, moeda, etc. Raramente você irá precisar criar seu próprio tipo de Field, mas se for o caso isso também é possível (apesar de requer um conhecimento mais profundo sobre Drupal). Ficou claro o conceito de Fields? 

Entities

Entities, como eu já mencionei, são coisas que usam Fields para guardar informações. Existem dois tipos distintos de Entities no Drupal:

1. Configuration Entity: utilizado para guardar diversos tipos de configurações como o nome do site, a lista de módulos instalados, menus, etc.
2. Content Entity: utilizado para guardar informações relacionadas à conteúdos como páginas, posts, usuários, etc.

Ambos Configuration e Content Entities são armazenados no banco de dados. Porém, por causa da distinção entre esses dois tipos de entities, é possível exportar e importar dados de Configuration Entities separadamente (em arquivos .yml), algo que é bastante útil durante o desenvolvimento e até manutenção do site. Isso torna possível alterar e salvar configurações do site independentemente do banco de dados.

Content Entity

Os exemplos de Entities que citei no começo do artigo enquadram-se todos no segundo tipo de Entity, o tal do Content Entity. Existem vários tipos de Content Entities que já vem com o Drupal como padrão de fábrica. Dentre eles, existem dois que gostaria de explorar em mais detalhes.

O primeiro é o Content Entity do tipo User. O User, como o nome sugere, representa um usuário do site e já vêm com 3 Fields: nome, email e senha. É possível adicionar mais Fields, mas esses três são básicos.

O outro tipo de Content Entity que quero apresentar chama-se Node. É importante clarificar que no backend ele se chama Node mas no frontend (interface gráfica) ele é frequentemente chamado de Conteúdo (ou simplesmente Content). Em outras palavras Node e Content são exatamente a mesma coisa. O fato da mesma coisa ter dois nomes pode ser confuso mas você se acostuma. O motivo dessa discrepância parece ter origem em um passado distante do Drupal (que nasceu em 2001!) e só tem importância se você tiver interesse em arqueologia de software. Saber que Node e Content são a mesma coisa é o que interessa. O resto não tem pressa.

Node

Content Entities podem opcionalmente ter subtipos e esse é exatamente o caso do Node. Usar subtipos é útil caso você precise construir tipos de Content Entity que tenham fields e funcionalidades semelhantes. Por exemplo, o Node já vem com fields para título, data de criação e autor além de funcionalidades como histórico de alterações. Isso permite que Páginas, Artigos, Posts, Notícias, Mensagens, etc, sejam todos criados como um subtipo de Node pois todos eles certamente precisam dos fields que já vem com o Node. Isso evita de termos que criar os mesmos fields e funcionalidades múltiplas vezes. Além disso, é possível adicionar fields distintos a cada um desses subtipos.

Eu gostaria que o que eu acabei de explicar realmente se chamasse subtipo (ou subtype). Porém o nome formal para isso é type ou bundle (dois nomes para definir a mesma coisa.. de novo? Sim. Saber apreciar a diversidade de termos para definir a mesma coisa é quase um pré-requisito para aprender Drupal).

Resumo da ópera

Recapitulando os pontos importantes sobre Content Entities:

• Existem diversos tipos de Content entities: User, Node (Content), Arquivo, Comentário, etc.
• Content entities podem ter subtipos como é o caso do Node (a explicação formal sem trapacear usando a palavra “subtipo” seria: “Tipos de Content Entities também podem ter tipos como é o caso do Node”).
   

Criar um novo tipo de Content Entity é complicado exige bastante experiência. Porém criar um subtipo de um Content Entity, como é com caso do Node, é extremamente fácil.

• Pensando em criar páginas para o seu site? Basta alguns cliques para criar um Node do tipo Página.
• Quer criar uma sessão de blog? Clique clique, e magicamente você terá um Node do tipo Post.
• Que tal uma sessão de eventos no site? Basta criar um Node do tipo Evento.
• Quer adicionar notícias? Taca um Node do tipo Notícias em sua lista.
   

É possível ir bem longe apenas usando o Node. Às vezes pode parecer inadequado criar um tipo de Node para modelar certos tipos de conteúdo (por exemplo menu de um restaurante ou pedidos de entrega). Porém a rapidez, praticidade e segurança de usar o Node em vez de criar um tipo próprio de Content Entity (que já disse ser complicado) muitas vezes compensa. Quanto mais você puder usar ferramentas já existentes e evitar criar algo customizado, melhor será sua qualidade de vida.

Entities, e mais especificamente o Node, são a espinha dorsal do Drupal. Porém o backend vêm com muito mais módulos (funcionalidades) de excelente qualidade. Abaixo segue uma lista abreviada de módulos que já vem com o Drupal.

Outros módulos Drupal

Views

Tudo que é relacionado em mostrar listas de conteúdo, buscas, filtros, queries personalizadas, etc pode e deve ser feito usando Views. Módulo extremamente versátil e útil.

Permissions

Permite restringir acesso a conteúdos do site baseado em vários parâmetros como o tipo de usuário (anônimo, administrador, etc), tipo de conteúdo (página, post, etc), tipo de ação (criar, ver, remover ou atualizar conteúdos), entre outros.

Content Translation

Permite publicar conteúdos em diversos idiomas. Visitantes do site podem facilmente selecionar o tipo de idioma desejado.

Dynamic Page Cache

O Drupal por natureza de sua flexibilidade no backend, necessita fazer um número relativamente alto de consultas ao banco de dados a cada visualização de página. Isso pode criar problema de lentidão no site. Dynamic Page Cache resolve esse problema colocando todas as páginas em cache para que a consulta ao banco de dados seja mínima a cada visualização de página. Essa funcionalidade pode tornar-se uma faca de dois gumes quando você não quer que certos dados do site sejam colocados em cache, mas em geral é uma ferramenta excelente e funciona sem necessidade de configurar.

JSON API

Algo que tem ganhado relevância no mundo Drupal por permitir expor APIs em json de forma simple e padronizada para que aplicativos externos possam interagir com o Drupal. Uma verdadeira mão na roda caso você precise abrir APIs no seu site Drupal para desenvolvedores externos.

Migrate

Permite importar conteúdos para o Drupal através de diversas formas como arquivos csv, apis, outros bancos de dados, etc. Requer um conhecimento mais avançado para usá-lo pois muitas de suas funcionalidades não são acessíveis pela interface gráfica.

Update Manager

Oferece um “painel de controle” que mostra todos os módulos instalados além de indicar atualizações pendentes (incluindo atualizações do próprio Drupal)

Conclusão

Esses são apenas alguns dos módulos que já vêm com a instalação do Drupal. Existem muitos outros módulos excelentes desenvolvidos pela comunidade Drupal disponíveis gratuitamente.

Espero que esse artigo tenha sido útil como material complementar em sua jornada de aprendizado. No próximo artigo exploraremos o outro lado do Drupal.. (suspiro profundo) o Frontend.