Permítanme decirlo: el jueves 4 de febrero fue bastante desmoralizante. Pasé muchísimo tiempo en enero trabajando en la API RESTREST API La API REST es un acrónimo de RESTful Application Program Interface (API), que utiliza solicitudes HTTP para OBTENER, ACTUALIZAR, CREAR y ELIMINAR datos. Es la forma en que la interfaz frontend de una aplicación (pensemos en una «aplicación para el teléfono» o un «sitio web») puede comunicarse con el almacén de datos (pensemos en una «base de datos» o un «sistema de archivos»)
https://developer.wordpress.org/rest-api/ de WP, preparándome para lo que quería hacer en la línea de comandos, y en esa reunión se destruyeron mucho impulso, inspiración y buenas sensaciones en general. Por eso, pasé gran parte de febrero y marzo trabajando en funciones de WP-CLIWP-CLI WP-CLI es la interfaz de línea de comandos para WordPress, utilizada para realizar tareas administrativas y de desarrollo de forma programática. La página del proyecto es http://wp-cli.org/ https://make.wordpress.org/cli/ no relacionadas con la API REST de WP (por ejemplo, la gestión de paquetes).
Pero he vuelto a la carga. Como llevo dos tercios del camino en una de esas sofisticadas aplicaciones de WordPress con API REST de WP + ReactReact React es una biblioteca de JavaScript que facilita el análisis, la construcción y el mantenimiento de interfaces de usuario sin estado y con estado.
https://reactjs.org, estoy encontrando docenas de maneras en las que quiero poder hacer que WordPress sea más eficiente. Y, por supuesto, esto significa hacerlo desde la línea de comandos.
Antes de continuar: la mayoría, si no todas, de las funciones RESTful de WP-CLI han requerido cambios internos en WP-CLI. Querrás ejecutar wp cli update --nightly para probar esta nueva funcionalidad localmente. Una vez hecho esto, puedes ejecutar wp package install danielbachhuber/wp-rest-cli para instalar la versión más reciente.
Usa --debug y --debug=rest para analizar tus endpoints REST
Las API REST giran en torno a la velocidad. Los milisegundos importan, y cada uno que logres ahorrar tendrá un impacto real en la experiencia del usuario.
Para que sea mucho, mucho más fácil entender cuántas consultas ejecuta tu endpoint y cuánto tardan, he añadido un análisis ligero a RESTful WP-CLI.
Usa --debug para obtener un resumen de tus consultas para cualquier comando.
$ wp rest post list --debug
Debug (rest): REST command executed 7 queries in 0.001954 seconds. Use --debug=rest to see all queries. (1.446s)
+----+-----------------------------+
| id | title |
+----+-----------------------------+
| 1 | {"rendered":"Hello world!"} |
+----+-----------------------------+
Usa --debug=rest para obtener la lista completa de consultas ejecutadas.
$ wp rest post list --fields=id,title --debug=rest
Debug: REST command executed 7 queries in 0.001696 seconds. Ordered by slowness, the queries are:
1:
- 0.000291 seconds
- 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 seconds
- WP_REST_Posts_Controller->get_items, WP_Query->query, WP_Query->get_posts, WP_Query->set_found_posts
- SELECT FOUND_ROWS()
3:
- 0.000256 seconds
- 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 seconds
- 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 seconds
- 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 seconds
- 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 seconds
- 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!"} |
+----+-----------------------------+
El análisis funciona para cualquier operación CRUD.
$ wp rest post create --title="Test post" --user=daniel --debug
Debug (rest): REST command executed 28 queries in 0.023962 seconds. Use --debug=rest to see all queries. (1.777s)
Success: Created post.
$ wp rest post update 3 --content="Foo bar" --user=daniel --debug
Debug (rest): REST command executed 31 queries in 0.023309 seconds. Use --debug=rest to see all queries. (1.634s)
Success: Updated post.
Espero que esta función se convierta en una parte inestimable de tu proceso de desarrollo de endpoints REST, como lo ha sido para mí. Envíame tus comentarios en su incidencia en Github.
Usa wp rest * edit para editar un recurso en el editor de tu sistema
Probablemente la mayoría de la gente no lo sepa, pero puedes usar wp post edit <id> para editar el contenido de una entrada en el editor de tu sistema (por ejemplo, vim). Ahora, con wp rest * edit, puedes editar cualquier recurso REST en el editor de tu sistema.
$ wp rest post edit 3 --user=daniel
Cuando ejecutas wp rest * edit, RESTful WP-CLI obtiene el recurso, lo transforma en un documento YAML y lo coloca en el editor de tu 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: [ ]
Si haces cambios en cualquiera de los campos, el comando los envía de vuelta a WordPress (a través de la API REST de WP) para actualizarlos.
En las instalaciones de WordPress compatibles con Basic Auth, la edición también funciona mediante HTTPHTTP HTTP es un acrónimo de Hyper Text Transfer Protocol (protocolo de transferencia de hipertexto). HTTP es el protocolo subyacente utilizado por la World Wide Web y define cómo se formatean y transmiten los mensajes, y qué acciones deben realizar los servidores web y los navegadores en respuesta a diversos comandos.:
$ wp --http=http://daniel:[email protected] rest post edit 1
Y, voilà.
¡Participa!
Me encantaría conocer tu opinión sobre las docenas de ideas que tengo para un WP-CLI más RESTful:
- Mostrar la documentación de ayuda en formatos como APIAPI Una API o interfaz de programación de aplicaciones es un intermediario de software que permite a los programas interactuar entre sí y compartir datos de formas limitadas y claramente definidas. Blueprint y Swagger [#36]
- Introducir
wp rest * generatepara generar datos simulados en el formato que espera tu aplicación [#55]. - Introducir
wp rest * diffpara poder comparar el estado de dos WordPress diferentes, al estilo de Dictator [#56]. - Encontrar una implementación elegante de alias, para que
--http=http://daniel:[email protected]se convierta en@wpdev[#2039]
¡Y también quiero conocer tus ideas! Además de cualquier comentario, pregunta o desacuerdo rotundo. Hablemos en Github.