WP REST API "rest_no_route" при попытке обновления мета-данных
Я работаю с WP REST API, и все команды GET (чтение) успешно получают нужные данные как из встроенных, так и из пользовательских типов записей (этот плагин очень помог в этом). Я также могу использовать POST для создания записей с информацией верхнего уровня для встроенных и пользовательских типов записей. Аутентификация работает нормально. Но когда я пытаюсь обновить мета-данные записи, я получаю следующий ответ:
{
"code": "rest_no_route",
"message": "Не найден маршрут, соответствующий URL и методу запроса",
"data": {
"status": 404
}
}
Я нашел упоминание в этой статье о возможной необходимости дополнительного кода для работы с мета-данными, а затем обнаружил этот плагин, который ДЕЙСТВИТЕЛЬНО решил проблему с публикацией мета-данных, но только для встроенных типов записей (не работает с моими пользовательскими типами записей, которые все еще возвращают ту же самую ошибку).
Все вышеперечисленное запутанно и усложняется, я думаю, изменяющимися возможностями и состоянием самого WP REST API.
Может кто-нибудь указать на четкую документацию по выполнению обновления мета-значений для пользовательского типа записи?
ОБНОВЛЕНИЕ:
Я только что обнаружил, что плагин rest-api-meta-endpoints, упомянутый выше, ПОЗВОЛЯЕТ записывать в CPT (пользовательские типы записей), но через /wp-json/wp/v2/posts/id/meta вместо /wp-json/wp/v2/cptname/id/meta... это ожидаемое поведение?
Тем не менее, для любых записей я могу только записывать новые данные, пока не могу понять, как обновить существующие мета-данные, есть идеи?

Вот что я узнал о WP REST API: это мешанина из недокументированного и незавершенного кода, который обещает многое, но вызывает разочарование из-за отсутствия ясности.
Тем не менее, у меня есть обходной путь, которым я поделюсь здесь, надеясь, что он будет полезен другим в подобной ситуации:
Я обнаружил, что могу обновить мета-поле, ЕСЛИ у меня есть его ID и ЕСЛИ я использую posts
в пути (даже для пользовательских типов записей). Например (предположим, ID моей записи — 1622, а ID мета-поля — 11395), этот запрос сработает:
POST https://example.com/wp-json/wp/v2/posts/1622/meta/11395?value=mykeyvalue
а следующие запросы НЕ сработают (по разным причинам):
POST https://example.com/wp-json/wp/v2/posts/1622/meta?key=mykeyname&value=mykeyvalue (добавит новое поле, но не изменит существующее)
POST https://example.com/wp-json/wp/v2/posts/1622/?key=mykeyname&value=mykeyvalue (404)
POST https://example.com/wp-json/wp/v2/my-cpt/1622/meta?key=mykeyname&value=mykeyvalue (404)
POST https://example.com/wp-json/wp/v2/my-cpt/1622/meta/11395?value=mykeyvalue (404)
Я также выяснил, что могу получить все мета-поля, выполнив такой запрос:
GET https://example.com/wp-json/wp/v2/posts/1622/meta/
Таким образом, если собрать всё вместе, я могу заставить это работать в текущем виде следующим образом:
GET https://example.com/wp-json/wp/v2/posts/1622/meta/
фильтрация полученных результатов для поиска ID нужного мета-поля
POST https://example.com/wp-json/wp/v2/posts/1622/meta/11395?value=mykeyvalue
Если у кого-то есть дополнения или идеи по другим возможным решениям, я готов выслушать. В противном случае, это мой "решение".
И обратите внимание на предварительные условия для того, чтобы это вообще заработало:
- Этот плагин должен быть настроен для отображения ваших типов записей и мета-полей.
- Этот плагин необходим для включения мета-эндпоинтов.
- Я не упомянул выше аутентификацию, так как это выходит за рамки обсуждения, но в зависимости от ваших настроек вам может потребоваться аутентификация перед использованием API (в моем случае используется OAuth и токены, которые обычно добавляются в URL).
