Вопрос или проблема
Я прочитал этот пост: Сериализованные настройки в REST API и, хотя я действительно убежден, что ответ именно то, что мне нужно, я не могу заставить его работать.
То, чего я пытаюсь достичь, это получить мои собственные настройки при вызове эндпоинта /wp-json/wp/v2/settings/.
Мои настройки зарегистрированы следующим образом:
public function __construct() {
add_action( 'init', array( $this, 'coopedia_settings_init' ) );
add_action( 'rest_api_init', array( $this, 'coopedia_settings_init' ) );
}
public function coopedia_settings_init() {
register_setting(
'coopedia_settings_group', // option_group
'coopedia_settings', // option_name
array(
'show_in_rest' => array(
'schema' => array(
'type' => 'object',
'properties' => array(
'identity_provider_uri' => array(
'type' => 'string',
),
'classifications_uri' => array(
'type' => 'string',
),
)
)
),
'sanitize_callback' => array($this, 'coopedia_settings_sanitize'),
),
);
}
Обновление и регистрация настроек на самом деле работают, они отображаются на моей странице настроек и сохраняются правильно.
Но затем, когда я вызываю эндпоинт внутри блока Gutenberg, используя следующий синтаксис:
async componentDidMount() {
console.log("fetching datatatata");
wp.api.loadPromise.then(async () => {
this.settings = new wp.api.models.Settings();
if (false === this.state.isAPILoaded) {
this.settings.fetch().then((response) => {
// Push the coopedia settings classification website in state
this.setState({
classifications_uri: response.classifications_uri,
isAPILoaded: true,
});
});
}
}
}
Вызов this.settings.fetch() выполняется (я проверил это на вкладке сети), но я получаю только стандартные:
{
"title": "coopedia-test",
"description": "Просто еще один сайт WordPress",
"url": "http://coopediatest.local",
"email": "benoit+32@******.com",
"timezone": "",
"date_format": "F j, Y",
"time_format": "g:i a",
"start_of_week": 1,
"language": "en_US",
"use_smilies": true,
"default_category": 1,
"default_post_format": "0",
"posts_per_page": 10,
"default_ping_status": "open",
"default_comment_status": "open"
}
Вот скриншот вызова сети и объект ответа из инспектора:
Что я здесь упускаю? Кстати, документация неясна в отношении возможностей расширения стандартных эндпоинтов, а также используемых объектов wp.* в новых мета-блоках Gutenberg.
У меня была похожая проблема, и я попал сюда.
Я не уверен, было ли это исправлено временем, но я попробовал этот код, и он работает как ожидалось, coopedia_settings: null присутствует в ответе fetch.
Единственный случай, который я могу представить: если класс, который вызывает rest_api_init, инициализируется в действии, которое происходит после вызова rest_api_loaded, он зарегистрируется для страницы настроек, но не зарегистрируется для API.
В моем случае создание класса прямо в инициализации плагина работает как ожидалось.
Ответ или решение
Конечно, давайте разберемся подробно с вашей задачей. Из вашего описания проблемы видно, что вы хотите получить доступ к пользовательским настройкам через REST API на WordPress, используя конечную точку /wp-json/wp/v2/settings/. Однако вы сталкиваетесь с тем, что получаете только стандартные настройки сайта.
Проблема
Основная проблема здесь заключается в том, что настройки, которые вы зарегистрировали с помощью функции register_setting, не добавляются в ответ вашего REST API. Это может быть связано с несколькими факторами:
-
Неправильное инициирование хука
rest_api_init: Если ваш класс или функции, которые регистрируют настройки, вызываются после момента, когда загружается REST API, они могут не быть зарегистрированы должным образом. -
Неправильный формат схемы: Важно убедиться, что ваша схема в параметре
show_in_restсоответствует всем требованиям WordPress для регистрации REST API полей.
Решение
Теперь давайте посмотрим, как вы можете решить эту проблему:
1. Правильная регистрация на хуке rest_api_init:
Убедитесь, что ваша функция coopedia_settings_init правильно регистрируется с помощью хука rest_api_init. Это критично для того, чтобы ваша настройка отображалась в API. Вот небольшой пример, как можно это сделать:
add_action('rest_api_init', function() {
register_setting('coopedia_settings_group', 'coopedia_settings', array(
'show_in_rest' => array(
'schema' => array(
'type' => 'object',
'properties' => array(
'identity_provider_uri' => array(
'type' => 'string',
),
'classifications_uri' => array(
'type' => 'string',
),
),
),
),
'sanitize_callback' => 'sanitize_callback_function',
));
});2. Проверка схемы: Убедитесь, что схема и структура данных соответствует требуемой для REST API формату. Это важно для правильной работы сериализации данных в API.
3. Инициализация класса: Убедитесь, что ваш класс инициализируется на этапе загрузки плагина, а не после загрузки всех API. Это может выглядеть как:
add_action('plugins_loaded', function() {
$your_class_instance = new Your_Class_Name();
});4. Проверка на JavaScript стороне: Убедитесь, что ваш front-end код корректно обрабатывает данные. Из кода видно, что вы используете модель wp.api.models.Settings, но для работы с пользовательскими настройками, возможно, вам потребуется самостоятельно писать запросы для получения специфичных данных.
Заключение
Проверьте каждую из перечисленных выше рекомендаций и убедитесь, что они соответствуют вашему общему коду и логике работы. Если проблема сохраняется, рассмотрите возможность проверки очередности загрузки вашего кода относительно остального плагина и системы, чтобы убедиться, что настройки зарегистрированы до вызова REST API.