05 de Março de 2014

Case: Site do Restaurante Madero

Drupal, Case

Em dezembro foi ao ar um dos meus últimos projetos. Eu sei que já tem algum tempo, mas só agora consegui parar para escrever sobre ele.

O projeto foi refazer o site da rede de hambúrgueres gourmet Madero, que tem sede em Curitiba e hoje é uma rede bastante importante na região, com um movimento de expansão acelerado para outras partes do Brasil. O grande diferencial do Madero em relação a maioria dos restaurantes que vendem hambúrgueres é que eles prezam pela qualidade do que eles vendem, e isso fica evidente na hora que eles entregam produtos frescos comprados de produtores locais.

Versão para celular Versão para tablet Versão para desktop menor Versão para desktop largo
(Versões do site para cada dispositivo, do menor para o maior. Clique para expandir)

A reformulação do site é um projeto da Agencia Solar, também aqui de Curitiba, que fez o projeto visual para o novo site, bem como delineou com o cliente o que haveria em cada seção. Eu já trabalho com eles há algum tempo, e quando surgiu a oportunidade de refazer o site, eles me contactaram.

O meu papel foi o de arquitetar a estrutura do site, de acordo com o que foi definido pelo cliente e a Agência, e também adaptar o layout desenvolvido para dentro do site. A proposta era sair de um site feito puramente com Wordpress onde só haviam páginas e posts de blog e evoluir para uma estrutura mais elaborada, organizada por tipos de conteúdo e seções claras. Para essa tarefa, como não poderia deixar de ser, escolhi o Drupal.

A arquitetura do site foi elaborada de acordo com as necessidades do cliente, sendo a mais evidente a facilidade de uso por parte da equipe interna que iria manter o conteúdo. Isso fez com que eu criasse tipos simples, mas que em conjunto com outros, tornasse o site rico, mas sem agregar complexidade demasiada. Todo o site gira em torno de restaurantes e cidades. Um restaurante está sempre em uma cidade e é de um tipo (Madero Burger & Grill, Madero Burger ou Madero Premium). Isso reflete diretamente em todo o restante do site, fazendo com que uma informação apareça em várias partes, sem necessidade de redigitação. Um exemplo são os cardápios do site, que são compostos por pratos (outro tipo de conteúdo bem simples), e que são associados a uma cidade e um tipo de restaurante. Cada cardápio é valido para uma cidade, e cada item do prato pode ter um valor definido somente para aquele cardápio, mas os pratos são sempre reaproveitados, evitando assim a repetição da digitação de informação. Ao todo foram criados 7 tipos de conteúdo que se complementam e fazem com que a gestão do site seja mais simples.

Em todo o site foram usado cerca de 40 módulos distintos do Drupal. Alguns deles muito pequenos (como o Tipsy), e outros realmente importantes como o Views e o Field Collection. Para dar suporte à simplicidade na gestão, criei um módulo pequeno que junta algumas partes do conteúdo.

Outro grande requisito por parte do cliente era que o site estivesse disponível para dispositivos móveis, o chamado site responsivo. Aí outra vez o papel da Agência Solar ficou em evidência. Os designers deles criaram os layouts para cada seção do site em 4 tamanhos diferentes, indo de celulares ao desktop com telas largas. Ainda no quesito responsivo, tomamos o cuidado de fazer as imagens que compoem o layout todas adaptadas para telas de alta qualidade (retina). O meu papel foi, com base no layout desenhado pela agência, criar o CSS e o Javascript necessário para funcionamento do site. Essa foi uma parte muito trabalhosa, mas muito divertida. Toda a criação do tema usado foi feita em cima do Zen, um ótimo tema para quem deseja trabalhar com SASS e quer aproveitar o poder do Zen-grids para construção de layouts responsivos.

O site, com eu disse, está no ar desde dezembro e tem um alto índice de visitas diárias. No que se refere a performance, o mesmo sempre esteve bem rápido e não precisei fazer nada extravagante, bastando apenas habilitar o cache regular do Drupal.

No fim, o projeto foi muito divertido e eu aprendi bastante sobre sites responsivos. Também evolui muito o meu conhecimento de CSS e HTML5. Se você ainda não viu o site, pode acessar em http://restaurantemadero.com.br

19 de Novembro de 2013

Sobre motores de templates

Drupal, Programação, Linguagens, Template

O Drupal nunca foi tido como um CMS fácil de se trabalhar. Para quem está acostumado com o Wordpress ou Joomla! ele às vezes é muito estranho (verdade seja dita, isso acontecia até o Drupal 6, desde o 7 isso melhorou muito). No entanto para nós, desenvolvedores ele sempre teve um dos códigos mais limpos, seguros e consistentes no mercado de CMSs Open Source.

Apesar de o código do Drupal ser muito bom, está longe de ser um código segundo os padrões de mercado (leia-se "enterprise"). O fato é que o código do Drupal sempre teve uma certa deficiência de aplicação de conceitos modernos como orientação a objetos, por exemplo (seja isso bom ou ruim, interprete segundo o seu gosto).

Com o lançamento iminente do Drupal 8 muita gente está ansiosa pela sua integração com o framework Symfony, e, talvez na mesma proporção, muita gente está chateada com isso. Tanto é verdade que há até quem tenha criado um fork.

O Symfony é um framework muito bem construído e que vem agregar muito valor ao Drupal, e vice-versa. Da minha parte acho que o casamento do Symfony com o Drupal é algo maravilhoso. É mais um passo do Drupal rumo ao profisionalismo que o Drupal vem sempre correndo atrás.

Como um framework desacoplado, o Symfony é composto de um core, mas orbitando há uma série de acessórios que podem ser anexados a eles. Um deles é o motor de templates/linguagem de templates Twig.

Quem me conhece há algum tempo sabe que não gosto de motores de template e gostaria hoje de falar um pouco mais detalhadamente sobre isso. Quero só deixar claro que essa é só a minha opinião e não uma verdade universal (sempre tenho que falar isso pois sempre tem quem ache que eu sou o dono da verdade :-p).

Propósito

A princípio, uma linguagem ou motor de templates é usado para, entre outras coisas, agilizar o trabalho de quem vai fazer a parte visual de um projeto Web. Há alguns anos, isso era ainda mais forte pois o "designer" não conhecia linguagens de programação e tinha que lidar com coisas elementos de programação e isso costumava criar atrito nas equipes.

Hoje em dia muita gente alega que linguagens de template fazem mais do que só melhorar a leitura do template, mas agregam segurança e facilidade de uso. Em um artigo de 2009 o Fabien Potencier, criador do Symfony e do Twig, tem alguns bons argumentos que você deveria ler.

Conceito

Motores de template processam um código pré-formatado substituindo variáveis, loops e etc. por HTML de acordo com um conjunto de variáveis passado. Muita gente não gosta da misturar de PHP com HTML por achar isso errado. Isso até é verdade mas só se código PHP não tem nada a ver com a apresentação, mas com lógica de negócio ou algo do tipo. Por isso alguns alegam que é preciso ter uma linguagem alternativa só para a camada de apresentação. Eu penso diferente. Acho que o PHP é bem capaz de fazer esse trabalho e ainda você diminui a quantidade de linguagens do projeto, diminuindo os requisotos para se contratar um desenvolvedor/themer.

Legibilidade

Eu não acho nenhuma dessas linguagens de template particularmente legível. Na verdade, como desenvolvedor, a notação que elas utilizam frequentemente me atrapalha mais do que me ajuda. Talvez para um usuário leigo elas sejam fáceis, para mim elas são terríveis. Talvez a única exceção seja a TAL (Template Attribute Language) usada no Plone e portada para o PHP na forma do PHPTal, mas ainda assim prefiro não usá-la pelos demais argumentos que apresento.

Nova linguagem

Ainda relacionado à legibilidade e também ao aprendizado. Essas linguagens são, como o nome diz, novas lingaugens que você tem que aprender sintaxe, nome de funções e mais uma série de detalhes. Apesar de gostar de aprender, e principalmente de gostar de estudar linguagens, não acho que os supostos benefícios justifiquem o aprendizado de uma nova liguagem só para templates. Se é para gastar meu tempo aprendendo lingaugens, prefiro Haskell, que muda totalmente o meu paradigma de programação.

Performance

No artigo do Fabien, ele comenta sobre a velocidade de processamento do Twig e de outras linguagens/motores. Apesar do Twig se sair melhor, isso não o torna rápido. Na verdade, se você compará-lo com o PHP puro verá que ele é até bem lento. Para mim performance é muito importante. Um site mais lento alguns milisegundos pode ser um problema em vários aspectos, como rejeição por parte de usuários, problemas de SEO entre outros.

Conclusão

Por mais que eu não goste dessas linguagens, como expus acima, não posso negar o seu valor e seus benefícios. Mas, como tudo na vida, esses benefícios não são para todos e essas linguagens não resolvem todos os problemas no que tange criação da camada de apresentação. Assim, sempre que posso, evito usá-las.

Se você gosta de linguagens de template, e em especial do Twig, fique feliz pois agora poderá usar no Drupal 8. Já se você pensa como eu e não gosta de linguagens de template, fique feliz, você não será obrigado a usar o Twig com o Drupal, pois a PHPTemplate continuará presente.

17 de Setembro de 2013

Modelos de hospedagem

Hospedagem, Drupal

Quando vamos desenvolver um projeto para a Web, frequentemente nos preocupamos com a aparência do site, trabalhamos o banco de dados ou ainda estudamos bem a arquitetura do CMS que pretendemos usar. Depois de tudo pronto, na hora de colocar o nosso produto no ar, vem um problema que, geralmente, é negligenciado pelos clientes: hospedagem.

Tenho alguns clientes que tiveram vários problemas por conta de escolhas de hospedagem errada, e por isso resolvi fazer esse micro guia.

Quando falamos de hospedagem o mercado oferece algumas opções, e temos que saber bem qual escolher, para não perdermos tempo e dinheiro. A seguir alguns comentários sobre os tipos mais comuns.

Hospedagem compartilhada

Esse é o tipo mais comum no mercado e é o modo mais barato de se hospedar um site. Em geral uma mesma máquina possui centenas de sites hospedados, todos compartilhado os mesmos recursos. São atraentes pois usam sempre a palavra ilimitado nos seus anúncios e fazem parecer que você nunca vai ter problema.
Como tudo é compartilhado, nesse modelo você, em geral, não pode mexer em configurações do servidor e isso pode ser um problema. Você também não dispõe de muito recurso de hardware (memória/CPU), o que pode ser um problema. Recentemente me deparei com um servidor que quase inviabilizou o uso do Drupal.

Hospedagem dedicada/co-location

Esse é um modelo que só tem sido usado por grandes empresas e indivíduos com muito dinheiro. Aqui uma máquina física é alocada única e exclusivamente para um cliente. Em geral esse modelo é muito caro e demanda uma equipe bem qualificada para instalar, configurar e manter o servidor.
Esse modelo é muito flexível, uma vez que você tem total controle sobre a máquina, além de um desempenho fantástico, já que você é o único usuário da máquina.
O maior problema desse modelo é o custo de manutenção.

Servidor virtual/VPS

Esse modelo é um intermediário entre a hospedagem compartilhada e a dedicada. O que você tem é uma máquina virtual em um servidor compartilhado entre várias máquinas virtuais, mas com uma quantidade de memória e CPU exclusivas para você.
Na prática você tem que instalar, configurar e manter o servidor, semelhantemente ao que acontece na hospedagem dedicada, mas a um custo muito mais baixo.
A maior vantagem desse modelo é o custo baixo com alto poder de personalização. A maior desvantagem é que se você é um usuário comum, sem muito conhecimento de gestão de servidores, você pode deixar algumas brechas de segurança ou mesmo estragar tudo no seu servidor.

Existe ainda os modelos chamados "na nuvem", que na prática são um dos modelos descritos acima (em geral o VPS) com a diferença de esse servidor não estar limitado a uma única máquina ou região física, o que gera um desempenho maior e também maior confiança. Dependendo da empresa que oferece o serviço, ele pode ser bem em conta, ou muito mais caro que o VPS.

Concluíndo

Por muito tempo eu fui usuário da hospedagem compartilhada. Os meus sites eram muito simples e eu não precisava de nada mais personalizado. À medida que fui desenvolvendo aplicações mais personalizadas, acabei precisando mudar um pouco minha abordagem. O que me fez mudar para o servidor virtual foi justamente a grande dificuldade de se fazer personalizações para os meus sites na hospedagem compartilhada. Eu não podia instalar pacotes, nem configurar o servidor de acordo com as minhas necessidades.

Eu recomendo que, antes de contratar uma empresa de hospedagem, você verifique o que vai precisar no servidor para evitar dores de cabeça no futuro. Os meus sites estão hospedados na Linode há mais de 2 anos, uma empresa que hospeda apenas VPS, e nunca tive nenhum tipo de problema.
 

08 de Janeiro de 2013

2013 e algumas novidades

Drupal, Consultoria, Treinamento, Curso

Antes de mais nada: feliz 2013 a todos!

Eu sei que estou devendo a finalização do tutorial de como criar o site da imobiliária, e acho que semana que vem termino o último artigo.

Hoje eu quero falar de outra coisa. Quero falar de uma iniciativa/parceria minha com o Thiago Régis num novo projeto. Esse projeto se chama Ninjas Drupal.

O Ninjas Drupal é uma iniciativa que visa agregar uma lista de bons profissionais que trabalham com Drupal no Brasil, para um contato comercial de consultoria, treinamento, ou qualquer outra necessidade relacionada a Drupal.

O diferencial do Ninjas Drupal é que tudo é feito pela Fisqua com um acordo de garantia. Assim o cliente terá uma garantia de que o trabalho foi bem feito ou então o dinheiro é devolvido, e o profissional não precisará se preocupar com a burocrática tarefa de cobrar o cliente (que paga antecipado).

Atualmente estamos listados lá, eu, o próprio Thiago e também o Joel Wallis, outro experiênte desenvolvedor Drupal brasileiro. No futuro certamente teremos ainda mais profissionais listados.

Então se você está precisando de consultoria, treinamento, de uma pessoa para finalizar aquele projeto bacana, ou outra coisa relacionada a Drupal, vá lá, confira os profissionais, e contrate aquele que melhor cabe no seu orçamento ou que tem o perfil mais adequado.

13 de Setembro de 2012

Tutorial: Criando um site de imobiliária com Drupal - parte 5

Drupal, Drupal 7, Tutorial, Imobiliária

Essa é a quinta parte do tutorial de como criar um site de imobiliária com Drupal. Se você perdeu, aqui está o link para a parte anterior.

Introdução

Hoje vou falar do mais famoso módulo não-core do Drupal: o Views. Se você está chegando agora no mundo do Drupal, esse será um módulo que com certeza você vai usar, mais cedo ou mais tarde.

De forma breve o Views é um módulo que te auxilia em consulta no banco de dados. Ao invés de ter que fazer um código ou mesmo um módulo inteiro para uma simples consulta, você usa o Views e faz tudo via uma interface (hoje) amigável.

Essa é uma definição bem rasa do Views, uma vez que ele pode fazer muito, muito mais coisas.

Toda vez que você pensar que precisa fazer uma listagem de conteúdo, usuário, comentário, taxonomia etc. você está, na verdade, pensando: preciso criar uma view. No Drupal, uma view é, como dito, uma consulta. Na verdade você pode ter mais de uma consulta em uma view, como veremos abaixo.

Essa consulta pode listar campos (o que no SQL seria um SELECT por alguns campos), receber parâmetros ou filtros (o que no SQL seriam cláusulas de um WHERE), fazer referências (em SQL seriam joins) e pode ter um limite de itens (em SQL a cláusula LIMIT). O resultado também pode ser ordenado por alguns critérios (o que no SQL é um ORDER BY).

O resultado da view pode ser exibido de várias formas: listas HTML, listas de divs, um slideshow (como o que é mostrado no nosso tutorial), em tabelas HTML e mais uma infinidade de modos. Algumas exibições extras são adicionadas por outros módulos que você pode ir baixando à parte.

Conceitos básicos

O Views é um módulo muito grande e tem uma grande quantidade de conceitos, configurações e opções. Eu vou listar alguns aqui com uma breve descrição do que se trata para que possamos continuar.

Conceitos básicos do Views
Conceito Breve definição
View Agrega um ou mais display, geralmente por uma funcionalidade ou assunto. Uma view vai estar sempre relacionada a um tipo de objeto tais como conteúdo, usuário, taxonomia, etc.
Display

Cada view pode ter um ou mais display. Esses displays nada mais são do que a materialização dessa view com um conjunto de configurações e opções. Os displays são, de fato, o que o usuário vê. Existe um display especial que é o display padrão, que não precisa ser sempre materializado em algo visível. Ele serve como um guia para os demais displays e geralmente é o primeiro display criado.

Existem vários tipos de display. Vou tratar só de página e bloco.
Campos É a informação que é extraída do objeto em questão (que, como dito, pode ser um conteúdo, usuário, comentário, taxonomia etc.). Nem sempre você fará uso de campos, mas esse é o modo mais flexível de se exibir o conteúdo.
Critério de filtro São condições fixas que você define para que o seu objeto seja exibido. Por exemplo só exibir nodes publicados ou que tenham uma data de publicação até um período específico.
Critério de ordenação Como o nome diz, é como o nosso conteúdo será ordenado.
Filtros contextuais São valores que são passados para essa view (de diversas formas) e que irão servir para compor o filtro do conteúdo. Falarei mais desse item abaixo.
Relacionamentos Quando um objeto está relacionado a outro e você precisa trabalhar com esse segundo, você cria esse relacionamento. Dessa forma os campos do segundo objeto estão disponíveis para serem usados nos outros itens (filtros, campos e etc.).
Outras Existem outras várias opções que não irei cobrir aqui para não ficar mais enfadonho.

O nosso caso

No site que criei para esse tutorial montei duas views. Uma delas para tratar somente o slideshow de fotos do imóvel e uma outra para as demais listagens de imóveis. Essa separação é inteiramente a seu critério. Eu, geralmente tento agrupá-las por assunto. A lógica que utilizei para minha separação foi:

  • View galeria: lista somente um campo dos imóveis com um filtro contextual.
  • View Lista de imóveis: todas as listagens de imóveis (objeto completo) são feitas aqui.

Obviamente você não precisa concordar com a minha visão e nem mesmo fazer assim. O importante é que você tenha os displays contidos nessas views. Se você achar melhor criar uma view para cada display, não tem problema (quer dizer, vai virar uma bagunça, mas é possível).

View Galeria

Vou começar por essa view pois ela só possui um display do tipo bloco.

Você deve se lembrar de quando na parte 3 do tutorial eu comentei que o campo Galeria de imagens é criado por uma view e importado via Display Suite. Pois bem, essa é a view em questão. Aqui utilizei o módulo Views Nivo Slider (criado pelo nosso colega Pedro Faria) para exibir as imagens do imóvel numa bela galeria. Abaixo uma tabela com as configurações que utilizei e uma breve explicação.

View Galeria
Item Opção Descrição
Formato Views Nivo Slider Aqui escolhemos como será exibida nossa view. Como dito usei o Views Nivo Slider
Exibir Campos Escolhi a opção de campos pois só desejo exibir um campo: imagem
Campos Foto Escolhi a foto no formato desejado.
Critério de filtro Publicado e tipo = imóvel Só deve funcionar se o tipo de conteúdo for um imóvel e estiver publicado
Filtros contextuais Conteúdo: NID Esse é o identificador do nosso imóvel. Para funcionar corretamente, ao escolher esse campo você deve configurar a opção "Quando o valor do filtro NÃO está disponível" com "ID do conteúdo pela URL". Assim ele sempre pegará o ID daquele conteúdo sendo visualizado.

Uma vez que a view esteja salva você pode voltar nas configurações do Display Suite (vide parte 3) e adicionar um campo do tipo bloco com esse display. Assim você tem como ir às configurações de exibição de campos do seu imóvel e adicionar esse novo campo ao topo da exibição do imóvel. O resultado é a tela de cada imóvel com uma galeria mostrando todas as imagens.

View Lista de imóveis

Essa view é um pouco mais complexa que a primeira. Ela possui quatro displays que descrevo sucintamente abaixo.

Imóveis por tipo

Se você já viu o site demonstração que montei, verá que na página inicial há uma separação (feita com o módulo Panels e comentado mais para a frente) de imóveis por tipo. Esse display é responsável por exibir somente imóveis de um determinado tipo (casa, apartamento, etc.).

Isso é feito com um filtro contextual semelhante ao da view galeria acima. A diferença, é claro, está no campo. Ao invés de utilizar o campo Conteúdo: NID, utilizei o campo Conteúdo: Tipo do imóvel (esse campo, se você se lembra, nós criamos na parte 2).

Outra diferença é que não escolhi o formato Views Nivo Slider, mas sim Lista sem formatação, uma vez que vou simplesmente exibir os campos e não fazer slideshow.

Slideshow de imóveis

Esse display de bloco é muito semelhante ao da galeria. As diferenças são: não há filtro contextual pois vou mostrar todos os imóveis (limitados a 10 por vez); e vou exibir somente a primeira imagem de um imóvel.

A configuração para exibir apenas a primeira imagem do imóvel é feita no campo de foto. Há uma opção chamada "Multiple field settings" que você deve marcar o item "Mostrar todos os valores na mesma linha" e em seguida escolher um limite definido na opção "Mostrar X valor(s) começando de Y" conforme imagem abaixo.

Imagem com descrição

Encontre um imóvel

Esse display é o único que é do tipo página e, portanto, é o único que tem um endereço. Você pode dar o endereço que você quiser, desde que ele não exista (senão haverá um conflito). Esse display é utilizado como página de busca de imóveis. Defini alguns campos que gostaria de deixar o usuário utilizar para pesquisa e exibo uma lista de imóveis baseado nesses campos.

Para fazer o efeito de formulário de pesquisa você deve marcar nos critérios de filtro quais campos devem estar expostos para o usuário através da opção "Expor este filtro para visitantes, para permitir que eles o alterem". Para fazer exibição com checkboxes para o filtro "Tipo de imóvel" eu utilizei o módulo Better Exposed Filters que agrega algumas novas opções.

Um último detalhe foi que eu mandei os filtros expostos serem exportados para um bloco, ao invés de aparecer no topo da página. Você faz isso marcando a opção "Formulário exposto no bloco" como sim. Depois basta posicionar o bloco como achar melhor.

Imóveis por corretor

Semelhante a galeria, esse display foi usado para ser anexado a um tipo de conteúdo. Então ele é um display de bloco, que será usado no Display Suite e depois agregado a meu tipo de conteúdo Agente.

Esse display lista os imóveis de um corretor que é passado via Filtro Contextual com o campo Conteúdo: Agente. Assim toda vez que você estiver vendo um agente esse display é executado e lista os imóveis dele. A posição onde esses imóveis irão aparecer você define na configuração de exibição de campos do seu Agente.

Finalizando

O Views é um dos, senão o mais, poderoso dos módulos para o Drupal. Praticamente qualquer site que você vá fazer precisa dele e é de suma importância que você aprenda usá-lo.

É importante notar que os usos dado aqui são simples mas envolvem conceitos importantes. Certamente em sites mais complexos, novos elementos e talvez até alguns módulos extra serão necessários para se obter o resultado desejado. Por exemplo, não cheguei a usar nenhum relacionamento, mas esse é um dos recursos mais importantes do Views. Talvez num tutorial futuro eu o aborde.

Espero que agora as coisas estejam fazendo um pouco mais de sentido.

Acredito que a próxima parte será a penúltima dessa série de tutoriais e assim teremos o site inteiro coberto.

Até semana que vem.

05 de Setembro de 2012

Tutorial: Criando um site de imobiliária com Drupal - parte 4

Drupal, Drupal 7, Tutorial, Imobiliária

Essa é a quarta parte da série de tutoriais sobre como criar um site de imobiliária com Drupal. A parte anterior está aqui.

Para essa parte resolvi fazer um vídeo com um resumo do que já falei até agora. Semana que vem volto com a parte escrita e com um tópico novo.

Como de costume, se você tem alguma dúvida, crítica ou sugestão, comente aí.

Semana que vem estarei de volta.

Update: parte 5 no ar

28 de Agosto de 2012

Tutorial: Criando um site de imobiliária com Drupal - parte 3

Drupal, Drupal 7, Tutorial, Imobiliária

Hoje vamos dar continuidade ao tutorial de como criar um site de imobiliária com o Drupal. Se você chegou agora, você pode ir para a parte 1 ou para a parte 2 para não ficar perdido.

Essa parte do tutorial vou dedicar a um único, mas complexo módulo: Display Suite.

Propósito

Toda vez que você precisa exibir um conteúdo você se depara com um problema: não consigo formatar todos os campos sem ter que mexer no tema. Se, por exemplo, você quer omitir a data, mas exibir o nome do autor, o modo tradicional é editar um template. O Display Suite vem para resolver esse problema.

O Display Suite é um módulo que te ajuda reformatar os campos de um conteúdo via interface. Se você já usou o Drupal você deve estar pensando: opa, mas o Drupal já me deixa fazer isso. Isso é verdade, mas o Display Suite vai além. Ele desmembra vários campos que você só tem controle via template (como o exemplo acima) e ele permite que você formate a exibição em layouts pré-definidos ou personalizados (via Panels).

Versões

No site que fiz trabalhei somente com Drupal 7. No momento que escrevo, para essa versão do Drupal, temos duas opções para o Display Suite: 7.x-1.5 e 7.x-2.0-beta2. Elas tem algumas diferenças que você pode ver aqui. Em resumo a versão 7.x-2.0-beta2 é a que está sendo desenvolvida e a outra não, mas somente a 1.5 tem suporte à visualização no estilo do módulo Panels.

Uma coisa muito importante é que você NÃO deve fazer o upgrade de uma versão para a outra senão você irá quebrar o seu site. Então antes de começar a trabalhar, escolha a versão que melhor se adéqua ao que você precisa. Nos meus exemplos vou mostrar a versão 7.x-1.5.

Submódulos

O Display Suite vem com alguns submódulos por padrão: Extras, Forms e Search Display.

Extras

Esse módulo, como o nome diz, habilita algumas funcionalidades além do que o Display Suite já trás. Elas não são específicas como os outros dois módulos. Uma das funcionalidades desse módulo é que ele habilita a possibilidade de personalizar cada node individualmente com o Display Suite. Se você verificar verá que há muito mais.

Forms

Se habilitar esse módulo você tem a possibilidade de utilizar o Display Suite para reformatar os formulários. Basicamente é a mesma coisa que você faz com o a exibição dos campos, mas dessa vez nos formulários. Não utilizo normalmente esse módulo pois gosto dos formulários como eles são.

Search Display

O Drupal, por padrão, já deixa que você personalize a visualização do resultado de pesquisas, mas com esse módulo você ganha ainda mais opções de personalização. Então se você precisa modificar como o resultado das pesquisas no seu site são exibidas, esse módulo vai te ajudar.

Visão geral

Imagem da tela do Display Suite

Acima você pode ver a tela de configurações do Display Suite (com o módulo Extras habilitado). Cada item desses dá uma opção a mais para você estender o Display Suite.

Campos

Você adiciona novos campos que ficam disponíveis para exibição no seus tipos de conteúdo. Esses campos podem ser blocos, podem ser execução de algum código PHP ou mesmo uma chamada a uma variável ou função do Drupal. No nosso exemplo vamos utilizar dois blocos, um para cada tipo de conteúdo.

Estilos

Você pode definir classes CSS que serão aplicadas em regiões ou nos seus campos.

Extras

Como expliquei acima são as opções do submódulo Extras.

Layout

É a gestão dos layouts propriamente dita. Veremos mais a seguir.

View modes

Você pode adicionar outros módulos de visualização além dos existentes (Conteúdo completo, Chamada, Resultado de busca e etc.). Isso pode depois ser chamado em locais específicos via código, por exemplo.

Emergência

Caso o seu Display Suite comece a dar algum problema, você deve ir a esse lugar.

Na prática

Para montar a visualização de imóvel que você vê no site de exemplo eu utilizei o layout Duas Colunas Empilhadas. Esse layout me dá um cabeçalho, duas colunas no meio e um rodapé. Assim eu distribui meus campos da seguinte forma:

Disposição dos campos
Região Campo Descrição
Cabeçalho Galeria de imagens Um bloco criado numa view e transportado para o Display Suite utilizando a funcionalidade de Campos citada acima.
Esquerda Descrição do imóvel A descrição do imóvel. O campo body.
Direita Informações do imóvel Field Group. Um fieldset para agrupar os dados do imóvel.
Direita Código do imóvel Campo sem configuração adicional.
Direita Ano de construção Campo sem configuração adicional.
Direita Modalidades Para exibir esse campo, utilizei o módulo Textformatter separado por vírgula.
Direita Tipo de imóvel Campo sem configuração adicional.
Direita Área total Formatado numérico.
Direita Área útil Formatado numérico.
Direita Preço Formatado numérico.
Direita Preço por m² Campo sem configuração adicional.
Direita Quantidade de quartos Formatado numérico.
Direita Quantidade de banheiros Formatado numérico.
Direita Vagas de garagem Formatado numérico.
Rodapé Endereço e mapa Field Group que agrega os dois campos seguintes.
Rodapé Endereço do imóvel Campo de endereço configurado padrão.
Rodapé Mapa Mapa configurado como Geofield Map o que me dá o mapa renderizado.
Rodapé Agente Fieldgroup que contém os dados do agente
Rodapé Agente Como esse campo foi feito com o Entity Reference, pedi para renderizar o node inteiro (rendered entity).

Em suma foram essas as configurações que fiz. Para os Field Group eu configurei para que eles fiquem sempre abertos, mas isso fica a seu critério.

Como não habilitei comentários, também não formatei a exibição deles, mas você pode, como dito anteriormente, usar o Display Suite para personalizar a visualização de qualquer entidade.

Como comentei na tabela acima, o campo Galeria de imagens foi feito utilizando-se a funcionalidade de Campos do Display Suite. Esse é o recurso mais avançado do Display Suite que utilizei nesse tutorial. Eu vou detalhá-lo melhor quando for comentar do módulo Views. Mas essencialmente ele é uma view com display de bloco que recebe como parâmetro o node atual e carrega, utilizando o Views Nivo Slider, as imagens desse imóvel. Calma, parece mais complicado do que realmente é. Vai fazer sentido quando a parte que trata de Views desse tutorial for publicada.

Finalizando

Depois do que comentei nesse tutorial, deixo para você a tarefa de pensar na visualização do tipo Agente. Como comentário ressalto que os imóveis do corretor é uma view semelhante à das imagens do imóvel.

Semana que vem teremos mais uma parte desse tutorial. Tenho tentado ser breve e não encher o tutorial com muita configuração. A idéia é ir mostrando os pontos chaves. Se você sentir dificuldade em entender algo, comente aí que vou explicando.

Até semana que vem!

Update: parte quatro já no ar!

21 de Agosto de 2012

Tutorial: Criando um site de imobiliária com Drupal - parte 2

Drupal, Drupal 7, Imobiliária, Tutorial

Como prometido semana passada, essa é a segunda parte do tutorial sobre como criar um site de imobiliária com o Drupal. Se você perdeu a primeira parte, você pode ver aqui.

Instalação

Nesse tutorial eu não vou cobrir a instalação de módulos, temas e nem a instalação do Drupal. Vou comentar apenas quais módulos instalei e vou dar uma passeada nas configurações que fiz para cada módulo. Se você ainda não sabe como instalar o Drupal você pode aprender no vídeo que gravei aqui. Se você não sabe como instalar módulos e temas você pode consultar a documentação oficial.

Arquitetura

Uma vez que você tenha o Drupal instalado e funcionando você já tem 2 tipos de conteúdo criados: Artigo e Página. Esses são os dois tipos básicos do Drupal e nós não os usaremos na estrutura do nosso site. Eventualmente você pode querer utilizar esses dois tipos para um blog ou páginas institucionais e por isso é importante mantê-los.

Nós vamos criar dois tipos novos de conteúdo. Um deles será um tipo chamado Imóvel que irá armazenar as informações do nosso imóvel. Esse é o tipo mais importante para o nosso site. O outro tipo que criaremos se chama Agente. Esse segundo tipo vai funcionar como um contato para um dado imóvel. Você pode imagina-lo como sendo uma imobiliária ou um corretor de imóveis que irá vender ou alugar aquele imóvel.

É interessante notar que essa é uma forma de organizar sua informação. Talvez você possa pensar em outras. A beleza do Drupal está na liberdade que você tem para personalizar como você achar melhor. No entanto é fundamental que você analise bem a sua arquitetura para evitar dores de cabeça no futuro. Mudar a estrutura é sempre possível, mas isso sempre vai implicar em mais configuração e geralmente um efeito em cadeia.

Agente

Um agente pode ser responsável por um ou vários imóveis. Um agente também pode ter várias formas de contato como telefone comercial, celular, site etc. Você pode ter vários agentes sem ter relacionamento com nenhum imóvel, mas não iremos permitir imóveis sem um agente.

Campos e módulos usados no Agente
Campo Módulo Descrição
Nome Texto (core) Usaremos o clássico campo de título do Drupal como o nome do nosso agente.
Logo Image (core) Um campo de imagem para conter a logo.
Biografia Texto longo (core) O campo que geralmente é o "corpo" de um artigo usaremos como biografia.
Telefone Phone Para armazenar o telefone utilizaremos o módulo Phone.
Celular Phone Mesma coisa para o celular.
Site Link Para armazenar o site utilizaremos o módulo Link.

Uma pequena nota: o módulo Phone ainda não suporta os telefones com 9 dígitos de São Paulo. Eu enviei um patch que ainda não foi aplicado para resolver esse problema.

Como você pode ver acima, utilizamos 6 campos e 3 deles foram feitos com módulos extra. Você pode está se perguntando o motivo de eu utilizar os módulos Phone e Link e não campos de texto que são padrão do Drupal. A questão é que esses módulos contém configurações e validações específicas para esses tipos de dado. Por exemplo o módulo Phone só aceita números de telefone, e quando os exibe o faz já com tudo formatado.

Criação de um agente:

Tela de criação de agente

Estrutura de campos de um agente:

Estrutura do tipo Agente

Configurações do campo de telefone:

Estrutura do campo do tipo phone

 

Imóvel

O tipo imóvel é um pouco mais complexo que o tipo Agente. Uma vez que o nosso negócio é gestão de imóveis, ele é o nosso objeto principal. A sua estrutura deve comportar todas as informações pertinentes a um imóvel. No meu modelo escolhi alguns campos que acho adequados quando imagino alguém indo buscar um imóvel. Vejamos os campos que utilizei:

Campos e módulos usados no Imóvel
Campo Módulo Descrição
Título Texto (core) Campo de título. Não faz muito sentido para um imóvel, mas pode servir como propaganda.
Código Texto (core) Um campo para armazenar um código. Pode ser usado em buscas.
Descrição Texto longo (core) Descrição detalhada do imóvel
Fotos Imagem (core) Número ilimitado de fotos de um imóvel.
Tipo de imóvel Listagem (core) Define se é uma casa, apartamento, terreno, etc.
Modalidade Listagem (core) Define se é um imóvel para aluguel ou venda ou os dois.
Endereço Address Field Usei o Address Field pois ele já provê o endereço completo o os dados armazenado são a base para o mapa.
Área total Ponto flutuante (core) Área total do imóvel
Área útil Ponto flutuante (core) Área privativa
Preço Ponto flutuante (core) Preço em reais.
Preço por m² Computed Field O Computed field faz um cálculo dividindo o preço pela área total e nos dá o prexo por m².
Ano de construção Inteiro (core) O ano que o imóvel foi construído.
Quantidade de quartos Inteiro (core) Quantos quartos tem no imóvel.
Quantidade de banheiros Inteiro (core) Quantos banheiros tem no imóvel.
Vagas de garagem Inteiro (core) Quantas vagas de garagem.
Mapa Geofield O Geofield gera um mapa baseado em vários tipos de dado. Aqui usamos o endereço do imóvel.
Agente Entity Reference O Entity Reference no Drupal 7 faz o papel do Node Reference no Drupal 6 só que para qualquer entidade.

Também enviei um patch para o Address Field para que ele aceite a formatação dos endereços brasileiros corretamente.

O interessante a se observar no tipo imóvel é que ele tem 2 campos que o usuário não preenche: Preço por m² e Mapa. Esses dois campos são derivados de outros campos. Como explicado acima, o Preço por m² calcula uma informação utilizando Computed Field e o Mapa (Geofield) consome os dados geográficos gerados pelo Endereço (Address Field).

Se você observar bem nas screenshots abaixo vai perceber que alguns campos como as áreas e os quartos, banheiros e vagas de garagem estão agrupados. Isso é feito utilizando o módulo Field Group. Esse módulo provê o agrupamento de campos, tanto na tela de criação/edição quanto na tela de exibição. Isso é muito útil quando você tem informações semelhantes e que acha necessário organizar melhor na tela.

Criando um imóvel

Criando um imóvel

Estrutura de um imóvel

Estrutura de um imóvel

Configurações

Como disse, não vou comentar tudo que se pode configurar. Escolhi alguns itens que acho interessante.

Endereço

Como dito, o campo endereço foi criado usando o Address Field. Esse módulo te dá a possibilidade de adicionar um campo de endereço já sub-dividido em Logradouro, Cidade, CEP, Estado e país (opcional). Ele também salva essas informações no formato xNAL. O interessante é que você pode utilizar esse campo para múltiplos países, e ele irá renderizar o conjunto de campos de acordo com o país. O fato de gravar os dados no formato xNAL é que o torna exportável para mapas.

O módulo Address Field, na sua versão atual, não está bem adequado para o endereço brasileiro, por isso envie esse patch para melhorar um pouco.

Preço por m²

Esse campo, como dito acima, é um campo processado com o módulo Computed Field. Esse módulo permite que você pegue o conteúdo de outros campos e faça processamento e apresente essas informações. É muito útil quando você já tem a informação mas ainda requerem cálculos para exibir e você não quer criar um módulo só para isso. Abaixo você pode ver o código que utilizei:

<?php
$area = array_pop(array_pop(field_get_items($entity_type, $entity, 'field_area')));
$preco = array_pop(array_pop(field_get_items($entity_type, $entity, 'field_preco')));

if ($preco > 0)  {
  $entity_field[0]['value'] = number_format(($preco / $area), 2, ',', '.');
} else {
  $entity_field[0]['value'] = 0;
}

Mapa

Esse campo, como descrito, é usado para exibir o mapa com o endereço provido pelo campo de endereço. Ele tem algumas configurações mas as mais importantes são:

  • Geocode from field - que você deve escolher de qual campo virá a informação de endereço.
  • Geocoder - qual serviço de mapa você vai usar para renderizar o mapa em si.

Agente

Esse campo é o que faz o link entre um imóvel com o Agente. O que é importante configurar nesse módulo é:

  • Target type - O tipo de entidade ao qual devemos fazer link. No caso o nosso agente é um node, então é isso que escolhemos.
  • Entity selection mode - Como você quer fazer para encontrar o conteúdo. Usei o Single para não precisar usar uma view.
  • Target bundles - Como escolhemos o node como target type, aqui irá listar apenas os tipos de node o que iremos escolher agente, já que esse é o tipo que desejamos fazer relacionamentos.

Conclusão

O ponto que você deve dar mais atenção na hora de criar um site é a arquitetura. Saber escolher os campos e os tipos de campos é fundamental para evitar retrabalho e dores de cabeça no futuro. Existem módulos para vários tipos de campos que facilitam nossa vida. É muito importante você dar uma olhada nos repositórios oficiais do Drupal para encontrar aqueles que melhor se adequem às suas necessidades.

Nós vamos parar por aqui e semana que vem continuamos com um novo tópico. Lembro que você pode acessar o site de demonstração da imobiliária aqui. Se você tiver alguma dúvida, envie um comentário que irei respondendo por aqui.

Até semana que vem.

Update: A parte 3 já está no ar.

14 de Agosto de 2012

Tutorial: Criando um site de imobiliária com Drupal - parte 1

Drupal, Drupal 7, Tutorial, Imobiliária

Há um bom tempo venho querendo escrever um tipo específico de tutoriais. Tutoriais que abrangem uma funcionalidade comum para muitas pessoas. Eu pensei em vários tipos de sites e funcionalidades e acabei escolhendo um que seja simples o suficiente para um iniciante com Drupal começar, e que tenha pontos interessantes para quem já tem algum tempo de estrada com o Drupal.

Seja bem vindo ao primeiro tutorial de uma série (não sei ainda de quantos) sobre como criar um site de imobiliária com o Drupal. A minha idéia é escrever alguns artigos mostrando pontos importantes na hora de criar um site com tais funcionalidades.

Screenshot do site

Disclaimer

Antes de começarmos, um alerta: quando se trabalha com Drupal, não existe apenas um único modo de se fazer uma coisa. Para criar uma funcionalidade você pode criar seu módulo, usar um serviço de terceiro ou usar várias combinações de módulos. O modo que vou utilizar aqui é o que acho mais simples sem que você precise escrever nenhum código, o que dá a oportunidade para quem não é programador também consiga segui-lo. Se você prefere fazer de outra forma e quer contribuir, deixe um comentário :-)

Introdução

Como você pode ver, esse é um tutorial sobre Drupal. Para você que está chegando aqui agora, e ainda não conhece aqui vai uma brevíssima descrição do que é o Drupal. Para saber mais, recomendo a leitura da documentação oficial.

O Drupal é um sistema CMS (sigla em inglês que significa Sistema de Gerenciamento de Conteúdo), o que quer dizer que ele é uma ferramenta para criar conteúdo na Internet. Se você já utilizou o Wordpress, você tem uma vaga idéia do que é o Drupal, uma vez que o Drupal tem muito mais funcionalidades que simplesmente um blog (que é a utilidade do Wordpress). Em suma, o Drupal é a base para a criação de um site dinâmico na Internet.

O Drupal funciona como um Lego. Tal como o famoso brinquedo, ele vem com um conjunto básico de peças que, à medida que você vai vendo a necessidade, pode receber adições. Quando você instala o Drupal pela primeira vez você já tem funcionalidades de blog, fórum, enquete e mais uma série de outras coisas básicas. Você também já tem pronto para sair usando um controle de acesso muito flexível e granular, o que te permite um grande poder de personalização de acesso.

Como dito, o Drupal funciona como um Lego onde podemos ir adicionando novas peças para formar um novo item. No Drupal essas peças são chamadas de Módulos. Atualmente existe milhares de módulos que você pode utilizar para fazer sites de todo tipo. Nesse tutorial iremos utilizar alguns desses módulos.

Módulos usados

Quanto mais você usa o Drupal, mais você percebe que ele é totalmente dependente dos seus módulos extra (ou como chamamos, módulos de terceiros). Ao contrário de outras comunidades como Joomla! e Wordpress, a maioria esmagadora de módulos para o Drupal são gratuitos. Esses módulos estão disponíveis para download, geralmente, na página oficial do Drupal.

Para criar o site da nossa imobiliária utilizaremos aproximadamente 25 módulos extra. Aqui vou dar uma visão geral dos principais e, à medida que eu for comentando as funcionalidades, vou introduzindo os demais módulos.

Views

Esse é o módulo de terceiro mais importante do Drupal. Tão importante que há uma força-tarefa para que ele se torne parte integrante do Drupal 8 (que é a próxima versão do Drupal).

De forma simples o Views é um módulo para que consigamos fazer extrações de conteúdo ou usuários do nosso site. Então sempre que você deseja exibir algum conteúdo que já foi enviado para o seu site, provavelmente o que você quer é utilizar esse módulo. Exemplos de uso do Views: uma galeria de imagens, a listagem de posts de um blog, um feed RSS, uma lista de usuários do site, uma lista de comentários de uma determinada página e assim por diante.

Nós vamos trabalhar bastante com o Views e eu vou tentar dedicar um tutorial só para ele.

Panels

A principal funcionalidade do Panels é a criação de páginas personalizadas. Eu costumo chamar de página em blocos, mas você pode chamar como quiser ;-) Ele é um módulo muito versátil para essa funcionalidade. Ele já vem com alguns layouts pré-definidos, mas você pode montar os seus sem muito esforço sempre pela interface Web do módulo.

O Panels é um módulo que é muito mal visto por muitos pela grande quantidade de código HTML que ele gera. Da minha parte eu gosto de usá-lo sempre que quero fazer uma página inicial diferente do padrão de blog. Como dito no início desse artigo, existem infindáveis modos de se fazer a mesma coisa e você pode escolher outra se você desejar.

A integração do Panels com o Views também é algo que me agrada bastante. Essa integração torna os dois figurinhas carimbadas em vários projetos que eu trabalho.

Display Suite

O Display Suite é o mago da personalização de nodes. Com ele você consegue modelar a visualização de um conteúdo de formas variadas. Você pode, por exemplo, dividir a exibição de uma página em blocos ou colunas, omitir campos, personalizar a exibição de determinados campos e etc. Ele possui uma integração com o módulo Panels caso você queria uma edição mais user friendly. Esse é outro módulo que está sempre na minha toolbox.

Você pode optar por não usar esse módulo e fazer tudo o que ele faz através de templates, mas para quem não quer mexer com código, esse é um módulo imprescindível.

Pathauto

Se você quer que seu site seja encontrado e bem posicionado nos mecanismos de busca, o primeiro passo é instalar o Pathauto. O Pathauto pega o título (ou qualquer outra variável que você quiser) e monta a URL dos seus conteúdos automaticamente. Para mim, depois do Views, esse é o módulo de terceiro mais importante do Drupal.

Usar o Drupal sem instalar o Pathauto é quase um sacrilégio.

Outros módulos

Nessa série de tutoriais vou usar outros módulos como o Views Nivo Slider, Colorbox, Wysiwyg, IMCE, Addressfield e etc. Como dito anteriormente, à medida que for usando essas funcionalidades, vou comentando sobre cada módulo.

Próximos passos

Esse primeiro tópico termina aqui. Ele é mais para servir como um teaser. Semana que vem teremos a primeira intervenção "mão na massa". Iremos instalar o Drupal, baixar os módulos e configurar o básico. Nas semanas que virão irei passar por os demais itens que compreendem a criação integral do site.

Para quem quiser ir vendo uma demonstração de como o site vai ficar pode acessar o site que criei só para isso. Esse site deve mudar à medida que eu for escrevendo essa série, então não se prenda muito no que você vir ali.

Abaixo também está o Makefile básico desse projeto. Nele dá para você ter uma idéia de como o site irá evoluir e se você quiser, já ir baixando e instalando os módulos.

Até semana que vem!

Update: Confira a segunda parte aqui

AnexoTamanho
Binary Data Makefile do projeto838 bytes
03 de Agosto de 2012

Site atualizado e novo tema

Drupal, Drupal 7, Atualização, Migração

Olá,

Esse é um post rápido para comentar que migrei meu site todo para Drupal 7 e aproveitei para fazer um tema novo.

A migração em si foi bastante simples, padrão do Drupal. Para quem tem curiosidade, o método que eu utilizo é o seguinte:

  • Faço uma cópia local do site
  • Desabilito todos os módulos extra
  • Volto para o tema padrão do Drupal
  • Rodo a atualização para núcleo do Drupal
  • Atualizo cada módulo individualmente
  • Rodo a atualização de banco de dados para cada módulo
  • Aplico novamente o tema (um novo)
  • Envio o site novamente para o servidor

Em resumo foi o que fiz. Tive um pequeno problema com o módulo Internationalization (i18n) pois ele tem uma sequência na ordem dos módulos que devem ser atualizados. Nada demais, só perdi algumas configurações que acabei refazendo.

Outra coisa que fiz foi desabilitar o módulo Contact (padrão do Drupal) em favor do Webform. No Drupal 7 o Contact é pouquissimo personalizável (do ponto de vista de tema também) e acabei ficando com o Webform. Sei que o objetivo principal do Webform não é ser usado para isso, mas ele funciona bem e assim tomei essa decisão. Num futuro próximo vou reavaliar um outro módulo mais direcionado para essa funcionalidade (talvez até criar um, se for o caso).

A outra coisa que fiz foi um tema. O meu tema se chama Fresh Green. Como de costume resolvi abrir o tema para que outras pessoas possam estudar e/ou usar. O tema está na minha conta do Github. Estou avaliando se envio para o Drupal.org ou não. Update: decidi por enviá-lo para o Drupal.org e você pode baixá-lo.

O Fresh Green não funciona em versões antigas de navegadores, assim, se você quer utilizá-lo, tenha em mente que só vai funcionar no IE >= 9, Firefox >= 14, Chrome >= 19.

É isso, espero que gostem e se virem algum problema no site, por favor, não deixem de me mandar uma mensagem.

Páginas