Agente revolucionário no modo como passamos a interagir com os websites, o AJAX começou a chamar a atenção no começo dos anos 2000 e hoje é parte integrante da esmagadora maioria das ferramentas online. Neste tutorial aprenderemos a usar a API AJAX do WordPress, mas não sem antes conhecermos alguns conceitos básicos necessários para o entendimento do que é verdadeiramente AJAX.

O que é AJAX no WordPress

Simplificando ao máximo podemos dizer que AJAX é a comunicação (envio de requisição e recebimento de resposta) com o servidor através de javascript, sem a necessidade de recarregar a página. AJAX não é uma tecnologia e sim a mistura de várias, é um modelo ou ainda uma abordagem de arquitetura de software.

Um Pouco de História

AJAX é o acrônimo formado por Asynchronous Javascript and XML, isto é, Javascript e XML assíncronos. O termo foi criado por Jesse James Garrett, cofundador da Adaptive Path, em 2005 para descrever a técnica que já vinha sendo utilizada pelo Google em algumas de suas ferramentas, como a sugestão instantânea de termos na busca do site principal enquanto o usuário digita e as diferentes interações do Google Maps.

No artigo onde usou publicamente o termo pela primeira vez, Garrett chamava a atenção sobre como seria possível inovar na interação dos usuários com os sites, já que a nova técnica tornava desnecessária a atualização completa da página para mudar o conteúdo de apenas algum componente – à medida que o usuário digitava o termo a ser buscado não era preciso recarregar toda a página para atualizar o elemento com as sugestões, assim como não seria possível carregar e enviar para o navegador de uma só vez todas as possíveis sugestões de todas as buscas.

O termo AJAX surgiu pela mesma necessidade de onde surgiram todos os outros termos: ainda não havia nenhuma forma que descrevesse rapidamente a reunião de tantos componentes necessários para o uso da tal técnica, mais ou menos como os apelidos de colégio servem para substituir os nomes e sobrenomes dos alunos. Citando Garrett, “AJAX não é uma tecnologia, na verdade são várias”, e na lista entram HTML, CSS, DOM, XML, XMLHttpRequest e Javascript. Com o avanço do tempo pudemos perceber que o XML cedeu cada vez mais espaço ao JSON, mais enxuto e, por isso mesmo, com melhor performance.

Execução Server-Side vs. Client-Side

Apesar de básico é preciso entendermos perfeitamente a relação entre lado Servidor vs. Lado Cliente. Sendo lado cliente o usuário do site com seu navegador e lado servidor a estrutura onde o site está hospedado, é importantíssimo entendermos que o computador do cliente não recebe nem processa absolutamente nada de PHP – e aqui cabe um aparte: os navegadores por si só são capazes de entender texto plano, HTML, CSS e Javascript.

Recapitulando o funcionamento básico de uma visita a um site temos então:

• O usuário faz uma requisição ao servidor através do protocolo HTTP(S): para ler este artigo você fez uma requisição GET ao entrar no canalwp.com.br;
• O servidor recebe a requisição, que pode ser feita por diferentes métodos como GET e POST, e faz todo o processamento da linguagem server side (PHP, usando aqui a linguagem do wordpress para facilitar o entendimento e simplificar a explicação): o servidor recebeu sua visita no index.php do WordPress, fez todos os includes, acessou o banco de dados e interpretou todo o php;
• O servidor então envia o resultado do processamento para o navegador. Na visita básica este resultado é o HTML do site, já com todas as tags PHP processadas: o servidor pegou todos os echoes, tags abertas e etc e gerou um HTML.
• O navegador recebe e interpreta este HTML, que pode apontar para outros arquivos através de suas tags, como por exemplo <script> e <link>. Caso essas tags demandem, o navegador faz outras requisições para receber os Javascripts e CSS necessários, seguindo o recebido no HTML gerado no passo 2: seu navegador está exibindo esta página baseado no html que você pode ver abrindo o código-fonte .

Estes passos descrevem o modelo básico de navegação, que se baseia em eventos rigorosamente sequenciais e, por isso, é chamado de síncrono. Os passos também deixam claro que depois de entregue o HTML para o navegador não é possível processar mais nenhum código PHP.

Se precisarmos desse processamento devemos recorrer a mais uma requisição para o servidor, o que, nos casos tradicionais, geraria a entrega de mais um HTML completo que significaria uma atualização da página.

No passo 4 notamos que a entrega de um HTML pode gerar várias outras requisições a arquivos javascript ou CSS. Já que passamos pelo assunto é importante dizer que diminuir o número destas requisições é passo fundamental para a melhora na performance do site.

Para mais informações é possível pesquisar nos vários artigos sobre performance aqui no CanalWP.

Exemplo Rápido

O html gerado tem um formulário de contato. Sabendo que não é possível enviar e-mail através de javascript, deduzimos que precisamos enviar os dados fornecidos para um script php de alguma forma. No caso tradicional o action do form seria um php que receberia os dados e geraria um html completo da página incluindo um aviso de sucesso ou erro. Teríamos então:

1. O HTML onde se encontraria o formulário. O formulário apontaria para um PHP, isto é, o <form> tem no action um arquivo PHP, para onde o usuário é redirecionado ao apertar o botão de enviar;
2. Este PHP envia o e-mail durante o processamento da parte server-side e envia para o navegador um outro HTML completo, com <head>, <body> e etc. avisando ao usuário se o e-mail foi enviado ou não.

Assincronismo

O primeiro A de AJAX (asynchronous) vem exatamente desta necessidade: requisições ao servidor que não influenciem no carregamento normal da página, antes pelo contrário, que sejam independentes dele, ou seja, assíncronas.

Responsável pelo envio e recebimento desta transação está o XMLHttpRequest (XHR), objeto Javascript criado pela Microsoft para o Outlook Web Access e adotado posteriormente pelas demais empresas do ramo. Apesar do nome o XHR não lida necessariamente só com XML, a resposta pode ir de um simples texto plano como “OK” até alguma estrutura mais complexa, lembrando que quanto maior for o tamanho da resposta pior será a performance.

Como dissemos anteriormente este é o motivo de vermos cada vez menos respostas em XML em detrimento de respostas JSON, como fica óbvio neste exemplo simples:

XML

<artigos-do-site>​
<artigo>​
<titulo>Este é o título</titulo>​
<texto><![CDATA[Este é o <strong>texto</strong>]]></texto>​
<data-publicacao>2016-06-01</data-publicacao>​
<data-atualizacao>2016-06-01</data-atualizacao>​
<autor>João da Silva</autor>​
</artigo>​
<artigo>​
<titulo>Este é o título</titulo>​
<texto><![CDATA[Este é o texto]]></texto>​
<data-publicacao>2016-06-01</data-publicacao>​
<data-atualizacao>2016-06-01</data-atualizacao>​
<autor>João da Silva</autor>​
</artigo>​
</artigos-do-site> 

JSON

[​
{​
titulo: 'Este é o título',​
texto: 'Este é o <strong>texto</strong>',​
data_publicacao: '2016-06-01',​
data_atualizacao: '2016-06-01',​
autor: 'João da Silva'​
},​
titulo: 'Este é o título',​
texto: 'Este é o texto',​
data_publicacao: '2016-06-01',​
data_atualizacao: '2016-06-01',​
autor: 'João da Silva'​ 
}​
] 

O primeiro tem 511 caracteres contra 326 do segundo, ou seja, a resposta em JSON é 37% menor, mas envia a mesma informação em menor tempo.

Neste cenário teríamos:

• O arquivo onde estaria o <form>, idêntico ao HTML do exemplo anterior;
• Um javascript que “sequestraria” o submit do formulário, e em seu lugar faria uma requisição para o servidor enviando os dados inseridos pelo usuário para um arquivo PHP, esperaria sua resposta e manipularia o DOM para exibir esta resposta da maneira desejada.
• O arquivo PHP que receberia os dados, tentaria enviar o e-mail e responderia se foi possível ou não, através de uma resposta muito menor que um HTML completo. Um simples “OK” ou um objeto JSON com o texto da resposta e seu respectivo status (sucesso ou erro);

Para Facilitar: jQuery

O uso de jQuery hoje é tão difundido que 70% de todos os sites do mundo o usam, e isso é MUITA coisa. Uma versão da biblioteca já é incluída no WordPress (usada largamente no painel), sendo possível incluí-la no tema. Com jQuery, de modo geral, é possível abstrair as diferentes abordagens adotadas pelos navegadores, enxugando significativamente o código e, por isso mesmo, simplificando sua manutenção.

Como dito anteriormente, AJAX é uma mistura de várias tecnologias e o jQuery ajuda demais em pelo menos duas delas: no XHR e na manipulação do DOM. Para exemplificar, segue uma chamada XHR sem jQuery e com:

Sem jQuery

function handler() {​
if(this.readyState == 4 && this.status == 200) {​
if(this.responseXML != null && 
this.responseXML.getElementById('test').firstChild.data) { //successo ​
alert(this.responseXML.getElementById('test').firstChild.data);​
} else {​
return false;​
}​
} else if (this.readyState == 4 && this.status != 200) { //página não encontrada ou erro 
na conexão​
return false;​
}​
}​ 
var client = new XMLHttpRequest();​
client.onreadystatechange = handler;​
client.open("GET", "arquivo.html");​
client.send(); 

Com jQuery:

$.ajax({​
url: 'arquivo.html',​
success: function(data) {​
alert(data);​
}​
}); 

E este exemplo é para requisições através do método GET sem passar nenhum parâmetro. Requisições com método POST sem jQuery são ainda mais complicadas.

O Pensamento Natural (e errado)

Transportando tudo isso para o WordPress, normalmente o que se faz é criar um arquivo PHP que, apesar de estar dentro da pasta do tema, não tem nenhuma conexão com o WP e, por isso, não pode usar suas funções. Não seria possível, portanto, usar nenhuma das funções para obtenção de conteúdo como get_posts, get_pages e get_categories, utilizar os parâmetros de conexão com o banco de dados através do objeto global $wpdb, checar se o usuário está logado ou obter algum valor de configuração através de get_option.

No nosso exemplo não seria possível usar a função wp_mail, muito melhor que a função nativa mail já que com a primeira é possível utilizar inúmeros Plugins para um melhor e mais rico funcionamento.

Com wp_mail poderíamos, por exemplo, usar o poderoso plugin WP Mail SMTP, configurando-o através do painel para enviar e-mails através de um servidor SMTP externo fornecendo usuário, senha, endereços e etc.

Por outro lado se usarmos a função nativa mail poderemos apenas contar, sem nenhuma configuração adicional, com o servidor smtp do próprio servidor, nem sempre disponível.

Conceito Usado pelo WordPress: Hooks

Não é recomendado alterar nenhum arquivo próprio do WordPress – nem de nenhum programa que receba atualizações, diga-se de passagem. Isso porque a alteração feita por você seria potencialmente sobrescrita por uma atualização de versão do WordPress.

Se você alterar diretamente o código da função wp_mail no arquivo wp-includes/pluggable.php da versão 4.5 sua edição será perdida quando fizer a atualização para 4.6, por exemplo. E não, você definitivamente não quer deixar de atualizar o seu WordPress por isso, ficando sem atualizações de segurança ou até mesmo de funcionalidades.

Para alterar o funcionamento do WordPress sem alterar seu código existem os hooks, que são previsões no código para a alterações de comportamento feitas por terceiros. Os hooks são divididos entre filters e actions. Enquanto filters normalmente são usados para alterar alguma coisa – a alusão a filtros não é à toa – as actions são usadas para momentos em que possivelmente deseja-se apenas executar algum código qualquer.

Quando um usuário é excluído, por exemplo, o WordPress verifica se algum plugin deseja executar alguma ação. Os plug-ins adicionam suas funções através da chamada

add_action( 'delete_user', 'nome_da_funcao_do_plugin' );

e o wordpress executa-as quando chama

do_action( 'delete_user' );

Se o tema ou algum plugin desejar alterar o conteúdo exibido com the_content basta chamar

add_filter( 'the_content', 'nome_da_função' );

O próprio WordPress faz uso deste mecanismo para adicionar a função wpautop (a função que gera parágrafos automaticamente) a the_content, por exemplo, como é possível ver no arquivo wp-includes/default-filters.php, linha 134 na versão 4.5.2.

Vamos nos concentrar apenas no tipo usado nas chamadas AJAX, mas se quiser saber mais sobre hooks manifeste seu desejo nos comentários que podemos criar um tutorial sobre o assunto. Importante dizer também, antes de prosseguirmos, que embora o código do WordPress não deva ser alterado ele deve ser sim explorado.

Abrir um arquivo do próprio WP é muito útil para quem quer saber mais sobre determinada função ou comportamento do software, além de sempre ensinar uma coisa ou outra de PHP também.

A API AJAX do WordPress

O WordPress tem um arquivo especialmente dedicado para trabalhar com AJAX, o wp-admin/admin-ajax.php. Apesar de seu nome e de sua localização este arquivo serve tanto para requisições feitas no painel, isto é, no back-end da aplicação, quanto no site em si. Falaremos sobre isto mais adiante.

Todas as requisições do próprio WordPress feitas através de AJAX também são direcionadas para este arquivo, então é preciso alguma forma para endereçar qual função responderá em qual caso. Para isso utilizaremos os hooks, mecanismos que o WordPress fornece para execução de código personalizado em determinados momentos da execução da aplicação, como explicamos lá em cima.

Dividiremos o uso da API em três partes:

1. O Server-side chamando o Client-side: como chamarmos os arquivos js da maneira correta
2. O Client-side: a parte executada do lado cliente (visitante e seu navegador com HTML e Javascript) e
3. O Server-side: a parte executada pelo servidor (nossa função PHP no ambiente wordpress).

Server-Side Chamando o Client-Side

É um ponto básico, mas importante. Com PHP chamamos admin_url( ‘admin-ajax.php’ ) e voilà, temos o endereço correto do wp-admin/admin-ajax.php, esteja ele na raíz ( /wp-admin/admin-ajax.php) ou em alguma pasta (/wordpress/wp-admin/admin-ajax.php, por exemplo).

No painel podemos usar no código javascript a variável ajaxurl, que aponta automaticamente para o caminho certo. No front-end não temos essa facilidade, então precisamos passar esse dado de um lado para o outro. Para isso existe a função wp_localize_script.

As inclusões de arquivos javascript no front-end, isto é, as tags <script> que podem ir tanto no <head> quanto no fim do conteúdo, perto do </body>, devem ser feitas sempre com o uso do hook wp_enqueue_scripts (no painel usamos admin_enqueue_scripts) e da função wp_enqueue_script.

Um exemplo de como chamar seu arquivo javascript no tema. Este código deverá estar no arquivo functions.php:

add_action('wp_enqueue_scripts', 'meu_tema_enqueue_scripts');​
function meu_tema_enqueue_scripts() {​
wp_enqueue_script('scripts', get_template_directory_uri()."/js/scripts.js", 
array('jquery'));​
wp_localize_script('scripts', 'ajax_object', array('ajax_url' => 
admin_url('admin-ajax.php'), 'outro_valor' => 1234));​
} 

Na primeira linha usamos o conceito de hooks: quando o wordpress executar do_action(‘wp_enqueue_scripts’) ele saberá que a nossa função ‘meu_tema_enqueue_scripts’ também deverá ser executada.

Na terceira linha declaramos nossa necessidade de uma tag <script> que aponte para o arquivo /js/scripts.js que está dentro do tema e que este arquivo depende da inclusão do jQuery. Em seguida dizemos que este arquivo deverá contar com o objeto ajax_object e que este objeto terá como atributos os dados do array do terceiro parâmetro.

Inserindo este trecho de código no nosso tema poderemos acessar então, no arquivo scripts.js, o valor de admin_url(‘admin-ajax.php’) através de ajax_object.ajax_url, assim como poderemos acessar o valor 1234 através de ajax_object.outro_valor.

Client-Side

Analisemos o código a seguir, o javascript de um formulário que envia nome, e-mail e mensagem de um formulário por AJAX:

jQuery(document).ready(function($) { // Instruções contidas nesta função serão executadas quando todo o HTML enviado pelo servidor for recebido e a árvore do DOM já estiver carregada. Ela recebe $ como parâmetro, assim podemos substituir "jQuery" por "$"​

$(‘form#form-ajax’).submit(function() { // Instruções executadas quando o formulário com id "form-ajax" for enviado, isto é, quando o usuário apertar enter em um campo ou clicar no botão de enviar​

var dados = { // Montagem do objeto que será transmitido na requisição AJAX.​

'action': 'minha_acao_ajax',  // Este é o sinal para o wordpress de qual função PHP será usada. Comporá o nome da action como veremos a seguir.​
 
'nome' : $("#form-ajax-nome").val(), // Coloca no objeto os dados de acordo com o valores de campos com determinados ids​
'email' : $("#form-ajax-email").val(),​
'mensagem' : $("#form-ajax-mensagem").val()​
};​

$.post(ajax_object.ajax_url, dados, function(resposta) { // Envia para o endereço (parâmetro 1, montado segundo explicado lá em cima) os dados (parâmetro 2). Como terceiro parâmetro passamos a função a ser executada no fim do processo, com a resposta.​

$(‘#form-ajax-resposta’).html('Esta foi a resposta: ' + resposta); // Coloca na div com id form-ajax-resposta a resposta enviada pelo servidor, que aqui presume-se ser texto puro.​
});​
return false; // Impede que o navegador faça o envio do formulário da maneira tradicional, ou seja, com o carregamento da página​
});​
}); 

<form id="form-ajax" method="post" 
action="http://localhost/wordpress/wp-admin/admin-ajax.php">​
<input type="hidden" name="action" value="minha_acao_ajax">​
<input type="text" name="nome" id="form-ajax-nome">​
<input type="text" name="email" id="form-ajax-email">​
<textarea name="mensagem" id="form-ajax-mensagem"></textarea>​
<input type="submit" value="enviar">​
</form>​

Repare que o método é POST (como a função jQuery chamada), o valor do atributo action é o primeiro parâmetro da função jQuery (já interpretado no html) e repare também nos atributos name dos campos (iguais aos passados na variável dados).

A correlação entre a chamada javascript e o HTML do formulário é fundamental para entendermos como trabalharemos os dados no lado servidor.

Server-side

A action wp_ajax

Ao receber a requisição no arquivo admin-ajax.php o wordpress tentará executar a seguinte instrução:
​

do_action( 'wp_ajax_' . $_REQUEST['action'] );​

se o usuário estiver logado e a instrução
​

do_action( 'wp_ajax_nopriv_' . $_REQUEST['action'] );​

se não estiver. No nosso exemplo a requisição receberá por POST os valores inseridos na variável javascript “dados”, então $_REQUEST[‘action’] será minha_acao_ajax, isto quer dizer que o wordpress tentará executar:

do_action( 'wp_ajax_minha_acao_ajax' );
ou
do_action( 'wp_ajax_nopriv_minha_acao_ajax' );

Isto significa que precisamos adicionar aos actions wp_ajax_minha_acao_ajax e wp_ajax_nopriv_minha_acao_ajax a função PHP que queremos executar como resposta à requisição feita:

add_action('wp_ajax_minha_acao_ajax', 'funcao_da_minha_acao_ajax');​
add_action('wp_ajax_nopriv_minha_acao_ajax', 'funcao_da_minha_acao_ajax');​
function funcao_da_minha_acao_ajax() {​
// Podemos acessar $_REQUEST para usar os dados enviados:​
$mensagem = "Nome: ".$_REQUEST['nome']."\n E-mail: ".$_REQUEST['email']."\n 
Mensagem: ".$_REQUEST['mensagem'];​
if (wp_mail('destinatario@dominio.com', 'Contato por AJAX', $mensagem)) {​
echo 'Mensagem enviada com sucesso';​
} else {​
echo 'Ocorreu um erro, tente novamente';​
}​
wp_die(); // Explico essa linha mais adiante​
}

Front-end, Back-end (painel), Usuários Logados e Não-Logados

Se usuários logados poderão em algum momento acionar o nosso código devemos incluir nossa função na action ‘wp_ajax_minha_acao_ajax’, seja ela chamada no front-end ou no back-end. Se usuários não logados poderão em algum momento acionar o nosso código devemos incluir nossa função na action ‘wp_ajax_nopriv_minha_acao_ajax’.

Se usuários não logados não podem executar nosso código não inclua sua função na action, porque você gerará uma brecha na segurança, ou seja, se você está desenvolvendo alguma coisa para o painel somente os usuários logados acessarão e, por isso, a linha com _nopriv é desnecessária (e perigosa).

Funções de Uso Não Exclusivo para AJAX

Se você está usando a mesma função para obter uma lista de conteúdos tanto por ajax quanto por requisições normais, por exemplo, e precisa diferenciar a resposta em um cenário e no outro há um teste simples disponível para isso. Logo ao entrar no admin-ajax.php o WordPress dá o valor true à constante DOING_AJAX. Desta forma é possível dar respostas diferentes para cada caso através do teste if (defined( ‘DOING_AJAX’ ) && DOING_AJAX).

Retorno da Função

O arquivo admin-ajax.php sempre escreverá “0” na resposta, ou seja, se a sua função terminar com echo ‘Enviado.’; o javascript receberá “Enviado.0”. Para evitar que isto aconteça é preciso chamar wp_die() no final da sua função, assim inibiremos o wordpress de dar sua resposta padrão.

Chamamos wp_die() ao invés de die() ou exit() porque a função do wordpress dá chance para outros códigos lidarem com o término do código em AJAX através do filter ‘wp_die_ajax_handler’.

Além de texto puro podemos enviar para o javascript como resposta um JSON, objeto javascript com suporte nativo do PHP, que como já falamos anteriormente tem substituído cada vez mais as respostas com XML.

Caso o e-mail seja enviado podemos substituir:

echo ‘Mensagem enviada com sucesso’;

por

echo json_encode(array('class' => 'sucesso', 'mensagem' => 'Mensagem enviada com sucesso')); 

Substituição semelhante também teria que ser feita no caso de falhas. No javascript trocaríamos

$(‘#form-ajax-resposta’).html('Esta foi a resposta: ' + resposta);

por

$(‘#form-ajax-resposta’).addClass(resposta.class).html('Esta foi a resposta: ' + resposta.mensagem);

Também é necessário acrescentar ‘json’ como quarto parâmetro da função $.post().

Para Formulários Extensos

Caso seu formulário tenha muitos campos é possível enxugar a montagem da variável dados através da função serialize do jQuery, desta forma:

var dados = {
'action': 'minha_acao_ajax',
'dados' : $(this).serialize()
};

Esta função passa para o PHP uma string formada por todos os valores informados no formulário, mais ou menos como aquela inserida ao final da URL quando enviamos um formulário com método GET.

No PHP teremos que tratar esta variável antes de usar seus valores, transformando-a de string em array indexada, da seguinte forma:

parse_str($_REQUEST['dados'], $array_dados); // O primeiro parâmetro é a string formada pelos valores do form e o segundo é o array que receberá seus dados.

Assim o nome informado estará em $array_dados[ ‘nome ‘].

Debug

Para debugar tudo de javascript os consoles são nossos amigos. O Chrome tem seu console nativo disponível através da tecla F12 ou no menu indo em Mais ferramentas → Ferramentas do desenvolvedor. Lá, na aba Network, podemos acompanhar todas as requisições feitas com XHR. Clicando no nome podemos ver o que foi enviado e o que foi recebido, conforme a figura a seguir.

De forma parecida no Firefox é possível usar o firebug, extensão excelente por sinal. No FF é mais fácil acompanhar as requisições pela aba Console.

O Exemplo Completo

Consolidando tudo o que aprendemos, nosso exemplo final ficaria da seguinte forma:

No arquivo functions.php teríamos tanto a inclusão do javascript que lidaria com o submit do formulário e sua resposta quanto a função PHP que enviará o e-mail e retornará o resultado para o javascript. Inclui na função alguma validação para os campos:

add_action('wp_enqueue_scripts', 'meu_tema_enqueue_scripts');​
function meu_tema_enqueue_scripts() {​
wp_enqueue_script('scripts', get_template_directory_uri()."/js/scripts.js", 
array('jquery'));​
wp_localize_script('scripts', 'ajax_object', array('ajax_url' => 
admin_url('admin-ajax.php'), 'outro_valor' => 1234));​
}​
​
add_action('wp_ajax_minha_acao_ajax', 'funcao_da_minha_acao_ajax');​
add_action('wp_ajax_nopriv_minha_acao_ajax', 'funcao_da_minha_acao_ajax');​
function funcao_da_minha_acao_ajax() {​
parse_str($_REQUEST['dados'], $array_dados);​
​
if (!isset($array_dados['nome']) OR empty($array_dados['nome']) OR ​
!isset($array_dados['email']) OR empty($array_dados['email']) OR 
!is_email($array_dados['email']) OR​
!isset($array_dados['mensagem']) OR empty($array_dados['mensagem'])) {​
​
echo json_encode(array('class' => 'erro', 'mensagem' => 'Todos os campos são 
obrigatórios.'));​
​
} else {​
$mensagem = "Nome: ".$array_dados['nome']."\n E-mail: 
".$array_dados['email']."\n Mensagem: ".$array_dados['mensagem'];​
if (wp_mail('felipe.elia@gmail.com', 'Wordpress :: Contato por AJAX', 
$mensagem)) {​
echo json_encode(array('class' => 'sucesso', 'mensagem' => 
'Mensagem enviada com sucesso!'));​
} else {​
echo json_encode(array('class' => 'erro', 'mensagem' => 'Sua 
mensagem não foi enviada.'));​
}​
}​
​
wp_die();​
}​

No arquivo scripts.js a função javascript:

jQuery(document).ready(function($) {
$('form#form-ajax').submit(function() {
var dados = {
'action': 'minha_acao_ajax',
'dados' : $(this).serialize()
};
$.post(ajax_object.ajax_url, dados, function(resposta) {
var $div_resposta = $('#form-ajax-resposta');
$div_resposta.removeClass('erro sucesso').addClass(resposta.class).html(resposta.mensagem);
}, 'json');
return false;
});
});

E finalmente precisaríamos de um template que contivesse o formulário. Para o exemplo criei um template template-contato.php e o associei à uma página. Seu conteúdo ficou da seguinte forma:

<?php
/*
* Template name: Página de contato
*/
get_header();
if (have_posts()) {
while (have_posts()) { the_post(); ?>
<div>
<h1><?php the_title(); ?></h1>
<?php the_content(); ?>
<form id="form-ajax" method="post" action="#">
<div id="form-ajax-resposta"></div>
<div><input type="text" name="nome" id="form-ajax-nome" placeholder="Nome"></div>
<div><input type="text" name="email" id="form-ajax-email" placeholder="E-mail"></div>
<div><textarea name="mensagem" id="form-ajax-mensagem" placeholder="Mensagem"></textarea></div>
<div><input type="submit" value="enviar"></div>
</form>
</div>
<?php }
}
get_footer();

Arquivos utilizados neste tutorial disponível para Download:

Baixar | Hospedagem

Conclusão

AJAX é uma técnica poderosíssima e não é preciso deixar de usá-la por se estar usando WordPress, pelo contrário! É simples utilizá-la em conjunto com o WordPress e o resultado pode ser poderosíssimo. Vale a pena investir seu tempo para dominar esta técnica e se diferenciar ainda mais no mercado de trabalho!

Se você gostou desse artigo considere compartilhar nas redes sociais. Siga-nos nas redes sociais para acompanhar mais artigos como esse. Se de alguma forma este artigo lhe foi útil deixa seu comentário abaixo para podermos saber a sua opinião.