O visitante que nunca preenche um formulário de contacto
Muita gente quer comprar, mas tem primeiro uma pergunta. Um formulário de contacto pede um assunto, uma mensagem e uma referência de encomenda; um número de telefone no rodapé pede que seja o cliente a ligar. Ambos perdem os indecisos.
Este módulo quase nada pede: um nome e um número de telefone ou um endereço de e-mail. O visitante toca num botão, escreve dois campos, e é você quem lhe liga de volta.
Quatro posições, escolhidas uma só vez para toda a loja
Você decide onde fica o formulário entre quatro opções: um separador deslizante na margem esquerda, um separador deslizante na margem direita, uma barra inferior ao longo do fundo da página, ou um botão flutuante. Se optar pelo botão flutuante, uma definição independente coloca-o no canto inferior esquerdo ou inferior direito.
O botão flutuante é a escolha certa se tiver dúvidas. Ao tocar-lhe abre-se um pequeno menu de ações, e é esse menu que abre o formulário numa janela modal — assim nunca compete com o conteúdo da página e comporta-se da mesma forma no telemóvel e no computador. O separador deslizante e a barra inferior escondem elementos de propósito à medida que o ecrã estreita, para que o formulário continue a caber: útil se o seu tráfego for sobretudo de computador, menos se a maioria dos seus visitantes usar o telemóvel.
Sem CAPTCHA, e isso não é nenhuma cedência
A versão 1.x incluía uma pergunta de cálculo que era resolvida e verificada inteiramente no navegador do visitante. Não travava nada e irritava toda a gente.
A versão 2 elimina-a e protege o formulário de três maneiras, todas invisíveis:
Um campo honeypot que os humanos nunca veem e que os bots preenchem. Um token de tempo assinado — uma assinatura HMAC-SHA256 sobre o momento em que o formulário foi gerado — de modo que um envio é rejeitado se chegar antes de dois segundos após o carregamento da página, ou depois de duas horas. E um limite por IP que aceita no máximo cinco pedidos por hora a partir do mesmo endereço.
Não há nada para configurar nem nenhum enigma para um visitante real resolver.
Cada pedido fica guardado, não é apenas enviado por e-mail
Um aviso por e-mail segue para os endereços que indicar. O pedido é também gravado na tabela de base de dados do próprio módulo e listado na página de configuração, onde pode marcar as entradas como lidas ou não lidas, eliminá-las em lote e anexar uma nota privada a qualquer pedido concreto.
Essa lista é a diferença entre uma notificação que lhe pode escapar e um pequeno fluxo de trabalho que consegue mesmo acompanhar.
O que o formulário pede
O nome é sempre pedido. Para além disso, escolhe apenas telefone, apenas e-mail ou ambos, e pode opcionalmente pedir um tipo de pedido, para que o contacto chegue já classificado.
As cores do texto e do fundo são definições, pelo que o widget pode acompanhar o seu tema em vez de destoar dele.
Consentimento e as suas páginas legais
A caixa de consentimento é sempre apresentada — não existe qualquer definição para a desativar. Chega já assinalada e, se um visitante a desmarcar, o servidor rejeita o envio com uma mensagem concreta em vez de o aceitar em silêncio. Pode apontá-la para os seus próprios URL de Termos e Condições e de Política de Privacidade; se deixar esses campos vazios, o módulo liga à página CMS de Termos e Condições já configurada na sua loja.
A versão 1.x tinha aqui, fixa no código, uma ligação para o site de demonstração do fornecedor. Isso desapareceu.
A versão 2 corrigiu várias coisas que falhavam em silêncio
O multiloja não funcionava. A parte pública e o gestor de envios liam sempre as definições da loja n.º 1, independentemente da loja em que o visitante estivesse. Passaram a ler a configuração da loja atual.
Os envios podiam falhar em silêncio. O formulário dava conta de sucesso acontecesse o que acontecesse no servidor. Agora devolve um resultado real, com mensagens por campo para um endereço de e-mail inválido ou para um consentimento em falta.
O e-mail de notificação não encontrava o seu modelo em algumas instalações, porque a diretoria de correio era resolvida em relação ao controlador e não à raiz do módulo.
A inserção dos pedidos construía o SQL por concatenação de texto. Os pedidos passaram a ser gravados através de inserções parametrizadas.
A tabela de armazenamento deixou de ter o nome genérico e propenso a colisões callbacks e passou a wecallyouback_request, sendo as linhas existentes migradas automaticamente na atualização.
Correções para o tema Hummingbird do PrestaShop 9
Vale a pena dizê-lo com clareza se usa o Hummingbird, o tema predefinido do PrestaShop 9.
O botão flutuante e a sua janela modal dependiam dos atributos de dados do Bootstrap 4 (data-toggle, data-dismiss), que um tema Bootstrap 5 ignora — clicar no botão não fazia absolutamente nada. A 2.0.5 reescreveu ambos com o JavaScript próprio do módulo, sem qualquer dependência do jQuery nem do componente modal do tema, pelo que o botão funciona em qualquer tema, seja qual for a sua versão do Bootstrap.
A 2.0.6 evitou que o texto de apelo à ação do botão se repartisse por cinco linhas e corrigiu o ícone, que ficava reduzido a um fio pelo flex-shrink. A 2.0.7 centrou a janela modal na vertical, em vez de a deixar colada ao topo do ecrã.
Um módulo mais leve por dentro
A versão 2 destina-se apenas ao PrestaShop 1.7+; foram removidos todos os caminhos de código 1.4/1.5/1.6 e a pasta backward_compatibility/. Quatro modelos de front office quase iguais — um por versão do PrestaShop — deram lugar a um só, e o CSS e o JS dos separadores deslizantes esquerdo e direito passaram a ficheiros partilhados.
Também desapareceram: a dependência externa dos Google Material Icons (agora SVG em linha), uma etiqueta <script> que apontava em duro para um CDN do jQuery, um antigo manual em PDF, um ficheiro de origem PSD e cinco pastas de idiomas de correio que não eram usadas.
Compatibilidade
PrestaShop 1.7 a 9, em oito idiomas: alemão, espanhol, francês, inglês, italiano, neerlandês, polaco e turco.
Uma nota honesta: o português não está entre esses oito. Esta página está em português, mas o painel do módulo no back office e o formulário que aparece na loja não estão — para o utilizar, escolha um dos oito idiomas acima. Nada disto afeta o conteúdo da sua loja: o que os seus clientes veem no formulário é o que as definições de idioma da sua loja produzirem.
Outra ressalva, com toda a honestidade: o modelo do e-mail de notificação existe apenas em inglês e francês. O formulário que o visitante vê e o back office estão traduzidos nos oito idiomas; o aviso que chega à sua caixa de entrada, não.
Três hooks padrão, sem overrides e sem modificar o tema. Ainda está no PrestaShop 1.5 ou 1.6? Use então a versão 1.x do módulo — a 2.0 e seguintes são só para 1.7+.
Perguntas frequentes
Os visitantes têm de resolver um CAPTCHA?
Não, e não existe qualquer definição para ativar um. A proteção consiste num campo honeypot oculto, num token de tempo assinado com HMAC que rejeita os envios que chegam antes de dois segundos ou depois de duas horas sobre o carregamento da página, e num limite de cinco pedidos por hora a partir do mesmo endereço IP. Um visitante real não vê nada disto.
Onde aparece o formulário?
Onde escolher para toda a loja, entre quatro opções: um separador deslizante na margem esquerda, um separador deslizante na margem direita, uma barra inferior ou um botão flutuante. Uma definição independente coloca o botão flutuante no canto inferior esquerdo ou inferior direito. Se tiver dúvidas, escolha o botão flutuante — abre uma janela modal, por isso a largura da página nunca o afeta.
Uso o Hummingbird no PrestaShop 9 e o botão flutuante não faz nada.
Atualize para a 2.0.5 ou posterior. Antes dessa versão o botão usava os atributos de dados do Bootstrap 4, que os temas Bootstrap 5 ignoram. Agora funciona com o JavaScript próprio do módulo e resulta em qualquer tema. Tenha em conta que o botão é, por desenho, um controlo em dois passos: o primeiro toque abre um pequeno menu de ações, e a entrada do menu abre o formulário.
A caixa de consentimento é opcional?
É sempre apresentada e não existe qualquer definição para a retirar. Chega já assinalada, mas é mesmo verificada: desmarque-a e o servidor recusa o envio com um erro concreto, em vez de o aceitar em silêncio.
O que pede o formulário?
Um nome, mais um número de telefone, um endereço de e-mail ou ambos — à sua escolha. Pode também pedir um tipo de pedido. A caixa de consentimento é sempre apresentada.
Para onde vão os pedidos?
Para os endereços de e-mail de notificação que definir e para uma lista na página de configuração do módulo. Aí pode marcá-los como lidos ou não lidos, eliminá-los em lote e acrescentar uma nota privada a qualquer pedido.
Não chega nenhum e-mail de notificação.
Verifique se está definido um endereço de notificação válido — se não estiver, aparece um aviso junto ao módulo na lista de módulos e cada envio fica registado com o respetivo motivo em Parâmetros avançados → Registos. Se houver um endereço definido e a entrega continuar a falhar, consulte Parâmetros avançados → E-mail e esse mesmo registo.
O formulário não aparece na loja.
Confirme que "Show the form" (Mostrar o formulário) está em Yes e que o módulo está ativado. Num tema muito personalizado, certifique-se de que este chama o hook displayHeader (ou header).
Posso usar a minha própria ilustração?
Sim. Substitua rep_bottom.png, rep_left.png ou rep_right.png na pasta views/img/ do módulo por um PNG do mesmo tamanho.
O texto desaparece em ecrãs estreitos.
É intencional na barra inferior e no separador deslizante, que vão escondendo elementos progressivamente para que o formulário continue a caber. Use antes a posição de botão flutuante se isso não se ajustar ao seu tráfego.
O que acontece aos meus pedidos existentes quando atualizo a partir da 1.x?
São migrados automaticamente. A antiga tabela callbacks é copiada para a nova tabela wecallyouback_request no primeiro carregamento após a atualização, e as suas definições vêm com eles.
Comentários (2)
Não é possível enviar a apreciação da sua avaliação.
Denunciar comentário
Denúncia enviada
O seu relatório não pode ser enviado