DocsWP — WordPress Help

RESTful WP-CLI – Над чем я работал

Позвольте сказать прямо — четверг, 4 февраля, был чертовски деморализующим. В январе я потратил огромное количество времени на WP REST APIREST API REST API — это сокращение от RESTful Application Program Interface (API), использующего HTTP-запросы для получения, изменения, создания и удаления данных. Именно так внешняя часть приложения (например, «телефонное приложение» или «веб-сайт») может взаимодействовать с хранилищем данных (например, «базой данных» или «файловой системой»)
https://developer.wordpress.org/rest-api/, готовясь к тому, что я хотел делать в командной строке, и на этой встрече был уничтожен значительный импульс, вдохновение и в целом позитивный настрой. Поэтому большую часть февраля и марта я работал над функциями WP-CLIWP-CLI WP-CLI — это интерфейс командной строки для WordPress, предназначенный для программного выполнения административных задач и задач разработки. Страница проекта: http://wp-cli.org/ https://make.wordpress.org/cli/, не связанных с WP REST API (например, управлением пакетами).

Но я снова в строю. Поскольку я уже на две трети завершил одно из тех продвинутых приложений WordPress на основе WP REST API и ReactReact React — это библиотека JavaScript, которая упрощает проектирование, создание и поддержку пользовательских интерфейсов без состояния и с состоянием.
https://reactjs.org, я сталкиваюсь с десятками способов сделать WordPress более эффективным. И, конечно же, это означает работу в командной строке.

Прежде чем продолжить: большинство, если не все, функций RESTful WP-CLI потребовали внутренних изменений в WP-CLI. Чтобы опробовать эту новую функциональность локально, вам понадобится выполнить wp cli update --nightly. После этого можно выполнить wp package install danielbachhuber/wp-rest-cli, чтобы установить последнюю версию.

Используйте --debug и --debug=rest, чтобы профилировать REST-эндпоинты

REST API — это прежде всего скорость. Миллисекунды имеют значение, и каждая сэкономленная миллисекунда реально влияет на пользовательский опыт.

Чтобы намного упростить понимание того, сколько запросов выполняет ваш эндпоинт и сколько времени они занимают, я добавил лёгкое профилирование в RESTful WP-CLI.

Используйте --debug, чтобы получить сводку запросов для любой команды.

$ 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!"} |
+----+-----------------------------+

Используйте --debug=rest, чтобы получить полный список выполненных запросов.

$ 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!"} |
+----+-----------------------------+

Профилирование работает для любой операции 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.

Надеюсь, эта функция станет незаменимой частью процесса разработки ваших REST-эндпоинтов — для меня она уже стала такой. Оставьте отзыв в соответствующей проблеме на Github.

Используйте wp rest * edit, чтобы редактировать ресурс в системном редакторе

Большинство людей, вероятно, не знают, что с помощью wp post edit <id> можно редактировать содержимое записи в системном редакторе (например, vim). Теперь с помощью wp rest * edit можно редактировать любой REST-ресурс в системном редакторе.

$ wp rest post edit 3 --user=daniel

При выполнении wp rest * edit RESTful WP-CLI получает ресурс, преобразует его в документ YAML и открывает его в системном редакторе:

---
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: [ ]

Если вы измените любые поля, команда отправит их обратно в WordPress (через WP REST API) для обновления.

В установках WordPress, поддерживающих Basic Auth, редактирование также работает через HTTPHTTP HTTP — это сокращение от Hyper Text Transfer Protocol (протокол передачи гипертекста). HTTP — базовый протокол Всемирной паутины; он определяет формат и передачу сообщений, а также действия, которые веб-серверы и браузеры должны выполнять в ответ на различные команды.:

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

И вуаля.

Присоединяйтесь!

Мне хотелось бы узнать ваше мнение о десятках идей, которые у меня есть для более RESTful WP-CLI:

  • Отображать справочную документацию в таких форматах, как Blueprint и Swagger для APIAPI API, или программный интерфейс приложения, — это программный посредник, позволяющий программам взаимодействовать друг с другом и обмениваться данными ограниченными и чётко определёнными способами. [#36]
  • Добавить wp rest * generate для создания тестовых данных в формате, ожидаемом вашим приложением [#55].
  • Добавить wp rest * diff, чтобы сравнивать состояние двух разных установок WordPress, по аналогии с Dictator [#56].
  • Разработать элегантную реализацию псевдонимов, чтобы --http=http://daniel:[email protected] превращалось в @wpdev [#2039]

И я тоже хочу услышать ваши идеи! А также любые отзывы, вопросы или яростные возражения. Давайте обсудим это на Github.