Deixe-me dizer apenas — quinta-feira, 4 de fevereiro, foi bem desmoralizante. Passei uma enorme quantidade de tempo em janeiro trabalhando na API RESTREST API A API REST é um acrônimo para RESTful Application Program Interface (API), que usa solicitações HTTP para OBTER, COLOCAR, PUBLICAR e EXCLUIR dados. É como a interface de uma aplicação (pense em “aplicativo de celular” ou “site”) pode se comunicar com o armazenamento de dados (pense em “banco de dados” ou “sistema de arquivos”)
https://developer.wordpress.org/rest-api/ do WP, preparando-me para o que eu queria fazer na linha de comando, e muito do impulso / inspiração / sentimentos positivos em geral foram destruídos naquela reunião. Por isso, passei grande parte de fevereiro e março trabalhando em recursos do WP-CLIWP-CLI WP-CLI é a interface de linha de comando do WordPress, usada para realizar tarefas administrativas e de desenvolvimento de maneira programática. A página do projeto é http://wp-cli.org/ https://make.wordpress.org/cli/ não relacionados à API REST do WP (por exemplo, gerenciamento de pacotes).
Mas estou de volta à ativa. Como já percorri 2/3 do caminho em uma daquelas sofisticadas aplicações WordPress com API REST do WP + ReactReact React é uma biblioteca JavaScript que facilita a compreensão, a construção e a manutenção de interfaces de usuário com e sem estado.
https://reactjs.org, estou encontrando dezenas de maneiras pelas quais quero poder tornar o WordPress mais eficiente. E, é claro, isso significa fazer isso na linha de comando.
Antes de prosseguirmos: a maioria, se não todos, dos recursos RESTful do WP-CLI exigiu mudanças internas no WP-CLI. Você vai querer executar wp cli update --nightly para experimentar essa nova funcionalidade localmente. Depois de fazer isso, você pode executar wp package install danielbachhuber/wp-rest-cli para instalar a versão mais recente.
Use --debug e --debug=rest para analisar o desempenho dos seus endpoints REST
As APIs REST são todas voltadas para velocidade. Milissegundos importam, e cada um que você conseguir economizar terá um impacto real na experiência do usuário.
Para tornar muito, muito mais fácil entender quantas consultas seu endpoint está executando e quanto tempo elas levam, adicionei uma análise leve de desempenho ao WP-CLI RESTful.
Use --debug para obter um resumo das suas consultas em qualquer comando.
$ wp rest post list --debug
Debug (rest): O comando REST executou 7 consultas em 0.001954 segundos. Use --debug=rest para ver todas as consultas. (1.446s)
+----+-----------------------------+
| id | title |
+----+-----------------------------+
| 1 | {"rendered":"Hello world!"} |
+----+-----------------------------+
Use --debug=rest para obter a lista completa das consultas executadas.
$ wp rest post list --fields=id,title --debug=rest
Debug: O comando REST executou 7 consultas em 0.001696 segundos. Ordenadas por lentidão, as consultas são:
1:
- 0.000291 segundos
- WP_REST_Posts_Controller->get_items, WP_Query->query, WP_Query->get_posts
- SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish') ORDER BY wp_posts.post_date DESC LIMIT 0, 10
2:
- 0.000257 segundos
- WP_REST_Posts_Controller->get_items, WP_Query->query, WP_Query->get_posts, WP_Query->set_found_posts
- SELECT FOUND_ROWS()
3:
- 0.000256 segundos
- WP_REST_Posts_Controller->get_items, WP_REST_Posts_Controller->prepare_item_for_response, setup_postdata, WP_Query->setup_postdata, get_userdata, get_user_by, WP_User::get_data_by
- SELECT * FROM wp_users WHERE ID = '1'
4:
- 0.000244 segundos
- WP_REST_Posts_Controller->get_items, WP_REST_Posts_Controller->prepare_item_for_response, setup_postdata, WP_Query->setup_postdata, get_userdata, get_user_by, WP_User->init, WP_User->for_blog, WP_User->_init_caps, get_user_meta, get_metadata, update_meta_cache
- SELECT user_id, meta_key, meta_value FROM wp_usermeta WHERE user_id IN (1) ORDER BY umeta_id ASC
5:
- 0.000233 segundos
- WP_REST_Posts_Controller->get_items, WP_Query->query, WP_Query->get_posts, _prime_post_caches
- SELECT wp_posts.* FROM wp_posts WHERE ID IN (1)
6:
- 0.000209 segundos
- WP_REST_Posts_Controller->get_items, WP_Query->query, WP_Query->get_posts, _prime_post_caches, update_post_caches, update_object_term_cache, wp_get_object_terms
- SELECT t.*, tt.*, tr.object_id FROM wp_terms AS t INNER JOIN wp_term_taxonomy AS tt ON tt.term_id = t.term_id INNER JOIN wp_term_relationships AS tr ON tr.term_taxonomy_id = tt.term_taxonomy_id WHERE tt.taxonomy IN ('category', 'post_tag', 'post_format') AND tr.object_id IN (1) ORDER BY t.name ASC
7:
- 0.000206 segundos
- WP_REST_Posts_Controller->get_items, WP_Query->query, WP_Query->get_posts, _prime_post_caches, update_post_caches, update_postmeta_cache, update_meta_cache
- SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE post_id IN (1) ORDER BY meta_id ASC
(1.598s)
+----+-----------------------------+
| id | title |
+----+-----------------------------+
| 1 | {"rendered":"Hello world!"} |
+----+-----------------------------+
A análise de desempenho funciona para qualquer operação CRUD.
$ wp rest post create --title="Test post" --user=daniel --debug
Debug (rest): O comando REST executou 28 consultas em 0.023962 segundos. Use --debug=rest para ver todas as consultas. (1.777s)
Success: Post criado.
$ wp rest post update 3 --content="Foo bar" --user=daniel --debug
Debug (rest): O comando REST executou 31 consultas em 0.023309 segundos. Use --debug=rest para ver todas as consultas. (1.634s)
Success: Post atualizado.
Espero que esse recurso se torne uma parte inestimável do seu processo de desenvolvimento de endpoints REST, assim como se tornou do meu. Envie-me seu feedback na issue dele no Github.
Use wp rest * edit para editar um recurso no editor do seu sistema
A maioria das pessoas provavelmente não sabe disso, mas você pode usar wp post edit <id> para editar o conteúdo de um post no editor do seu sistema (por exemplo, vim). Agora, com wp rest * edit, você pode editar qualquer recurso REST no editor do seu sistema.
$ wp rest post edit 3 --user=daniel
Quando você executa wp rest * edit, o WP-CLI RESTful busca o recurso, transforma-o em um documento YAML e o abre no editor do seu sistema:
---
date: 2016-04-14T14:02:57
date_gmt: null
password:
slug:
status: draft
title:
raw: Test post
rendered: Test post
content:
raw: Foo bar
rendered: |
|
Foo bar
excerpt:
raw:
rendered: |
|
Foo bar
author: 1
featured_media: 0
comment_status: open
ping_status: open
sticky: false
format: standard
categories:
- 1
tags: [ ]
Se você fizer alterações em qualquer um dos campos, o comando os enviará de volta ao WordPress (por meio da API REST do WP) para atualização.
Em instalações do WordPress que oferecem suporte à autenticação básica, a edição também funciona por HTTPHTTP HTTP é um acrônimo para Hyper Text Transfer Protocol (Protocolo de Transferência de Hipertexto). HTTP é o protocolo subjacente usado pela World Wide Web, e esse protocolo define como as mensagens são formatadas e transmitidas e quais ações os servidores Web e navegadores devem executar em resposta a vários comandos.:
$ wp --http=http://daniel:[email protected] rest post edit 1
E pronto.
Participe!
Eu adoraria receber sua opinião sobre as dezenas de ideias que tenho para um WP-CLI mais RESTful:
- Renderizar a documentação de ajuda em formatos como APIAPI Uma API, ou Interface de Programação de Aplicações, é um intermediário de software que permite que os programas interajam entre si e compartilhem dados de maneiras limitadas e claramente definidas. Blueprint e Swagger [#36]
- Introduzir
wp rest * generatepara gerar dados fictícios no formato esperado pela sua aplicação [#55]. - Introduzir
wp rest * diffpara poder comparar o estado de dois WordPress diferentes, à la Dictator [#56]. - Criar uma implementação elegante de aliases, para que
--http=http://daniel:[email protected]se torne@wpdev[#2039]
E também quero ouvir suas ideias! Assim como qualquer feedback, pergunta ou discordância veemente. Vamos conversar no Github.