Quote Request Pro - Formulário de pedido de orçamento, bloco lateral e botão flutuante para PrestaShop

O comprador que não encontra um preço

Há catálogos que não conseguem mostrar um preço fixo. Fabrico por medida, tarifas por volume e B2B, tudo o que se orçamenta por projeto: o valor depende da resposta a uma pergunta que ainda ninguém fez. Quem chega a essa página tem duas hipóteses: adivinhar ou ir-se embora.

Este módulo dá-lhe uma terceira. Um formulário curto na página de produto transforma o "não encontrei o preço" num contacto com nome e endereço de e-mail.

Dois sítios para perguntar, um só formulário

O formulário aparece em dois sítios que partilham o mesmo código, para que o visitante use aquele que tiver à vista.

Um bloco lateral encaixa na coluna esquerda ou direita do seu tema — a instalação do módulo regista as duas. Um botão flutuante fica sobreposto à página e abre o formulário com um toque.

O botão flutuante conta mais do que parece, e vale a pena dizer com franqueza porquê. Um bloco lateral só pode aparecer onde o seu tema desenha de facto uma coluna. No Hummingbird, o tema predefinido do PrestaShop 9, a página inicial e as páginas de produto ocupam toda a largura e não têm colunas nenhumas: um bloco associado a uma coluna não tem onde se mostrar precisamente nas páginas em que alguém está a decidir se lhe pede um preço. O botão flutuante não depende de nenhuma coluna, por isso cobre essas páginas. Se o seu tema tiver uma coluna lateral, use os dois; se não tiver, o botão flutuante é o módulo. Em qualquer dos casos tem a sua própria definição de ligar/desligar.

Peça só aquilo de que precisa mesmo

Três coisas são sempre obrigatórias: a descrição do produto, um endereço de e-mail para responder e a caixa de consentimento. Tudo o resto é um interruptor na página de definições: o nome do visitante, a morada, a localidade, o telefone, a quantidade pretendida, o destino do envio, uma escolha de urgência, uma caixa "já tenho conta PayPal" e uma caixa "esta seria a minha primeira encomenda". Nome, morada, localidade, telefone, quantidade, destino e urgência vêm ligados; as duas caixas vêm desligadas.

Desligue tudo aquilo sobre o que não vai agir. Um formulário com quatro perguntas é concluído mais vezes do que um com nove, e nada do que desligar fica guardado, mesmo que alguém tente enviá-lo à força.

Clientes com sessão iniciada não são questionados duas vezes

Se o cliente tiver sessão iniciada, o módulo vai buscar o nome e o e-mail à conta dele e nem sequer mostra esses campos. Aos visitantes não identificados são pedidos os dois. O formulário que um cliente habitual vê é genuinamente mais curto do que aquele que um desconhecido vê.

Todos os pedidos ficam guardados, não apenas enviados

Os pedidos são escritos na tabela de base de dados do próprio módulo antes de se tentar enviar qualquer e-mail, e ficam listados no separador Quote Requests ("Pedidos de orçamento") da página de configuração. Pode filtrar por Todos, Novos ou Tratados, avançar de vinte em vinte, abrir qualquer pedido num painel de detalhe, marcá-lo como tratado ou devolvê-lo a novo, e eliminá-lo.

O painel de detalhe mostra tudo o que o visitante enviou, com etiquetas para o que se lê num relance — Urgente, Tem conta PayPal, Cliente pela primeira vez — além do texto completo do produto e do endereço IP de onde chegou o pedido.

É esta a parte que faz do módulo uma ferramenta e não um simples formulário. Um servidor de correio em baixo num dia mau não lhe pode fazer perder um contacto: o pedido já está guardado, e um envio falhado é escrito nos registos em vez de ser mostrado ao cliente.

Dois e-mails, não um

A notificação ao comerciante segue para os endereços que indicar — escreva vários, separados por vírgulas, e todos a recebem.

O cliente também recebe um e-mail. Confirma-lhe que o pedido chegou e repete o que ele pediu, que é a diferença entre um comprador que espera pela sua resposta e outro que assume que o formulário estava avariado e compra noutro sítio.

Um cartão de aviso no Dashboard

Quando há pedidos de orçamento à espera, aparece um cartão no topo do Dashboard (painel de controlo) do back office com a contagem e uma ligação direta para a lista. Desaparece sozinho assim que todos os pedidos estiverem marcados como tratados ou eliminados, por isso funciona como indicador de tarefas e não como mobília permanente.

Está ligado ao hook dashboardZoneOne de propósito. A escolha óbvia, displayDashboardTop, acaba por disparar na maioria das páginas de administração que mostram uma linha de KPI — a de Desempenho incluída —, pelo que o cartão o teria seguido por todo o back office em vez de ficar no Dashboard, que é o lugar dele.

Sem CAPTCHA, e isso não é uma cedência

A versão 1.x trazia uma pergunta de matemática. A versão 2 elimina-a e protege o formulário de três maneiras, nenhuma delas visível para um visitante real:

Um campo honeypot que as pessoas nunca veem e os robôs preenchem — e, quando vem preenchido, o formulário responde educadamente que correu tudo bem e descarta o envio em silêncio, para que o robô não perceba que foi apanhado. Um token de tempo assinado, uma assinatura HMAC-SHA256 sobre o instante em que o formulário foi gerado, de modo que o envio é rejeitado se chegar em menos de três segundos após o carregamento da página, ou mais de uma hora depois. E um limite de pedidos por IP, que aceita no máximo cinco pedidos por hora da mesma ligação.

Não há nada para configurar nem nenhum enigma para resolver.

Continua a funcionar com o JavaScript desligado

Com o JavaScript disponível, o formulário é enviado em segundo plano e dá lugar a uma mensagem de confirmação. Sem ele, o formulário é submetido normalmente, o servidor trata dele exatamente da mesma maneira e o visitante regressa à página de onde veio, com uma mensagem de sucesso ou de erro no topo.

O endereço de regresso é verificado contra o domínio da sua própria loja antes do redirecionamento, para que o formulário não possa ser usado para atirar alguém para outro site.

Uma imagem promocional e as suas próprias ligações

A página de definições aceita uma imagem promocional opcional, carregada diretamente, sem caminhos de ficheiros para descobrir. É ajustada para caber dentro de 400×280 píxeis mantendo as proporções e é recodificada em vez de ser simplesmente copiada, de forma que nada possa ser contrabandeado para o seu servidor colado a um ficheiro de imagem válido. Aceita JPG, PNG, GIF e WEBP até 4 MB.

Ao lado ficam três ligações, cada uma definida por idioma: uma ligação Saber mais para uma página que explique como funcionam os seus orçamentos, e os URL dos seus Termos e Condições e da sua Política de Privacidade. Se deixar o campo dos termos vazio, o módulo liga à página CMS de condições já configurada na sua loja. Se deixar o da privacidade vazio, essa ligação simplesmente não é mostrada. A caixa de consentimento é sempre mostrada e sempre obrigatória.

Multiloja, e um módulo que se repara sozinho

As definições são guardadas por loja, por isso cada loja de uma instalação multiloja tem os seus destinatários, a sua seleção de campos e as suas ligações. Se, por alguma razão, uma loja ficar sem linha de definições — porque foi acrescentada depois da instalação, ou por outro motivo qualquer —, é criada na hora, em vez de o formulário se avariar sem aviso para essa loja.

Abrir a página de configuração também volta a fixar os hooks e o esquema de base de dados do módulo e sincroniza o número de versão guardado. O botão Atualizar da lista de módulos do PrestaShop pode falhar por razões alheias a qualquer módulo, por isso, em vez de depender dele, o módulo converge para o estado correto sempre que um administrador o abre de facto.

Compatibilidade

PrestaShop 1.7 até 9, em oito idiomas: neerlandês, inglês, francês, alemão, italiano, polaco, espanhol e turco.

Sejamos claros quanto a uma coisa: o português não está nessa lista. Esta página de produto está em português, mas o módulo não inclui ficheiro de tradução portuguesa — nem o back office nem o formulário apresentado na loja existem em português. Para trabalhar com o módulo, terá de escolher um dos oito idiomas acima. Isto diz respeito apenas à interface do próprio módulo: os textos da sua loja, os seus produtos e tudo o que escreve continuam em português, tal como estão hoje.

Uma segunda ressalva honesta: os modelos de e-mail existem apenas em inglês, francês, espanhol e turco. O formulário que os visitantes veem e todo o back office estão traduzidos nos oito idiomas; os dois e-mails, não.

Cinco hooks padrão, sem overrides e sem modificar o tema. O PrestaShop 1.4, 1.5 e 1.6 deixaram de ser suportados: a versão 2.0.0 abandonou-os, juntamente com o antigo CAPTCHA matemático no navegador e o manual em PDF, substituído pelo separador Tutorial dentro do módulo.

Perguntas frequentes

Os visitantes têm de resolver um CAPTCHA?

Não, e não existe qualquer opção para ativar um. A proteção é um campo honeypot escondido, um token de tempo assinado com HMAC que rejeita envios que cheguem em menos de três segundos ou mais de uma hora após o carregamento da página, e um limite de cinco pedidos por hora a partir do mesmo endereço IP. Um visitante real não dá por nada disto.

Onde aparece o formulário?

Em dois sítios. Um bloco lateral entra na coluna esquerda ou direita do seu tema, e um botão flutuante fica sobreposto à página e abre o mesmo formulário. O botão flutuante tem a sua própria definição de ligar/desligar; o bloco lateral depende de estar associado a um hook de coluna em Design → Posições e de o seu tema desenhar mesmo uma coluna nessa página. No Hummingbird, o tema predefinido do PrestaShop 9, a página inicial e as páginas de produto não têm colunas nenhumas, por isso é o botão flutuante que as cobre. Se o seu tema não mostrar colunas laterais no telemóvel — e muitos não mostram —, o botão flutuante é o que os visitantes vão usar.

O formulário não aparece na loja.

Abra Design → Posições, procure priceandorder e confirme que está associado a um hook de coluna para o bloco lateral e ao hook do rodapé para o botão flutuante. A instalação do módulo associa os dois hooks de coluna, por isso normalmente isto só importa num tema personalizado.

Se o botão flutuante aparece mas o bloco lateral nunca aparece, o hook está provavelmente bem e a razão é o tema: muitos temas desenham apenas uma coluna esquerda, ou nenhuma nas páginas de largura total. O Hummingbird desenha uma coluna esquerda nas páginas de categoria e não desenha coluna direita em lado nenhum. Mova o módulo para a coluna que o seu tema usa de facto e conte com o botão flutuante nas páginas de largura total.

Que campos posso remover?

Todos, exceto a descrição do produto, o endereço de e-mail e a caixa de consentimento. Morada, localidade, telefone, quantidade, destino do envio, urgência, a pergunta do PayPal e a da primeira encomenda são interruptores independentes. O nome do visitante também é um interruptor e é dispensado automaticamente para clientes com sessão iniciada, juntamente com o e-mail deles.

Para onde vão os pedidos?

Para os endereços de notificação que definir — vários, separados por vírgulas, se quiser — e para o separador Quote Requests ("Pedidos de orçamento") da página de configuração do módulo. Aí pode filtrar por Todos, Novos ou Tratados, percorrê-los de vinte em vinte, abrir qualquer um num painel de detalhe, marcá-lo como tratado e eliminá-lo. Os pedidos são guardados antes de qualquer e-mail ser enviado, por isso um problema de correio não pode fazer perder nenhum.

O cliente recebe uma confirmação?

Sim. São enviados dois e-mails: um para si e outro para a pessoa que preencheu o formulário, a confirmar o que ela pediu. O e-mail para o cliente existe em inglês, francês, espanhol e turco.

Não chega nenhum e-mail de notificação.

Verifique primeiro o endereço de destinatário nas definições — se não houver nenhum, aparece um aviso junto ao módulo na lista de módulos. Depois veja a pasta de spam e confirme que o envio de correio funciona de todo em Parâmetros avançados → E-mail. Cada envio falhado fica anotado em Parâmetros avançados → Registos, e o pedido em si está no separador Quote Requests de qualquer forma.

Um visitante diz que o formulário rejeitou o envio dele.

Quase sempre é a proteção antispam automática. O envio chegou menos de três segundos depois de a página carregar, mais de uma hora depois, ou era o sexto a partir daquela ligação na mesma hora. Peça-lhe que recarregue a página e tente outra vez.

Não vejo o cartão de aviso no Dashboard.

O cartão só aparece no próprio Dashboard e apenas enquanto houver, pelo menos, um pedido marcado como Novo. Se há pedidos à espera e mesmo assim ele não aparece, veja em Design → Posições o hook dashboardZoneOne e certifique-se de que priceandorder está lá associado e ativo — isso é controlado de forma independente dos hooks da loja.

Funciona se o visitante tiver o JavaScript desativado?

Sim. O formulário passa a um envio de página normal, o servidor processa-o de forma idêntica e o visitante regressa à página onde estava, com uma mensagem de confirmação ou de erro. Não se perde nada.

A imagem promocional aparece esticada ou é rejeitada.

Não deve aparecer esticada — a imagem é ajustada para caber dentro de 400×280 píxeis com as proporções preservadas, nunca distorcida. As rejeições costumam dever-se ao formato ou ao tamanho: são aceites JPG, PNG, GIF e WEBP até 4 MB.

Falta a ligação para os Termos e Condições ou para a Política de Privacidade, ou está errada.

Defina as duas explicitamente nas definições, por idioma, e comece cada uma por http:// ou https:// — o módulo rejeita qualquer outra coisa. Um campo de termos vazio recorre à página CMS de condições da sua própria loja; um campo de privacidade vazio limita-se a esconder essa ligação.

O que acontece às minhas definições quando atualizo a partir da 1.x?

São migradas automaticamente. Os seus interruptores de campos passam para o novo esquema, o endereço de destinatário mantém-se, a tabela de registo de pedidos de orçamento é acrescentada e as chaves de configuração que sobraram de instalações muito antigas são limpas.