DocsWP — WordPress Help

RESTful WP-CLI – Ce sur quoi j’ai bricolé

Permettez-moi simplement de dire ceci : le jeudi 4 février a été vraiment démoralisant. J’ai consacré énormément de temps en janvier à l’API RESTREST API L’API REST est l’acronyme de RESTful Application Program Interface (API), qui utilise des requêtes HTTP pour récupérer, modifier, créer et supprimer des données. C’est ainsi que la partie visible d’une application (pensez à une « application mobile » ou à un « site web ») peut communiquer avec le stockage des données (pensez à une « base de données » ou à un « système de fichiers »)
https://developer.wordpress.org/rest-api/ de WP en préparation de ce que je voulais faire en ligne de commande, et une grande partie de l’élan, de l’inspiration et des bonnes dispositions générales ont été anéantis lors de cette réunion. J’ai donc passé une bonne partie des mois de février et mars à travailler sur des fonctionnalités de WP-CLIWP-CLI WP-CLI est l’interface en ligne de commande de WordPress, utilisée pour effectuer des tâches d’administration et de développement de manière programmatique. La page du projet est http://wp-cli.org/ https://make.wordpress.org/cli/ sans rapport avec l’API REST de WP (par exemple, la gestion des paquets).

Mais me revoilà en selle. Comme j’en suis aux deux tiers d’une de ces applications WordPress sophistiquées combinant l’API REST de WP et ReactReact React est une bibliothèque JavaScript qui facilite la conception, la construction et la maintenance d’interfaces utilisateur sans état et avec état.
https://reactjs.org, je découvre des dizaines de façons dont j’aimerais pouvoir rendre WordPress plus efficace. Et bien sûr, cela signifie le faire en ligne de commande.

Avant de poursuivre : la plupart des fonctionnalités RESTful de WP-CLI, si ce n’est toutes, ont nécessité des modifications internes de WP-CLI. Vous devrez exécuter wp cli update --nightly pour tester cette nouvelle fonctionnalité localement. Une fois cela fait, vous pouvez exécuter wp package install danielbachhuber/wp-rest-cli pour installer la dernière version.

Utilisez --debug et --debug=rest pour profiler vos points de terminaison REST

Les API REST sont entièrement axées sur la rapidité. Les millisecondes comptent, et chaque milliseconde que vous parvenez à économiser aura un impact réel sur l’expérience utilisateur.

Pour comprendre beaucoup plus facilement combien de requêtes votre point de terminaison exécute et combien de temps elles prennent, j’ai ajouté un profilage léger à WP-CLI RESTful.

Utilisez --debug pour obtenir un résumé de vos requêtes pour n’importe quelle commande.

$ wp rest post list --debug
Debug (rest): La commande REST a exécuté 7 requêtes en 0.001954 seconde. Utilisez --debug=rest pour voir toutes les requêtes. (1.446s)
+----+-----------------------------+
| id | title                       |
+----+-----------------------------+
| 1  | {"rendered":"Hello world!"} |
+----+-----------------------------+

Utilisez --debug=rest pour obtenir la liste complète des requêtes exécutées.

$ wp rest post list --fields=id,title --debug=rest
Débogage : la commande REST a exécuté 7 requêtes en 0.001696 seconde. Classées par lenteur, les requêtes sont les suivantes :
1:
  - 0.000291 seconde
  - 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 seconde
  - WP_REST_Posts_Controller->get_items, WP_Query->query, WP_Query->get_posts, WP_Query->set_found_posts
  - SELECT FOUND_ROWS()
3:
  - 0.000256 seconde
  - 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 seconde
  - 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 seconde
  - 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 seconde
  - 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 seconde
  - 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!"} |
+----+-----------------------------+

Le profilage fonctionne pour toute opération CRUD.

$ wp rest post create --title="Test post" --user=daniel --debug
Debug (rest): La commande REST a exécuté 28 requêtes en 0.023962 seconde. Utilisez --debug=rest pour voir toutes les requêtes. (1.777s)
Succès : article créé.
$ wp rest post update 3 --content="Foo bar" --user=daniel --debug
Debug (rest): La commande REST a exécuté 31 requêtes en 0.023309 seconde. Utilisez --debug=rest pour voir toutes les requêtes. (1.634s)
Succès : article mis à jour.

J’espère que cette fonctionnalité deviendra une partie indispensable de votre processus de développement de points de terminaison REST, comme elle l’est devenue pour le mien. Faites-moi part de vos commentaires sur son issue Github.

Utilisez wp rest * edit pour modifier une ressource dans l’éditeur système

La plupart des gens ne le savent probablement pas, mais vous pouvez utiliser wp post edit <id> pour modifier le contenu d’un article dans votre éditeur système (par exemple, vim). Désormais, avec wp rest * edit, vous pouvez modifier n’importe quelle ressource REST dans votre éditeur système.

$ wp rest post edit 3 --user=daniel

Lorsque vous exécutez wp rest * edit, WP-CLI RESTful récupère la ressource, la transforme en document YAML et l’ouvre dans votre éditeur système :

---
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 vous modifiez l’un des champs, la commande le renvoie à WordPress (via l’API REST de WP) pour le mettre à jour.

Sur les installations WordPress qui prennent en charge l’authentification Basic, la modification fonctionne également via HTTPHTTP HTTP est l’acronyme de Hyper Text Transfer Protocol. HTTP est le protocole sous-jacent utilisé par le World Wide Web ; ce protocole définit la façon dont les messages sont formatés et transmis, ainsi que les actions que les serveurs web et les navigateurs doivent effectuer en réponse à diverses commandes. :

$ wp --http=http://daniel:[email protected] rest post edit 1

Et voilà.

Impliquez-vous !

J’aimerais beaucoup connaître votre avis sur les dizaines d’idées que j’ai pour un WP-CLI plus RESTful :

  • Afficher les documents d’aide dans des formats tels que APIAPI Une API, ou interface de programmation d’application, est un intermédiaire logiciel qui permet aux programmes d’interagir entre eux et de partager des données de manière limitée et clairement définie. Blueprint et Swagger [#36]
  • Introduire wp rest * generate pour générer des données fictives au format attendu par votre application [#55].
  • Introduire wp rest * diff pour pouvoir comparer l’état de deux WordPress différents, à la manière de Dictator [#56].
  • Trouver une implémentation élégante des alias, afin que --http=http://daniel:[email protected] devienne @wpdev [#2039]

Et je veux aussi connaître vos idées ! Ainsi que vos commentaires, vos questions ou vos désaccords véhéments. Discutons-en sur Github.