TL; DR
Não há API JavaScript no núcleo do WordPress e ninguém está planejado, mas, na verdade, não há necessidade disso.
Processo interno
Antes de tudo, digamos que, em relação ao back-end, algumas informações úteis podem ser buscadas a partir de variáveis globais do JavaScript já presentes (o WordPress ama todos os sabores globais).
Por exemplo
ajaxurlpara que o admin-ajax.phpURL seja usado em chamadas ajaxpagenow para slug da página de administração atual, por exemplo, 'painel'adminpage para o arquivo atual da página de administração, por exemplo, 'index-php' (os pontos são substituídos por hífens)typenowpara o tipo de postagem atual enquanto estiver em edit.php, post.phpoupost-new.phpuserSettings pode ser usado para obter informações do usuário logado atual
Essas informações fornecem um "contexto" do estado do aplicativo enquanto você está no back-end.
Para outras coisas mencionadas na pergunta, você não precisa de nenhuma "API", porque funções jQuery super simples podem fazer o truque. Por exemplo, para saber se o menu de administração está fechado, você pode verificar a classe "dobrada" no corpo:
if ( $(body).hasClass('folded') ) {
alert( 'Admin left menu is closed!' );
} else {
alert( 'Admin left menu is open!' );
}
Falta de documentação
Para coisas como os trechos anteriores, não vale a pena criar funções. O WP já possui muitas funções no PHP. Eu realmente espero que funções adicionais como essas não sejam adicionadas ao núcleo.
O que o JavaScript no WordPress realmente precisa é de mais documentação para os recursos existentes: nada do que escrevi acima está documentado em nenhum documento oficial como o Codex ou nos arquivos de origem.
A parte dianteira?
Até aqui, eu só falei sobre o back-end.
Isso ocorre porque praticamente todas as coisas que acontecem no frontend estão relacionadas ao tema atualmente em uso. Vamos imaginar que exista um arquivo JavaScript fornecido pelo WordPress contendo funções para obter informações sobre o estado atual do aplicativo; se um tema não enfileirar esse arquivo JS, essas funções não estarão disponíveis e forçar um tema a enfileirar esse script estaria absolutamente errado.
Não há necessidade de (outra) API
No entanto, no WordPress, todas as informações que você pode obter via PHP também podem ser facilmente usadas em JavaScript e sem nenhuma solicitação AJAX. Essa função que torna isso possível é wp_localize_script().
Vamos supor que você deseja obter o usuário atual e os dados do usuário, como sua função de usuário em seu JavaScript, e também deseja conhecer as variáveis de consulta usadas na página atual. Você pode fazer o seguinte:
$data = array(
'user' => wp_get_current_user(),
'query_vars' => $GLOBALS['wp']->query_vars
);
wp_localize_script( 'myscript', 'MyScriptData', $data );
Fazendo isso em seu script, a MyScriptData.uservariável será um objeto JavaScript com todas as informações dos usuários e todas as variáveis de consulta.
Isso é válido para scripts de back-end e front-end (em outras palavras: para ambos os "lados"). Não há necessidade de nenhuma API JavaScript adicional apenas para buscar essas informações. PHP é suficiente se você usar as maneiras adequadas de passar informações de PHP para JS.
Backbone.js
Backbone.js , é uma estrutura JavaScript que permite um (tipo de) padrão de desenvolvimento MVC com JavaScript. Foi incluído no núcleo com o WP 3.5 - principalmente para lidar com a galeria de mídia.
Esta biblioteca não é uma API JavaScript do WordPress, pois certamente permite um desenvolvimento mais poderoso do JavaScript, mas nenhuma função específica do WordPress foi adicionada a essa biblioteca e é o único uso atual do Backbone.js. A biblioteca de mídia é mais ou menos indocumentada e não possui API pública. E a AFAIK não está planejada para preencher essa lacuna. (Mais do que feliz em mudar / remover essa declaração - se alguém puder me provar que estou errado).
API WP
Conforme apontado por Rarst e Brian Fegter , a API do WP fará parte do núcleo (provavelmente começando com o WP 4.1).
Mas eu tenho que dizer que é não uma API JavaScript. Ele apenas permite conectar uma solicitação HTTP a um ponto de extremidade do aplicativo controlado pela WP-API. E a API busca dados do banco de dados e os retorna no formato JSON. Exemplo dos documentos:
Deseja receber as postagens do seu site? Basta enviar uma GETsolicitação para /wp-json/posts. Atualizar usuário com ID 4? Envie uma POSTsolicitação para /wp-json/users/4. Obter todas as postagens com o termo de pesquisa "impressionante"? GET /wp-json/posts?filter[s]=awesome.
Como solicitações HTTP e respostas JSON relacionadas podem ser tratadas com qualquer linguagem que suporte solicitações HTTP e formato de dados JSON (entre eles PHP, Ruby, Python, ASP, etc.), o principal objetivo da WP API é permitir obter e definir dados do WordPress de aplicativos não WP. Isso significa que dentro de qualquer aplicativo , não apenas o WordPress.
Claro, como o JavaScript é uma linguagem que pode lidar com solicitações HTTP e formato JSON, você também pode usar a API WP no JavaScript do WordPress. Alguém também está trabalhando em um cliente WP js para essa API, mas
usando wp_enqueue_script()+ as funções Ajax API + WordPress PHP, é possível recuperar todas as informações necessárias sem nenhuma API adicional. E como todos os três "ingredientes" são padrões estabelecidos pelo WP, usá-los não é uma "solução própria". Ele apenas usa soluções padrão para executar tarefas personalizadas (e comuns), que é o objetivo deste desenvolvimento de plug-ins.
ainda é possível usar JavaScript para utilizar a API do WP. Só porque a WP-API retorna JSON, ela não a torna uma API JavaScript. Não há função JavaScript envolvida (uma solicitação HTTP é enviada e um reenvio JSON é retornado. Praticamente o mesmo que acontece usando a API AJAX). Caso contrário, qualquer serviço que retorne JSON deve ser considerado uma API JS do WordPress. A WP-API deve ser considerada uma API de serviço externo que retorna JSON e pode ser que o site que consome esse serviço JSON seja o mesmo que o fornece.
não há nada que possa ser feito com a API WP que também não possa ser feito usando a API AJAX. Mas há muitas coisas que podem ser feitas com a API AJAX. mas não com a WP-API.
Uma observação sobre o WP-API + Backbone.js
Com o Backbone.js, é possível obter e salvar informações em aplicativos que suportam solicitações HTTP RESTful .
O problema é que o WordPress, tanto em solicitações "regulares" quanto em AJAX, é praticamente RESTful: ele suporta $_GETe $_POSTsolicita apenas por padrão, e usar um ou outro com o mesmo URl acaba em ... o mesmo resultado .
Pelo contrário, a API do WP é RESTful, portanto, aplicativos baseados em Backbone podem tirar proveito dela para aplicativos avançados de JavaScript, mas eu evitaria definir a API de Backbone ou WP ou a API de Backbone + WP como uma API JavaScript para WordPress. acima.